Claude Code 还是 Codex？这个问题问错了

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

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

一个真实的场景。

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

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

图1

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

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

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

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

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

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

先承认这个对仗找得真准

要先把好话说完。

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

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

ClaudeCode的核心是一个文件：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项目？选ClaudeCode。”

“你是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个模块在不同标尺上。

会发生什么？

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

选了ClaudeCode的团队：新模块那边用得很顺——团队需要快速形成共识，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”。

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

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

什么叫”规则稳定”？

接口已经定型（半年没大改了）；

文件结构不会经常重构（命名约定、目录划分都定下来了）；

新人按照现有约定就能上手（不需要每次跟一个老人复述”为什么这里这样写”）；

代码里反复出现的模式可以被一句话固化（”接口必须Pydantic、错误处理走raise_for_status风格”）。

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

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

什么叫”规则不稳定”？

这周还叫service.py，下周可能被拆成service/handler.py和service/processor.py；

团队还在讨论”什么放model，什么放schema”；

你给AI一个任务，写代码之前必须先解释三段背景（”我们这个项目跟一般Python项目不一样，我们的model不是ORM的model……”）；

每写一个新功能，teamreview都会冒出”这个该归到哪类”的争论。

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

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

这个模块最近3个月，文件结构有过大调整吗？

你给一个新人写过这个模块的入门文档吗？写完没有？

你能用3行规则讲清楚这个模块的核心约定吗？

AI上一次写错代码，是因为它没读到全局规则，还是因为它没读到这个目录的局部规则？

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

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

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

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

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

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

原文最缺的是反话。

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

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

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

最常见的早期信号是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。gitdiff一片红绿。

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

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

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

这两种失败的共性

不是工具不好用。

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

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

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

这不只是工具选择

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

把视角再往深一层。

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

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

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

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

匹配你团队的标志：

如果你团队有那种”愿意花两小时把一个争论写成文档”的人，且这种文档能被其他人持续维护——CC的宪法派路线适合你。

如果你团队更习惯”写代码的时候顺手把规则写在注释和README里”，且很难凑齐时间集中讨论全局规则——Codex的联邦派路线适合你。

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

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

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

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

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

所以真正的问题是

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

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

CLAUDE.md在问你：”你们团队能形成共识吗？能形成的话，沉淀成一份文档让所有人共用吗？”

AGENTS.md在问你：”你们团队的目录结构稳定吗？稳定的话，把规则下沉到目录里吗？”

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

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

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

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

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

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

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

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

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

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

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