如果你刚开始接触 AI 编程工具，Codex 可以理解为一个“能读代码、能改文件、能跑命令、能解释结果”的编程助手。它不是只能聊天的问答机器人，而是可以在你的项目里工作：阅读仓库、定位问题、修改代码、运行测试，并把做了什么告诉你。

这篇文章适合完全没用过 Codex 的新手。你不需要一开始就理解所有高级配置，只要先掌握几个基本习惯，就能让 Codex 稳定地帮你完成日常开发任务。

1. Codex 适合做什么？

Codex 最适合处理这些任务：

  • 解释一个陌生项目的结构和关键文件。
  • 修复报错、定位 bug、补测试。
  • 根据你的描述实现一个小功能。
  • 帮你重构一段代码，但保持行为不变。
  • 审查本地改动，指出潜在风险。
  • 生成脚本、文档、示例代码或迁移计划。

新手可以先从“解释”和“修小问题”开始，不要第一天就让它重写整个系统。任务越清楚、范围越小，结果越容易检查。

2. 第一次启动 Codex

如果你使用命令行，可以在项目目录里运行：

codex

这会打开一个交互式终端界面。你可以像聊天一样输入需求，Codex 会根据当前目录读取项目文件、分析问题，并在需要时执行命令。

也可以直接带上第一句话：

codex "解释这个项目的目录结构，并告诉我从哪里开始看"

如果只是想快速得到一次性结果，也可以用非交互方式：

codex exec "找出最近一次测试失败的原因，并给出修复建议"

刚开始建议用交互式 codex，因为你可以看到它的计划、工具调用和修改过程，更容易建立信任。

3. 新手最容易忽略的一点：提示词要给上下文

Codex 很强，但它不是读心术。一个好提示词通常包含四件事：

  • 目标：你想让它完成什么。
  • 背景：相关文件、错误信息、业务规则是什么。
  • 约束：哪些做法不能用，哪些风格必须遵守。
  • 完成标准：怎样算完成，比如测试通过、页面正常显示、接口返回正确。

不太好的写法：

帮我修一下这个项目。

更好的写法：

登录接口在密码错误时返回 500，请帮我定位原因并修复。
相关代码大概率在 controller/user.go 和 model/user.go。
不要改数据库结构。完成后运行相关测试，并说明你改了什么。

再比如你想让 Codex 加一个功能，可以这样写：

请给订单列表增加按支付状态筛选的能力。
要求：
- 只改后台接口和现有列表页面，不新增独立页面。
- 筛选项包括全部、待支付、已支付、已取消。
- 保持现有 UI 风格。
- 完成后运行前端类型检查和后端测试。

你会发现，提示词越像一个清楚的小任务说明，Codex 输出越稳定。

4. 让 Codex 改代码前，先让它讲计划

如果你不确定它会怎么改，可以先要求它只分析、不动手：

先不要修改文件。请阅读相关代码，给我一个修复方案，说明会改哪些文件、风险是什么。

确认方案没问题后，再说：

按这个方案实现，并在完成后运行测试。

这对新手很重要。你不需要完全懂每一行代码，但至少要知道它准备改哪里、为什么改、怎么验证。

5. Codex 的安全机制：权限和沙箱

Codex 在本地工作时会受到沙箱限制。简单理解就是：它可以在允许的项目范围内读文件、改文件、运行常规命令；如果要访问范围外的文件、联网、执行高风险操作，通常需要你确认。

常见权限模式可以这样理解：

  • Auto：默认模式，适合日常开发。Codex 可以在工作区内自主执行常规操作，越界时会问你。
  • Read-only：只读模式，适合让它解释代码、做方案、审查问题，不让它直接改文件。
  • Full Access：完全访问，权限更大。只建议在你信任项目和任务时使用。

新手建议先用默认模式或只读模式。等你熟悉它的行为后，再考虑更开放的权限。

6. 怎么检查 Codex 改得对不对？

不要只看 Codex 的总结。你应该养成三个检查习惯：

git diff

看它到底改了哪些文件。

git status

确认有没有意外新增或删除文件。

npm test
# 或
go test ./...
# 或项目自己的测试命令

让测试证明修改没有破坏已有行为。

你也可以直接让 Codex 做这些检查：

请检查当前 git diff，说明每个文件为什么被修改，并运行项目测试。

7. 用 AGENTS.md 给 Codex 写“项目规矩”

如果你经常在同一个项目里使用 Codex，建议在项目根目录放一个 AGENTS.md。它相当于给 Codex 的项目说明书。

示例：

# AGENTS.md

## 项目约定

- 后端修改后运行 `go test ./...`。
- 前端修改后运行 `bun run typecheck`。
- 不要随意新增依赖。
- 保持现有目录结构和命名风格。
- 修改数据库结构前必须先说明方案。

这样每次 Codex 进入项目，都会先读取这些规则。你不用在每个提示词里重复“不要乱改结构”“记得跑测试”。

8. 什么时候用 CLI、IDE、云端？

Codex 不只有一种使用方式。新手可以这样选：

  • CLI：适合在终端里处理真实项目，最直接、最适合开发者。
  • IDE 扩展：适合边看代码边让 Codex 修改，尤其适合局部改动。
  • Codex app：适合规划、审查、长任务和多步骤协作。
  • 云端任务：适合把一个独立任务交出去并行处理，比如“给这个仓库补一组测试”。

刚入门不用纠结，先从 CLI 或 IDE 扩展开始即可。

9. 常用的几个提示词模板

解释项目：

请用新手能听懂的方式解释这个项目的目录结构、启动方式和核心模块。

定位 bug：

这个错误是：<粘贴错误信息>。
请先分析可能原因，不要直接改文件。找到最可能的问题后给出修复方案。

实现功能：

请实现 <功能描述>。
约束：
- 保持现有代码风格。
- 不新增不必要依赖。
- 完成后运行相关测试。

代码审查：

请审查当前未提交改动，重点找 bug、边界条件、回归风险和缺失测试。

生成文档：

请根据当前代码写一份使用说明，面向第一次接手项目的新同事。

10. MCP 是什么？新手需要马上学吗？

MCP 可以理解为让 Codex 连接外部工具和资料的协议。比如连接文档搜索、浏览器、设计工具、监控系统、GitHub 等。

新手不需要第一天就配置 MCP。你可以先把 Codex 当成本地编程助手用起来；当你发现它经常需要查某个外部系统时，再考虑配置对应的 MCP。

11. 一个推荐的新手学习路径

第一天：让 Codex 解释项目，不让它改代码。

第二天：让它修一个小 bug，并要求它说明修改原因。

第三天：让它补测试，自己用 git diff 检查。

第四天：写一个 AGENTS.md，把项目规则固定下来。

第五天：尝试 /review 或让 Codex 审查你的改动。

一周后，你基本就能判断哪些任务适合交给 Codex，哪些任务需要你自己先设计清楚。

12. 最重要的心态：把 Codex 当成会执行的同事

使用 Codex 的关键不是“让 AI 一次性给出完美答案”，而是学会协作：

  • 你负责说清目标、边界和验收标准。
  • Codex 负责读代码、改文件、跑命令和解释过程。
  • 你负责审查结果、确认取舍和最终发布。

当你这样使用它时，Codex 不只是代码补全工具，而是一个能参与真实开发流程的助手。

参考资料