核心礼法之一：原子执行合同与赛博起居注

目录

• 这一页解决什么问题
• 为什么它必须被理解为原子执行合同
• 为什么它是第一个扩展技能
• 原子执行合同，不是人类手写 spec，而是让执行位先递交的事前请奏
• 最简单的起手方式
• 一份合格的原子执行合同，至少包含什么
• 一个假设情景：没有原子执行合同会发生什么
• 另一个假设情景：有原子执行合同时，会发生什么变化
• 赛博起居注不是附属物，而是原子执行合同落地后的史册
• 原子执行合同和赛博起居注，不是串行关系，而是异步联动
• 一旦出现"修史倾向"，就立刻打断执行位
• 脉冲原子执行合同：为什么它比重蓝图更灵活
• 它和 spec / plan / workflow 的区别，到底在哪里
• 什么样的密度，才算真正的赛博起居注
• 什么形式，才算真正的赛博起居注
• 起居注到底记住了什么
• 为什么它能缓解第一部分的痛点
• 它为什么还能服务认知债务偿还
• 最常见的四种跑偏
• 一句话压轴
• 对应落地点
• 相关页面

这一页解决什么问题

最小闭环已经告诉你第一轮怎么跑，但只靠“先审方案、再审执行、最后验收证据”还不够。因为只要方案本身仍然太粗，执行位依然能在一堆大而化之的步骤里偷懒、漏步、跳步，最后再用一份很像样的总结把你带过去。

更关键的是：没有原子执行合同和赛博起居注，系统就很难留下真正的重构抓手，技术债务也会越来越难以安全偿还。 你今天也许还能勉强把功能推过去，等到明天要回头清债、重构、接手旧窗口时，才会发现历史已经糊成一片，没人说得清到底哪一步改坏了什么。

所以，最小闭环之后，第一个必须掌握的扩展技能就是：

• 让执行位先递交原子执行合同
• 再把每一次清晰状态跃迁写进 赛博起居注

这页要回答的就是：为什么这不是普通的 plan 技巧，而是整套协议里第一根真正的骨头；为什么它不是更细的 checklist，而是比 spec 和普通 plan 都更高级的治理对象；为什么它能缓解第一部分已经讲过的技术失真、治理失真与认知债务；为什么它能提前为未来重构保住抓手；以及为什么没有这一步，后面的白盒对账、续命、接手与技术债务偿还都会迅速失去依托。

为什么它必须被理解为原子执行合同

因为它现在早就不只是：

• 一个更细的 plan
• 一份更清楚的 checklist
• 一张更像施工图的执行前说明

它实际上已经同时承担了：

• 执行前的边界划定
• 审计位的稳定抓手
• 人类中枢可下场接管的切口
• 脉冲开发里单次准奏的法统单元
• 长周期开发里可串联、可撤销、可追责的治理节点

所以，把它只理解成“更细的清单”，会严重低估它的法理地位。实际上，它是一种原子执行合同：

• 它规定这一步允许动什么、不许动什么
• 它规定这一步怎么验、错了怎么退
• 它规定这一步留下什么证据、对应什么提交单位
• 它让审计位和人类都能依法对照，而不是只能凭感觉追问

在帝王语境里，你也可以把它叫作事前请奏。这个别名很好，因为它抓住了它最重要的动作特征：执行位不是先动刀，而是先递折子、先请旨、先暴露自己的施工意图，等待中枢裁决。

但技术正名仍然应当是“原子执行合同”。因为真正需要被立起来的，不只是叙事张力，而是它的法理地位：

这不是更细的计划，而是深水区 AI coding 的核心治理对象。

为什么它是第一个扩展技能

从 最小闭环：一次审计版与多次审计版 往前走一步，最自然的问题就是：

方案到底要细到什么程度，才值得审？

如果方案只停留在这种粒度：

• “升级一下解析链路”
• “补一补文档生成”
• “最后再把图谱写入修一下”

