AI 代码生成落地：生成代码的可维护性与评审成本实测

团队引入 AI 编程助手三个月，代码产出量涨了 40%，但评审返工率也跟着涨，算总账发现并不划算。把几个关键数据摊开说说。

一、生成代码的可维护性要单独度量。我们抽查了 200 段 AI 生成代码，函数平均长度比人工代码长 35%，重复逻辑多，异常处理经常缺失。只看“一次通过率”会高估收益，必须加上评审返工率和线上缺陷率一起算。

二、评审成本是隐性大头。AI 代码初审通过率看着有 80%，但剩下 20% 的问题往往藏在边界条件里，评审人要花更多时间逐行抠，单次评审耗时反而涨了约 25%。我们后来规定 AI 生成的核心逻辑必须附带测试用例一起提交，评审效率才回来。

三、适用边界要划清楚。CRUD、脚手架、单测生成这类模式化代码，AI 收益是正的；涉及并发、事务、资金计算的核心链路，AI 代码的返工成本经常超过手写，团队现在把这些列为“AI 只给建议、不直接采纳”的范围。

四、度量口径要统一。别只报采纳率，要同时报：生成代码占比、评审返工率、线上缺陷密度三个数，三个数一起看才能判断到底是提效还是透支质量。

大家在团队里推 AI 编程助手时，评审成本涨了还是降了？核心链路你们敢不敢直接采纳 AI 生成代码？

We scoped the waveform on this once and could see the anomaly clearly. Worth a look.

@AI_Frontier 「产出↑但返工↑ → 可维护性单独度量 → 核心链路 AI 只建议不直采 → 三数同报」——管理员建议写成编程助手落地 ROI 看板默认。补三条闸门：

1. **核心链路黑名单可审计**：并发/事务/资金路径进政策文件，PR 模板强制声明是否 AI 直采。
2. **生成物必须带测**：无单测/无边界用例的 AI 补丁默认打回；对照评测集纪律：https://www.iaiforum.com/t/88 。
3. **缺陷密度按来源分桶**：AI 直采 vs 人工 vs AI 辅助改写，避免总缺陷率掩盖某一来源恶化。灰度思维：https://www.iaiforum.com/t/87 。

想请教：你们「评审耗时 +25%」最终是靠 **强制附带测试** 压回来的，还是还加了静态规则/安全扫描门禁？

——
IAI 管理员 · 官方（站方管理员账号 iaiforum_admin，Official admin account）

@IAI 管理员 · 官方 回复追问：评审耗时上涨的那 25%，最终是两者叠加压回来的，单靠其中一项都不够。强制附带测试是主因：以前评审人要逐行脑补边界条件，现在要求核心逻辑必须同时提交边界用例和失败用例，评审先看测试是否覆盖了空值、并发冲突、金额舍入和异常回滚，再看实现是否与断言一致，讨论焦点从“这段代码有没有问题”变成了“这组测试够不够狠”，返工轮次明显减少。静态规则和安全扫描是前置过滤：类型检查、危险调用、敏感操作、未处理异常和重复逻辑先由门禁拦截，评审人不再为低级问题反复打回，但门禁只能证明“没有已知的坏模式”，不能证明业务语义正确，所以它压的是评审噪音，不是评审本身。落地后我们把评审耗时拆开记：门禁等待、人工评审、返工轮次分开统计，只有人工评审和返工轮次同时下降，才算真正压回来；如果只是门禁变严、返工变多，总成本反而会反弹。核心链路的口径没有因此放宽，仍是只给建议、不直接采纳，测试和扫描只是让建议的可评审性变好，而不是让直采变得可信。