昨天团队合并了 30 个 PR。你真正读了几个不是 skim不是扫一眼 diff是真正理解 tradeoffs、edge cases、跟三个目录外的代码怎么交互。如果你诚实答案可能是0 个最多 2-3 个。这不是你懒也不是纪律问题这是数学问题。AI 生成的 PR 已经占了代码提交量的巨大份额高 AI 采用率的团队 PR 量比去年暴增好几倍。review 时间没变PR 数量却爆炸式增长Agent 正在触达你栈的每一个角落。你生成代码的速度已经远远超过你理解代码的速度。瓶颈早就变了大多数团队还没反应过来过去几十年软件交付的真正约束一直是“写代码”——逻辑对不对、类型对不对、测试过不过。我们的整个流程sprint、code review、CI都是围绕这个瓶颈设计的。现在这个约束没了。写代码已经成了最廉价的环节。但大多数团队还在用老流程卡自己盯着 Agent 40 秒生成的 diff 逐行 review把 PR 当成唯一质量关卡把人类注意力浪费在“机器能自己验证的事”上数据已经把真相摆在眼前AI PR 平均等待被 pickup 的时间远长于人类 PR一旦开始 review接受率却大幅低于人类代码近 70% 的 AI PR 被直接拒绝。审查者不是不专业而是根本不信任。于是队列越堆越长PR 越老越没人碰。更隐蔽的问题是AI 生成的代码 AI 生成的测试往往是“自圆其说”的。传统 review 默认测试是独立检查在 Agent 世界里这个假设经常失效。代码 review 曾经是概率过滤器现在连概率都保不住了。真正该审的从来不是代码而是 Spec你真正抓住重要 bug 的时刻其实从来不是盯着 diff架构选错了抽象层级不对功能 technically works但解决的是错误的问题这些问题都发生在代码上游——意图、约束、成功定义。当 Agent 根据 Spec 写代码时你其实有两个选择选择 Areview 每一行、每一个文件、每一个 diff希望在生成文本的海洋里碰运气。选择 Breview Spec、批准计划、定义验收标准让确定性验证去管剩下的。一个能规模化一个注定崩溃。金句工程师的真正工作已经从写代码变成了写合同。真实工作流长什么样早上打开一个迁移任务新流程10 分钟搞定读 Agent 基于的 Spec所有金额必须用 Money 类型API 绝不向客户端返回 raw error每个 checkout 状态迁移都有显式测试验证报告显示三条全部成立。Done。老流程浪费 30 分钟打开 400 行 diff扫前 100 行留一句变量名评论因为要赶会就 approve 了。哪个流程真正抓住了架构错误实际落地我们团队正在用的 4 层验证体系Spec 先于代码任何任务先写清晰 Spec端点、约束、不变量、验收标准再让 Agent 生成。可验证的验收标准不是“代码看起来不错”而是“必须满足以下 5 条每条都有机器可执行的检查”。多层机器验证栈测试每变更必跑类型系统编译时抓 contract violation自定义 linter组织级不变量权限隔离改日期解析的 Agent 碰不到 auth对抗 Agent专门尝试打破第一个 Agent 的成果人类只审意图只在 Spec 阶段介入确认“这是不是我们真正想要的”。你以为你在审代码其实你在做 linter 能干的事你以为你在把关质量其实真正致命的假设错误早就溜过去了。5 个问题马上自测你团队是否还活在旧时代你 review 评论里有多少是 linter 一秒就能 catch 的如果超过一半你在用人做机器的活上一次 code review 抓到真正的架构错误是什么时候不是 typo不是漏测试是设计级错误你的 PR 有 written spec还是只有标题 diff没有 spec就没有可审的 intent如果现在一个 Agent 提交 PR它能验证自己是否符合什么如果答案是“没有明确 contract”说明你的规范还不够硬你 review 时间在“信任的代码”和“不信任的代码”上分配是否合理如果对工具函数和支付接口花一样的时间风险感知已经失灵总结代码不再是核心 artifact意图才是AI 时代写代码成了商品定义意图成了护城河。把精力从“读 AI 写的 diff”解放出来放到“写清晰、可验证的 Spec”上你会发现团队出货更快信心更强真正致命的生产事故大幅减少因为质量关卡终于放在了决策发生的地方而不是 diff 出现的地方。你团队的 PR review 现在还在盯着代码吗评论区说说你的痛点我继续拆更狠的 Spec 模板和验证栈。我是紫微AI我们下期见。完
别再逐行审代码了！AI 时代，真正该 review 的是 Spec：我们团队把 PR 审查效率提升 5 倍的秘密
昨天团队合并了 30 个 PR。你真正读了几个不是 skim不是扫一眼 diff是真正理解 tradeoffs、edge cases、跟三个目录外的代码怎么交互。如果你诚实答案可能是0 个最多 2-3 个。这不是你懒也不是纪律问题这是数学问题。AI 生成的 PR 已经占了代码提交量的巨大份额高 AI 采用率的团队 PR 量比去年暴增好几倍。review 时间没变PR 数量却爆炸式增长Agent 正在触达你栈的每一个角落。你生成代码的速度已经远远超过你理解代码的速度。瓶颈早就变了大多数团队还没反应过来过去几十年软件交付的真正约束一直是“写代码”——逻辑对不对、类型对不对、测试过不过。我们的整个流程sprint、code review、CI都是围绕这个瓶颈设计的。现在这个约束没了。写代码已经成了最廉价的环节。但大多数团队还在用老流程卡自己盯着 Agent 40 秒生成的 diff 逐行 review把 PR 当成唯一质量关卡把人类注意力浪费在“机器能自己验证的事”上数据已经把真相摆在眼前AI PR 平均等待被 pickup 的时间远长于人类 PR一旦开始 review接受率却大幅低于人类代码近 70% 的 AI PR 被直接拒绝。审查者不是不专业而是根本不信任。于是队列越堆越长PR 越老越没人碰。更隐蔽的问题是AI 生成的代码 AI 生成的测试往往是“自圆其说”的。传统 review 默认测试是独立检查在 Agent 世界里这个假设经常失效。代码 review 曾经是概率过滤器现在连概率都保不住了。真正该审的从来不是代码而是 Spec你真正抓住重要 bug 的时刻其实从来不是盯着 diff架构选错了抽象层级不对功能 technically works但解决的是错误的问题这些问题都发生在代码上游——意图、约束、成功定义。当 Agent 根据 Spec 写代码时你其实有两个选择选择 Areview 每一行、每一个文件、每一个 diff希望在生成文本的海洋里碰运气。选择 Breview Spec、批准计划、定义验收标准让确定性验证去管剩下的。一个能规模化一个注定崩溃。金句工程师的真正工作已经从写代码变成了写合同。真实工作流长什么样早上打开一个迁移任务新流程10 分钟搞定读 Agent 基于的 Spec所有金额必须用 Money 类型API 绝不向客户端返回 raw error每个 checkout 状态迁移都有显式测试验证报告显示三条全部成立。Done。老流程浪费 30 分钟打开 400 行 diff扫前 100 行留一句变量名评论因为要赶会就 approve 了。哪个流程真正抓住了架构错误实际落地我们团队正在用的 4 层验证体系Spec 先于代码任何任务先写清晰 Spec端点、约束、不变量、验收标准再让 Agent 生成。可验证的验收标准不是“代码看起来不错”而是“必须满足以下 5 条每条都有机器可执行的检查”。多层机器验证栈测试每变更必跑类型系统编译时抓 contract violation自定义 linter组织级不变量权限隔离改日期解析的 Agent 碰不到 auth对抗 Agent专门尝试打破第一个 Agent 的成果人类只审意图只在 Spec 阶段介入确认“这是不是我们真正想要的”。你以为你在审代码其实你在做 linter 能干的事你以为你在把关质量其实真正致命的假设错误早就溜过去了。5 个问题马上自测你团队是否还活在旧时代你 review 评论里有多少是 linter 一秒就能 catch 的如果超过一半你在用人做机器的活上一次 code review 抓到真正的架构错误是什么时候不是 typo不是漏测试是设计级错误你的 PR 有 written spec还是只有标题 diff没有 spec就没有可审的 intent如果现在一个 Agent 提交 PR它能验证自己是否符合什么如果答案是“没有明确 contract”说明你的规范还不够硬你 review 时间在“信任的代码”和“不信任的代码”上分配是否合理如果对工具函数和支付接口花一样的时间风险感知已经失灵总结代码不再是核心 artifact意图才是AI 时代写代码成了商品定义意图成了护城河。把精力从“读 AI 写的 diff”解放出来放到“写清晰、可验证的 Spec”上你会发现团队出货更快信心更强真正致命的生产事故大幅减少因为质量关卡终于放在了决策发生的地方而不是 diff 出现的地方。你团队的 PR review 现在还在盯着代码吗评论区说说你的痛点我继续拆更狠的 Spec 模板和验证栈。我是紫微AI我们下期见。完