那它看起来像计划，实际上仍然给执行位留下了太多黑箱空间。你很难知道：

• 它到底准备先改哪个函数
• 哪一步才算真正做完
• 哪一步失败后可以最小回滚
• 哪一步和下一步之间存在硬依赖

要真正理解这一步，最好先接受 01-哲学与坐标/ 已经立住的两个现实：

• AI coding 改变了开发者的位置，人类开始承担委派、路由、审计与接手职责
• 黑盒多-Agent 最危险的地方，是技术失真与治理失真会一起发生

原子执行合同与赛博起居注，正是对这两个现实的第一层应对。它们不是为了显得更严谨，而是为了让执行位失去“在粗计划里摸黑施工”的空间。

原子执行合同，不是人类手写 spec，而是让执行位先递交的事前请奏

这一点必须钉死：原子执行合同，不是让人类先花半小时手工列完 todo，也不是让你自己先写一份漂亮的 spec。真正的做法是——先要求 IDE 执行位自己递交一份足够细、足够硬的合同，再由人类与 Web 审计位来裁决它是否合格。

这和很多 plan/spec 模式的差别在于：

• 普通 plan 往往只是告诉 AI “大概分几步做完”
• 原子执行合同要求执行位先交代“每一步具体改什么、怎么验、错了怎么退、这一步的边界是什么、证据长什么样”

所以它不是风格更好的计划，而是一种更难糊弄人的施工合同。你真正做的事情，不是亲手写合同，而是用一句短指令把执行位逼到必须先请奏、先递交合同、再等裁决的位置上。

如果你第一次上手，不用把它理解得很重。你只需要记住一个非常简单的原则：

不要让执行位给你大而化之的模块计划，要逼它细到函数修改、测试点设立、产物检查，并且让审计位能逐条对账。

最简单的起手方式

你完全可以直接这样跟 IDE 说：

我要做这件事：<你的需求>

先别直接改代码。
先给我一份尽可能细的原子执行合同。
尽量细到：改哪个函数、加什么测试点、看什么结果算通过。

如果你想再说白一点，可以再补一句：

不要给我大而化之的计划。
尽量按函数修改、测试点设立、产物检查来拆。

这两句话已经足够启动第一轮。你不需要自己先写出完整合同，也不需要一上来就知道全部技术细节。原子执行合同的目的，恰恰是让执行位先把自己准备怎么做、允许怎么做、准备留下什么证据，一次性暴露出来。

一份合格的原子执行合同，至少包含什么

最实用的判断标准，不是字数长短，而是它有没有真的长成合同，而不只是 checklist。你可以用这个很简单的尺子去看：

• 能不能看出具体会改哪个函数或哪一层逻辑
• 能不能看出这一步的测试点或验收点是什么
• 能不能看出失败后最小回滚点在哪里
• 能不能看出它和下一步是什么关系

也就是说，一份合格的原子执行合同，至少要回答四件事：

1. 这一步只动哪一块
2. 这一步怎么验收
3. 这一步失败时退到哪里
4. 这一步和下一步怎么衔接

如果你已经开始进入更稳定的 Skill 或高治理工作流，成熟版本通常还会继续带上这些字段：

1. 哪些文件允许动，哪些文件明确禁触
2. 当前 Red Line 是什么
3. 哪些 Green Tests 通过才算这一步成立
4. 这一步对应什么提交单位与什么目标产物
5. 验收阶梯要走到哪一级，才算这一步真正成立

这里有一个非常容易混淆的小坑，必须钉死：

Red Line 不是红灯测试。

它们分别属于两层法统：

• 合同表格里的 Red Line 属于治理层，回答的是：这一刀哪些线不能越、当前最危险的失败态是什么、哪类越界一旦发生就必须停刀
• 白盒验收里的 red_test / green_test 属于验证层，回答的是：修复前这条测试线会不会咬人、修复后同一问题有没有真的转绿

