三起提交残缺：工作区能跑 ≠ 干净检出能跑

上一篇讲的是权力线：干活的不能说”完成”。

这篇讲这条权力线第一次真正救命的地方——因为它拦下的那种失败，是你看不见的。

一、先看一个画面

代码写完了，你打开页面，能点、能提交、能存进数据库。

一切都对。

然后你把代码推到服务器上，重新拉一份干净的——跑不起来。

这就是这篇文章要讲的那种失败。

它不是”写错了”，是”你以为交付了，其实交付物是残缺的”。而且它最阴的地方在于：在你自己的电脑上，它永远是好的。

二、同一天，三起

2026 年 9 月 14 日。上午先是审核侧在巡查时发现一个任务包的代码已经落盘，但没有提交、没有任务包文件、没有认领声明。

这已经够糟了。但真正让人后背发凉的是接下来的排查——顺着查下去，同一天又爆出两起同类：

#	事故	表象	后果
①	构建配置漏提交	本地构建正常	挂了两周才被发现
②	前端漏提交	页面开发一切正常	98.8% 的前端代码不在版本库里
③	控制器漏提交	本地接口能通	三个接口线上全 404

三起事故，三个不同的文件，不同的写手，不同的模块。

同一个形态。

我把这个形态提炼成一句话，它后来成了整个项目的口头禅：

工作区能跑，干净检出不能跑。

三、为什么这个形态最阴

因为它同时骗过了三方。

第一，它骗过了干活的 AI。

编码 AI 在自己的工作区里跑测试，全绿。它交活时说”编译通过、功能正常”——它没有撒谎，它说的是真话。在它的世界里，那个文件确实存在、确实生效。

它缺的不是诚实，是视角。它看不到”这个文件有没有进版本库”这件事——因为它的参照系是自己脚下的这台机器。

第二，它骗过了审核 AI——如果审核 AI 偷懒的话。

这是全套方法里我最看重的一个设计细节。审核侧的复验动作是这么定的：

编码 AI 说”编译通过”不算数，审核 AI 自己重跑一遍。 而且是干净检出、自己编译、自己打接口、浏览器实测页面。

注意”干净检出”这四个字。

如果审核侧图省事，直接在写手的工作区里复跑一遍测试——三起事故一个都抓不到。因为写手的工作区正好是那个”能跑”的环境。

第三，它也差点骗过了我。

我不读代码。我看到的是页面能点、流程能走。如果没有”干净检出”这个动作，我能做的只有相信。

四、根因：参照系选错了

把这三起事故抽象一下，根因只有一条：

验收用的参照系，和交付用的参照系，不是同一个。

这是个很本质的错误，而且它不只出现在 AI 协作里。你回想一下自己带项目时最常听到的那句话：

“我这跑着没问题啊。”

这句话之所以让人火大，不是因为对方在推责，而是因为它可能是真的——只是参照系不对。

所以规矩不能再定成”你要确保代码是完整的”。这种话没有可执行性，AI 听了也只能点点头。

规矩必须定成一个动作。

五、规矩：完工必对账

最后定下来的规矩叫完工必对账，只有一句话：

提交的文件清单 == 自己改过的文件清单。

对账的动作要落在提交前，而且必须逐项比对，不能凭印象。

这里有个很关键的实操细节——三起事故里，写手全都不是”忘了提交”，而是走了一条看起来很合理的路：

提交前只看了一眼工作区状态（git status 显示干净），就认为提交完整了。

这就是隐蔽绕过点。

工作区状态干净，只能说明”没有未提交的改动”；它不能说明”你已经提交的东西就是你应该提交的东西”。

这两件事差得很远：

你以为你在检查	你实际在检查
提交内容 = 改动内容	工作区没有遗留改动
需要逐项比对文件清单	一条命令就能过

而且注意：这个对账动作是可脚本化的。后来我把”提交完整性对账”列进了自动化清单里，跟它并排的还有：干净检出自测、在途写手探针、权限矩阵回归、幂等性复跑。

能做成脚本的，就不要指望人（或者 AI）的自觉。

六、一条让写手没法糊弄的联动

光有对账规矩还不够，得有个地方逼它落地。

三件套里的第一条是改动清单，原本的写法是”改了哪些文件、为什么改”。

后来这条被改了，改成了一句带等号的话：

改动清单 == 提交记录里的文件清单。

一个等号，性质就变了。

原来是”请你描述一下你改了什么”——这是作文题，AI 很擅长写一篇格式完美的作文。

改完之后是”请你证明你的描述和事实一致”——这是举证，而证据是可以被另一个人重跑验证的。

这就是为什么我常说：“谁主张，谁举证”这六个字，比任何提示词技巧都管用。

你说完成了，可以，请举证。而举证的标准不是”你说了”，是”别人能重跑出一样的结果”。

七、它是怎么变成铁律的

整套方法里，我最想让你抄走的其实不是这条规矩，而是规矩的产生流程。

这套流程定型之后一直是四步：

事故 → 通报 → 拍板 → 入册

拿这次的”完工必对账”走一遍：

事故（09-14 上午）：三起提交残缺，同一形态。审核侧顺着一条”代码落盘无声明”的线索查出来的；
通报（当天）：审核侧出书面通报，把巡查证据逐条列出来，要求补提交、补三件套、补权限脚本；
拍板（当天）：我当天就拍了，含这条规矩的试点口径；
入册：写进项目交接书与开工必读；十天后（09-24）我拍板统一升格为六条铁律的正式口径。

