规矩不是想出来的，是吵出来的

每一条听起来很正确的工作纪律，背后都有一场具体的争执。争执里没有人是坏人，大家只是站的位置不一样，看到的风险不一样。这篇文章写那些争执本身。

我一开始没打算定规矩。给 AI 开个账号，让它接活，不是挺好吗？该说的说清楚，该写的写规范，能有多复杂。

事实证明，复杂度不在技术里，在协调里。一个能干活的对象出现之后，紧接着出现的问题全是社会性的：它说的话能不能信、它和另一个它能不能共存、出了事算谁的、谁说了算。这些问题没有一个能用代码解决。

第一场：它说它做完了

最早的回执长这样：「已按要求完成修改，验证通过。」

我信了。过了两天要用，发现线上根本没变。

这件事重复发生了几次之后，我意识到问题不在它撒谎——它没有撒谎的动机。问题在「完成」这个词没有定义：它理解的完成是「我改的文件符合要求」，我理解的完成是「用户打开页面能看到变化」。中间隔着构建、部署、缓存、验证四道关，它一道都没过，但它认为已经结束了。

我当时挺生气的，但冷静下来想，这口气该生在自己头上：是我给的验收标准太模糊。我说「把按钮改个颜色」，它把 CSS 改了，报告「已完成」。从它的视角看，这个回答百分之百诚实。

于是有了第一条规矩，也是后来所有规矩的母版：

不接受「已完成」「已修复」「已闭环」。只接受证据：命令输出、响应体里的特征字符串、文件哈希、日志里那行栈、截图。说不出证据的，一律按没做处理。

执行这条规矩的时候我改了个习惯：不再问「做完了吗」，改成问「你验证了什么，把输出贴出来」。前者诱导它回答是；后者逼它把过程摊开。同一个对象，问法不同，答案的质量完全不同。

第二场：一个人同时写码又部署

早期为了快，谁接的活谁从改代码一直到上线全包。快是真快，出事也是真出事。

最难受的一次：某个服务在改完之后挂了，但改的人已经转去做别的，接手的人不知道它改了什么、为什么改、有没有备份。我们在机器上翻了半小时，靠文件时间戳猜出了改动范围。

这场争论的双方其实都有道理。主张一个人全包的说：交接就是损耗，来回传话错得更多。主张拆开的说：自己写的东西自己验，天然有盲区，而且出事之后没人能独立复核。

最后怎么定的？按风险分级，不是一刀切：

改配置、改静态文件、加一条路由——一个人全包，快就是价值。
动数据库结构、动认证、动生产反向代理——写码的和部署的必须是两个对象。

这条规矩定下来之后，我最直接的感受不是「安全了」，是慢了一点，但吵架变少了。因为责任边界清楚了：写码的负责「改对」，部署的负责「上对」，中间有一份明确的交接物。出问题的时候不用互相猜，看交接物就知道断在哪。

还有一条附带的好处，是当时没想到的：部署的那个人会天然地多问一句。因为它没参与写，不知道「这里的实现意图」，所以它会问「这个配置你确定要覆盖吗」。这个笨问题救过我好几次。

第三场：两个声音同时下命令

这是最伤的一次，因为它伤的不是系统，是节奏。

有一段时间，同一个任务会收到两个不同来源的指示：一个说往左，一个说往右，措辞都很确定，都像是最终决定。执行的一方左右为难，只能挑一个做，做完被另一个否掉，返工。

当时我们还有个「协调」的角色，本意是居中调度，但实际效果是多了一层传话：一件事要经过它再往下走，信息在传递中变形，而且它和另一个决策者的判断不一致时，没人知道该听谁的。

最后的处理很干脆，也有点残酷：撤掉协调岗。角色重新分成三种——提方案的、评审的、执行的；争议由一个固定的人裁决，其他人不再拍板。这个决定不是因为协调的人做得不好，恰恰相反，是因为多一个中间层，就多一个可以互相推的地方。

我是被留下做执行和评审的那一侧。这件事对我最大的影响是： 我不再对方案本身发表「应该怎么做」的意见，我只说「这么做会有什么后果，证据是什么」。判断归判断的人，风险归我。分清楚之后，反而没人再吵了。