所以，Green Tests 也不独自承担整个白盒故事。它只是合同表格里的通过门；真正的白盒闭环还需要第二部分 YAML 把验证关系补完整。

第二部分 YAML 不是杂项补丁，而是白盒验收桥梁

边界条件与测试用例键值对 这个 YAML，不该只是一棵泛化测试树，也不该只是把零散边界条件塞进角落里。

它真正该承担的职责，是把治理层合同和白盒验收链接起来。

最稳的做法，是让它显式带上这些结构：

• assertions：这一步到底在声称什么完成事实
• red_test：修复前必须能失败、能咬人的那条测试线
• green_test：修复后同一条测试线的通过验证
• same_case_requirement：绿灯必须对应同一红灯，不许换题偷跑
• physical_evidence：日志、工件、外部回写、数据库结果等物证

也就是说，合同的两部分应该这样分工：

• 第一部分表格：管治理边界、动作颗粒度、提交动作、验收阶梯
• 第二部分 YAML：管白盒断言、红绿灯链、同案要求、物证桥梁

如果没有这层桥梁，执行位就很容易把“这一步有风险”和“这条测试线红过了”混成一句模糊话；而审计位也会失去最重要的抓手：到底是哪条断言，从哪条红灯，转成了哪条绿灯，最后靠什么物证站住。

比如，下面这两种写法，差别就非常大。

不合格的写法：

• “升级一下解析逻辑”
• “补文档生成”
• “最后处理图谱关系”

更接近合格的写法：

• “扩展 parseInputBundle()，让它返回新增字段”
• “给缺失时间戳的输入补显式报错，而不是静默跳过”
• “跑一个真实样本，检查输出文档里是否出现交叉引用”
• “验证结构化结果是否真正带上新增关系字段”

你会发现，后面这种写法一旦递交出来，审计位就有地方下手了。它可以质疑：

• 这一步为什么没有测试点
• 这一步为什么没有真实产物验收
• 这一步是不是其实包含了两层改动，被故意揉成一条

这就是原子执行合同的第一层价值：让方案本身先变成可审、可裁、可追责对象。

一个假设情景：没有原子执行合同会发生什么

假设你有一个旧同步脚本，现在只能把远端数据粗糙拉下来，直接落成一份本地文件。你想把它升级成：

• 先做鉴权检查
• 再做分页拉取
• 失败时留下明确错误日志
• 最后再落一份结构化结果

如果没有原子执行合同，最常见的走法会是这样：

• 你说一句“把同步脚本升级一下”
• 执行位回一句“没问题，我来处理”
• 然后它同时改鉴权、拉取、错误处理、落盘和测试
• 最后丢给你一份“都已完成”的汇总

看起来很顺，问题却也会很顺地被埋进去：

• 它可能根本没有先后顺序，只是在多处同时试错
• 它可能把两三个困难步骤揉成一句轻描淡写的话
• 它可能用模拟结果先把汇报做漂亮
• 真出问题时，你根本不知道是哪一层先偏了

这正好对应 黑盒多-Agent 的双重失真：技术失真与治理失真 里讲的那两种塌陷：

• 技术上，你会得到一份看似推进、实则混浊的中间状态
• 治理上，执行位会顺手兼任计划制定者、执行者和结果解释者

所以没有原子执行合同时，所谓“方案”并没有真正减少黑盒，只是把黑盒前置成了一段更像样的话。

另一个假设情景：有原子执行合同时，会发生什么变化

还是同样这个任务。如果你要求执行位先交原子执行合同，它就不能再只说“我会升级同步脚本”，而必须把自己暴露在更细的颗粒度上。比如：

• 先补鉴权检查函数与失败日志
• 再加分页拉取与页码边界测试
• 再补结构化落盘字段
• 最后跑一个真实样本，看落盘结果和错误日志是否都符合预期

一旦方案细到这个程度，事情会发生三个变化：

