Codex 使用技巧：把它当成真正的工程代理

Codex 最容易被低估的地方，不是它会写代码。

而是它可以完整参与一个工程任务：

1	读项目 -> 拆任务 -> 改文件 -> 跑命令 -> 验证结果 -> 总结改动 -> 提交代码

如果只把 Codex 当成“更聪明的代码补全”，那会浪费它一半以上的能力。

我更建议把它当成一个能在本地仓库里工作的工程代理。你给它目标，它自己去找文件、看上下文、改代码、跑测试，然后把结果交回来。

这篇文章就聊一些真实使用 Codex 时更容易提升成功率的技巧。

一、先让 Codex 读项目，不要上来就改

很多人第一次用 Codex，会直接说：

1	帮我实现一个用户登录功能

这个提示不是不能用，但风险很高。

因为 Codex 还不知道你的项目结构、技术栈、目录习惯、测试命令、代码风格，也不知道哪些文件不能碰。它当然可以猜，但真实项目里，猜得越多，返工越多。

更稳的第一句应该是：

请先阅读这个项目，告诉我：
1. 项目使用什么技术栈
2. 入口文件在哪里
3. 核心业务目录在哪里
4. 测试和构建命令是什么
5. 如果要改登录功能，应该先看哪些文件

这一步看起来慢，其实是在省时间。

Codex 一旦建立了项目地图，后面改代码会稳很多。尤其是多文件任务，前期理解越充分，后面越少出现“功能写了，但接错地方”的问题。

二、把需求写成工程任务，而不是聊天问题

Codex 喜欢明确的目标、边界和验收方式。

不要只写：

帮我优化首页。

这个范围太空了。

更好的写法是：

请优化博客首页的文章列表：
1. PC 端改成两列卡片
2. 移动端保持单列
3. 每张卡片显示标题、摘要、标签、日期
4. 不要改文章页
5. 改完运行 pnpm build
6. 如果构建失败，请继续修复直到通过

这类提示会让 Codex 更像工程师一样工作。

它知道哪些地方可以动，哪些地方不要动，也知道最后用什么标准判断完成。

三、给 Codex 一个可以验证的信号

AI 编程最怕一句话：

看起来应该好了。

“看起来”不是验证。

Codex 真正强的地方，是它可以跑命令。所以你应该给它一个明确的验证动作：

1	改完之后运行 pnpm build。

或者：

1	改完之后运行 pnpm test，并修复所有失败用例。

如果是前端页面，可以加：

1	启动本地服务，打开浏览器检查桌面端和移动端截图。

如果是接口，可以加：

1	用 curl 调用新增接口，确认返回结构符合预期。

没有验证，Codex 只能靠代码静态判断。给了验证，它就能进入闭环：

1	修改 -> 运行 -> 看报错 -> 再修改 -> 再运行

这才是 agentic coding 的核心。

四、善用权限模式，不要一开始就全自动

Codex 可以在不同权限下工作。

刚接触一个项目时，我建议保守一点：

1	先让它读代码和给方案

等你确认方向没问题，再让它自动编辑。

对于熟悉的仓库、低风险改动、格式化、文档更新、批量重命名，可以放宽权限。

但涉及这些内容时要谨慎：

删除文件
数据库迁移
权限系统
生产配置
密钥和环境变量
大范围重构

Codex 很能干，但能干不等于每次都应该放开手。权限模式本质上是你和代理之间的刹车系统。

五、让 Codex 先写计划，再执行

任务稍微复杂一点，就不要直接开写。

比如你要改一个后端接口、一个前端页面、一个数据库字段，再加测试。这个时候可以先说：

1	请先给出修改计划，列出需要改哪些文件、每个文件改什么、验证命令是什么。先不要修改文件。

等计划看起来合理，再说：

按这个计划执行。

这样做有两个好处。

第一，你可以提前发现方向错误。

第二，Codex 自己也会更稳。它会把任务拆成几个阶段，而不是一口气把上下文搅在一起。

六、用 Git 保护你的工作区

Codex 官方文档也会提醒：自动编辑之前，最好确认当前目录在版本控制里。

原因很简单：

1	AI 改代码之前，Git 是你的安全网。

我一般会先做三件事：

1
2
3

git status
git branch --show-current
git diff

如果当前已经有未提交改动，要先判断这些改动是谁的。

不要让 Codex 随手覆盖你的临时修改。也不要在一个脏工作区里做大重构，最后分不清哪些是原来的，哪些是新改的。

比较稳的习惯是：

1	一个任务，一个分支，一个清晰提交。

Codex 很适合帮你做提交说明，但提交前还是应该看一下 diff。

七、把项目习惯写进 AGENTS.md

如果你经常在同一个项目里用 Codex，就应该沉淀项目规则。

比如：

构建命令使用 pnpm build
不要直接修改 themes/keep 以外的主题文件
新增博客文章放在 source/_posts
Markdown 文章需要 front matter
提交前必须运行 hexo generate

这些规则可以写进 AGENTS.md 或项目说明文件里。

不要每次都靠聊天重复交代。

项目规则越清楚，Codex 越像一个熟悉团队习惯的协作者。

八、把 Codex 用在它擅长的任务上

Codex 很适合这些场景：

修构建错误
重构重复代码
写单元测试
梳理陌生项目
迁移配置文件
根据报错定位问题
写技术文档
做代码审查
批量改 Markdown
跑本地验证流程

但有些任务仍然需要你给方向。

比如产品取舍、架构边界、核心安全策略、数据库长期演进，这些不是“让 AI 猜一下”就能解决的。

你要做的是给 Codex 清晰的判断标准。

Codex 负责执行和验证，你负责方向和边界。

九、一个我常用的 Codex 提示模板

我日常最常用的是这个模板：

请先阅读相关代码，找到实现位置。

目标：
xxx

约束：
1. 不要改无关文件
2. 保持现有代码风格
3. 不要引入新依赖，除非确实必要

完成后：
1. 运行 xxx
2. 如果失败，继续修复
3. 最后总结改了哪些文件、验证结果是什么

这个模板不花哨，但非常有效。

它把 Codex 从“回答问题”拉回“完成任务”。

十、结语

Codex 的正确打开方式，不是让它替你敲几行代码。

而是让它进入你的工程流程。

让它读项目，让它写计划，让它改文件，让它跑测试，让它看结果，让它总结变更。

当你开始这样使用 Codex，它就不再只是一个聊天窗口，而是一个可以真正交付小任务的工程代理。

这也是 AI 编程最值得关注的变化：

1	不是代码生成变快了，而是完整开发闭环开始可以被代理执行了。