假设 AI 编程 Agent 很快生成一份大 PR，团队却需要更久来审查、返工和排查问题，编码提速是否真的提高了交付效率？关键不是“它写得快不快”，而是一个被验收的需求，最终耗费了多少团队时间。本文给出一套能在自己的项目里复测的比较方法，不引用未经验证的提效百分比。
适合读者：已经使用 Git、Pull Request 和自动化测试，正考虑让 AI Agent 参与日常开发的工程师或团队负责人。只需具备基础 Python 知识即可运行文中的计算示例。
Why：为什么“产出更多代码”可能让交付变慢
代码量是输入，不是结果。一个 Agent 生成的改动如果需要人逐行辨认意图、补测试、修回归，节省的编码时间会转移到审查与返工。就像打字速度快不等于写完一份能签字的合同，真正的交付要经过验收。
先把结果定义清楚：以“通过既定验收条件的任务数 / 编码、审查和返工的总人时”作为主指标，同时记录发布后的缺陷。缺陷是护栏：不能靠放宽质量要求换取表面速度。
What：把 Agent 纳入完整交付链路
同一类任务与验收标准
↓
人工组 / Agent 辅助组
↓
实现 → 测试 → PR 审查 → 返工 → 发布
↓
验收结果 + 总人时 + 发布后缺陷每个任务都记录人参与编码或提示词协作的时间、人工审查时间、返工时间、是否验收，以及发布后是否出现关联缺陷。Agent 独立运行的等待时间和计算费用另列；它们影响交付周期与成本，但不等于人时。模型版本、提示词、工具权限和测试环境也要记录，否则下次无法解释结果变化。对照任务应尽量在规模与风险上接近；不要拿简单文案改动与数据库迁移比较。
How：用一个最小实验计算真实成本
先选一组低风险、验收条件明确的任务。下面是演示数据，不是任何团队的实测结果：Agent 组编码更快，但审查与返工增加。把数组替换为你们的任务记录即可复算。
from collections import defaultdict
# 模式、验收任务数、人工编码/协作分钟、审查分钟、返工分钟、关联缺陷数
rows = [
("manual", 1, 80, 20, 10, 0),
("agent", 1, 30, 45, 60, 1),
]
totals = defaultdict(lambda: [0, 0, 0])
for mode, accepted, build, review, rework, defects in rows:
totals[mode][0] += accepted
totals[mode][1] += build + review + rework
totals[mode][2] += defects
for mode, (accepted, minutes, defects) in totals.items():
rate = accepted / (minutes / 60) if minutes else 0
print(f"{mode}: {rate:.2f} 个验收任务/人时，关联缺陷 {defects}")保存为 compare.py，运行 python3 compare.py。演示输出约为：人工组每人时 0.55 个任务、Agent 组 0.44 个任务。这个数字只说明计算方法；真实结论取决于足够多的可比任务及缺陷观察窗口。
- 先写验收标准：任务完成的定义包含功能、测试和代码审查，不以“生成了 PR”作为完成。
- 记录全部人工时间：包括提示词调整、审查、修复和发布协助。Agent 的运行成本另列，不与人时混淆。
- 固定试点条件：记录模型、工具版本、权限和任务类型，避免比较期间改变多项变量。
- 追踪质量：给发布后缺陷关联任务 ID；尚未经过观察窗口的任务不要算作“零缺陷”。
避坑与延伸
只统计合并的 PR，会漏掉未被采纳的产出；只统计编码时间，会把成本藏进审查队列；只看平均值，会掩盖少量高风险返工。建议按任务类型和风险分层，再看中位数与异常样本。先从一个流程试点，确认指标可信后再扩大使用范围。
继续阅读：DORA 的软件交付研究，以及 GitHub Pull Request 文档。