| English | 中文 |
团队开始使用 Agent 后，PR 数量和 AI 代码占比可能很快上升，但这两个数字只能说明活动发生了变化。它们不能单独证明任务交付更快、审查成本更低或线上质量更好。
本文给出一套短期试验可用的测量口径。下面五项是本文的本地测量定义，不是 DORA 或 SPACE 的官方指标。DORA 将软件交付表现放在吞吐量与不稳定性中观察，并提醒团队结合应用上下文、同时使用多个指标；SPACE 论文也明确指出，开发者生产力不能由单个指标或维度衡量。
在试验开始前写下这些规则，结束后不要按结果改口径：
In progress 的任务组成固定队列，统计到 4 月 30 日；合入后问题再观察 7 天，所以数据截点延长到 5 月 7 日。none、assist、agent-led。人和 Agent 混合完成的任务保留为混合归因，不写成 Agent 独立产出。样本不足而合并分组时，要披露合并规则。避免用这些指标做个人排名。排名会鼓励拆小 PR、少报返工和回避高风险任务，也会把协作结果错误归到个人。
定义：窗口内达到约定验收状态的任务数 ÷ 固定队列中的任务总数。
开放中的任务留在分母里；已关闭但没有交付的任务也不能静默删除。若业务取消与实现无关，可以按预先约定排除，同时单列数量和原因。
限制：验收标准过松会抬高结果；不同复杂度的任务不能直接混在一起比较。
定义：每个已完成任务从 work_started_at 到 accepted_at 的时长，报告中位数，并在旁边报告窗口完成率。
未完成任务没有完整时长，不用窗口结束时间伪造完成时间。可以将它们标为右删失，或只在完成率中体现。若团队只有合入数据，就把终点改为 merged_at，并将指标命名为“合入前置时间”，避免把合入当成生产验收。
限制：只看已完成任务会产生幸存者偏差；等待外部依赖的时间是否扣除，必须提前统一。
等待时间定义：先按 PR 计算。起点是 PR 首次进入有效可审查区间的时间：以非草稿状态创建时取 PR 的 created_at；由草稿转为可审查时，取 REST timeline 中 ready_for_review 事件的 created_at。若首个人工 review 前出现 convert_to_draft 事件，丢弃这段区间，从下一次 ready_for_review 重算。终点是该区间内首个实质性人工 review 的 submitted_at；早于起点的 review 作为数据异常单列。
一个任务有多个 PR 时，先取各有效 PR 等待时间的中位数作为任务值，再报告队列中任务值的中位数。没有实质性人工 review 的 PR 无法得到等待时间；报告缺失 PR 和受影响任务数，不把它们静默移出结果。
实际投入定义：reviewer 在该任务所有 PR 的各次审查会话中记录的活跃分钟数之和。GitHub 时间戳可以重建等待，不能推出 reviewer 实际看了多久。报告有投入记录的任务中位数和记录覆盖率。等待下降而投入上升，表示排队改善了，但审查成本可能增加。
限制：机器人 review 不计入实质性人工 review；仅写 “LGTM” 的人工反馈是否算实质性，需要预先定义。活跃分钟通常需要抽样自报或已有工时记录。
定义：首次实质性人工 review 后，至少有一次作者代码更新明确关联到 review 反馈的已审查合入任务数 ÷ 已审查合入任务总数。关联可以来自 review thread、提交说明或团队已有的变更记录。
这项指标回答“多少任务需要因 review 再改”，不表示返工规模。审查后新增的需求范围单列，不能计为 review 返工；无法分类的代码更新也要报告数量。补提交、强制更新分支或多个 PR 对应一个任务时，需要按任务 ID 合并事件。关联依赖记录纪律，因此它仍是返工的代理指标。
定义：任务最终 merged_at 后 7 天内关联到 revert、hotfix 或生产事故的任务数 ÷ 已经拥有完整 7 天合入后观察期的任务数。
观察期不足的任务从这个分母中排除，并报告排除数量。关联规则应依赖任务 ID、PR 链接、部署版本或事故记录，不能仅凭提交标题猜测。
限制：七天之外暴露的问题不会被计入；合入后延迟发布会缩短真实暴露时间。修复率也受发布策略、监控能力和事故记录质量影响。
下面数据仅演示计算，不代表任何团队的生产结果。队列包含同一代码库、相近复杂度的任务；每个任务只有一个 PR，所有已验收任务均已合入并接受过实质性人工 review，表中的返工均已关联到 review 反馈。A5 在窗口结束时仍开放且尚无人工 review。所有已合入任务都有完整 7 天合入后观察期。
| 队列 | 任务 | 状态 | 前置时间（小时） | 首审等待（小时） | review 投入（分钟） | 合入前返工 | 7 天内修复 |
|---|---|---|---|---|---|---|---|
| 未使用 Agent | N1 | 已验收 | 40 | 8 | 30 | 否 | 否 |
| 未使用 Agent | N2 | 已验收 | 48 | 12 | 45 | 是 | 否 |
| 未使用 Agent | N3 | 已验收 | 56 | 20 | 30 | 是 | 是 |
| 未使用 Agent | N4 | 已验收 | 72 | 24 | 60 | 是 | 否 |
| Agent 辅助 | A1 | 已验收 | 24 | 6 | 45 | 是 | 是 |
| Agent 辅助 | A2 | 已验收 | 30 | 10 | 60 | 是 | 否 |
| Agent 辅助 | A3 | 已验收 | 36 | 14 | 60 | 是 | 是 |
| Agent 辅助 | A4 | 已验收 | 42 | 18 | 75 | 否 | 否 |
| Agent 辅助 | A5 | 开放 | - | - | - | - | - |
复算结果：
4 / 4 = 100%；Agent 辅助为 4 / 5 = 80%。(48 + 56) / 2 = 52 小时；Agent 辅助为 (30 + 36) / 2 = 33 小时。(12 + 20) / 2 = 16 小时；Agent 辅助为 (10 + 14) / 2 = 12 小时。(30 + 45) / 2 = 37.5 分钟；Agent 辅助为 (60 + 60) / 2 = 60 分钟。4 / 4 = 100%；Agent 辅助都是 4 / 5 = 80%，缺失项都是仍开放的 A5。3 / 4 = 75%。7 天内修复率分别是 1 / 4 = 25% 和 2 / 4 = 50%。这组数据只支持一个描述：Agent 辅助组中已完成任务更快、首次 review 等待更短，同时 reviewer 投入更高、完成率更低、短期修复更多。样本太小，而且仍可能有任务复杂度、reviewer 安排等混杂因素，不能据此断言 Agent 提高或降低了生产力。
无需先建仪表盘或新采集系统。任务系统通常提供开始、验收、复杂度和工作类型；GitHub 的 Pull requests REST API、Pull request reviews REST API 与 Timeline events REST API可以提供 PR、合入、review 和可审查状态事件。Issue event types说明 ready_for_review、convert_to_draft 的事件名和 created_at 字段。部署与事故系统负责验收版本、hotfix 和事故关联。先人工抽取一个固定队列，保留任务 ID 到 PR、部署和事故的映射，再判断自动化是否值得投入。