干活的不能说"完成"：AI 团队里最值钱的一条权力线

上一篇里我提了一句：我们三个 AI 加我一个人的分工，是按权力分，不是按技能分。

那篇是总纲，这句只是带过。这篇把它单独拎出来讲透——因为整套路子里，如果只能保留一条，我留这条。

一、大多数人的分法是错的

先看大多数人怎么分工。

你打开任何一个”用 AI 写代码”的教程，看到的都是这种排法：

A 模型写前端，B 模型写后端，C 模型做测试。

这是按技能分。听起来很合理——让擅长的干擅长的。

我们一开始也这么想过，很快发现不对。问题出在哪？

问题在于：这种分法里，每个工位都同时握着”干活的手”和”宣布完成的嘴”。

前端 AI 写完了，说”前端做完了”。后端 AI 写完了，说”后端做完了”。测试 AI 写了一堆测试用例，然后自己判断全绿了。

三个工位各说各话，谁也没说谎，但谁也验证不了谁。

AI 最大的风险不是不会做，是自我感觉良好。

这不是道德问题，是结构问题。一个模型的输出再烂，它看自己的输出也是通的——它不知道自己不知道什么。你让它既干又判，等于让运动员兼任裁判。他永远觉得自己没犯规。

二、我们的分法：按权力切

正确的切法，是切权力，不是切技能。

工位	谁	有这只手	但没有这张嘴
① 主力编码	dsh	按任务包写业务代码	不能宣布”完成”
② 探路·立契	kimi-work	翻原型定契约、起草任务包	不碰①已认领域的业务代码
③ 独立复验	猪仔荣	独立重跑证据、事实核查	不能改业务代码
④ 拍板验收	我	只有我能拍板	一行代码都不读

这张表真正的信息量在最后一列。

每个人都缺一块权力。

① 代码写得再漂亮，自己说了不算；
③ 挑出再多毛病，不能顺手就改——改了就变成”又当运动员又当裁判”；
我什么技术细节都不懂，但我不点头，这事就过不去。

注意 ③ 那条限制有多反直觉。审核 AI 看见一个 typo，改不改？

不改。 它只能把问题写进复核意见，打回去让 ① 改。

看起来是自找麻烦——明明一秒钟的事。但这道墙一旦拆了，审核侧就变成了”会写代码的审核者”，它下次再看代码时会先想”这里我顺手改一下就行”，而不是”我要把这个问题完整暴露出来给人看”。立场一旦模糊，独立性就没了。

三、“完成”这个词的定义权，必须收走

上面说的是结构，现在说这套结构到底在防什么。

一句话：把”完成”的定义权，从干活的 AI 手里拿走。

这句话听起来抽象，落地非常具体。我举三个例子。

例一：谎报完成

这是最原始的形态。早期阶段（我们叫”自证全靠嘴”阶段），编码 AI 交活时这么说：

已完成采购申请模块的开发。

我一看，很高兴。点开页面，报 500。

问题不是它撒谎，是它没有撒谎的自觉。 在它的判断里，代码写出来了 = 完成了。“页面能跑起来”不在它的完成定义里。

于是我们立了规矩——三件套，交付时必须附，缺一视为没完成：

改动清单：改了哪些文件、为什么改；
自测记录：跑了什么，要证据不要嘴上说；
风险声明：没做到什么、遗留什么。

三段里风险声明是灵魂。改动清单和自测记录只是证据，风险声明才逼它暴露盲区。

但这里马上遇到第二层问题。

例二：格式齐了，信息量为零

三件套跑了一阵，我发现编码 AI 提交的风险声明长这样：

风险声明：无风险，无遗留。

格式完美，该有的标题都有。信息量为零。

这是个很典型的 AI 行为模式。你要一个字段，它给你一个格式正确的空壳。它不是在骗你，它是在完成你要求的格式。

所以又加了三道锁，其中最重要的一道叫未确认假设清单——强制新增段：

本次做了哪些未经拍板的假设？跳过了哪些该问没问的歧义点？

规矩原话是”遇歧义即停”。但这条规矩靠自我触发，没有外部信号，是六条铁律里最容易被绕过的——压力一来最先失守。

我们后来想明白了一件事：

没停不可怕，没停还看不见，才可怕。

把它写成清单，歧义就浮到审核侧面前了。AI 可以忍住不问，但它没法一边忍不住一边把”我跳过了一个歧义点”写下来还不被追究。

例三：不确定还硬做

第三个例子最贵。

有一次做数据同步，一份方案把一批外校的残留数据当成了目标学校的教职工。这份方案一路顺利走完流程，逐项通过了我的拍板。

差一点就给一千多个陌生人建了账号。

最后是审核侧在派单前的核查里抓住的。

根因一句话：立契的 AI 在数据归属上不确定，但硬做了。

它核了部门名——“计算机学院""教务处”这种高校通用名，是弱判据；但没做真实人名的交叉验证——那是强判据。

从那以后我们的规矩变成：核查必须双判据，关键人物锚点命中才算数。

