开篇 · 一个分水岭
别再把 Codex 当聊天框了
市面上大多数 Codex 教程还停在「安装 CLI → 写 Prompt → 让它改个文件 → 测试通过」的玩具阶段。
但真正进入生产，你会撞上一堆玩具教程回答不了的问题：
①一个项目有几十个任务时，谁决定先做什么？
②Codex、Claude、Kimi、GLM 同时可用时，谁接单？
③某模型额度不足、登录失效时，任务怎样换人但不降级？
④多个 Agent 同时写代码，怎样避免互相覆盖？
⑤聊天窗关闭、电脑重启后，任务怎样恢复？
⑥Agent 说「完成了」，完成的到底是代码、测试、部署，还是客户真的能用？
作者给的答案是一句话，也是整篇文章的「第一原则」：
人类控制目标，系统控制流程，模型负责执行，证据决定完成。
这条原则贯穿全文。这堂课带你一步步搞懂它到底意味着什么——全程动手。
第 1 课 · 四个身份
一支 AI 开发团队，有四种「身份」
蜂群OS（SwarmOS）是「人类目标」和「各类 AI 执行器」之间的一层开发操作系统。它把容易混淆的四种身份分得清清楚楚——没有这层区分，多 Agent 系统就会变成一堆脚本互相调用，谁都能改策略、谁都能自称审查通过。
1人类 = 唯一的蜂王主脑 👑决定业务目标、资金动作、最终风险接受度、版本晋级。AI 处理日常，但不能把「装了个插件」当成「拿到全局治理权」。
2蜂群OS Core = 控制面 🧠保存项目、任务依赖、运行状态、权限、派单结果、证据。状态不能只活在聊天窗口里，否则关掉会话团队就失忆。
3Worker = 执行节点 ⚙️当前电脑、工作站、服务器、临时算力。只执行获批任务，不拥有全局调度权。
4CLI = 可替换的员工入口 🔌Codex、Claude、Kimi、GLM 都只是适配器。用你自己的账号和额度；蜂群凭据只证明「谁有权接什么任务」，绝不冒充模型账号。
🎯 判断：下面每个「角色」属于哪一层？
点击选择，看你对不对。
「决定这个版本能不能正式上线」
对。版本晋级是「最终风险接受度」的体现，只有人类能批准。
「保存项目状态、任务依赖、派单结果、证据」
对。这些状态必须存在 Core 里，不能只活在某个聊天窗口，否则换个平台、关个会话就失忆。
「Codex / Claude / Kimi / GLM」
对。它们只是「适配器」，是可以替换的。今天最强的模型，明天可能额度不足。
第 2 课 · 工程宪法
AGENTS.md 不是「代码风格说明」，
是这家 AI 公司的「工程宪法」
很多人把 AGENTS.md 理解成「告诉 Codex 代码风格的地方」——这只用了它一小部分价值。蜂群工程里，它承担四层职责：
1身份层：谁能决定什么这不是「建议」，是运行时权限合同。界面隐藏按钮不算权限控制，API/MCP/Core 必须真正拒绝越权请求。
2行为层：哪些自动做，哪些必须停普通安装、依赖修复、测试、重启、候选部署——在明确范围内自主做。需要人确认的只有少数：付款、整机重启、不可逆删除、正式版晋级。
3工程层：怎么写、怎么并行、怎么验证关键不是「用 TS 还是 Python」，而是把并发边界写清：一个管数据面、一个管 API、一个管前端、一个只读审查——互不重叠。
4记忆层：让错误变成下一次的能力每次失败留下可复用记录：症状、根因、无效尝试、最小解法、验证、回滚、防复发。
🎯 一个反直觉的点：权限模糊 ≠ 更安全
作者说了一句很关键的话：
「模糊的权限不会带来安全，只会带来两种坏结果：要么 Agent 什么都问、团队失去速度；要么 Agent 自己猜、风险反而更大。」
👆 点我看「授权边界」的正确姿势
✅ 好：把「普通安装、修依赖、跑测试」明确授权给 Agent 自主做，只有「付款、整机重启、删数据、正式晋级」才停下问人。
❌ 坏：每三分钟问一次「我可以继续吗？」——看起来谨慎，其实既拖垮速度，又没真正降低风险。
第 3 课 · 编译，而不是总结
最快的开发，不是从 Prompt 开始，
而是把现实「编译」成工程
项目最原始的输入通常不是代码，而是：一份合同、几个压缩包、一堆截图、客户语音、旧数据库、历史聊天记录，加一句「帮我尽快上线」。
普通做法：把这些材料扔进模型，让它总结需求。蜂群做法：编译成工程。
为什么叫「编译」而不是「总结」？
因为编译有源文件、中间表示、类型检查、错误、目标产物。意味着：
- 原始合同不能在「模型总结」之后消失；
- 模型的推断不能伪装成客户事实；
- 模糊条款必须成为「待决问题」；
- 每一项交付要求必须能追到「验收动作」。
第一步：原件保全（先别毁证据）
接管旧项目时，别先格式化、别删「看起来没用」的文件、别为了 Git 状态漂亮清理现场。先记录：原始包 SHA-256、Git 历史是否完整、未提交内容、数据库能否恢复、哪个数据源才是权威。
👆 点我看最贵的错误是什么
「AI 时代最昂贵的错误，经常不是代码写错，而是把唯一原件覆盖后，所有 Agent 都在错误事实之上高速前进。」
第 4 课 · 交付的四层状态
「做完」是类型，不是情绪
一个项目至少要区分四种状态。很多 AI Demo 的问题，就是把第一个状态叫成第四个状态。
1code-complete代码已实现，局部测试通过。
4deliverable备份恢复、迁移、客户文档、公网入口、最终验收全部完成。
🎯 判断：下面这些「漂亮话」，实际卡在哪一层？
「页面打开了！」
对。页面能打开最多算 preview。备份、迁移、客户文档、公网入口、最终验收没做完，就不能叫「交付了」。
「接口返回 200！」
对。接口返回 200 只说明这一个接口通了，不等于业务闭环，更不等于交付。
蜂群OS 要求：每个状态都要有证据，状态不能靠 Agent 的语气推进。
第 5 课 · 验收 Oracle
写代码之前，先定义「机器如何判案」
Oracle 不是一句「请确保质量良好」，而是可执行的判定。关键是在任务开始前，就把「什么算对」说清楚。
🎯 一个真实的反例
问题：「当两个请求同时修改一个预约时，究竟应该发生什么？」
👆 点我看「没定义 Oracle」会怎样
如果这个问题没在任务开始前说清楚，两个模型可能分别写出「看起来都合理」的实现，等集成时才撞出业务语义冲突——那时返工的成本已经很高了。
✅ 正确做法：开工前就定义好——「两个并发请求，只能有一个成功、一个被拒绝，且必须留下两条审计记录」。这就是「验收 Oracle」。
任务图：把「帮我做完项目」拆成可并行的依赖网络
大目标不能平均切成四份。先找依赖，再找并行边界。一个任务节点至少包含：
目标 · 依赖 · 角色 · 读写模式 · 唯一写入范围 · 输入版本 · 输出 · 测试 · 超时 · 重试 · 回退 · 成本影响 · 证据位置
关键：模型名称不能写进业务合同。任务写「需要后端并发角色实测的实现者」，而不是永远写死「必须某模型」。供应商是路由层的决定，不是产品层的依赖。
第 6 课 · 多模型调度
谁空闲、谁合格、谁有额度，谁上
「多模型协作」最容易被写成华丽架构图：一个规划、一个代码、一个审查。但现实是渠道不是永远在线——额度会重置、账号会掉线、模型会漂移。所以调度要像生产系统，每次派单重新计算。
四道门，按顺序过：
1角色资格模型必须先通过对应岗位的真实考试（前端、后端、review、research…）。没过实测的，再便宜、再空闲也不能接。
2当前身份与健康实际调用的是谁？CLI 版本？登录有效？最近一次真实调用成功？——配置写着「高级模型」不代表当前跑的就是它。
3可信额度「我感觉还有额度」不能用于派单。要有：剩余比例、重置时间、采集时间、是否需人工登录、保留线。
4空闲槽位 + 幂等保护同一任务要有幂等键，不能因为「没看到回复」就再派一次，导致两个模型同时写、烧两份额度。
🎯 判断：该不该派这个单？
一个模型「感觉还有额度」，但额度记录已经过期
对。「我感觉还有额度」不能用于自动派单。未知额度的渠道可以被人工点名探测，但不能进自动路由。
一个模型很便宜、很空闲，但没通过「前端岗位实测」
对。作者原话：「质量资格永远先于成本。」没过岗位实测，再便宜、额度再多也不能接这个岗。
第 7 课 · 可恢复 + 自举
并行开发要「可恢复」，系统要「能开发自己」
Session / Worktree / 事件流
每次可恢复工作都要有 Session ID——它不是聊天标题，是工程记录。写入型 Agent 默认用独立 Worktree；每个文件范围只有一个 Owner，别人能审查、不能同时改。
为什么只存一个 status=succeeded 不够？因为最终状态解释不了发生了什么。事件流让系统区分「从未接受」「已接受但确认未知」「Worker 已开始」「Worker 已结束」这些完全不同的状态——避免重复派单、并发写入。
更重要的是：进度终于能给人看，而不是一个沉默七小时的黑箱。
狗粮循环：系统必须先能安全地开发自己
「吃自己的狗粮」不是一句口号。真正的自举要求：当前稳定版创建候选版，候选版不能覆盖唯一可用版本。
👆 点我看自举暴露的真实竞态
一次自举测试里：调度后端已经接受任务，Worker 启动得太快，抢在 Core 持久化「标准执行对象」之前就恢复了。任务本身成功了，但「由 Core 确认派单」的事件缺失。
只看最终状态，这个任务是绿的；看事件链，它不具备可证明的调度路径。
修复不是「多等几秒」，而是三条规则：Worker 给 Core 短暂优先确认窗口；Core 只对完全一致的恢复做幂等确认；发布门禁绑定「当前这一次 execution」。
三种时间，别再只说「几个人天」
机器执行时间所有 Agent、测试、构建累计消耗的时间
关键路径墙钟从开工到满足下一门禁的现实时间
外部等待登录、付款、平台审核、客户反馈、DNS 生效等非工程等待
AI 时代真正稀缺的，往往不是 Token，而是人类注意力、清晰决策、可测试环境、可靠反馈。
结业 · 测一测
你真的懂了吗？
Q1. 蜂群OS 的第一原则是？
对。整篇文章就围绕这四句话展开。
Q2. 为什么「页面打开了」不能叫「交付了」？
对。「做完」是四层状态（code-complete → integrated → preview → deliverable），不能把第一个当第四个。
Q3. 多模型调度，什么必须「先于成本」？
对。作者原话：「质量资格永远先于成本。」没过岗位实测，再便宜也不能接单。
Q4. 为什么「合同和素材」要「编译」而不是「总结」？
对。编译有源文件、中间表示、类型检查、错误、目标产物——原始合同不能消失，推断不能伪装成事实。
恭喜
🎓
你抓住了这篇文章的核心
提示词会过时，工程闭环会复利。
真正长期增值的，不是某段神奇的 Prompt，而是你的合同编译器、任务图、测试 Oracle、错误知识库、模型能力档案和发布闭环。
一句话带走的 7 个结论
1️⃣ 四个身份：人类主脑 / Core 控制面 / Worker 执行 / CLI 适配器。
2️⃣ AGENTS.md 是工程宪法，不是代码风格说明。
3️⃣ 把现实「编译」成工程，别「总结」成 Prompt。
4️⃣ 「做完」是四层状态，不是 Agent 的语气。
5️⃣ 写代码前先定义「验收 Oracle」。
6️⃣ 多模型调度：质量资格 > 可信额度 > 空闲槽位 > 成本。
7️⃣ 狗粮循环——系统先能安全地开发自己。
原文：《Codex No.1教程》by 大婶王（@dashen_wang）