全程当天闭环。

这里有个对比是我故意留着的。大多数团队的复盘会长这样：会开了，纪要写了，大家点头了，然后——没有然后了。下次同一个坑再踩一遍，再开一次会。

所以这套流程里我加了一条硬门槛：

事故必须长出一条能写进 AI 必读文件的规矩，才算结案。

注意这个门槛的措辞——不是”要反思”，不是”要加强”，是”必须长出一条规矩，而且必须写进 AI 每天开工会读的那个文件”。

为什么强调”写进必读文件”？

因为我们吃过这个亏。规矩如果只存在于会议纪要里，那它等于不存在——AI 没有隔夜记忆，它每次开工的实际知识来源只有那份交接书和一页纸必读。 你写在别处的所有规矩，对它来说都是耳旁风。

八、一个更反直觉的发现：证据也要分级

这套东西跑下去，冒出来一个我一开始没想到的问题。

写手自测通过了，审核侧重跑也通过。那这次验收算过了吧？

不一定。

三起提交残缺给了一个很贵的教训：“写手自测通过”和”审核侧干净检出通过”，是两种不同等级的证据。

前者是在”能跑的环境”里验的，后者是在”交付的环境”里验的。看起来都叫”测试通过”，含金量差着一个维度。

所以后来我们的证据体系干脆分了级——什么级别的结论，需要什么级别的证据。这条在系列后面还会展开，这里先给一个结论：

不认截图，认自己亲手跑出来的退出码。

九、连规矩本身都要验收

这篇里我最喜欢的一个细节，是它发生在这条规矩已经生效之后。

2026 年 9 月 28 日，审核 AI 在做自己的对账时，发现了一个洞：

铁律④ 对我们这个项目大约一半的交付物，字面上根本不可执行。

为什么？因为这条规矩的前提是”受版本控制的仓库”。而我们的文档根目录不是版本库——任务包、情况通报、拍板材料、甚至这套方法论的初稿，全都在版本控制之外。

对它们做”提交对账”，字面上没有意义。

于是补了一条适用前提，并且给了等价的替代方案：

受控交付物	非受控交付物（等价替代）
提交的文件清单 == 改动清单	交付人自列改动文件清单（含增删行数）
版本库可比对	关键文件记修改时间 / 字节数
—	接收方逐项复核

最后收在一句话上：

替代 ≠ 豁免。

这件事本身的价值，其实超过了那个洞本身。因为它证明了一件事：

规矩的”可执行性”，本身也是需要验收的。

一条你写下来、大家都点头、但实际根本执行不了的规矩，比没有规矩更糟——它会给你一种”这事已经管住了”的错觉。

而这个洞，是审核侧在给自己干活做对账的时候挖出来的。它在用规矩检查自己的时候，发现了规矩本身的问题。

我觉得这是整套方法里最健康的一个信号。

十、你只有一个人加一个 AI，怎么用

这条不需要四工位，也不需要团队。

动作就一个：

AI 说做完了，你不看它的工作区，你自己干净拉一份，跑一遍。

规矩就一句：

提交的文件清单 == 你告诉我的改动清单。

判据就一条：

我能在”一个干净的、只有代码的环境”里，跑出和你一样的结果吗？

如果你嫌麻烦，我给你一个更省的用法：把这一条留给”每次交付的最后一环”。 不用每个中间步骤都拉一遍，但每一个要交给别人的版本，都过一遍这个动作。

顺便说一句成本，免得你觉得这事很贵。我们这套跑下来的实测数据是：

项	实测
单包复验总耗时	30–90 分钟
其中造数 + 清理	约 40%（最被低估的一项）
干净检出离线编译	1 分 49 秒

那 1 分 49 秒，就是防住这三起事故的全部成本。

复验真正贵的从来不是”跑”,是”判断”——“这算不算缺陷""这个偏离能不能接受”，这些没法脚本化。但”提交完整性”这类事，一条命令就够了，没有理由不做。

十一、最后

回来看看这三起事故的共同点。

它们谁都不是因为 AI 笨。恰恰相反——编码 AI 每次都把活儿干得挺漂亮，页面能跑、接口能通、测试全绿。

它失败的地方在边界上：它知道自己脚下这台机器是什么样，它不知道”交出去之后”是什么样。

而这恰好是我上一篇说的那件事的另一个侧面：

干活的人，看不到”交接之后”的世界。

所以版本控制这件事，对 AI 协作来说不是工程规范，是认知补丁。

它把”我这跑着没问题”和”你拿去也能跑”，硬生生切开成两件事。切开的那个动作，就是 git commit 之前那一次逐项对账。

代码在你看得见的地方跑得好，不算数。

在你看不见的地方也能跑起来，才算。

这个系列的底线，就三句话： 干活的不能说”完成”，验收的不改代码，只有老板能拍板。

上一篇：《干活的不能说”完成”：AI 团队里最值钱的一条权力线》 —— 四工位怎么切权力，以及”完成”的定义权为什么必须收走

下一篇：《一个不写代码的人，凭什么敢验收》—— 直击同类读者最大的心结

相关旧文：

《让两个 AI 搭伙干活：怎么立规矩、怎么防埋雷》 —— 这些规矩最早是怎么立起来的
《双 AI 协作开发，我们三到底如何分工，如何协作》 —— 分工定下来之后，活儿具体怎么干