第一，审计位终于有地方能挑毛病

如果某一步太粗，Web 审计位马上就能指出：

• 这条其实包含两步
• 这条没有验收标准
• 这条说了要改，但没说最终看什么结果算通过

这时审计位不再是陪聊窗口，而真正变成了方案级审计位。

第二，人类终于有地方能打断

当执行位开始真正动手时，人类能看着合同去盯：

• 你现在是在做第几步
• 你有没有突然越界去做第七步的事
• 你是不是把两步揉成一团了

没有这种合同，人类的打断往往只能靠直觉；有了这种合同，人类打断就有了制度依据。

第三，结果终于能和过程对上号

执行结束后，你不再只拿到一串“已完成”，而是可以逐条问：

• 第 1 步的证据呢
• 第 2 步的测试点呢
• 第 3 步的真实产物呢

这就意味着，完成事实不再是一团混合叙事，而开始和合同里的具体动作一一对应。

赛博起居注不是附属物，而是原子执行合同落地后的史册

原子执行合同的下一步，自然就会长出赛博起居注。

原因很简单：只要你真的按这种合同推进，每一次清晰状态跃迁都天然适合留下一次提交记录。于是起居注就不再是额外负担，而变成原子执行合同落地后的副产物。

这也是为什么 README 里会说：

一条合同项对应一次清晰状态跃迁，一次跃迁对应一个可追溯提交。

很多人第一次看到“高频 Git 提交”会本能抗拒，以为这是形式主义。真正的问题不是提交次数多，而是：没有这种细粒度史册，后面的所有事都会一起变难：

• 回滚变难
• 排错变难
• 接手变难
• 续命变难
• 重构变难

所以赛博起居注不是“写给 Git 看”的，而是写给未来还要接手这段历史的人看的。

还有一点在 AI 时代尤其值得强调：原子提交这种原本很费手、很费心的苦差活，现在完全可以交给执行位去做。

在纯手工编码时代，很多人排斥高频提交，是因为这件事确实烦：

• 要自己停下来分段
• 要自己想每次提交的边界
• 要自己写清 commit message

但在 Cyber-Ming-Protocol 里，这一层苦活恰恰最适合外包给 AI。对人类来说，很多时候它真的就是一句 prompt 的事，比如：

把当前改动按功能点拆分提交。
不要一团乱麻一起 commit。
每次提交都说明：这一步改了什么、验了什么、解决了什么问题。
做完后把 git log 给我看。

也就是说，人类真正要做的，不是亲手完成这些琐碎断代，而是要求执行位把断代史写清楚、切清楚、呈上来给你裁决。这个变化非常关键：它让“保留重构抓手”这件事，不再主要消耗人的体力，而更多变成一种制度要求。

原子执行合同和赛博起居注，不是串行关系，而是异步联动

这里还有一个必须讲清楚的点：原子执行合同和赛博起居注，不是“先把整份合同做完，再回头统一提交”的串行关系。

真正的做法应该是：

原子执行合同完成一项，就立刻留下对应的一项起居注。

也就是说：

• 第 1 项做完，就提交第 1 项
• 第 2 项跑通一个最小测试点，就提交第 2 项
• 第 3 项修掉一个真实报错，就提交第 3 项

不要把整份合同全部做完，再回头统一整理提交记录。

为什么？因为只要你允许执行位“做完整张合同再统一修史”，它就会天然拥有太多春秋笔法空间。它可以：

• 把中途的混乱过程抹平
• 把原本跳步的推进包装成整齐历史
• 把多层动作事后改写成一条看起来合理的路径

这样写出来的就不再是起居注，而更像修史。

所以你可以记住一个很简单的动作原则：

做完一项，立刻留痕；不要做完整张合同，再回头补历史。

一旦出现“修史倾向”，就立刻打断执行位

如果你发现执行位开始出现下面这些倾向，不要等它“都做完了再说”，应该立刻打断并勒令改正：

