十天前翻到 dev.to 上 Harsh 那篇讲「AI 把写代码变便宜了，为什么软件交付还是贵」的文章，评论区我翻了两遍。他举的例子我印象很深：认证流程这种带数据库结构、API 路由和单测的活儿，三十秒能让 AI 生成一份；可另一个他自认为简单的功能，从动手到进生产走了三周。中间那段是合并请求，同事审了两天，卡在缓存逻辑里一个不显眼的边界情况上；上线之后又把 AI 完全不了解的遗留系统撞坏了，排查加回滚加重写，一周没了。
这段看着像段子，但上个月我在这边碰到的是同一件事的缩小版，只是没那么惨。所以这篇不打算写「AI 生成的代码要小心」这种谁都知道的话，我想记的是看完那篇文章和评论区之后，自己真去改掉的两条流程，以及一条我试了一周就放弃的建议。
先拆开看看成本去哪了。代码生成这个环节是能被工具放大的一项，读代码、判断一段改动会牵动仓库里哪些地方，这些放不大。AI 能写出局部成立的函数，但它判断不了这个函数接到系统里会连带影响什么，集成成本全压在审查这一侧。缓存那类东西正好是「局部正确、整体错误」的常发区，它的正确性依赖调用顺序和失效时机，而这些信息根本不在被生成的那个文件里，审查的人只能自己从 diff 反推作者的假设。评论区里 Tanay Dwivedi 说自己现在几乎不写代码，时间全花在编辑和调试上。我看完的感受是：编辑和调试之前那一步「对齐」要是省了，后面就得拿审查时间补。
第一条：先让它交假设清单，再让它写代码
这条是从 Odinaka Robert Nnamani 的评论里学来的，我照着改成了自己固定的开场白。以前我的习惯是直接把需求丢过去，等它把代码写完再一行行看；现在是先让它别写代码，只交两样东西。
在动手写代码之前，先输出两段，不要写任何代码：
1. 你判断这次改动会碰到的边界条件和调用方，逐条列，不要合并成一句
2. 你还不确定、需要我先确认的部分
我确认完第二段之后再开始写。
改成这个顺序之后，审查的起点从 diff 挪到了清单上。清单一般不长，扫一遍用不了两分钟，但哪里理解偏了当场就能拦下来，不用等两百行代码生成完再从头理解一遍。💡 小技巧：第二段「不确定的部分」比第一段有用得多——模型往往会在那里老实写出「旧版客户端的兼容分支是否还需要保留」这种它自己也在猜的东西，而这一条恰恰是我经常忘了交代的。
配合这个，我在 PR 描述里固定留一节，格式很土但管用：
## 这段改动我没把握的地方
- 缓存失效时机（TTL 还是显式清）
- 旧客户端分支要不要留
写不满三行说明这次改动我确实读懂了；写不出来但心里隐约发虚，那就是还没读懂，先别提交。
第二条：按任务范围切，别按行数切
评论区有人提限 PR 行数，我不太信这个办法。上个月我把一个改动切成十来个 PR，每个都在两百行以内，全部通过，合起来却是一次没人完整读过的重构——单看每一个都合格，拼在一起谁也说不出整体行为变没变。行数是个太容易满足的指标，把一个功能切碎就能达标，可审查疲劳一点没少。
后来我改成一次只让 AI 碰一件事，规矩直接写进 CLAUDE.md：
一次会话只做一个任务。改动跨模块时先停下来，
拆成两到三个独立任务，我挑一个再开始。
提交前必须能回答：这次改动影响到的调用方有哪几个？
按任务范围切的好处，是每个 PR 都有一个能一句话说清的目的，审查的人不用在脑子里同时装三个上下文。同一条评论里还提到把审查集中到固定时段，别随到随审——通知一来就切过去看，两个小时里切八次，每次都得把背景重新加载一遍，这才是审查疲劳真正贵的地方。我试了两周，确实比「有空就看一眼」省力。
那条我放弃的建议
原文里有一条是给资深开发者留更多审查时间，我照着做了一周就放弃了。原因很朴素：资深的人时间本来就排满，多留出来的时间实际上是从别的地方挪的，挪完他还是会被拉去开会，审查队列该堵还是堵。
真正该做的是让「没人讲得清楚在干什么」的代码压根别进队列。评论区有个人说，审查团队没人能解释清楚的 AI 生成代码是主要瓶颈；还有人说接手过一个 v0 生成的商店项目，Supabase 的行级安全是关的，联系表单压根没真的发消息，页面上看着一切正常。这种东西不是多给审查时间能解决的。
写到这我得承认「不该进队列」这话有点不现实——生成方和审查方常常是同一个人，你没法把自己拦在门外。所以落到具体动作上还是绕回那份假设清单：它逼着你在生成之后先停一下，把「我确定」和「我不确定」分开写下来，写的过程本身就是一次自查。
顺带记一条我认同的判断：AI 更适合干的活是删旧代码、补测试、重构遗留系统，而不只是加新功能。删和重构的成果能被测试验证，加功能只能靠人审，前者的验证成本低一个量级。
划重点：把审查的起点从 diff 挪到生成之前的那份假设清单；PR 按任务范围切，限行数基本是自我安慰；资深审查时间是稀缺资源，与其多要时间，不如减少没人能解释的代码进队列。这条记下来了，下次应该用得上。你要是有更省事的假设清单模板，甩过来，我补进下一篇踩坑笔记。