当AI编程工具的选择被简化为‘0-1用Claude Code，1-N用Codex’时，我们是否忽略了项目的真实复杂性？本文通过真实案例揭示中型SaaS项目中模块的阶段性差异，拆解两种工具背后的工程哲学，并给出‘规则稳定度’这一更具操作性的选型维度。从CLAUDE.md的宪法主义到AGENTS.md的联邦制，你的选择实则是团队工程纪律的镜像。

项目阶段不是项目的属性，是模块的属性

一个真实的场景。

某个中型 SaaS 团队，主仓库迭代了两年。代码量大约 30 万行，模块清晰，CI/CD 流水线齐整，是典型的”1-N”阶段——稳定生长。

半年前，他们启动了一个 AI 客服模块。结构还在调，API 来回改，连命名约定都还没完全定下来。是典型的”0-1″阶段——从零摸索。

图 1

这个团队最近在选 AI 编程工具。摆在桌面上的是 Claude Code 和 Codex。

技术决策最流行的回答是这样的：

“看主仓库的阶段。主体是 1-N 就选 Codex，主体是 0-1 就选 Claude Code。”

这个回答最近在中文技术圈相当流行——逻辑漂亮、对仗工整、决策清晰。Claude Code 是”治理派”，Codex 是”执行派”；CLAUDE.md 用于”建模”，AGENTS.md 用于”扩张”。听起来一切都解决了。

我的判断是：这个问题，从一开始就问错了。

不是答案错。是问题本身偷了懒。

先承认这个对仗找得真准

要先把好话说完。

把 Claude Code 和 Codex 的核心差异概括为”治理 vs 执行”——这个对仗确实精确。两个工具在指令机制层面的设计哲学完全相反。

图 2 CLAUDE.md 与 AGENTS.md：两套指令机制 · 两种工程哲学

Claude Code 的核心是一个文件：CLAUDE.md。放在项目根目录，每次会话开始时被完整加载。它配套一整套结构：CLAUDE.local.md（个人偏好，自动 gitignore）、.claude/子目录下的settings.json、rules/、agents/、skills/、hooks/。所有这些被设计成一个整体——一份”项目宪法”，团队共享，commit 到 git，长期沉淀。

Codex 的核心是另一种东西：AGENTS.md。它不在根目录”独占”，而是可以放在任意子目录下，按 cwd 路径逐层向上发现。Codex 还允许AGENTS.override.md（个人覆盖）、配置project_doc_max_bytes限制每个文件的读入量、用project_doc_fallback_filenames指定备选文件名。整套机制被设计成”分层注入”——你在哪个目录，就读哪一层的规则。

把这两套机制拍在一起看，差异就出来了：

• CLAUDE.md 假设你的项目有一套”全局共识”。它鼓励你把规则集中、统一、可被所有人读到。
• AGENTS.md 假设你的项目没有完全的全局共识，或者全局共识不该管所有事。它鼓励你按目录把规则散下去。

一个是”立宪”，一个是”分治”。

“治理 vs 执行”是表面的说法。底层是”共识驱动 vs 容器驱动”。Anthropic 信前者，OpenAI 信后者。

到这里为止，原文的对仗成立。

但好的对仗有一个副作用——它会让人误以为，这是个二选一的问题。

真实项目里：阶段不是项目的属性，是模块的属性

绝大多数试图替你做选择的文章，最终都会落到一个简化的二元划分上。

“你是 0-1 项目？选 Claude Code。”

“你是 1-N 项目？选 Codex。”

这个推论的前提是：一个项目在某个时间点，整体只处于一个阶段。

图 3 “0-1 / 1-N”这个划分偷了懒

这个前提在现实里几乎不成立。

回到开头那个 SaaS 团队。主仓库 1-N、新模块 0-1，这种结构不是个例，是绝大多数中型团队的常态。三五年的老项目几乎都是”主体稳定 + 新模块持续探索”。完全 0-1 的项目只在创业前六个月存在；完全 1-N 的项目只在生命末期存在。中间几年——也就是绝大多数项目的绝大多数时间——是两个阶段共存。

再往细里看，”阶段”这个词本身可能就用错了。

电商主仓库迭代两年，结构稳定，是 1-N。但里面”营销活动模块”每三个月推倒重来一次，每次都是 0-1。

一个 3 年的内容平台，整体 1-N。但今年突然要做 AI 重构，老的内容审核管道完全保留（极度 1-N），新加的 AI 审核流是从零开始（彻底 0-1）。两条管道并行跑在同一个仓库里。

开源项目更明显。React 是 1-N 还是 0-1？主分支当然 1-N，但experimental/子树里的新特性永远在 0-1。

所以”项目阶段”这个概念，真实指代的不是项目，是项目里某一个模块或某一条功能线。

按”项目阶段”来选工具，等于强迫你为整个项目挑一个标尺，而项目里至少有 5-10 个模块在不同标尺上。

会发生什么？

按原文的逻辑硬选一边，一定有一边吃亏。