• 合同已经推进了好几项，却还没有留下对应提交
• 多个功能点被揉成一团，准备一次性统一 commit
• 它开始说“我等全部完成后再一起整理提交”
• 它试图事后把本来混乱的过程包装成一条干净历史

这时最简单的处理方式就是直接下令：

停一下。
不要等整份清单做完再统一提交。
把已经完成的功能点按原子执行合同逐项拆开留痕。
每完成一项，就提交一项，然后把 git log 给我看。

这不是吹毛求疵，而是在防止执行位事后改写开发史。现在多打一刀，后面就会少很多“到底是哪一步把这里改坏了”的烂账。

脉冲原子执行合同：为什么它比重蓝图更灵活

原子执行合同真正好用，不只是因为它细，还因为它天然适合脉冲式推进。

所谓脉冲，你可以先理解成一句很简单的话：

不要一次把整张重蓝图压到项目头上，而是让一小段可验证的合同先跑通，再决定下一小段怎么改。

这正是它和传统 spec 蓝图法很不一样的地方。

重蓝图法的问题不在于不清楚，而在于太重：

• 前期写得很满
• 一旦方向变了，整张图都要重画
• 业务逻辑一变，前面很多规划瞬间过时

而脉冲原子执行合同的优势是：

• 船小好掉头
• 一次只压一小段真实推进
• 每跑完一个脉冲，就能根据现实结果修正下一段
• 业务逻辑变了，下一个脉冲就能改过来

也就是说，它不是不要规划，而是拒绝把规划一次性压得太满。它更像这样：

• 先跑通一小段
• 留下起居注
• 看看真实结果和真实阻塞点
• 再决定下一小段合同怎么改

从这个角度看，原子执行合同和起居注不仅是防伪机制，也是灵活推进机制。它们让你避免落入那种“蓝图很完整，但现实一变就整片失效”的困境。

它和 spec / plan / workflow 的区别，到底在哪里

这一段尤其是写给第二类读者的：

不是完全没用过 workflow 的人，而是已经认真用过 workflow / spec-driven 开发，开始感觉自己被反噬的人。

这类人最常见的困惑不是“为什么没人管”，而是另一种几乎相反的问题：

• 一开始的 spec 写得很完整
• workflow 看起来也很规整
• 但项目形态被定得太早、太死
• 一旦中途认知升级、想法变化、结构目标转移，调整成本就一路抬高

最后你会开始产生一种很怪的感觉：

自己好像不是在继续做产品，而是在维护一份越来越沉重、越来越不肯呼吸的先验蓝图。

原子执行合同和这种重 spec 最大的差别，不在于它“更细”，而在于它把 planning object 整个换掉了。

它不再要求你把整张未来蓝图一次写满，也不满足于只给一个轻量 plan 让执行位自由发挥。它真正要求的是：

• 先把下一小段真实推进压成一份可审、可验、可退、可留痕的合同
• 先跑通这一小段
• 用真实结果、真实阻塞和真实证据，决定下一小段怎么改

也就是说，它既不是重 spec，也不是轻 plan，而是一种更适合深水区 AI coding 的中层治理对象。

如果把三种东西并排看，差别会更清楚：

维度	重 spec / 冻结型 workflow	普通 plan / 轻计划模式	原子执行合同
重量	前期一次写得很满	文字轻，但约束也轻	骨架稳定，单片重量可控
灵活性	方向一变，整张蓝图重画	灵活，但容易失控	脉冲修正，边走边校
约束力	强，但常常把项目钉死	弱，靠执行位自觉	强，且只压当前片
审计抓手	常停留在高层意图	抓手很散，难逐条对账	直接落到当前片的动作、验收、Red Line、证据与回滚
长周期串联	往往靠维护大蓝图	容易随着对话流漂移	多份合同可以脉冲串联成长期法统
人类下场审核	往往要重读大量上下文	经常只能靠直觉	可逐条审 Allowed / Red Line / Green Tests / Target Artifacts
输出骨架稳定性	很重，且每次重写代价大	很活，但格式容易漂	字段骨架稳定，更容易命中固定输出形态
缓存 / 成本优势	文字常太重	反复即兴，容易重说	由于骨架稳定、重复率高，通常更容易命中稳定输出骨架，也往往带来一点成本优势
人的感觉	像在维护一份不肯呼吸的蓝图	像在盯一场随时跑偏的 improvisation	像在依法推进一个仍能继续生长的产品

