Codex 高效使用技巧
少返工、少废话、少走弯路
Codex 更像一个真正会动手的终端编程助手。它能读代码、改文件、跑命令、做验证，但前提是你要把任务边界讲清楚。这篇文章不是讲安装，而是讲怎么把 Codex 用得更稳、更快、更像一个高质量协作工程师。
// 先理解代码
一、先让 Codex 理解，再让它动手
很多人上来就说“直接改”。这通常会带来更多返工。
❌
给这个页面加一个筛选功能，直接改吧这类指令没有限定读哪些文件、改哪些模块、保留哪些行为，Codex 很容易一边读一边猜。
✅
先阅读以下文件并总结现状：
- src/components/ComparisonTable.tsx
- src/data/platforms.json
- src/app/[locale]/page.tsx
告诉我筛选功能应该落在哪一层，准备改哪些文件。
先不要写代码，等我确认后再开始。💡 先对齐理解，可以显著减少“改了再推翻”的无效轮次。
// 限制范围
二、明确修改范围，避免它顺手改太多
Codex 是会主动执行的，范围不收紧，就容易出现“本来只想小修，最后改了一串文件”。
要同时说清楚三件事
| 要素 | 你要给的信息 | 示例 |
|---|---|---|
| 改哪里 | 允许修改的文件或目录 | 只改 src/components/Navbar.tsx |
| 别改哪里 | 禁止触碰的区域 | 不要改样式系统和 i18n 数据 |
| 改到什么程度 | 是最小修复还是允许重构 | 只做最小必要修改 |
只修改 src/components/LocaleToggle.tsx
目标：修复移动端换行问题
约束：
- 不要改动其他组件
- 不要重构样式变量
- 只做最小必要修改// 文件路径上下文
三、少贴大段代码，多给准确文件路径
Codex 在本地工程里工作，本来就能看文件。你应该提供入口和重点，而不是把整段代码粘进对话。
高效做法
- 直接给绝对或项目内相对路径
- 补充“从哪个函数/组件开始看”
- 必要时指出相关联的上游和下游文件
✅
问题出在这几个位置：
- src/components/PlatformDetail.tsx
- src/lib/platforms.ts
- src/data/platforms.json
先沿着 PlatformDetail -> platforms.ts -> platforms.json 的数据流排查，
找到 why "Codex" 标签没有展示的具体原因，再修复。// 一轮一件事
四、一轮只推进一件事
Codex 可以连续做很多事，但你不应该一次塞太多目标。
❌
帮我一起做：
1. 新增 guide 文章
2. 调整首页文案
3. 修复 sitemap
4. 优化 SEO
5. 顺便把卡片样式也重做✅
先完成一件事：新增一篇 /guide/codex-tips 文章
要求：
- 支持中文英文
- 风格与 claude-code-tips 接近
- 同步加入 guide 列表和 sitemap
其余改动先不要做。💡 目标越单一，Codex 的输出越稳定，也越容易验收。
// 先计划
五、先要计划，再要实现
对于中等以上任务，让 Codex 先说“准备怎么做”，通常比直接开工更稳。
规划型 Prompt
先别写代码。
请先基于当前仓库给出一个 3 步以内的实现计划，说明：
- 会改哪些文件
- 每个文件改什么
- 哪些地方可能有回归风险
等我确认后再开始编辑。这样做的价值在于：你能在真正改文件前，把错误方向拦下来。
// 给验收标准
六、写清楚验收标准，而不是只说“做一下”
如果没有完成标准，Codex 很难判断什么叫“做好了”。
| 维度 | 建议写法 |
|---|---|
| 功能 | 新文章在 /zh/guide/codex-tips 和 /en/guide/codex-tips 都能访问 |
| 入口 | Guide 列表能看到新卡片并跳转正确 |
| SEO | 页面有 metadata 和 alternates |
| 索引 | sitemap 包含新 slug |
| 风格 | 视觉风格与现有 guide 文章一致 |
✅
完成标准：
- 新文章路由可访问
- 中英文内容都完整
- guide 首页出现新卡片
- sitemap 增加 codex-tips
- next lint 通过（如果当前项目可运行）// 要求自测
七、让 Codex 自己验证，不要只交代码
好的协作方式不是“改完就结束”，而是“改完后说清楚验证过什么”。
改完后请继续做两件事：
1. 运行项目里已有的校验命令（例如 lint / build）
2. 告诉我你实际验证了什么、还有什么没验证到为什么这很重要
- 逼它从“生成代码”切换到“交付结果”思维
- 更早暴露拼写、类型、路由、引用遗漏等问题
- 方便你判断这次修改是否可以直接合并
// 要求 review
八、让 Codex 顺手做一轮自我审查
很多 bug 不是“不会写”，而是“写完没回头看”。
交付前复查 Prompt
在结束前，请你基于刚刚的修改做一次简短 review。
重点检查：
- 有没有改漏的入口文件
- 有没有中英文不一致
- 有没有死链或错误路径
- 有没有不必要的改动
如果发现问题，直接修掉后再汇报。💡 你是在要求它像一个靠谱工程师，而不是一个只会吐代码的生成器。
// AGENTS.md
九、把长期规则写进 AGENTS.md
重复说十次，不如固化一次。对于固定仓库，建议把协作规范写进 AGENTS.md。
# AGENTS.md
- 默认先阅读相关文件，再开始修改
- 修改时优先最小改动，不主动重构无关代码
- 变更完成后运行 lint
- 最终回复中说明：改了什么、验证了什么、还存在哪些风险
- 新增页面必须补 metadata 和 sitemap
- 中英文页面要同步维护这样 Codex 每次进入项目时，都会更接近你的协作习惯。
// 实用模板
十、直接可用的 Codex Prompt 模板
新增页面
新增一篇 guide 文章，slug 为 codex-tips。
要求：
- 路径放在 src/app/[locale]/guide/codex-tips/page.tsx
- 支持 zh / en
- 页面风格参考 src/app/[locale]/guide/claude-code-tips/page.tsx
- 同步加入 src/app/[locale]/guide/page.tsx 的卡片列表
- 同步加入 src/app/sitemap.ts
先阅读相关文件，给出计划，再开始修改。最小修复
修复 src/app/sitemap.ts 中遗漏的 guide slug。
要求：
- 只改这个文件
- 不要顺手重构其他逻辑
- 改完后说明新增了哪些路由条目定位问题
请先排查为什么新文章卡片没有出现在 guide 首页。
从以下文件开始看：
- src/app/[locale]/guide/page.tsx
- src/data/i18n.json
- src/app/sitemap.ts
先告诉我根因，不要马上改代码。// 总结
总结
Codex 高效使用的核心，不是“会不会下 prompt”，而是有没有把协作边界定清楚。
01
先理解
先读代码和计划，再开始动手
02
控范围
明确允许改哪里，不让任务失控
03
重验证
要求自测、review、交付说明
把 Codex 当成能执行命令的工程协作者来用，而不是普通聊天机器人，效果会稳定很多。