关于 dev-ai-coding-metrics
面向评估 AI 编码助手和 Agent 的团队，提供区分两类工作流的指标、研究设计、隐私规则和报告模板，支持围绕决策开展测量。
主要功能
- 01区分助手与 Agent 指标
- 02制定面向决策的计分卡
- 03规划对照或描述性研究
- 04纳入质量、成本与体验
- 05保护个人使用数据
适用场景
- 01评估 AI 编码工具的推广
- 02比较助手与 Agent 工作流
- 03估算续订决策的 ROI
- 04设计 Agent 评估试点
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/dev-ai-coding-metrics确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
learnings.consolidated.mdlearnings.mdagents/openai.yamlassets/adoption-survey-template.mdexecutive-report-template.mdexperiment-design-template.mdmetric-dashboard-template.mdroi-calculator-template.mddata/sample-ai-metrics.jsonsources.jsonreferences/adoption-metrics.mdagent-execution-metrics.mdbenchmarking-methodology.mddeveloper-experience-metrics.mdevidence-update.mdproductivity-metrics.mdquality-metrics.mdroi-framework.mdtheory-of-constraints-applied.mdscripts/extract_github_events.pyREADME.mdroi_calculator.pytest_input_contracts.pytest_roi_calculator.py详细介绍
AI 编码指标
衡量编码助手和编码 Agent，避免将结果简化成虚荣指标或混合成一个总分。
关键区别在于模式：助手通过行内建议或聊天提供帮助；Agent 执行多步骤工作，需要在任务层面进行衡量。不要把它们当作同一类来衡量。
何时使用此技能
| 触发情形 | 示例 |
|---|---|
| 设计试点或推广评估表 | “我们要向 200 名工程师推广 Copilot——应该衡量什么？” |
| 诊断使用量上升、成果持平 | “席位利用率达到 80%，但 PR 吞吐量没有变化” |
| 比较助手与 Agent 工作流 | “我们应该分别进行埋点吗？” |
| 构建 ROI 模型或领导层报告 | “财务部门希望在 Q3 前决定是否续约” |
| 设计优于供应商基准测试的实验 | “我们无法相信供应商的数据——如何开展自己的研究？” |
默认原则
| 规则 | 理由 |
|---|---|
| 从决策出发，而不是从现有遥测数据出发 | 避免产生“只衡量容易衡量之事”的偏差 |
| 分开统计助手和 Agent 的漏斗 | 混在一起会掩盖究竟是哪种工作流带来了成效 |
| 每项速度指标都搭配质量和体验指标 | 单看速度会产生误导 |
| 按团队汇总 | 个人仪表板会变成监控；参见个人数据政策 |
| 将基准测试视为能力信号，而非业务 KPI | 基准测试中的差距不等于生产环境中的差距 |
工作流
- 明确决策。
- 选择项目模式：助手、Agent 或混合模式。
- 制定最小可行评估表。
- 选择研究设计。
- 产出一项交付成果。
快速参考
从决策到交付成果：
| 决策 | 默认输出 |
|---|---|
| 购买、续订或停用某个工具 | ROI 模型及高管报告 |
| 提高采用率 | 采用指标及调查 |
| 证明交付影响 | 生产力指标及实验计划 |
| 检查质量是否发生偏移 | 质量指标及仪表板 |
| 了解信任或摩擦 | 开发者体验指标及调查 |
| 评估编码 Agent | Agent 执行指标及实验计划 |
项目模式
| 模式 | 分析单位 | 主要侧重点 |
|---|---|---|
| 助手 | 开发者日、团队周、代码库月 | 采用、交付、质量、体验 |
| Agent | 任务、PR、工作流运行 | 任务成功率、合并、回滚、审查负担、每项已接受变更的成本 |
| 混合 | 团队周及任务级样本 | 先分别分析两种漏斗，再合并结果 |
指标类别
使用能够回答决策问题的最精简评估表：
| 类别 | 说明 |
|---|---|
| 采用 | 使用是否真实且持续 |
| 交付 | AI 实际参与流程的环节中，软件交付是否更快 |
| 质量 | 速度提升是否被缺陷、返工、审查负担或扩展稳健性下降所抵消 |
| 经济性 | 价值是否足以抵消工具和运营成本 |
| 体验 | 开发者是否信任该工具并愿意继续使用 |
| Agent 执行 | 自主工作流能否在生产环境中成功运行，而不只是在演示中奏效 |
研究设计默认值
规划默认值：干预前数据取 8 周。这是本地规划下限，并非研究得出的充分性阈值：在开展因果试点前，应根据基线自身的周间方差和团队周数，计算最小可检测效应（MDE）。如果该 MDE 大于你愿意据此采取行动的任何效应，就不要开展因果研究；应报告标注为方向性的描述性评分卡。
| 情况 | 设计 |
|---|---|
| 新试点，没有对照组 | 以未采用或较晚采用的团队为对照，采用双重差分；或者使用具有 ≥8 个干预前时点的中断时间序列；单一的前后变化只能作为方向性结果（它会吸收冻结期、重组和招聘潮的影响）。当团队在不同时间采用时，普通的双向固定效应 DiD 会产生偏差；应使用交错处理估计量，并在将平坦的前趋势视为证据前，检查前趋势检验的效能（因果推断基础） |
| 有足够的可比较团队 | 匹配 A/B 或分层分配 |
| 团队不愿永久禁止使用工具 | 交叉设计 |
| 针对某一任务类别改变 Agent 工作流 | 任务级影子对比或评审者盲评 |
| 管理层希望快速得到答案 | 提供明确注明局限的平衡评分卡，而非因果结论 |
队列与分母约定
在查看结果前，固定测量人群。记录每项指标的符合条件人群、分配规则、实际暴露情况、观察窗口和认可结果。并列报告 eligible、assigned、exposed 和 observed 的数量；绝不能悄悄用活跃用户、已完成任务或已合并 PR 替换分配队列。仅使用幸存者作为分母，会让采用率和成功率看起来更高，而设置失败、放弃的 Agent 运行或未合并的变更恰恰可能是问题所在。
对于不完整的观测，注明原因（not_started、abandoned、still_open、telemetry_missing 或 excluded_by_rule），并将其保留在漏斗中。在结果观察窗口结束前，应将仍未关闭的工作视为右删失，而非失败。遥测数据不完善时，报告可以是方向性的，但必须说明每个百分比使用的分母，以及缺失案例可能如何改变决策。
导出 GitHub PR 时，应在按开启时间划分的队列中保留仍开启、已关闭但未合并以及已合并的结果。PR 导出无法找回那些从未产生 PR 的已分配任务；报告 Agent 成功率前，应将其与任务登记表关联。根据《个人数据政策》，应将作者级 CSV 视为受限源数据。
测量检查清单
发布任何 AI 编码报告前，请使用以下清单：
- 已建立基线（干预前 ≥8 周）
- 分别追踪助手和 Agent 漏斗
- 每项速度指标至少搭配一项质量指标
- 已说明样本量、置信水平和研究设计
- 已记录混杂因素（团队变动、发布压力、政策变更）
- 已将供应商证据标记为供应商证据
- 在使用趋于稳定后测量（而非第 1 周的新鲜感阶段）
- ROI 模型纳入评审负担和返工成本
- 针对可编辑的 Agent，测量其在不断演进的规格检查点上的表现，包括后期检查点的成本和质量变化斜率
- 按团队汇总（不提供管理者可见的个人仪表板）
证据规则
研究中得出的长期适用规则；有日期的研究、数据和注意事项见 references/evidence-update.md：
- AI 会放大现有系统的优势和弱点；它不是普适的加速器。
- 感知到的提升和测量到的提升可能不同；绝不要将自我报告的提升说成测量得出的影响。
- 吞吐量提升可能会将负担转移到评审和事故处理上；任何吞吐量提升都应搭配评审负担和事故指标。
反投机核对清单
出现以下任一情况时，请拒绝该评分卡或报告：
- 将使用情况、速度、主观感受和质量混为一谈，得出单一的 AI 生产力分数
- 将席位激活量或提示词量作为交付影响的依据
- 未控制技术栈、任务组合、人员配置或发布压力，却进行跨团队比较
- 测量周期少于 8 周，或包含第 1 周的新鲜感窗口
- 将供应商基准测试作为生产环境 ROI 的证据
- ROI 模型未计入审查负担
- 管理者可以看到个人层面的 AI 使用情况
- 将前后变化趋势表述为因果关系，却未采用受控设计
- 将 SlopCodeBench 的平均值或趋势信号用作组织目标或因果 ROI 证据
个人数据政策
个人层面数据统一遵循此政策，并与指向本页的 dev-contribution-quality-analysis 共享：
- 默认采用团队层级。AI 使用情况和 AI 辅助指标绝不按个人展示给管理者，也绝不用于绩效、晋升或人员配置决策。
- 只有在个人主动选择的自我审查或辅导场景中，才允许输出个人层面的结果；应先展示给本人，并提供抽样证据和更正途径。
- 关于个人的问题（“谁善于使用 AI”“每位工程师的质量”）应在这些限制下转交给
dev-contribution-quality-analysis；团队层面的 AI 工具影响仍由此处负责。
导航
参考资料
- references/adoption-metrics.md — 助手和 Agent 采用漏斗、指标定义、停滞模式、隐私规则
- references/productivity-metrics.md — 将 DORA 和 SPACE 应用于 AI 工作流、交付栈分解、混杂因素管理
- references/quality-metrics.md — 缺陷、复杂度、测试、安全和技术债务指标及其目标和警报阈值
- references/roi-framework.md — 完整成本模型（包括审查负担）、收益模型、场景规划、执行报告结构
- references/developer-experience-metrics.md — 满意度调查、认知负荷、摩擦指标、信任校准、DX 反模式
- references/agent-execution-metrics.md — Agent 漏斗、核心指标、审查者负担、用于试点／扩展／执行决策的评分卡
- references/benchmarking-methodology.md — A/B、前后对比、交叉、影子设计；统计严谨性；混杂因素管理
- references/theory-of-constraints-applied.md — 在埋点前识别瓶颈、用于 ROI 的吞吐量核算、用于保护审查队列的 DBR、用于解决推广停滞的 CRT、用于化解采用与质量矛盾的蒸发云
- references/evidence-update.md — 带有注意事项的带日期引文：METR RCT（2025）、METR 2026 更新（选择偏差注意事项）、DORA 2025 AI 报告、DORA 2026 ROI 报告、DX Core 4、Faros 2026 遥测、SlopCodeBench
资源与数据
- assets/metric-dashboard-template.md
- assets/adoption-survey-template.md
- assets/roi-calculator-template.md
- assets/executive-report-template.md
- assets/experiment-design-template.md
- data/sources.json
- data/sample-ai-metrics.json
脚本
- scripts/roi_calculator.py — 计算产能价值场景时，请提供观察周期和两项测得的负担项；零成本 ROI 未定义。各类别的评级区间仅是示例性的本地规则，并非经过验证的构念。
- scripts/extract_github_events.py — 收集 PR 结果队列或提交遥测时；进行实时导出前，请查阅 GitHub 端点权限和速率限制指南。
- scripts/README.md
交叉引用
- ../dev-contribution-quality-analysis/SKILL.md — 根据提交和 PR 历史评估个人或团队贡献质量，并遵循个人数据政策
- ../dev-context-engineering/SKILL.md
- ../ai-agents/SKILL.md
- ../qa-observability/SKILL.md
- ../product-management/SKILL.md
经验循环
如果以往的决策或陷阱与当前情况有关，请查阅 learnings.consolidated.md（如果存在）；仅在需要了解历史或将其作为可用的备用资料时，才使用 learnings.md。否则跳过这两个文件。
应用后，如果遇到值得记住的模式、值得避免的错误或令你意外的领域事实，请通过 agents-skills-feedback-loop/scripts/append_learning.py 在 learnings.md 中追加一条带日期的条目。不要修改 SKILL.md 本身。