很多人第一次使用 Codex，会把它当成一个更强的代码补全工具：输入一句话，让它生成一段代码；遇到报错，再让它修一下。
这种用法当然有价值，但很难稳定完成真实项目。真实项目通常不是“写一个函数”这么简单，而是要先找到正确的仓库，理解已有代码，遵守项目约束，处理历史兼容，运行测试，检查页面，最后把结果发布出去。
这篇文章给出一套更完整的使用方法。目标不是让 Codex 偶尔帮你省几分钟，而是让它成为一个可以被管理、被验证、被复用的工程协作伙伴。
一、先理解 Codex 的工作边界
Codex 可以帮助你：
- 阅读和解释代码
- 搜索项目中的相关实现
- 制定修改计划
- 编辑多个文件
- 执行命令和测试
- 调试错误
- 做重构和迁移
- 检查代码差异
- 处理文档和发布流程
但它不会自动知道你的业务目标、历史约束和风险边界。
因此，最可靠的协作方式不是“让它自由发挥”，而是给它足够上下文，并明确验收标准。
官方的 Codex Best Practices 也把 Prompt、Plan、验证、MCP、Skills 和自动化视为一套完整工作习惯，而不是孤立的提问技巧。
二、第一次打开项目，先做项目体检
不要刚打开仓库就直接说“帮我开发一个功能”。先让 Codex 做一次只读检查：
请先不要修改任何文件，完成一次项目体检：
1. 说明项目使用的语言、框架和包管理器
2. 找出应用入口、主要模块和测试目录
3. 找出构建、测试、格式化和部署命令
4. 检查是否存在 AGENTS.md、README 或其他项目规则
5. 列出与当前任务最相关的文件
6. 标记你不确定的地方
最后输出：
- 项目结构摘要
- 当前任务可能涉及的文件
- 建议的实现步骤
- 需要我确认的问题这一步可以避免三个常见错误：找错项目、漏掉已有约束、在不了解上下文的情况下直接改代码。
三、用 AGENTS.md 固定项目规则
如果每次都重复告诉 Codex “先跑什么命令”“哪些目录不能改”“提交前要检查什么”，效率会越来越低。
可以在项目根目录创建 AGENTS.md，写入长期有效的规则：
# 项目协作规则
## 修改前
- 先阅读 README 和相关目录下的 AGENTS.md
- 先检查当前 git 状态
- 不要修改与任务无关的文件
## 验证要求
- 修改代码后运行：npm run build
- 修改样式后必须在浏览器中检查实际页面
- 修改文章或资源后检查链接和文件是否存在
- 汇报时区分“已验证”和“推测”
## Git 要求
- 提交信息使用中文
- 提交前检查 git diff
- 不使用强制推送
- 不提交密钥、Token 和本地配置规则文件应该保持小而明确。不要把所有想法都塞进去，否则真正重要的规则反而会被淹没。
四、把模糊需求改写成可验收任务
不推荐这样说：
帮我把首页优化得高级一点。推荐改成：
目标：降低首页的模板感，让内容层次更清晰。
允许修改：
- 首页布局
- 颜色、间距、字体层级
- 文章卡片样式
必须保持：
- 所有文章标题和链接不变
- 不删除现有分类和标签
- 不影响移动端布局
验收标准：
1. 本地构建成功
2. 桌面端和移动端都能正常显示
3. 首页首屏能看出网站主题和最新内容
4. 没有新增控制台错误
5. 汇报具体改了哪些文件以及如何验证
开始前先检查现有页面和样式，不要直接修改。需求越具体，Codex 越容易做出可控结果。审美要求也应该尽量转成可观察的描述，比如“减少卡片边框”“增加留白”“降低颜色数量”“突出标题层级”，而不是只说“高级一点”。
五、推荐的五步工作流
第一步：观察
让 Codex 阅读相关文件、目录结构和现有实现，不要急着改。
第二步：计划
要求它给出最小修改方案，并列出可能影响的地方。
第三步：执行
一次只解决一个明确目标，避免同时进行无关重构。
第四步：验证
至少执行构建或测试；涉及页面时，还要实际打开浏览器检查；涉及资源时，要检查真实链接。
第五步：复盘
让 Codex 汇报：
- 修改了哪些文件
- 哪些检查已经通过
- 哪些地方仍然不确定
- 有没有发现相关但未处理的问题
可以把这套流程直接写成任务模板：
请按以下流程完成任务：
1. 先阅读相关代码并总结现状
2. 列出最小修改计划
3. 等计划清晰后再执行修改
4. 运行必要的构建、测试或检查
5. 检查是否有同类问题
6. 汇报修改内容、验证结果和遗留风险六、代码任务的实用 Prompt
新增功能
请为当前项目实现：______。
先完成：
1. 找出相似功能
2. 说明当前架构和数据流
3. 给出最小实现方案
限制：
- 不引入新的依赖
- 不修改无关模块
- 保持现有代码风格
验收：
- 正常场景可用
- 异常场景有处理
- 相关测试通过
- 输出最终 diff 摘要排查 Bug
现象：______。
复现步骤：______。
预期结果：______。
实际结果：______。
请先不要直接修改：
1. 阅读相关代码和调用链
2. 给出三个可能原因
3. 用日志、测试或最小复现逐个排除
4. 找到根因后再给出最小修复
5. 补充回归验证迁移旧内容
请迁移这批旧文章和资源。
必须保持：
- 标题和正文原意不变
- 图片和 PDF 不丢失
- 原有分类和标签尽量保留
- 历史 URL 要有兼容方案
禁止：
- 根据标题自行补写正文
- 用占位图片替换真实图片
- 遇到不确定内容时直接猜测
完成后检查：
1. 文章数量
2. 资源数量
3. 图片和 PDF 链接
4. 分类和标签
5. 旧 URL 和新 URL七、验证比生成更重要
每次任务至少检查以下项目：
- 构建是否成功
- 测试是否通过
- 是否出现 TypeScript、Lint 或控制台错误
- 是否修改了无关文件
- 是否破坏已有链接
- 是否漏掉图片、PDF 或字体资源
- 移动端是否正常
- 线上部署是否真的完成
如果是网页任务，最好让 Codex 本地运行项目，然后用浏览器实际检查，而不是只看代码。页面布局、字体比例、滚动行为和浏览器缓存，往往只有在真实页面中才能发现。
如果是内容迁移，必须把“内容准确”列为验收条件。AI 生成的文字很流畅，但流畅不等于真实。
八、Git 和发布流程
一个简单可靠的发布流程是：
git status --short --branch
git diff --stat
git diff --check
npm run build
git add -- <实际修改的文件>
git diff --cached --check
git commit -m "feat【无平台】描述本次变更"
git pull --rebase --autostash
git push每次只提交当前任务相关文件，不要习惯性使用 git add .。
发布完成后，还要检查：
- GitHub Actions 是否成功
- 页面是否返回 200
- 新页面内容是否正确
- 旧页面是否仍然可访问
- 图片和 PDF 是否能打开
“代码已经提交”与“线上已经生效”是两个不同的状态。
九、什么时候应该让 Codex 停下来问你
以下情况不要让 AI 自行决定：
- 要删除数据或文章
- 要修改公开页面
- 要改变权限或安全配置
- 要引入高风险依赖
- 要改变数据库结构
- 需求存在多种完全不同的解释
- 可能泄露隐私或密钥
好的 Agent 不是永远不提问，而是在真正影响结果的地方提问，并且先把已经查到的事实和可选方案整理清楚。
十、从“会用 Codex”到“拥有自己的 Agent 工作流”
可以按三个阶段提升：
阶段一：个人效率
掌握任务模板、代码解释、Bug 排查、测试和 Git 操作。
阶段二：项目效率
建立 AGENTS.md、自动化脚本、Skills、检查清单和统一发布流程。
阶段三：团队效率
把稳定的工作流交给团队复用，让 Agent 读取团队知识、调用内部工具，并且在明确权限和审批边界内执行。
官方文档提供了 Skills、CLI、IDE、MCP 和云端任务等扩展方向，可以按自己的工作场景逐步增加，而不是一次性把所有能力都装上。
结语
Codex 最适合做的，不是替你思考所有事情，而是把已经明确的目标变成一连串可执行、可验证的动作。
真正高效的使用方式可以浓缩成一句话：
先给上下文，再给边界；先让它验证，再让它修改；先确认结果，再谈完成。
当你能把项目规则、任务目标、验收标准和发布流程组织起来时，Codex 才不只是一个聊天窗口，而会变成你自己的工程生产系统。
说明：本文由 Codex 协助整理，内容结合官方 OpenAI 文档和实际项目工作流编写，并经过人工校正。
参考资料：