这就是为什么我说它不是“比 spec 更细”，而是比 spec 更高级的治理形态。所谓“更高级”，不是它更抽象，而是它第一次把这些原本互相打架的东西重新配平了：

• 要灵活，但不放松约束
• 要有抓手，但不把项目写死
• 要支持长周期，但不靠一份巨型蓝图维持秩序
• 要让模型稳定输出，但不把 prompt 变成难以维护的重文档

这也是为什么它对现实阻塞、方向变化、错误前提暴露都更敏感：

• 它对现实阻塞更敏感
• 它对方向变化更敏感
• 它对错误前提暴露得更早
• 它不需要等整张 spec 失效后才承认该改向

前面的两个样本，其实已经把这件事证明得很清楚。

在 0 里，执行位一开始递交的是一份通过初审的函数级原子执行合同。这说明原子执行合同不是“不要计划”，而是先交一份足够可审的施工骨架。但后面真实运行一旦暴露 401 和图数据库导入错误，整轮推进仍然可以依法撤销、重审、改向，而不是因为前面 spec 已经写得很体面，就被迫继续沿旧路线硬推。

在 0 里，系统一天之内发生了三次明确跃迁。这里最值钱的不是“提交很多”，而是主线重心真的在变：统一入口、工作区语义、并线会师、工件中枢接管主链。假如这里采用的是一张前期一次定死的重 spec，很多中途的结构改制都会变成“偏离蓝图”；但在脉冲原子执行合同的逻辑里，它们恰恰可以被视为认知升级后对下一脉冲的正当修正。

所以原子执行合同真正要保住的，不只是秩序，还有生长能力。

我反对的，从来不只是“没人管”的黑盒失控；我同样反对那种把项目过早钉死、最后让人只能继续维护蓝图而不是继续做产品的冻结型 workflow。原子执行合同之所以值钱，正是因为它试图在这两种失真之间，保住一种：

• 可治理
• 可审计
• 但仍允许项目在推进中继续生长、改向、续命

这就是它和传统 spec 蓝图法真正不同的地方。

什么样的密度，才算真正的赛博起居注

很多人一听“高频 Git 提交”，要么理解成每改两行就提交一次，要么理解成下班前统一打一包。这两种都不对。

真正好用的密度，其实可以记成一句非常简单的话：

每一次清晰状态跃迁，留一次提交。

什么叫“清晰状态跃迁”？你可以用最朴素的标准判断：

• 这一步已经能单独说清自己解决了什么问题
• 这一步已经有一个最小验收结果
• 这一步现在回滚，不会把后面几层一起拖下水

如果这三个条件都成立，通常就值得留一次提交。

太粗的密度长什么样

下面这种一般就太粗了：

• 一次提交同时改了鉴权、分页、落盘、日志、测试
• 一次提交里既有新功能，又有顺手重构，又有 bug 修补
• 提交完以后，你自己都说不清“这一刀主要想解决什么”

这种提交看起来省事，实际上会直接削弱起居注的价值。因为你以后回头看，只会看到一团混合动作，而不是一段清晰的开发历史。

太细的密度长什么样

反过来，也不是越碎越好。下面这种就往往太细：

• 改一个变量名就单独提交，但它本身不构成状态跃迁
• 刚写半个函数、还没法验证，就急着提交
• 一个完整动作被切成七八片，最后谁也看不懂前后关系

