第 8 章：如果你要自己做 — 该向谁学，先学什么
出处
来源：原网页 · 状态：已读 · PDF：book2-comparing.pdf p.37–43
一句话
学 Claude Code，是学如何让系统在现场稳定运行；学 Codex，是学如何让系统在组织里长久维持秩序。 真正值得做的，是根据主矛盾决定先长哪根骨头，而不是选边站。工程系统不是耳机，不靠横评下单。
核心概念
比较的最终用途是少走弯路。不要把两套系统当成消费品二选一。真正要问的是：自建或重构 harness 时，先借哪一边的哪一块。两者是起步姿势，不是现成答案。
Claude Code 一侧：别把运行时问题想得太文雅。真正拖垮系统的是主循环里的脏活——工具结果收口、上下文膨胀、中断恢复、子代理清理、验证独立、失败熔断。Codex 一侧：控制层别靠心照不宣。instruction、schema、approval、thread、hook、skills 越早显式越好治理。指望运行时临场发挥代替制度的系统，最后都像口头约定搭起来的棚子。
三种常见团队，三种起手：
已有原型，长会话失控 → 先学 Claude Code。 症状：上下文发乱、工具链断、中断后状态不清、子代理无人收口、验证随口一说。缺的是主循环纪律，不是更多配置。先把 runtime heartbeat 做稳，再谈制度美学。阶段：主循环状态集 → tool_use 闭账/abort → memory/collapse/autocompact → verifier ≠ implementer → 子代理可观测。可以进入下一步的标准：24h 会话无熔断、无孤儿子代理、无 tool_result 泄漏。
规则很多，来源散、权限糊 → 先学 Codex。 症状：乡约四处散落、prompt/工具约束分不清、审批埋进代码、扩展一多边界糊掉。先把 instruction、tool、policy、thread 这些概念定义清楚，再让 runtime 在里面工作。阶段：instruction fragment 化 → schema（additional_properties=false）→ approval 可单独评估 → thread/rollout → hook 拆事件 + skill fingerprint。可以进入下一步的标准：规则变更可 PR diff。
从零起步。 最危险：两边优点都想要，做成折中失败品。先钉一个主矛盾、立主结构，另一边只补最低限度。风险若是「模型会乱来」，先上 Claude Code 式 runtime discipline；若是「团队会失去秩序」，先上 Codex 式显式控制层。阶段：先声明主矛盾 → 最小权限 → 只立一侧结构 → 另一侧最小必要 → 1–2 个 skill 闭环。
该向谁学，按短板借，不按别人已经做了什么借。Claude Code：主循环状态心智、compact/上下文治理、工具编排与中断、子代理生命周期、验证独立、失败路径当主路径。Codex：instruction fragment、tool schema、approval/policy 显式化、thread/rollout/state 基建化、hook 与 skills 资产管理。这不是折衷——前提是你得知道自己在学什么。
书里还有一张上下文治理三路径对照。Claude Code 把上下文当工作内存来经营（先想什么该保住、什么该压缩）。Codex 把上下文当结构化单元来治理（先想来源类型、作用域和状态承接）。第三路把上下文当 prompt 容器来扩容（先想还能再塞什么，超了再说）——解决的是装进去多少，不是继续工作真正需要保住什么。第三方常见高代价路线：不按寿命/职责/入口成本拆上下文，而是把 bootstrap、技能说明、身份、工作区文本尽量塞进 prompt，溢出再靠截断、compact、恢复链补锅。表面有 memory/skills/compact，主轴仍是「先注入，再抢救」。堆叠文本的第一层代价是 token，更糟的是语义信号被稀释。
一个危险误区：把「显式」与「灵活」误认为天然对立。把显式等同于笨重、把灵活等同于可先凭经验后补结构，都是偷懒。要分清：哪些必须写死、哪些留给现场、哪些要持久化、哪些只在会话内暂存。显式不必然僵硬，灵活也不必然混乱。
从零建议按事故出现的先后排，而不是按演示时的好看程度排：（1）高风险动作与最小权限；（2）主循环或线程生命周期；（3）上下文治理与恢复；（4）技能、本地规则与 hook；（5）多代理、平台化与复杂生态。
关键洞察
谁只学前者，容易变成经验过强、制度不足。谁只学后者，容易变成制度漂亮、现场发虚。真正值得做的，是根据自己的主矛盾决定先长哪根骨头。工程里的设计顺序，应该按事故出现的先后排。
个人思考
这一章把前面七章从判断收成顺序。对照本库里已有的三条线：Anthropic 的工件闸门、Warp 的 skill 沉淀、Ng 的改规格节奏——都假设已经有一个能连续跑、能被拦住的 harness。自己做时最容易的错，是第 8.2 类型三：两边都想一次学全。先写下一句主矛盾，比先画一张「我们也有 thread 也有 compact」的架构图有用。