我们如何用 AI 交付：「为它负责」到底是什么意思

我们是一支以 AI 为主要生产工具的团队。但我们对客户的承诺不是"用 AI 所以更快"——更快是结果，不是承诺。我们的承诺是：每一份交付，都有一个具名的工程师能为它负责，而不是"AI 写的，我们也不太确定"。

用 AI 开发最常见的翻车，不是 AI 不够强，而是人把一整包模糊需求丢给它、然后对产出失去掌控：代码能跑，但没人说得清它为什么这么写、哪里最可能出问题，出了 bug 只能反复猜。我们栽过一次——把一份完整架构一次性交给 agent 去实现，结果在调试上花掉的时间远超写它的时间。复盘后发现，问题不在 AI，而在任务进场时没有任何一处可供对照的"做完算什么样"：它一路自洽地往下写，我们却没给它、也没给自己一个能对照的标准。

第一条：没写下"做完算什么样"，不进场

这逼出了第一条规矩：没写下"做完算什么样"的任务，不进入开发。每项工作开工前先拆成可独立检验的单元，每个单元都带一句验收边界、一个具名负责人、一个判定办法。拆分的标准不是"尽量小"，是"小到这一块能被单独验证"——说不清怎么验，就继续拆。对客户来说，这意味着你交来的需求从第一天起就带着可检验的成功标准，而不是一个两周后才揭晓的黑箱。

这里最容易被糊弄过去的，是"验收目标"这四个字。很多人写下的是"把登录做好""顺便优化下性能"——这不是目标，是愿望。一个合格的验收目标，必须能被明确地衡量：做完之后，你能指着一个具体的东西说"看，它就是对的"。说不出这个"具体的东西"，这个模块就还没准备好进场。

怎么衡量一个模块"做完了"

每个模块的验收目标，我们只认三种能拿来对照的证据，而且每一种都得把话说死：

• 能跑的测试——给定这些输入，必须得到这些输出，红变绿由机器替人判。
  「手机号格式非法时，注册接口返回 422、且不写库」✅  /  「把校验做好」❌
• 可观测的行为——在接近真实的环境里能被看见、能复现的表现，且带一个写死的阈值。
  「1 万条数据下，列表首屏 < 1.5 秒」✅  /  「优化性能」❌　　「断网重连后草稿不丢」✅  /  「体验更流畅」❌
• 人工核对的具体项——实在没法自动化时，写成一条能打勾的清单项。
  「导出的 PDF 在 A4 下不串行、页码连续」✅  /  「导出正常」❌

三种的共同点，是都带一个能判真假的锚点：一个阈值、一个可复现的场景、或一条能打勾的清单。带数字的必须写死——是"< 1.5 秒"，不是"快一点"；是"并发 500 不报错"，不是"能扛住"。凡是只能靠"我觉得差不多了"来判断的，都不算验收目标。

这条纪律有个特别值钱的副作用：当你被迫为一个模块写出可衡量的验收目标时，你其实是在开工前就把需求想清楚了。写不出来，往往不是偷懒，而是这块需求本身还没想明白——那恰恰是该停下来继续拆、继续追问的信号，而不是把一团模糊丢给 AI、让它替你猜一个。

第二条：得有人"为它答话"——但答到什么程度

但真正难的是第二条，而且为它我们内部吵过：AI 写的东西，在交付前，得有人能为它答话。问题是——答话到什么程度？

先说一个前提：我们默认 AI 写出来的是对的。这不是偷懒。逻辑上，如果你打心底默认它是错的，那你根本就不该用它。所以这道门槛要管的，不是逼工程师逐行复查 AI（那既不信任工具，也根本无法规模化），而是确保每次改动都被收敛、提炼到一个工程师真正该掌握的抽象层级——恰当的 abstraction 加一份总结，而不是淹没在每行实现里——再要求他完整看过、独立想透。"能为它答话"，就是能在这个层面说清三件事：这次改动到底做了什么、它的要害逻辑依据什么、它最可能在哪崩、我做了什么验证。

同一道坎，两种过法

可即便定义到这一步，我们四个人的做法还是差得很远。一种人先当架构师：让 agent 写之前，自己先把这块拆成几层想清楚，把设计发给它再让它补，一层层做，始终知道它做到哪。另一种人胆子很大：不一定知道结果该长什么样，先让 agent 做出来看效果，但他同时让好几个不同的 agent 去查同一份代码，而且写的和查的用的是不同模型——一个负责写，另一个专门 debug、不写。

一开始我以为这两种是对立的，谁对谁错。后来才明白，它们是同一道门槛的两种过法。

你对 AI 写的代码，总要跨过同一道坎：从"它生成了一坨能跑的东西"，到"我敢交出去、出了事我认"。跨这道坎有两条路——要么你自己在恰当的抽象层面想透，亲手为它兜底；要么你造一个足够独立的验证者替你把关。两条都到得了终点，选哪条看这块活好不好验证：前端能一眼看出对错，你就不必懂它每一行；后端逻辑藏得深，你要么自己钻进去，要么让另一个模型替你钻。

但有一条不能省：那个验证者必须独立。让 AI 自己查自己基本没用——它查的时候用的还是它写的时候那套逻辑，盲区原封不动。真正有效的，是换一个底座不同、harness 不同的模型去查，它的盲区和前一个不重合，才揪得出问题。我们试过同一个模型换个 prompt 自查，效果远不如换一个模型。

按后果，拧同一个旋钮

我们按后果给这道门槛分级：低风险、可快速回退的改动，门槛较轻，靠快速回滚兜底；触及不可逆或高影响的部分（数据、计费、权限、迁移），要求更高的知情，并增加交叉核对。速度和稳妥在我们这里不是两件事，是同一个旋钮的两端，按后果来拧——而不是一刀切地慢，也不是一刀切地赌。

经验，乘以团队人数地长

最后一件，是我们怎么持续变好。我们把自我纠错当成一项明确的工作，而不是出事才反应：每次出现非预期的返工或缺陷，不止步于修好它，而是追问机制层面的原因，把结论固化成一条规则。更重要的是，这种复盘以团队为单位做——一个人趟过的坑，当场变成全队的共识。于是经验不是一个人慢慢长，而是乘以团队人数地长：队里任何一个人踩过的坑，整支队伍都不必再踩第二遍。开头那条"进场即带验收"，就是这么从一次真实的翻车里长出来的。

所以，问题该这么问

所以回到最初那个问题——"对 AI 写的代码，你要懂到什么程度？"——其实问错了。该问的是：

这块代码，从生成到我敢负责，中间那道坎，
我打算用"自己懂"还是"独立验证"来跨？

想清楚这个，比纠结要不要逐行读代码有用得多。这就是我们在每个项目上，真正在反复做的判断。

把你的需求讲给我们 →