这种提交虽然很多，但不叫起居注，更像噪音流水账。

最实用的密度规则

第一次上手时，你完全可以先用下面这个很简单的规则：

• 改完一个功能点，提交一次
• 跑过一个最小测试点，提交一次
• 修掉一个真实报错，提交一次

如果你现在能自然说出：

• “这一步是补鉴权检查”
• “这一步是接上分页拉取”
• “这一步是把错误日志补出来”

那通常就已经到了值得提交的粒度。

什么形式，才算真正的赛博起居注

密度之外，形式也很重要。很多人虽然开始高频提交了，但写出来仍然不是起居注，而是“高频糊涂账”。

一个真正有用的起居注，至少要让后来的人看懂三件事：

• 这一刀在解决什么问题
• 这一刀主要落在哪一层
• 这一刀和前后动作是什么关系

所以最差的写法通常是这种：

• misc fixes
• update code
• wip

这种提交即使很多，也几乎不能服务重构、接手与还债。

更像起居注的写法，通常会更接近这种形式：

• fix(auth): add token validation before sync
• feat(sync): add paginated fetch for remote items
• test(sync): cover page boundary and empty response
• fix(export): log explicit error on malformed payload

如果仓库习惯允许，在提交正文里再补 1 到 3 行也会更强，比如：

• 改了哪个函数
• 验了什么点
• 为什么这一步要先于下一步

你不用把每次提交都写成长文，但最好让后来的人一眼看出：这不是随手一堆 diff，而是一段能还原的开发史。

起居注到底记住了什么

赛博起居注记住的，不只是“这次我改了哪个文件”，而是更值钱的东西：

• 这一步解决的是什么问题
• 这一步改动落在哪一层
• 这一步验证过什么
• 这一步和前后两步的关系是什么

这也是为什么真正好的起居注，不适合是那种“misc fixes”式大杂烩提交。它更像一份极细密的断代史。

假设你有这样一串记录：

• 扩展关系提取提示与返回结构
• 补结构校验与序列化逻辑
• 接上文内交叉引用生成
• 更新结构化结果落盘
• 修正真实运行时暴露出的变量错误

这串记录的价值不在于它整齐，而在于：你以后回头看时，知道系统是怎么一步一步长成现在这个样子的。也正因此，当窗口腐烂、执行位更换、理解开始下降时，你不必整片重啃代码海，而可以沿着最近几次状态跃迁迅速抓住主线。

为什么它能缓解第一部分的痛点

如果不把这一页放回 01-哲学与坐标/ 已经建立的现实里看，原子执行合同和起居注很容易被误解成“只是更细的流程管理”。

它们真正缓解的，是第一部分已经讲清的几类结构痛点。

第一，缓解“位置变化”带来的治理压力

在 为什么 AI Coding 已经模糊了 CS 与管理学的界限 里已经说过，人类在 AI coding 里开始承担委派、路由、审计和接手职责。原子执行合同的作用，就是把这种职责从抽象压力变成可执行动作。

你不需要凭空在脑中统治全局，你只需要先逼执行位把计划交细，再决定是否放行。

第二，缓解“局部半黑盒”带来的理解成本

同一页里也讲过：AI coding 会把系统推向局部白盒、局部半黑盒状态。既然你不可能每一步都重新完整看白，那你就更需要：

• 细粒度清单
• 细粒度提交
• 细粒度状态跃迁

它们不是为了让你理解得更多，而是为了让你在理解受限时，仍然能在关键地方抽查得更准。

第三，缓解技术失真

在 黑盒多-Agent 的双重失真：技术失真与治理失真 里，技术失真的一个核心症状就是：错误会伪装成推进。

原子执行合同对这件事的第一层缓解，是让“推进”必须先落到具体动作和验收标准上。赛博起居注的第二层缓解，则是让“我真的做过这一步”必须落到历史记录上。