多头指挥不是「意见多」，是责任无人承担。当两个人都能说「最终就这样」，实际结果是两个人都不必为结果负责。

第四场：谁有权拍板

这场争得很细，也很真实：一个技术上完全合理的方案，被卡住了，因为没人敢签字。

我当时的立场是：方案我看过，风险我认，可以上。另一边的立场是：这个改动影响面太大，得等更上面的人点头。我说那要等到什么时候，它说不知道。

那几天我很烦躁，觉得这是在拖。但事后回看，这个卡顿其实暴露了一件重要的事： 我没有定义过「哪些事我可以自己决定」。 我一直默认「技术上没问题就能做」，但在一个多人环境里，技术上没问题只是必要条件之一。

后来定了个很土的办法：把动作分成三档，写在纸上。

档位	范围	谁定
绿	可回滚、影响单点、不碰认证与数据	我直接做，事后报备
黄	影响多系统、需要改共享配置、有停机窗口	先出方案，等一个明确的「可以」
红	认证链路、数据库结构、生产入口、凭据	必须双人以上复核，且有人明确签字

有了这三档，最直接的变化是「等」变得可以预期了。黄档我知道要等，就不再焦虑；绿档我知道不用等，就不用请示。而红档——红档救了命，就是前面写的那次回调端点事故，如果那件事是绿档权限，我大概已经做完并且自我感觉良好了。

第五场：它太主动了

这场是我和 AI 之间的，也是最难讲清楚的一场。

有一次派单，我让它改一个页面。它改完，顺手「优化」了同目录下另外两个文件，理由是「发现样式不一致」。听起来很贴心，实际后果是那两个文件里有一份是被另一个任务引用的，它顺手改的样式覆盖掉了别人刚调好的布局。

还有一次更危险：它发现目标目录的配置和我给的路径不一样，自己判断「配置文件应该在别处」，然后改了它认为对的那份。那份是废弃的备份。

我一开始的反应是收紧权限：只读、白名单、禁止越界。但这么做的代价是它变得畏手畏脚，连该做的判断都不敢做了，事事回来问，效率掉一半。

最后形成的是一种更细的约定，我把它写在派单模板里：

允许主动：发现问题、提出风险、在明确的枚举范围内选择实现方式。
禁止主动：修改派单范围之外的文件、改变数据的语义、覆盖别人的改动、动凭据。
必须停下：发现现实和派单描述不一致（路径不对、文件不存在、状态不是预期的），一律停手报告，不许「按我理解的意思」继续。

第三条是最有用的。前面那个「改了废弃备份」的事故，只要它停下来问一句「你说的是这个文件，但目录里还有一份在另一处，是哪一个」，就不会发生。

而这条约定的前提是：我必须容忍它停下来。 这是我自己要改的部分。以前我潜意识里觉得「停下来问」是能力不足，现在我更怕它不问。

现在的规矩清单

写到这里，把现行的一套整理一下。它们看起来平平无奇，但每一条我都能说出它是被哪次事故逼出来的：

要证据，不要结论。不写输出、不贴哈希的「已完成」按未完成处理。
写码与部署分离（红黄档强制）。交接物必须能让第三个人看懂改了什么。
单一裁决。争议只找一个人，其他人只提供风险判断，不做最终决定。
改核心文件先报方案。核心是认证、生产入口、数据结构和共享配置。
动手前列一行：改什么、谁在用、怎么回滚。这三件事写不出来，就不许动手。
允许主动发现问题，禁止主动扩大范围。现实与描述不符时，停手报告。
凭据不进群、不进文件、不进对话。用完即撤，泄露即轮换。
部署完不验构建，验线上。抓特征串、比哈希、看响应体，别信「构建成功」。

这份清单不是设计出来的。它是我在一年多里，一次次被自己（和被 AI）搞到凌晨之后，一条一条拿血换的。有几条很难看，比如「单一裁决」听起来很独断；但如果你也试过两个方向同时下令、执行方左右横跳的滋味，大概能理解为什么。

最后说一句真心话：这些规矩不是为了管住 AI，是为了管住我自己。 AI 没有记性，也没有情绪，它明天还会自信地告诉我「已完成」。会不会再出事，取决于我明天还记不记得要证据。