AI 帮我写完功能后，我把 Code Review 的第一问换了

上周我让 AI 改一个很普通的功能订单列表增加“只看待支付”筛选并记住用户上一次的选择。它很快给出了 PR筛选组件、URL 参数、请求参数、本地存储、单测一个不少。跑起来也没报错。但我没有急着看 diff而是手动做了三件事先选“待支付”刷新页面复制链接到无痕窗口打开清空筛选后点浏览器后退。第三步就出问题了页面回到了“待支付”的视觉状态请求却发的是全部订单。原因不复杂——URL、组件 state 和 localStorage 三个状态源在“后退”这个路径上没有统一优先级。这不是 AI 特有的 bug。人手写也会踩。区别在于AI 很容易把主流程补得又快又完整让人误以为需求已经被实现但它不会天然知道浏览器后退、旧链接、失败重试、权限变化哪些才是我们项目里真正昂贵的边界。所以我现在给 AI 的第一份输入不再是“帮我实现这个需求”而是一组验收样例。从“描述功能”变成“描述可观察行为”以前我会这样提需求给订单列表加状态筛选默认全部刷新后记住用户选择。这句话对人够用了对 AI 却留了不少空白“记住”是 URL、localStorage 还是服务端URL 和本地记录冲突时听谁的老链接带了已经下线的状态怎么办切换租户或账号后还能沿用吗请求失败时筛选项是否要回滚把它改成验收样例后输入会变得像这样describe(订单状态筛选,(){it(首次进入且 URL 没有 status 时展示全部订单,(){})it(URL 中有合法 status 时URL 优先于本地缓存,(){})it(选择待支付后应更新 URL、发起对应请求并在刷新后保持一致,(){})it(URL 中 status 非法时回退到全部订单并清理非法参数,(){})it(切换账号后不读取上一个账号的筛选缓存,(){})})注意这不是为了追求测试覆盖率。它真正的作用是把“完成”的定义钉在可观察结果上。AI 可以根据这些样例补实现、补测试甚至提出状态设计但优先级、异常策略和产品取舍仍然需要开发者先做判断。这里恰好是人比模型更值钱的部分。我会让 AI 先回答两个问题而不是直接改代码现在接到类似需求我通常先让 AI 做一轮“反向澄清”根据下面的需求和现有代码列出状态来源、冲突优先级、可能破坏现有行为的路径。不要写实现先给出需要确认的验收场景。这个限制很有用。因为一旦直接让它写代码它会自然选择一种自洽的方案然后用很多代码把方案包起来。等我们发现设计不对删掉的不只是几十行代码还有已经被 review、联调甚至提测的时间。第二个问题是如果这个功能上线后只能保留 5 条自动化测试你会保留哪 5 条每条防的是什么回归这能筛掉不少“测了等于没测”的用例。比如只断言按钮文字变了意义不大而“浏览器后退后 UI 与请求参数仍一致”就是很典型的回归点。Code Review 也该换顺序AI 生成的代码经常很整洁命名像样、注释齐全、类型也补得很勤快。先盯着函数拆分和写法很容易陷进去。我现在 review 的顺序更粗暴一点用户能从哪些入口到达这个状态每个入口下页面、URL、缓存和请求是否一致如果请求失败、数据为空、权限变化用户看到什么这些路径里哪几个已经有测试或可重复的验证步骤最后才看代码是否优雅。前四项没过后面的“优雅”基本没有意义。有一次 AI 把一个复杂表单的保存逻辑抽成了三个漂亮的 hook。review 到最后才发现接口返回 409 时它统一 toast 了“保存失败”但产品实际要求是提示用户刷新并保留未提交的编辑内容。代码没错业务结果错了。这类问题不该靠“认真一点”避免而要在验收阶段显式写出来。一个不那么完美、但够用的工作流我目前用的是下面这个小闭环没什么神奇之处先写 35 条验收样例至少包含一个异常或回退路径让 AI 只输出方案和风险点不要急着改人确认状态归属和优先级后再让 AI 实现要求它把验收样例转成可运行测试或给出明确的手工验证步骤review 时从用户路径倒推不从 diff 正着读合并后记录一次真实漏掉的边界下次变成团队的样例模板。最后一步尤其重要。团队不需要一份越来越厚的“AI 使用规范”更需要把真实踩过的坑留下来分页与筛选联动、重复提交、权限切换、弱网重试、老链接兼容……这些才是项目自己的上下文。别把“会用 AI”理解成提示词技巧AI 编程让“产出代码”变便宜了但并没有让“定义正确结果”变便宜。甚至相反代码来得越快模糊需求被迅速包装成完整 PR 的概率越高。以前一个需求写两天中间还能被各种阻塞打断、重新思考现在半小时就有可运行页面人更容易跳过那段本该慢下来的设计。我不觉得每个小需求都值得写完整测试矩阵。一个内部运营页的文案调整确实没必要上纲上线。但只要功能涉及状态同步、钱、权限、数据删除或者用户能通过浏览器行为绕出主流程我就会至少写下那几条验收样例。它们不是 AI 的束缚而是我们不把判断力外包出去的方式。你在用 AI 改需求时最容易漏掉的是哪类边界状态同步、异常处理还是对旧功能的兼容欢迎在评论区聊聊你踩过的坑。