AI Coding 真正拉开差距的,是验收能力

AI 已经能在短时间内补一个接口、写一个页面、生成一组测试。于是很多人开始用“几分钟做完一个功能”衡量效率。但用户不会因为代码行数增长而满意，他们只会遇到一个很简单的问题：这个功能到底能不能用。

当生成变得便宜，验收反而变成更稀缺的能力。

一、把“做完了”翻译成可检查的行为

“增加订单导出”“支持用户登录”都不是验收条件，它们只是需求标题。真正能检查的，是用户在什么情况下做什么，会得到什么结果。

以“支持修改手机号”为例，至少要问：原手机号是否需要验证？新号码已被使用怎么办？验证链接过期怎么办？修改后哪些会话仍然有效？

这些问题不一定都要在第一版解决，但需要明确哪些是范围内、哪些暂不处理。否则 AI 会在它能猜到的地方填空，而你直到线上才知道猜错了。

二、每次改动都过三道检查

一个适合日常使用的验收顺序是：行为、边界、影响。

AI 很擅长给出正常路径，却未必会主动发现系统里的隐性约束。你不需要手工重测一切，但要针对这三层挑出最重要的例子。

三、阅读差异，比阅读一大段解释更重要

让 AI 用很长一段话解释“我做了什么”，通常不如直接看差异有效。你应该能说清：为什么改这个文件？新增逻辑在哪个边界？原有行为是否被保留？

特别要警惕三种变化：为了小功能而顺手重构公共模块；为解决一个异常吞掉所有异常；在没有需求依据时引入新依赖或新配置。

它们不一定错误，但必须有独立理由。生成工具倾向于让方案完整，工程师的职责是让改动保持必要。

四、把验收结果记录下来

一次小改动结束时，写下四行就够：改了什么、验证了什么、没有验证什么、已知限制是什么。

这份记录既方便自己隔周回看，也能让协作者知道哪些结论有证据、哪些仍是猜测。对于使用 AI 的团队，它还会变成很好的反馈材料：哪些提示有效，哪些需求表述总会导致遗漏。

AI Coding 没有让工程能力失效，它只是把价值从“敲出第一版代码”推向了“定义正确、审查变化、确认结果”。真正可靠的开发者，不是永远不让 AI 犯错的人，而是能尽早发现错误、把错误关在交付之前的人。