返回学习资料
AI 是黑箱，你不知道它为什么这样输出，但你得拿到你要的东西。
一套借自控制论的交付控制结构，以及它是怎么搭出来的。
快和乱是一体的：写得越快，模糊的地方被填得越快，而且每次填的都不一样。
你不知道它为什么这样输出，也不能保证下次输出一样。
但你必须拿到你要的东西。
人也是黑箱。区别在于 AI 的输出方差更大、单次成本更低——同样的模糊，代价被放大了。
让 AI 在尽可能多的情况下、尽可能大的范畴里，
高效、高质量地自主完成交付。
"尽可能多""尽可能大"是这句话的重点：不是让 AI 在人盯着的时候干活，是把人盯着的范围不断缩小。挡在这个目标前面的，就是下一页的问题。
如果 AI 就是个黑箱，
怎么确保获得自己想要的产出？
先修正一个词：控制论不承诺"确保"，只承诺偏差可观测、可校正、收敛在你能承受的范围内。这场讲的就是怎么做到这三件事。
Ashby 在 1950 年代研究黑箱时的结论：你不需要知道里面是什么，只需要掌握输入和输出的关系，并且能持续校正。
整个回路存在的意义只有一个：让实际值逼近目标值。目标值必须可测——"让屋里舒服"不行，"26 度"才行。目标值是人定的，空调不会自己决定该几度。
验收标准是什么？一句话：定义"完成需要什么证据"。
不是描述你想要什么，是描述怎样才算拿到了。26 度是证据，"舒服"不是；"点击后两秒内看到结果"是证据，"体验流畅"不是。写不出证据，就没有任何控制可言——传感器不知道该测什么。
从这里开始不再说"目标值"，直接说验收标准。
产品经理写需求，附几条验收标准，开发拿到就开始做。开发人员的心智模型是：验收标准是输入，代码是输出。
验收标准写得糙也没关系，因为执行的是人。人会在开发过程中自己补——
人类开发者一直在无声地替验收标准做收敛，只是没人把这叫收敛。
验收标准里的每一处模糊，过去由人的判断吸收，现在直接变成输出的方差。
过去人在执行中替你补齐了验收标准。
现在没有人了，你得先把它补齐。
验收标准从"给定的输入"变成了"必须先被生产出来的产物"。"完成需要什么证据"这个定义，是整套结构里唯一能约束黑箱输出的东西，它的质量决定后面所有环节的上限。
这么关键的东西，不能靠一个人一次写成。它自己就得经过一个回路。
一条合格的验收标准，背后要有两种判断：
用户要的到底是什么，哪些是边界，什么不做
这条能不能被测、怎么测、拆成几块才验得了
不要教 AI 怎么做事。模型里装着整个行业几十年积累的最佳实践，它做起来比 99% 的人好。别以为你比它更懂"怎么做"——你比它更懂的，是"要什么"。
| 写 | 写什么 |
|---|---|
| 目标 | 做完之后，用户能做到什么、看到什么。这是验收标准的来源 |
| 要求 | 必须满足的约束：性能、兼容、安全、和现有系统的关系 |
| Do | 明确要做的事、必须覆盖的场景、必须保留的行为 |
| Do not | 不做什么、不能碰什么、不能改的对外契约 |
写很细的操作步骤，等于把你的做法当成了唯一解，把 AI 降级成了执行你想法的手。步骤写得越细，你替它做的决定越多，它的知识用得越少，而且步骤本身还可能是错的。
外循环产出可执行的方案，内循环负责把方案交付落地。两个循环各是一个黑箱，各自都要控制质量——外循环的输出，就是内循环的目标。
外环和内环是同构的，都由这几种角色组成。缺任何一个，回路要么不转，要么转不停。
| 角色 | 负责 | 缺了会怎样 |
|---|---|---|
| 目标来源 | 定这一轮"完成需要什么证据" | 黑箱自己定目标，做出来的是它想要的 |
| 执行器 | 改东西的唯一角色 | 两个黑箱同时改一个东西，输出没法归因 |
| 传感器 | 只找偏差，不裁定 | 没人发现偏差；或者发现偏差的人顺手就改了 |
| 控制器 | 裁定哪些偏差值得改，计轮次 | 每条意见都被改，回路震荡 |
| 终止条件 | 一个可检查的"停" | 回路转到评审者没话说为止 |
| 人 | 目标对不对、不收敛怎么办、最后收不收 | 回路能证明"和目标一致"，不能证明"目标是对的" |
传感器和控制器必须是两个独立角色。这是全场最贵的一条。
用黑箱控制黑箱，末端总有一个黑箱要靠人兜底。
但兜底的范围，应该越来越小。
人的工作不是消失了，是换了位置：
边界不是固定的。每次升级到人，都是一次问出"这一类情况能不能下次不用人"的机会：把人的判断变成可检查的规则、变成仓库里的规范、变成新的传感器。三个点里，能收缩的先收缩——收尾授权最先，可开工裁决最后。
我们可以搭流程让 AI 各种互审。
但 AI 从来不会主动质疑人类的需求本身——一次都没有发生过。
评审员能找出方案里测不了的、矛盾的、漏掉的；审查员能找出代码和方案不一致的。它们都在问"和目标一致吗"，没有一个在问"这个目标该不该要"。
所以整套结构控制得再好，人类怎么提需求，依然是最重要的交付质量变量。回路把方差压下去了，均值还是你给的。
为的是把能用的手段都讲清楚——遇到不同的问题时，你能找到对应的那一个。不是说全都必须用。
其他的——写代码、读代码、找 bug、写测试——现在的模型已经足够强，不再是问题。剩下的是结构和判断。
把控制器做出来：谁是执行器、谁是传感器、谁是控制器？
同一个队长带五支小队，同一个工程师在两支小队干活。谁是这局的谁，由花名册决定。
对应理论：控制结构不是一个黑箱，是把黑箱拆成执行器、传感器、控制器三种角色
角色做出来了，为什么必须让它们独立运作？
核心只有一件事：让每个 AI 拿到干净的、独立的上下文。上下文一混，独立性就没了。
对应理论：黑箱不能给自己打分；传感器要独立，首先是它的输入要独立
| 控制论角色 | 岗位 | 唯一权限 | 不做 |
|---|---|---|---|
| 目标来源 | 提需求的人（人） | 写方案正文 | 不写实现 |
| 控制器 | 队长 | 派活、裁定、改方案、推进状态、计轮次 | 不写代码、不当评审 |
| 传感器 · 外环 | 方案评审员 | 对方案出意见 | 不裁定、不改正文 |
| 执行器 | 工程师 | 写代码（唯一写入者） | 不裁自己的码、不改目标、不推远端 |
| 传感器 · 判断性 | 审查员 | 对代码差异出意见 | 不裁定、不修复 |
| 传感器 · 确定性 | 测试员 | 同版本真实环境独立验收 | 不修代码 |
| 人 | 人类审批人（人） | 可开工、升级裁决、收尾授权 | 不看对话记录，看诊断 |
终止条件不是岗位，是队长手里的一条规则：一轮零采纳即停。
怎么控制干活的质量？
回路能保证收敛，不能保证收敛到对的地方。控制质量的手段有五个：
对应理论：传感器只能测偏差，测不出目标本身对不对——那是人的事
方案收敛了，就等于方案对了吗？
一条真实 issue：方案 v1 进，4 轮各修一个 P1 级真实缺陷，v4 收敛后停下等人，人拍板才开工。另一条在第一次派发就被人以"产品前提未定"取消——评审跑得再好，前提错了也是白跑。
对应理论：验收标准是人定的目标值，回路只负责逼近它
审查不能任由 AI 自由发挥——它会把地图越画越大、分支越来越多、细节越抠越细。怎么定边界？
边界不是限制审查的深度，是限制审查的宽度。宽度不限，做出来的一定是一套复杂度很高、怎么修都总在出问题的东西。
对应理论：传感器只测与目标的偏差，不测"还能更好"；控制器的阻尼就是这些规则
边界定好了，AI 还是在发散。什么叫收敛，什么时候交给人？
判断顺序很重要：先确认审查是有边界的，再把发散归咎于方案。反过来做，会去改一个没错的方案。
对应理论：串级控制——内环的偏差反向修正外环的目标；不收敛时人一定在
有些东西代码里看不出来，黑箱怎么知道？
用什么工具承载不重要，市面上可选的很多。重要的是这两个目标：方案在动手前被充分探讨过；代码表达不了的约束有地方活着。
对应理论：控制输入——把隐性知识变成显性约束，黑箱才不会自己填空
判断性的评审总有漏网的，下限靠什么兜？
对应理论：判断性传感器抬上限，确定性传感器保下限，两个都要
角色做出来、权限分清楚、输入管住，回路就能跑
最好的模型当队长和审查员、人把关目标、审查先定边界、看震荡定收敛和升级、文档测试 CI 补齐，回路才跑对
配置、prompt、工具链，都是从这两个问题推出来的。
工具是可以换的，结构不可以。下面是这套结构目前的一种承载方式：方案阶段两个工具，交付阶段一支小队、一条流水线。
每一步后面都标了它在控制结构里对应什么。看的时候盯着那一栏，工具名可以忘。
| 步骤 | 怎么做 | 控制什么 |
|---|---|---|
| 探讨出初版方案 | 用 OpenSpec 的 explore：一场无压力的对话，AI 读代码库、列出可选路径和取舍、把模糊的想法磨成一个可建的方案。这一步不产出任何工件，只产出"我们要做的到底是什么" | 目标来源——人和 AI 一起把目标想清楚，而不是让 AI 替你填空 |
| 方案进 issue 正文 | 初版方案写成 issue 正文，带版本号；评审期间只有队长能改写 | 目标的单一来源 |
| 方案评审小队加固 | 异厂商评审员只出意见 → 队长过事实门逐条裁定、改正文升版 → 干净轮收敛 | 外循环：传感器 + 控制器 + 终止条件 |
| 人裁决可开工 | 收敛后 issue 停在待裁决，人做产品判断，改派交付小队 | 目标对不对，人说了算 |
| 步骤 | 怎么做 | 控制什么 |
|---|---|---|
| 承接检查 | 开工前对方案最后再查一次：确认已收敛、没有待人拍板的开放项。不合格不开工，交回外循环 | 目标校验 |
| 起独立工作区 | 工程师在独立 worktree 上干活，不碰主 checkout | 执行器的隔离 |
| 写变更工件 | 先写 OpenSpec 工件再动代码：变更提案、规范、任务清单。代码表达不了的约束进活的规范，和代码一起进仓库 | 规矩的显性化 |
| 写代码、自测 | 真实全栈，无 mock；工程师是唯一写入者 | 执行器 |
| 提交测试员 | 同版本、同环境、真实客户端独立验收，每步"操作 → 预期 → 实际 → 证据" | 确定性传感器 |
| 代码审查循环 | 审查员出意见 → 队长裁定 → 工程师只修采纳项 → 干净轮收敛，轮次到上限升级 | 判断性传感器 + 控制器 + 终止条件 |
| 提交人类验收 | 人看可观测行为和可执行的验收步骤，一句话授权收尾 | 最终传感器 |
在工作区里跑：审查员对代码差异出意见，队长裁定，工程师修，干净轮收敛。审的是"这次实现对不对"。
推到远端后再跑一次：对合并结果审查，CI 跑通，基线未变才合。审的是"合进去之后整体对不对"。
为什么要两道：本地循环看到的是差异，远程循环看到的是合并后的整体。大 PR 尤其如此——差异各自没问题，合起来未必。
CI 在这里是确定性传感器的最后一道，它不讲道理，这正是它的价值。
东西太小，流程的很多环节根本走不到——方案评审一轮就过、代码审查没意见、升级从不触发。培养不出对每个环节的手感。
第一次跑，环境要搭、角色要调、规则要改。项目一大，问题混在一起，分不清是流程的问题还是项目的问题，一下就 hold 不住。
我的建议：找一个全靠人做要一到两个月的项目，算上第一次搭建 AI 工作环境的一两天，试试能不能一周左右做完。
一到两个月的量，足够让每个环节都被真实地跑到几次；一周的目标，逼着你把人盯着的时间压下来——这正是这套结构要证明的事。
不是为了省事，是把一个控制器 hold 不住的对象，切成几个 hold 得住的。
对应理论：Ashby 的必要多样性；反馈时滞与稳定性；递归的控制结构
换掉左边任何一样，流程还在。换掉右边任何一样，就回到黑箱自由发挥。
每一项都对应前面讲过的一个要点。先找结构的问题，再怪模型。
| 目标 | |
| ☐ | 验收标准是不是写成了「完成需要什么证据」——只描述可观测行为，不写实现？ |
| ☐ | 每条标准能不能归到自动回归或人工验收之一？归不了的是不是还留在里面？ |
| ☐ | 方案写了「不做什么」吗？ |
| ☐ | 方案是干净轮收敛后才开工的吗？开工时还有待人拍板的开放项吗？ |
| ☐ | 人真的判断过「该不该做」吗，还是把收敛当成了开工？AI 不会替你质疑需求。 |
| 回路与收敛 | |
| ☐ | 收敛条件是可检查的「零采纳」，还是「评审者没话说」？ |
| ☐ | 有轮数上限吗？到线是升级了，还是继续派轮、换模型顶上？ |
| ☐ | 审查有边界吗：每条意见有触发条件 / 后果 / 依据？只审范围内？过了事实门？修复复杂度配得上缺陷代价？ |
| ☐ | 是震荡（同一批问题反复）还是发散（每轮新问题、范围越来越大）？前者查机制，后者查方案。 |
| ☐ | 内环有没有在悄悄改目标：改了对外契约、用户可见行为、架构，却没打回外环？ |
| ☐ | 升级交给人的是诊断（做到哪、唯一阻塞、可选方案），还是一堆对话记录？ |
| 质量下限 | |
| ☐ | 实现是真实全栈吗？有 mock 吗？ |
| ☐ | 测试员是在同一版本、同一环境用真实客户端重走的吗？每步有证据吗？ |
| ☐ | CI 在跑吗？合入前基线未变吗？ |
| ☐ | 代码表达不了的规矩，在仓库里有活的规范吗？同一规则是不是只写在一处？ |
| 范围 | |
| ☐ | 需求是不是太大，一个回路 hold 不住？该不该分步实施、分步验收？ |
| ☐ | 验收周期是不是太长，偏差累积到测出来时已经很大了？ |
黑箱还是黑箱。变的是：它的目标被收敛过、它的输入被约束住、它的输出被独立测量、它的偏差会收敛、它不收敛时人一定在。
做到这些，人盯着的范围就能一点点缩小——AI 能自主交付的情况越来越多，范畴越来越大。这就是整套结构存在的理由。
这套结构是从控制论推出来的，工作流是从这套结构推出来的——不是反过来。
质量控制得越好，AI 就能干越多的事。
因此，你也就能干越多的事。
控制不是为了限制 AI，是为了放开它。每多一条能自动检查的验收标准、每多一个不需要人的检查点，就多一块能交给 AI 的范畴——而你的时间，就从盯着它，换成了决定下一件要它做的事。
AI 快速普及这一年多，我观察到一个明显的分野：用得多的人和用得少的人。区别不在技术，在于一个人眼里有没有很多非解决不可的问题，脑子里有没有很多东西想变成现实。
AI 是给 Problem Solver 和 Builder 准备的。
对他们来说，这是最好的时代。
今天讲的所有控制结构，都是为了让你少操心 AI、多操心问题本身。如果你眼里有问题、手里有想建的东西，这套方法是给你的。
这是小队里控制器（队长）实际在用的裁定规则，全文照录。第五部分"审查的边界"那六条，就是从这里提炼的。
# mtc-adjud — 审查意见裁定 skill 均为 SHALL 级要求，缺一条即未完成。裁判员 = 队长；Reviewer 只出意见，Change Owner（squad-pr 为 PR Owner）只修采纳项，三者不兼任。 ## 计数 一个 Issue 一个计数，本地与远程（codex bot）轮共用，只由裁判员维护于 metadata review_round：首轮前置 0，只增不减，换 head 不清零。每派一轮先 +1 并在契约写明轮次号；因接单退回、无回帖、bot 未接单而重派沿用原号；台账只抄契约。上限默认 10，Human Approver 放宽时写 review_round_limit；达上限未收敛即升级，不再派轮。 ## 核对 Reviewer 回帖先核：复述的 worktree、base、head、轮次号与契约逐字一致；每条意见有编号且含触发条件、后果、依据；Reviewer 未裁定、未改文件、未 @人。不合规以原轮次号退回一次，只指缺项；再不合规按无回帖处理。「无意见」且核对通过 = 采纳 0。 ## 裁定 每条意见显式裁定：采纳 / backlog + 理由，逐条落台账。 直接排除，不进入可采纳判断：纯风格偏好；方案范围外既有问题；无依据推测；违背明确需求或已定约束。 可采纳须过一道门：依据门（能说明触发条件、实际后果、依据）或 事实门（可经代码事实、文档、现有约定验证）。两门都不过记 backlog，不纳入「是否需改进」判定。 涉及 OpenSpec 的意见只有一条标准：指出审查范围内代码与 live spec（openspec/specs/**）不一致、或 delta specs（openspec/changes/<name>/specs/**）本身有错的，采纳；只针对 proposal / design / tasks 本身的，视为文档精修，记 backlog（理由「文档精修」），不计入可采纳。 疑不可行先查代码事实或文档实证，不以读方案推断。核查在 worktree 内只读进行（读文件、只读 git、不写工作树的测试 / 类型检查 / lint）。须写入工作树才能实证的标「待实证」，派 Change Owner 只出实证、不改码、不 commit，回来补裁；其余意见不等。 「观察」项不裁，只记录。 ## 台账 裁定回帖落本轮派活线程，累积表逐轮追加不改旧行：轮次｜编号｜P 级｜裁定（采纳 / backlog / 待实证）｜理由｜修复 SHA｜复验。另维护累计 backlog。 ## 收敛 本轮（含待实证补裁）采纳数 0 = 干净轮 = 收敛。不为「再确认」加轮。 有采纳：只把采纳项（编号、原文、依据、期望最小修复范围）派给 Change Owner，不转 backlog 与观察。Change Owner 最小修复、更新工件、验证、重跑受影响验收、commit、回报；队长核新 head 在分支上且未扩围后以新 head 开下一轮，Reviewer 全新派活、契约不附裁定。 剩余 backlog 不阻交付，进最终汇报。 ## 升级 任一命中即停、保留现场、按流程 skill「升级」处置：已采纳问题修复后下一轮仍被提出且核实未解决；意见冲突且代码事实无法裁定；修复引入同级以上风险；修复明显超范围；意见指向方案不可行须推翻架构；同一轮次号连续两次派 Reviewer 无回帖；达上限未收敛（提示人类僵局可能在需求或方案本身）。 不写代码、不改工件、不修复、不 commit；不替 Reviewer 补意见，派活不给背景或既往裁定；不替 Change Owner 定修法；不自行放宽上限。
| 环节 | 模型 | 控制论角色 |
|---|---|---|
| 聊需求 | Claude Fable | 和人一起定目标 |
| 审方案 | GPT 5.6 Sol | 外循环传感器 |
| 小队长 | Claude Fable | 控制器 |
| 写代码 | Claude Opus | 执行器 |
| 跑验收、审查代码 | DeepSeek V4 Flash | 内循环传感器 |
| 审 PR | Codex Cloud | 远程循环传感器 |
但最重要的，仍然是一开始输入给 AI 的需求的质量。
这张表明年就会过时。上面那句话不会。