选了 Claude Code 的团队：新模块那边用得很顺——团队需要快速形成共识，CLAUDE.md 把目录约定、命名习惯、API 规范一次性沉淀进去，Claude 每次会话都读到，写代码符合规约。但是老模块那边痛苦。两年的项目积累，CLAUDE.md 写到 3000 行就停不下来了。每次会话 Claude 都要全量读这 3000 行，token 烧得心疼，更糟糕的是上下文被噪声填满，真正重要的规则反而被淹没。新人接手，光读这份 CLAUDE.md 比读代码还累。

选了 Codex 的团队：老模块那边用得很顺——稳定的目录结构对应稳定的 AGENTS.md，规则随代码长，简单直接。但是新模块那边痛苦。AI 客服模块的目录结构还在变，今天叫agents/，明天改名pipelines/，AGENTS.md 跟着重构跑，每次重构都要重写规则。更尴尬的是 AI 经常自作主张创建新文件夹放代码——因为它看到 AGENTS.md 只覆盖了已有目录，新增的地方没有规则约束。

这两种痛苦不是工具不好用，是工具的预设跟项目的真实结构不匹配。

项目阶段不是项目的属性，是模块的属性。

真正的选型维度是”规则稳定度”

不要问”这个项目是 0-1 还是 1-N”。

要问的是另一个问题：”这个模块的工程规则稳不稳定”

这是一个更落地、更可操作、更接近你日常体感的维度。

图 4 3 分钟自检：你的模块在 0-1 还是 1-N

什么叫”规则稳定”？

• 接口已经定型（半年没大改了）；
• 文件结构不会经常重构（命名约定、目录划分都定下来了）；
• 新人按照现有约定就能上手（不需要每次跟一个老人复述”为什么这里这样写”）；
• 代码里反复出现的模式可以被一句话固化（”接口必须 Pydantic、错误处理走 raise_for_status 风格”）。

这些信号叠加起来，说明你这个模块进入了”规则可以下沉”的阶段。

这种模块上 Codex 会非常顺。AGENTS.md 跟着目录走，规则跟着代码长，AI 在局部范围内做局部修改，不需要每次都把全局拉一遍。

什么叫”规则不稳定”？

• 这周还叫service.py，下周可能被拆成service/handler.py和service/processor.py；
• 团队还在讨论”什么放 model，什么放 schema”；
• 你给 AI 一个任务，写代码之前必须先解释三段背景（”我们这个项目跟一般 Python 项目不一样，我们的 model 不是 ORM 的 model……”）；
• 每写一个新功能，team review 都会冒出”这个该归到哪类”的争论。

这种模块上 Claude Code 才合适。CLAUDE.md 把团队还在形成共识的那些规则集中沉淀，每次会话都全量给 AI 看一遍，避免它在没有共识的地方乱写。

判断可以再简化——给你一个”3 分钟自检清单”：

1. 这个模块最近 3 个月，文件结构有过大调整吗？
2. 你给一个新人写过这个模块的入门文档吗？写完没有？
3. 你能用 3 行规则讲清楚这个模块的核心约定吗？
4. AI 上一次写错代码，是因为它没读到全局规则，还是因为它没读到这个目录的局部规则？

如果 1 是”有”、2 是”没写完”、3 是”不能”、4 是”全局规则”——这个模块还在 0-1 阶段，用 Claude Code。

如果 1 是”没有”、2 是”写完了而且不需要更新”、3 是”能”、4 是”局部规则”——这个模块进入了 1-N，用 Codex。

同一个项目里有的模块得 1、有的模块得 4，完全正常。

正常解读：你的项目本来就不是单一阶段。两个工具应该共存。

选错工具会发生什么——实战信号清单

图 5 选错了怎么识别 · 两种失败的早期信号

原文最缺的是反话。

“什么时候你选错了”、”怎么从日常使用中识别出选错了”——这些没人告诉你。

我把两种选错都拆给你看，附上具体信号。下次踩到，你能立刻反应过来。

信号一：1-N 模块硬上了 Claude Code

最常见的早期信号是 CLAUDE.md 文件本身的膨胀。

刚开始可能只有 200 行——技术栈、目录约定、几条 review 清单，很舒服。

半年后你打开看，1500 行了。新加的规则一条一条往里塞，旧的没人删。

一年后变成 4000 行。你已经记不清里面写了什么，但每次会话都全量加载，每条 prompt 都要重新塞进去。

team 里有人开始抱怨”Claude 怎么又忘了我们的规则”，但其实不是 Claude 忘了，是 CLAUDE.md 里有 50 条互相冲突的规则，Claude 在选最近读到的那条。

这个信号背后的真实问题是：你的项目已经成熟到，”全局共识”撑不住单文件治理了。规则需要按模块分散下去，每个目录管自己的事。继续用 CLAUDE.md，是在用一份开国宪法管理一个治理结构已经分层的国家。

信号二：0-1 模块硬上了 Codex