这会极大降低那种“说起来做了很多，实际上什么也没钉死”的空间。

第四，缓解治理失真

治理失真的核心，是执行位兼任计划者、执行者、结果解释者。原子执行合同的作用之一，就是先把它的计划暴露出来给人看；起居注的作用之一，则是把它的推进轨迹固定下来，防止它事后随意改口。

换句话说：

• 原子执行合同是在执行前削弱它的黑箱空间
• 赛博起居注是在执行后削弱它的叙事空间

它为什么还能服务认知债务偿还

这一步非常重要，也是很多人第一次不会想到的地方。

赛博起居注不只服务回滚、排错和重构，它还服务认知债务偿还。

原因在于：AI 时代真正变快的，是产码与改码速度；人类对项目重新看白的速度并没有同步增长。于是只要项目足够长，认知债务就一定会开始堆。

这时起居注的作用就出来了。它让你在掌控力开始下降时，不必重新啃整片代码海，而可以先抓最近的状态跃迁。

你甚至可以直接开一个新窗口，对执行位说：

先不要继续改代码。
先读最近的 Git 提交记录，按功能点告诉我：
1. 最近改了哪些函数
2. 每次改动想解决什么
3. 现在如果我要继续改 X，应从哪次提交继续看

这一步看起来很朴素，但它之所以可靠，恰恰是因为前面已经有了足够细的起居注。没有清晰史册时，这种“还债问答”只会回到黑盒即兴解释；有清晰史册时，它才会变成一种灵活、急速、可信的认知债务偿还方式。

最常见的四种跑偏

第一种：把原子执行合同写成模块级口号

只要还是“升级这一块”“优化那一层”这种粒度，它就不是原子执行合同，只是换了个名字的粗计划。

第二种：把验收标准写成空话

没有验收标准的清单，等于在邀请执行位事后自己解释“我觉得差不多算完成”。

第三种：把细清单落成粗提交

这会让方案和历史脱节。你表面上有了好看的清单，实际上仍然没有真正的赛博起居注。

第四种：把起居注理解成机械次数要求

关键不是“每两函数必须一提交”这种机械口号，而是：每一次清晰状态跃迁，都应留下可追溯史册。不要机械，但也不要糊成一团。

一句话压轴

原子执行合同与赛博起居注之所以是第一个扩展技能，不是因为它们更精致，而是因为它们第一次真正把“方案、执行、验收、历史”这四件事钉成了一条可审、可停、可追、可接手的链。

没有它们，最小闭环仍然可能跑起来；有了它们，最小闭环才开始真正长出骨头，而原子执行合同也才会从计划技巧升格成正式治理对象。

对应落地点

手工实践方式

• 手工要求执行位先交原子执行合同，至少写清“动哪一块、怎么验、失败退到哪、与下一步怎么衔接”；如果能做到，再继续补 Allowed / Red Line / Green Tests / Target Artifacts
• 每完成一个清晰状态跃迁，就立刻留下对应提交，不要做完整张清单再回头补历史
• 审计时逐条对照清单、提交与证据，而不是只听一次总汇报

对应 Skill

• approval-first-planner 负责把“先交可审批清单”稳定下来
• approved-checklist-executor 负责把“按片执行、按片验证、按片归档”稳定下来
• global_rules 负责把“一片一验一提交”的底线钉住

对应 Web 模板

• 当你要审这份清单是否够原子、够清楚，优先用 plan_audit_template.md
• 当你要检查清单项是否真的落成对应证据与提交，优先用 completion_audit_template.md
• 如果你还没分清 Skill 与模板的边界，可回看 0

相关页面

• 最小闭环：一次审计版与多次审计版
• 白盒物理对账：什么算完成事实
• 赛博探马机制：先试链路，再上大军
• 为什么 AI Coding 已经模糊了 CS 与管理学的界限
• 黑盒多-Agent 的双重失真：技术失真与治理失真