这段时间我一直在用 Claude Code 和 Codex 做项目。用得越多，我越能感觉到：面对同一个问题，它们处理事情的习惯还真不太一样。
这种差别不只是写代码的时候能看出来，连拆任务、写方案，以及写 OpenSpec 的 proposal.md，给我的感觉都不一样。
Claude Code：喜欢把事情一步一步拆开
我感觉 Claude Code 处理一个问题时，很喜欢先把整件事拆成几个阶段，然后再把每个阶段拆成更细的步骤。
比如要做一项功能，它可能会先分成准备、实现、验证、交付几个阶段。到了每个阶段，又会继续说清楚：这一步做什么、依赖什么、完成之后怎么进入下一步。
下面是我之前看到的任务拆分和阶段安排：
这种写法有时候确实细，但我读起来比较容易跟上。尤其是事情比较复杂的时候，我能很快知道现在走到了哪一步，接下来又准备做什么。
给我的感觉就是：它比较像一个细心、做事有条理的人，把事情摊开，一步一步往前推。
还有一点我特别喜欢：Claude Code 每完成一个功能，会告诉我处理过程中遇到了什么问题。这样我不只是知道“功能做完了”，还能顺便看到中途有哪些地方值得继续处理。
如果我想把这些问题也解决掉，它还可以帮我把问题拆开，分别开多个上下文去处理。每个上下文盯着一件事，不用把所有问题都挤在同一段对话里。比起 Codex 有时候只给我一段提示词，让我自己再开对话去处理，这种方式可省心多了，呵呵呵。
Codex：有时候会小心过头
Codex 给我的另一种感觉是，它做事也很小心，但有时候会小心过头。
比如一个问题本身可能没有那么复杂，它却会补上一堆测试，或者加一些我觉得没有必要的防御逻辑和限制。原本是为了让事情更稳，最后却可能把方案和代码都搞得更重。
我的感受大概是：Claude Code 的小心，更像是把步骤想清楚；Codex 的小心，有时候会变成先把各种可能的风险都围起来。
当然，测试和防御本身不是坏事。涉及数据、并发或者生产环境的时候，该有的保护肯定要有。我不喜欢的是不管问题大小，先堆一套看起来很安全、但不一定解决当前问题的东西。
同样写 proposal.md，关注点也不一样
这种差别，在写 OpenSpec 的 proposal.md 时尤其明显。
一份方案通常会写 Goal 和 Non-goal：前者说这次要解决什么问题，后者说这次不准备做什么。看起来都是列清单，但两者写出来的感觉不太一样。
Claude：主打业务讲清楚
我看到 Claude 写方案时，Goal 和 Non-goal 通常比较精简。它更愿意围绕“这次到底要达到什么目的”来写，把业务上期望发生的变化说清楚，再划出这次不做的范围。
比如同样是处理一个批次结束的问题，它会先讲：批次结束后，没完成的任务应该变成什么状态；这个状态在业务上怎么理解；历史数据需不需要处理。
我读的时候能比较快地抓住重点：**这次到底要解决什么，做完之后会变成什么样。**拿来审批也更直观，比较容易判断方向是不是我要的。
Codex：更容易把技术和验证细节放进目标
Codex 写出来的方案，在我的使用体验里会更偏技术一些。它会比较细地列出数据怎么处理、哪些逻辑要共用、哪些边界不能碰，以及哪些场景需要验证。
这些内容对执行当然有帮助，但有时候它把太多验证条件和实现细节提前塞进 Goal 和 Non-goal，读起来就会让我觉得：方案好像在围着测试和边界转，最开始的业务目的反而没那么突出了。
尤其是 Non-goal 一长串列下来，虽然范围看起来很严谨，但审批的时候，我得先从各种“不改什么、不做什么”里面，把真正要做的事情找出来。
我更喜欢怎么配合它们
有意思的是，我自己平时其实还是偏向读技术文档。技术细节写清楚，我能看出方案准备怎么落地，也方便检查边界。
但到了方案审批这一步，我会更喜欢 Claude 那种先从业务目标出发的写法：先让我看明白为什么做、要达到什么效果、这次不做什么；需要深入的时候，再去看具体的技术设计和验证方式。
所以我现在比较喜欢的方式是：
- 先让 Claude 把方案写出来。 把业务目标、要解决的问题和范围整理清楚，我先看方向对不对。
- 再开一个 Subagent 审批。 我会给足业务背景和相关上下文，让它帮我看看方案符不符合实际，目标和边界有没有说清楚。
- 再把方案交给 Codex 执行。 让它基于确认好的方案去看代码、拆任务、实现和验证。
- 执行过程中继续把关。 测试该做就做，但对于额外增加的防御逻辑和限制，我会看它们到底解决了什么问题，有没有必要。
这样一来，Claude 帮我把“做什么、为什么做”讲清楚，Codex 根据方案去把事情落下去。我自己在中间负责判断方向、补充业务背景，也检查最后做出来的东西。
最后：奶龙镇楼