最常见的早期信号是 AGENTS.md 跟着目录重构跑。

刚开始你按 Codex 推荐的方式，在每个子目录放一份 AGENTS.md，看起来很整齐。

两周后你把agents/改名成workers/，跟着要把agents/AGENTS.md改到workers/AGENTS.md。git diff 一片红绿。

一个月后，你不耐烦了，开始把规则统一塞到根目录的 AGENTS.md 里——但 Codex 是按目录加载的，根目录的规则只在 cwd 是根目录时生效。AI 在子目录里跑就读不到这些规则。

你发现 AI 经常自作主张创建新文件夹，因为它看的那一份 AGENTS.md 没有覆盖到新增的位置。

这个信号背后的真实问题是：你这个模块还没到”规则可以下沉到目录”的阶段。结构本身还在变，规则跟着结构跑等于自找麻烦。这种阶段需要的是一份”全项目通看”的指令系统——把还在变动的约定集中放在一个地方，每次都全量给 AI 看。

这两种失败的共性

不是工具不好用。

是你的工程纪律没跟上你选的工具的预设。

Claude Code 假设你能维护一份”项目宪法”——这是个工程纪律要求，能不能维护，取决于你团队有没有人定期 review 和裁剪这份文件。Codex 假设你能维护”按目录的局部规则”——这也是个工程纪律要求，能不能维护，取决于你的目录结构稳不稳定。

工具选错了，本质上是你选了一个”超出你团队工程纪律承载能力”的预设。

这不只是工具选择

图 6工具背后是两个问题 · 两种治理哲学

把视角再往深一层。

选 Claude Code 还是 Codex，其实是在选两种工程治理哲学。

Claude Code 是宪法派。它相信全局共识可以形成、可以沉淀、可以让所有人遵守同一份文档。这是 Anthropic 的工程哲学——单点高杠杆、共识驱动、长期记忆。背后假设是：好的团队应该能写出一份让所有人都认可的”项目说明书”。

Codex 是联邦派。它假设全局共识形不成，或者即使形成了也不该管所有事。每个目录管自己的、每个模块有自己的规则、个人覆盖凌驾于团队默认。这是 OpenAI 的工程哲学——分层注入、容器驱动、按需局部。背后假设是：好的团队应该把治理切碎到能管得过来的颗粒度。

这两种哲学没有对错，只有匹配度。

匹配你团队的标志：

• 如果你团队有那种”愿意花两小时把一个争论写成文档”的人，且这种文档能被其他人持续维护——CC 的宪法派路线适合你。
• 如果你团队更习惯”写代码的时候顺手把规则写在注释和 README 里”，且很难凑齐时间集中讨论全局规则——Codex 的联邦派路线适合你。

这是工程文化问题，不是技术能力问题。

更深一层看，这两个工具其实都在逼着团队”长大”，只是逼的方向不同。

CC 逼着你形成共识。如果你用 CC 一段时间，CLAUDE.md 永远只有空洞的”写好代码、follow best practice”这种废话，说明你的团队还没有真正形成可写下来的共识。这时候 AI 给你写的代码风格永远飘忽，那是 CC 在用”你的工程治理还没长出来”这件事告诉你结果。

Codex 逼着你稳定结构。如果你用 Codex 一段时间，发现 AGENTS.md 总在跟着目录重构跑、规则永远写不稳定，说明你的工程结构本身还没定型。这时候 AI 自作主张乱建文件夹，那是 Codex 在用”你的工程结构还没定型”这件事告诉你结果。

工具不会替你解决治理问题。它只是把这个问题摆到你面前，让你看见。

所以真正的问题是

你打开 Claude Code 或者 Codex 那一刻，你以为你在选一个 AI 编程工具。

你其实在选你对自己团队工程纪律的承认。

• CLAUDE.md 在问你：”你们团队能形成共识吗？能形成的话，沉淀成一份文档让所有人共用吗？”
• AGENTS.md 在问你：”你们团队的目录结构稳定吗？稳定的话，把规则下沉到目录里吗？”

这两个问题，你心里有什么答案，决定了哪个工具能帮上你。

回到开头那个 SaaS 团队。主仓库 1-N、新模块 0-1。它们的正确解法不是从两个工具里挑一个，是同时用两个——

老模块上 Codex，让规则跟着稳定的目录长。

新模块用 Claude Code，让团队边写边形成共识。

如果团队不愿意接受两个工具并行的工程成本——那是另一个问题：选一个能力强的工具凑合用，但要预期它在不匹配的那一半模块里会持续摩擦。

但没必要假装这种摩擦是工具能解决的。

软件项目永远不是 0-1 然后 1-N。它是 N 个模块各自处于不同阶段。

真正应该问自己的不是”我的项目在哪个阶段”，是另一个更难的问题：

哪些模块我可以立宪，哪些模块我必须分治？

这个问题答好了，工具自己就选好了。

答不好这个问题，选哪个工具都会觉得不顺。