AI Agent 的Human-in-the-Loop工程实践：何时停下来问人，如何设计ApprovalFlow
三个月前，我和另一位 Tech Lead 在某次线下聚会上聊起各自团队推进 AI Coding 的情况。他们已经全员上线 Cursor 超过两个月，每周 AI 辅助的代码接受率（Acceptance Rate）稳定在 35% 左右，看起来很漂亮。
“那 PR 质量呢？” 我问。
他沉默了几秒：“CR 打回率好像高了……但我们觉得是因为开发速度快了，提交频率高了，总量稀释了。”
这个回答让我想起我们团队三个月前走过的同一段弯路——只看 AI 生成量，忽略了下游所有指标。等我们开始补全仪表盘，才发现速度数据背后藏着多少噪音。
一个指标的崩塌：LOC 陷阱
AI Coding 最容易被量化的指标是代码行数（Lines of Code）。工具内置的接受量统计天然会让你看到这个数字在增长。但 LOC 作为生产力指标有一个根本性的问题：它衡量的是输出体积，不是交付价值。
这个问题在 AI Coding 场景下被放大了。AI 生成的代码有几个典型特征：
- 防御性膨胀：AI 倾向于生成完整的错误处理分支，即便许多分支在业务场景下永远不会触发
- 注释增量：AI 生成的代码往往带有大量注释，LOC 统计把注释也算进去
- 冗余覆盖：AI 不善于利用项目内已有的工具函数，更倾向重新实现
我们团队在 2026 年 3 月到 4 月的两个月内，代码提交量上涨了约 60%。但当我们剔除测试文件的 LOC 增量，再剔除 AI 生成代码中被 reviewer 要求删除的冗余部分，净有效代码的增量只有 20% 左右。
这还不是最糟的。真正的问题出现在两个月后的维护窗口：那段时间进来的 AI 代码修改密度（churn rate）明显高于同期人工代码。
为什么要建仪表盘，而不是几个单独指标
单独看任何一个指标都可以被"玩弄"或误读：
- 接受率高 → 可能只是 reviewer 过于宽松，或 AI 生成的是低风险样板代码
- CR 通过率高 → 可能是 reviewer 压力大，走过场
- 部署频率高 → 可能是把一个 PR 拆成多个小 PR
指标之间的关系才是信号。仪表盘的价值在于让你看到多个维度的横截面：当速度指标在上升、而质量和返工指标同步恶化时，你才能说"这是债务转移，不是提效"。
下面我给出五个维度的指标体系，这是我们团队经过约四个月实践后沉淀下来的版本。
AI Coding 质量仪表盘：五维指标体系
维度一：速度指标
速度指标是最容易采集也最容易误读的一类。你需要的不是"AI 帮我写了多少行"，而是有效交付速度。
| 指标 | 定义 | 采集方式 | 误读风险 |
|---|---|---|---|
| Cycle Time（需求→上线） | 从需求进入开发到部署生产的时间 | 线性：Jira issue created → production deploy timestamp | 不能只看均值，要看 P90。AI 加速了简单任务，但复杂任务如果拖长，均值会掩盖真实情况 |
| PR Lead Time | PR 首次提交→合并入主干的时长 | GitHub/GitLab API：merged_at - created_at | 缩短可能是 reviewer 标准降低，不一定是代码质量上升 |
| AI Acceptance Rate（接受率） | AI 生成的代码中被开发者采纳的比例 | Cursor/Copilot 原生统计面板 | 接受率高 ≠ 代码好。开发者在赶 deadline 时倾向于全部接受，接受率反映压力状态，不只是 AI 质量 |
| Commit Frequency | 单位时间内的有效提交数 | git log 分析；去除 merge commit | 提交频率上升可以是好信号（小步快跑），也可以是坏信号（频繁返工修补） |
关键误读防范：Cycle Time 缩短是你最想要的信号，但它受需求大小影响极大。建议按任务复杂度分桶（simple / medium / complex），分别跟踪趋势，而不是混在一起看。
维度二：质量指标
质量指标回答一个问题：AI 写出来的代码，上线之后表现如何？
| 指标 | 定义 | 采集方式 | 误读风险 |
|---|---|---|---|
| Defect Escape Rate | 上线后 7 天内发现的 bug 数 / 总上线功能数 | 生产 incident tracking（Jira Bug / Sentry）关联 deployment tag | AI 密集期如果 Defect Escape Rate 上升，是强烈的质量信号；但这个数据滞后 7 天，不适合实时决策 |
| Test Coverage Delta | AI 辅助代码的单测行覆盖率 vs 全量代码基线 | CI pipeline：lcov/coverage.py，按 blame 分段 | AI 往往会帮你生成测试文件，让覆盖率数字好看，但测试质量（assertion 密度、边界覆盖）不在 coverage 数里 |
| Build Failure Rate（构建失败率） | CI/CD pipeline 中首次运行失败的 PR 比例 | GitHub Actions / GitLab CI job status | AI 生成的代码偶尔会引入不兼容依赖或错误的 import，这个指标能提前捕捉 |
| Complexity Growth（圈复杂度增量） | 每次合并的平均圈复杂度增量 | lizard/radon，集成到 CI，输出 diff 对比 | AI 特别擅长生成扁平代码，但有时会把多个 case 平铺成巨型 if-else，圈复杂度会悄悄攀升 |
一个真实数据点：我们在 2026 年 4 月测量了 6 周的 AI 辅助 PR 和纯人工 PR 的 Defect Escape Rate。AI 辅助 PR 的 7 天 Defect Escape Rate 是纯人工 PR 的 1.6 倍。但当我们按任务类型拆分，发现问题集中在"业务逻辑重构"类任务，AI 在这类任务上对上下文理解不足。简单的 CRUD 和工具函数类任务，AI 辅助 PR 的质量和人工相当。
这不是"AI 质量差"，而是"在错误的任务类型上用了 AI"。
维度三：Review 指标
Code Review 是 AI Coding 影响最深的环节之一——不是因为 AI 让 Review 更难，而是因为 Review 流程本身会随着提交量增加而崩溃。
| 指标 | 定义 | 采集方式 | 误读风险 |
|---|---|---|---|
| Review Turnaround Time | PR 首次提交到首条 review comment 的时长 | GitHub/GitLab PR API：reviews[0].created_at - pr.created_at | Turnaround Time 变长说明 reviewer 积压；变短可能说明 reviewer 走过场而不是效率提升 |
| Comment Density（评论密度） | 每 100 行代码的有效 review comment 数（非 nit） | PR comment 数 / (additions + deletions) × 100；过滤 LGTM/nitpick | AI 时代 PR size 膨胀，comment density 下降可能不是代码变好了，而是 reviewer 审查面积跟不上 |
| CR Rejection Rate（打回率） | 被 Request Changes 的 PR 占比 | GitHub API：review.state == 'CHANGES_REQUESTED'/ 总 PR 数 | 打回率上升是质量恶化的强信号；打回率下降需要结合 Defect Escape Rate 验证，不能单独庆祝 |
| Reviewer Load（评审人负载） | 每人每周被 assign 的 PR 数 | GitHub/GitLab assignment 记录 | 负载超过 8–10 个 PR/人/周时，Review 质量开始显著下滑；AI 扩张期要主动监控这个数字 |
一个反直觉的发现：AI Coding 规模化之后，我们团队的 CR Rejection Rate 在第一个月确实下降了——不是因为代码变好了，而是因为 reviewer 来不及深审，开始走形式。我们是在两个月后看到 Defect Escape Rate 上升才回过头来排查的。
建议：把 Reviewer Load 设置为告警指标。超过阈值时自动提醒 Engineering Manager，防止 Review 沦为橡皮图章。
维度四：返工指标
返工（Rework）是衡量 AI Coding 债务转移最直接的指标。如果代码写出来之后频繁被修改，无论初始速度多快，总体成本都是虚高的。
| 指标 | 定义 | 采集方式 | 误读风险 |
|---|---|---|---|
| Code Churn Rate（代码扰动率） | 新写的代码在 N 天内被再次修改的比例 | git blame + git log 组合：统计行级 author→rewrite 链条；工具：git-churn脚本或code-churnGitHub Action | Churn 高不一定是坏事：新功能迭代期正常；问题是 AI 代码的 churn 系统性高于人工代码才说明质量问题 |
| Hotfix Frequency | 上线后 72 小时内的紧急 fix 提交数 / 月 | Git taghotfix/*统计；或 incident severity = P0/P1 且 commit 在 deploy 后 72h 内 | 频率上升是最直接的质量危机信号；AI 密集期要提高基线阈值期望，但不能无限上调 |
| PR Reopen Rate | 合并后又被重新打开（关联新 issue）的 PR 比例 | GitHub/GitLab PR link 分析；closed_as_reopenedevent | 这个指标在大多数团队被忽视，但它是"Review 时漏掉的问题上线后被发现"的代理指标 |
| AI Assist Rework Ratio | AI 辅助写的代码被返工的比例 vs 人工代码 | 需要在 commit message 或 PR label 中标记 AI 辅助，再与 churn 数据交叉 | 这个指标需要规范的标注才能采集，是成本最高的指标，但也是最有说服力的 |
采集 AI Assist Rework Ratio 的实际方案：在 CI pipeline 中加一个 pre-commit hook，当检测到cursor/或.copilot相关的 context 文件时，自动给 PR 打 labelai-assisted。这样不需要依赖开发者人工标记，数据相对可靠。
维度五：技术债指标
技术债是 AI Coding 最难量化、但最需要主动管理的维度。AI 生成的代码往往在局部是"正确的"，但在系统层面会引入结构性偏差。
| 指标 | 定义 | 采集方式 | 误读风险 |
|---|---|---|---|
| Dependency Freshness（依赖新鲜度） | 项目依赖中过期超过 12 个月的包比例 | npm outdated/pip list --outdated/dependabot报告；CI 中定期运行 | AI 生成代码时会引入它训练数据截止时间附近的包版本，可能带入已有已知漏洞的版本 |
| Dead Code Ratio（僵尸代码率） | 从未被调用过的函数/类/模块比例 | ts-prune(TypeScript) /vulture(Python) /deadcode(Go)；每月扫描一次 | AI 生成的代码有时包含"备用路径"或"兜底函数"，长期不被调用但占用维护成本 |
| Architectural Coupling Score | 模块间不合理依赖的数量（循环依赖、跨层依赖） | dependency-cruiser(JS/TS) /ArchUnit(Java)；集成到 CI 作为 soft gate | AI 对项目架构分层理解有限，容易在不该引用的层之间直接 import，久了会破坏架构边界 |
| TODO/FIXME Density | 代码库中 TODO/FIXME/HACK 注释数 / 总代码行数 | grep -r 'TODO|FIXME|HACK' --include="*.{ts,py,go,java}" | AI 有时会生成// TODO: handle edge case这类注释但不实现，这些是隐性债务的标记 |
一个容易忽视的技术债模式：AI 在生成代码时会创造大量"内联工具函数"——本该抽象成共用工具的逻辑，被以略微不同的形式重复实现了五六次。这不会触发任何 lint 规则，也不会让测试失败，但随着时间推移，维护这些冗余实现的成本是真实的。建议每季度跑一次 AST-level 相似度分析（jscpd/cpd），把 AI 带进来的重复代码主动消灭。
如何使用这张仪表盘
最小起步配置（第一周可以落地）
如果你从零开始，建议先跑通这三个指标：
- Cycle Time（P50 + P90）— 代表速度，最直观
- CR Rejection Rate— 代表质量，采集成本低
- Hotfix Frequency— 代表返工，结果最直接
这三个指标不需要任何特殊工具，GitHub/GitLab API + 一个简单的 Python 脚本就能每周生成报告。
30 天后加入的指标
待基线建立之后，再加入：
- Code Churn Rate（需要 git-blame 分析）
- Test Coverage Delta（需要 CI 集成）
- Reviewer Load（需要 webhook 统计）
90 天后才值得看的指标
这些指标需要历史数据积累才有意义：
- Defect Escape Rate Trend（需要 7–14 天滞后数据）
- Architectural Coupling Score（需要 baseline 快照对比）
- AI Assist Rework Ratio（需要 PR 标注积累）
一个实用的周会模板
每周 Engineering Review 建议固定讨论这张卡片（15 分钟）：
AI Coding Weekly Health Check — [日期] 速度 Cycle Time P50: __h (vs 上周: __h) Cycle Time P90: __h (vs 上周: __h) 质量 Defect Escape Rate: __% (vs 基线: __%) Build Failure Rate: __% (vs 上周: __%) Review Reviewer Load 峰值: __ PR/人 (阈值: 10) CR Rejection Rate: __% (vs 上周: __%) 返工 Hotfix 次数: __ (vs 上月均值: __) Churn Rate P75: __% (vs 基线: __%) 技术债 TODO/FIXME Delta: +__/-__ (vs 上周) 本周新增依赖: __ 个，过期依赖: __ 个 本周关注点: _______________ 下周行动项: _______________这个模板不追求完整，追求的是让数字说话的节奏。每周填一次，四周后你就能看到趋势；八周后你就能预判风险。
两种错误的应对方式
看到这些指标恶化时，有两种常见但都错误的应对：
错误一：禁止 AI 辅助高风险任务。这是过度反应。AI 在哪类任务上质量稳定，应该由数据来回答。"重构"类任务的 Defect Rate 高，不代表 AI 不能用于重构，可能只是 prompt 工程不够，或者缺少足够的测试保护网。
错误二：忽视数据，坚信"时间长了工具会越来越好"。这是另一种逃避。AI 工具确实在进步，但你的团队今天已经积累了债务，不会因为工具进步而自动消失。
正确的应对是：用仪表盘定位是哪个维度的问题，再针对那个维度采取干预措施。比如 Reviewer Load 超标 → 考虑引入 AI-assisted review 工具（如 CodeRabbit）分担初筛工作；比如 Churn Rate 偏高 → 考虑在 AI 辅助的 PR 上强制要求额外的 reviewer；比如 Dead Code 快速增长 → 考虑在 CI 中加入 dead code 检测的 soft gate。
给 Tech Lead 的最后一条建议
别把这套仪表盘变成 KPI 考核工具。这是诊断工具，不是绩效工具。
如果开发者知道"AI 辅助代码的 Churn Rate 会被记录"，他们会开始避免使用 AI，而不是提升 AI 使用质量。指标应该帮助你发现系统性问题，帮助团队改进流程，而不是让个体背锅。
用它来问"我们的 AI Coding 流程在哪个环节出了问题"，而不是"谁的 AI 代码质量最差"。
这两个问题看起来相似，但前者会让你的团队越来越好，后者会让你的团队停止使用 AI。
本文指标数据来自作者所在团队 2026 年 3–5 月的内部工程实践，具体数字已做脱敏处理。采集脚本和看板模板可通过评论区联系获取。