第 1 章：为什么要把 Claude Code 和 Codex 放在一起看
出处
来源：原网页 · 状态：已读 · PDF：book2-comparing.pdf p.8–11
一句话
比较的是对模型的不信任，不是谁更会调命令。 Claude Code 把不信任做成运行时纪律，Codex 把不信任做成显式控制面；错的是混着用，最后两边都没有。
核心概念
如果把两者当「会写代码的助手」来比，比较会很无聊：谁支持更多工具、谁的终端更顺手、谁的配置项更细。这些有用，但不解释系统为什么长成今天这副样子。真正值得比的，是它们都承认一件对产品宣传不太友好的事实：模型不能直接拿来当执行体。
Claude Code 看起来像被事故磨出来的运行时。失败、膨胀、中断、误操作，都在 query.ts、toolOrchestration.ts、compact.ts 附近变成值班表，而不是品牌文案。精华发生在主循环附近：会话还要继续答，秩序还要继续在。
Codex 也有运行时，但真正特别的一步，是把控制层做成显式结构。用户和 skill 文本作为带标记的 contextual fragment 进入（fragment.rs、user_instructions.rs）；工具先是构造好的 schema（tools/src/lib.rs）；审批和限额住在独立的 execpolicy crate 里（Policy、Rule、Evaluation、Decision）。它对控制面有一种近乎文书工作的偏爱：不拒绝灵活，但不愿让灵活失去边界。
两边回答的是同一个问题：如何让一个会说话、会调工具、但本质不可靠的模型，在工程环境里做出可接受的事。起笔位置不同。Claude Code 假定模型已经在循环里，要保护的是下一轮。Codex 假定模型会吞进许多控制信号，要先让这些信号显式、可组合、可策略化。前者强调流转，后者强调分层；前者把秩序安在 runtime heartbeat 上，后者把秩序安在 typed substrate 上。
关键洞察
一个团队以后会形成什么样的工作方式，常常取决于它最先把秩序放在哪。
运行时优先的团队，注意力会落在错误恢复、中断处理、状态污染、工具编排、长会话可靠性。显式控制面优先的团队，注意力会落在 instruction 边界、配置分层、工具 schema、策略语言、线程状态和持久化。
基本判断：它们代表两种 harness 设计哲学，而不只是两个「谁功能更全」的产品。殊途同归，是因为都知道模型不可信，真正可信的只能是约束结构。各表一枝，是因为一个更接近从现场经验里塑出来的运行时系统，另一个更接近由类型、策略和线程模型塑出来的控制系统。
错的不是选边，是混着用，最后既没有运行时纪律，也没有清楚的控制层，只剩一堆可以演示、但不好维护的聪明把戏。
个人思考
这一章把 Book 1 的「模型是不稳定部件」从原则变成路线图。后面五章分别拆控制面、心跳、工具、乡约、委派，其实都是在追问同一件事：不信任被安装在哪一层，团队以后就会围着哪一层长肉。读的时候不要急着站队，先记下自己系统现在把秩序放在哪。