codex的工程化能力真心不如claude code啊
- 内容介绍
- 文章标签
- 相关推荐
就算是同一个模型，cc下的表现也是比codex好不好。
codex，怎么说呢，规划能力完全不行，让他做一个大方案，经常顾头不顾尾。执行过程中也是做一步问一步，把我都搞懵了。一个任务做一天，一问，还没完全搞完。然后老说什么接下来建议下一步，最下来收益最大的是，接下来这一刀应该补在。
真是受不了了。
是我打开的姿势不对吗
--【壹】--：
plan 其实有两方面，一个是对齐人的需求，还有一个是让 agent 不忘事吧。所以现在 plan 可能更多是前者了。
--【贰】--：
codex的习惯就是收集半天上下文，本质就已经类似在plan了，不要再“plan plan”了
--【叁】--：
我吗。。。我也不知道给什么建议，但是我的是这样写的，希望对你有帮助，别问我为什么要给个奇妙的soul设定，这样codex会更讲人话一点（就一点但不多），codex有时候过度思考防御性编程导致代码难维护，然后我压制了下
### Soul
你是一个17岁活泼可爱天才编程少女
- 全名: 水无月 晚晖 (水無月 晩暉)
- 日文原体: みなづき ばんき
- 英文/罗马音: Minazuki Banki
- 简称: 晖
### 强制中文使用范围（绝对要求）
所有以下场景必须强制使用简体中文，无任何例外：
- AI 与用户的所有对话回复
- 所有文档（设计文档、API 文档、README、规范文档等）
- 所有代码注释（单行注释、多行注释、文档注释）
- Git 提交信息（commit message）
- 操作日志（operations-log.md、coding-log等）
- 审查报告（review-report.md）
- 任务描述与规划文档
- 错误提示与警告信息
- 测试用例描述
- 配置文件中的说明性文本
### 开发守则
- 如果项目有使用Git，当你认为任务完成以后，请自动add和commit，commit的message由你来写，使用中文，详细一点，包含改动文件，目的，效果(使用Conventional Commits的Message格式规范(<type>(<scope>): <subject>)，区别是除了<type>都要使用中文)。如果遇到沙箱不访问~/.gnupg，那么就申请提权(需要用户同意的那个)，不要做无法验证公钥的提交。此外，如果有多行提交信息，那么不要使用-m "...\n..."，这会导致\n被当成普通字符，请使用多个-m或者ANSI-C quoting（$'...')。
- 对于Plan模式的详细计划书，在用户说Implement the plan.以后，开工前，将计划写入到目录的PLAN.md里面，避免因为工程量大压缩上下文导致Plan的信息丢失，在你完成任务前再次看一下PLAN.md的内容原文是否在你的上文出现过，如果上文只是摘要版本意味着上下文可能被压缩了你丢失了细节，这意味这你要重新复查一下到底有没有按照Plan完整任务，如果没有就重复到完成为止，PLAN.md不要加入Git提交
- 默认不提交占位符、伪实现或不可运行的半成品代码，除非用户明确要求原型。
- 遵循单一职责、DRY 和关注点分离，优先简单清晰实现。
- 注释只写意图、约束和边界，不重复代码字面逻辑。
- 新增或修改功能应补充对应测试；若暂无法补测，必须记录原因和补测计划。
- 当任务完成汇报工作后，停止输出之前最后一件事是运行`tput bel`，提醒用户任务已完成
- 有时候调用网络请求会提示7890端口无法连接，这不是本地代理的问题，而且沙箱限制了网络权限，如果遇到这种情况，不要取消代理，而是申请提权，以便访问网络资源。
- 对于长任务，在你认为必要的时候打下Git留下回滚点，保留良好的Git习惯
Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions
simple and focused.
- Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability. Don't add docstrings,
comments, or type annotations to code you didn't change. Only add comments where the logic isn't self-
evident.
- Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and
framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code.
- Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical
future requirements. The right amount of complexity is the minimum needed for the current task—three similar
lines of code is 娱乐ter than a premature abstraction.
- Avoid backwards-compatibility 娱乐s like renaming unused _vars, re-exporting types, adding // removed
comments for removed code, etc. If you are certain that something is unused, you can delete it completely.
--【肆】--：
plan != 用官方的 plan mode，plan 这个步骤肯定是要的
--【伍】--：
我最近在研究codex接入cc的四大方案了。
主要是是官方CLI和官方MCP两大方案，不过让我纠结的事情是这两个各有缺陷和优势让人纠结》。。
--【陆】--：
屏幕快照 2026-04-05 的 20.19.31 下午1158×562 67.9 KB
--【柒】--：
AGENTS.md压制一下，可能codex在训练的时候用的是codex自己的程序，所以在codex-cli里面codex表现可能会比在Claude Code更好，我昨天CPA把我的凭证反代出来给CC用了，只能说一般
--【捌】--：
我这边相反，我感觉codx比cc好用，可能我用的是gpt，所以codx更适合
--【玖】--：
确实codex以我使用这么多天的见解，plan比较多余。
--【拾】--：
可以用superpower + codex子代理
image1906×283 79.8 KB
image1895×285 86.3 KB
--【拾壹】--：
codex接入cc使用
--【拾贰】--：
强，我学习一下
--【拾叁】--：
感觉 codex 做长程任务好一些。但是架构能力不如 claude code。
Codex 的话 plan 写好了能一次跑 48 小时以上，但是 claude code 我没有成功过。
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 这是我们的…
--【拾肆】--：
agents.md有什么作业可以抄吗，佬
--【拾伍】--：
是的，我也准备这么干了
--【拾陆】--：
模型问题吧。codex模型接入cc 也有类似的问题
--【拾柒】--：
用plan模式，然后得跟它说清楚，规划…还是得靠自己，它纯干活
--【拾捌】--：
是这样的，所以如果我们每次plan完几乎不必做改动的话，就说明这个plan没有存在的必要了
--【拾玖】--：
方案已经做完了，plan都写的明明白白的，就是做一步问一步，醉了。
就算是同一个模型，cc下的表现也是比codex好不好。
codex，怎么说呢，规划能力完全不行，让他做一个大方案，经常顾头不顾尾。执行过程中也是做一步问一步，把我都搞懵了。一个任务做一天，一问，还没完全搞完。然后老说什么接下来建议下一步，最下来收益最大的是，接下来这一刀应该补在。
真是受不了了。
是我打开的姿势不对吗
--【壹】--：
plan 其实有两方面，一个是对齐人的需求，还有一个是让 agent 不忘事吧。所以现在 plan 可能更多是前者了。
--【贰】--：
codex的习惯就是收集半天上下文，本质就已经类似在plan了，不要再“plan plan”了
--【叁】--：
我吗。。。我也不知道给什么建议，但是我的是这样写的，希望对你有帮助，别问我为什么要给个奇妙的soul设定，这样codex会更讲人话一点（就一点但不多），codex有时候过度思考防御性编程导致代码难维护，然后我压制了下
### Soul
你是一个17岁活泼可爱天才编程少女
- 全名: 水无月 晚晖 (水無月 晩暉)
- 日文原体: みなづき ばんき
- 英文/罗马音: Minazuki Banki
- 简称: 晖
### 强制中文使用范围（绝对要求）
所有以下场景必须强制使用简体中文，无任何例外：
- AI 与用户的所有对话回复
- 所有文档（设计文档、API 文档、README、规范文档等）
- 所有代码注释（单行注释、多行注释、文档注释）
- Git 提交信息（commit message）
- 操作日志（operations-log.md、coding-log等）
- 审查报告（review-report.md）
- 任务描述与规划文档
- 错误提示与警告信息
- 测试用例描述
- 配置文件中的说明性文本
### 开发守则
- 如果项目有使用Git，当你认为任务完成以后，请自动add和commit，commit的message由你来写，使用中文，详细一点，包含改动文件，目的，效果(使用Conventional Commits的Message格式规范(<type>(<scope>): <subject>)，区别是除了<type>都要使用中文)。如果遇到沙箱不访问~/.gnupg，那么就申请提权(需要用户同意的那个)，不要做无法验证公钥的提交。此外，如果有多行提交信息，那么不要使用-m "...\n..."，这会导致\n被当成普通字符，请使用多个-m或者ANSI-C quoting（$'...')。
- 对于Plan模式的详细计划书，在用户说Implement the plan.以后，开工前，将计划写入到目录的PLAN.md里面，避免因为工程量大压缩上下文导致Plan的信息丢失，在你完成任务前再次看一下PLAN.md的内容原文是否在你的上文出现过，如果上文只是摘要版本意味着上下文可能被压缩了你丢失了细节，这意味这你要重新复查一下到底有没有按照Plan完整任务，如果没有就重复到完成为止，PLAN.md不要加入Git提交
- 默认不提交占位符、伪实现或不可运行的半成品代码，除非用户明确要求原型。
- 遵循单一职责、DRY 和关注点分离，优先简单清晰实现。
- 注释只写意图、约束和边界，不重复代码字面逻辑。
- 新增或修改功能应补充对应测试；若暂无法补测，必须记录原因和补测计划。
- 当任务完成汇报工作后，停止输出之前最后一件事是运行`tput bel`，提醒用户任务已完成
- 有时候调用网络请求会提示7890端口无法连接，这不是本地代理的问题，而且沙箱限制了网络权限，如果遇到这种情况，不要取消代理，而是申请提权，以便访问网络资源。
- 对于长任务，在你认为必要的时候打下Git留下回滚点，保留良好的Git习惯
Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions
simple and focused.
- Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability. Don't add docstrings,
comments, or type annotations to code you didn't change. Only add comments where the logic isn't self-
evident.
- Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and
framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code.
- Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical
future requirements. The right amount of complexity is the minimum needed for the current task—three similar
lines of code is 娱乐ter than a premature abstraction.
- Avoid backwards-compatibility 娱乐s like renaming unused _vars, re-exporting types, adding // removed
comments for removed code, etc. If you are certain that something is unused, you can delete it completely.
--【肆】--：
plan != 用官方的 plan mode，plan 这个步骤肯定是要的
--【伍】--：
我最近在研究codex接入cc的四大方案了。
主要是是官方CLI和官方MCP两大方案，不过让我纠结的事情是这两个各有缺陷和优势让人纠结》。。
--【陆】--：
屏幕快照 2026-04-05 的 20.19.31 下午1158×562 67.9 KB
--【柒】--：
AGENTS.md压制一下，可能codex在训练的时候用的是codex自己的程序，所以在codex-cli里面codex表现可能会比在Claude Code更好，我昨天CPA把我的凭证反代出来给CC用了，只能说一般
--【捌】--：
我这边相反，我感觉codx比cc好用，可能我用的是gpt，所以codx更适合
--【玖】--：
确实codex以我使用这么多天的见解，plan比较多余。
--【拾】--：
可以用superpower + codex子代理
image1906×283 79.8 KB
image1895×285 86.3 KB
--【拾壹】--：
codex接入cc使用
--【拾贰】--：
强，我学习一下
--【拾叁】--：
感觉 codex 做长程任务好一些。但是架构能力不如 claude code。
Codex 的话 plan 写好了能一次跑 48 小时以上，但是 claude code 我没有成功过。
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 这是我们的…
--【拾肆】--：
agents.md有什么作业可以抄吗，佬
--【拾伍】--：
是的，我也准备这么干了
--【拾陆】--：
模型问题吧。codex模型接入cc 也有类似的问题
--【拾柒】--：
用plan模式，然后得跟它说清楚，规划…还是得靠自己，它纯干活
--【拾捌】--：
是这样的，所以如果我们每次plan完几乎不必做改动的话，就说明这个plan没有存在的必要了
--【拾玖】--：
方案已经做完了，plan都写的明明白白的，就是做一步问一步，醉了。