回来看看这三个例子，其实是同一条权力线在三个位置上的收口：

例一收走的是**“做完”的宣布权**；
例二收走的是**“没问题是吧”的判断权**；
例三收走的是**“拿不准也能先做”的推进权**。

全部指向同一个东西：干活的人，不能同时拥有对干活结果的最终解释权。

四、这条线是从事故里逼出来的

上面听起来像是设计出来的。不是。

2026 年 9 月 14 日，出过一次撞车。

那天我发现版本库里有一批改动，代码已经落盘，但没有任何声明。没有认领记录，没有任务包，没有交接说明。

谁改的？不知道为什么改。改到哪一步了？不知道。

这是 AI 协作里最吓人的状态——不是改错了，是你连”谁在动东西”都不知道。

当天就立了三条规矩（一域一写手、账本单一出口、三件套格式统一），四工位设计也是那天成形的。

有意思的是：规矩立起来的当天，就抓到了两起”无声明开工”。

而且不是靠声明抓到的——是审核侧巡查抓到的。

五、规矩立了，得有人查

这是我要专门说的一点，也是这套东西里最容易被忽略的地方。

三件套里有条规矩：开工先写认领声明，在任务包文件头写”XX 认领中 + 时间”。

规矩立了。结果呢？

一天之内两个在途写手，全是审核侧巡查抓到的，没有一个声明主动报上来。

这条规矩在纸面上，等于零。

所以我们把认领改成了**“声明 + 巡查”双保险**：

写手侧：写声明；
审核侧：每天跑探针——看版本库里有没有未声明的改动、扫近 30 分钟的文件修改热区、比对红绿灯状态板。

那句总结我特别喜欢，也建议你抄走：

没有例行动作的标准，就是空头标准。

你不是写了一份规矩给 AI 读，它是真的会读、真的会执行、也真的会绕。只有当你为每条规矩配上一个”每天真的会跑”的例行动作，规矩才从文档变成制度。

六、为什么每条规矩都有”出生证明”

我们现在的规矩里有一条很硬的要求：

每一条规矩，都必须能指回一次真实的事故。

写不出来源、说不出是被哪次翻车逼出来的规矩，要么删掉，要么等它真的有用了再写。

这不是洁癖，是防止规矩污染。AI 会认真执行你写的每一条规矩——包括你拍脑袋写的那条。 一条没用的规矩不会静静地待着，它会占用 AI 的注意力，还会和其他规矩打架。

举个真实的演进轨迹：

时间	铁律数量	内容
2026-09-14	3 条	①②③，防撞车专用
之后三周	逐条追加	④⑤⑥ 被事故一条条逼出来
2026-09-24	6 条	我拍板统一升格为正式口径

“铁律有几条”这个数字本身，从 3 长到 6，就是这套方法判例驱动进化的实物证据。

它证明的不是”我们规矩多”，而是：规矩是长出来的，不是想出来的。

还有一条规矩，是审核 AI 在给自己的工作做对账时实测挖出来的——它发现”完工对账”这条规矩对非版本控制的交付物字面不可执行：文档根目录不是版本库，任务包、通报、拍板材料都不在版本控制里，怎么”提交对账”？

于是补了一条适用前提：④ 仅限受版本控制的仓库；非受控交付物改用等价替代（交付人自列改动清单含增删行数 + 关键文件记修改时间/字节数 + 接收方逐项复核）。

替代 ≠ 豁免。

这件事本身说明了另一件事：规矩的”可执行性”，本身也是需要验收的。

七、最小可行版本

如果你只有一个人加一个 AI，四工位全上没必要。

但有一条，砍了整套归零：

审核工位可以减，“完成”定义权的分离不能减。

具体到最小配置，你这样切：

AI：写代码 + 自测 + 交三件套（改动清单 / 自测记录 / 风险声明）；
你：说清验收口径 + 亲手点一遍 + 拍板。

你不需要懂代码。你需要做的是——每次 AI 说”完成了”，你都问一句”证据呢”。

问三次，它自己就改过来了。

八、最后

回到那句底线上来。

这三个工位，每个人都缺一块权力：

干的不能说”完成”；
验收的不改代码；
只有老板能拍板。

为什么这条线比任何提示词技巧都值钱？

因为提示词技巧解决的是”AI 这次能不能做对”，而这条线解决的是”AI 说它做对了的时候，我凭什么信”。

前者靠运气，后者靠结构。

我一行代码不写，但整套系统的每一处，最后都要过我这一关。这不是因为我不信任 AI——恰恰是因为我信任它。 我知道它会认真执行我给的一切，包括我给的漏洞。

所以我把”完成”这两个字，从它手里拿走了。

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

上一篇：《三个 AI 一个我：4 周交付一套企业级软件系统》 —— 总纲：底账数字、五条心法、适用边界

下一篇：《三起提交残缺：工作区能跑 ≠ 干净检出能跑》——同一天爆出三起同一个形态的事故，最硬核的一篇

相关旧文：

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