我使用 Codex 三个月后的真实工作流

别再让 Codex 只帮你写几行代码了：10 个真正实用的开发技巧

很多程序员第一次使用 Codex，通常会这样提问：

帮我写一个登录页面。

帮我生成一个接口。

帮我修复这段代码。

Codex 很快就会返回一堆代码。

看起来效率很高，但真正放进项目后，却经常出现各种问题：

代码风格和原项目不一致；
修改了不应该修改的文件；
功能能运行，但破坏了其他逻辑；
没有补充测试；
没理解业务，只实现了表面需求；
改动太大，根本不敢直接合并。

问题不一定出在 Codex 能力不够。

更常见的原因是：

我们仍然把 Codex 当成代码生成器，而不是一个可以阅读仓库、执行命令、修改文件、运行测试和检查结果的编程代理。

Codex 目前可以在终端、IDE、桌面应用和云端环境中使用。Codex CLI 能直接读取本地仓库、修改文件并调用电脑上已经安装的开发工具；云端版本则可以在隔离环境中并行执行多个任务。

真正提高开发效率的关键，不是让它“多写代码”。

而是让它完成一个完整的软件开发闭环。

一、先根据任务选择正确的 Codex 使用方式

Codex 并不只有一个聊天窗口。

不同的开发任务，适合放在不同的位置完成。

1. 小范围修改：使用 IDE 插件

例如：

修改当前组件；
补充一个接口参数；
解释一段代码；
修复一个类型错误；
调整某个函数的实现。

这类任务需要频繁查看代码和立即检查差异，放在 IDE 中最方便。

你可以一边查看源代码，一边让 Codex 修改，再直接检查它生成的 diff。

2. 调试和本地开发：使用 Codex CLI

例如：

启动项目；
运行测试；
查看构建错误；
搜索代码调用关系；
执行 Git 命令；
分析日志；
修改多个相关文件。

在项目目录中运行：

<span leaf="">codex</span><br>

Codex 就可以读取当前仓库，并使用本机已经安装的 Node.js、Python、Rust、Git、测试工具和构建工具。

Codex CLI 还提供了几个很实用的命令：

<span leaf="">/init</span><br><span leaf="">/status</span><br><span leaf="">/permissions</span><br><span leaf="">/model</span><br><span leaf="">/review</span><br>

其中：

/init：生成项目的 AGENTS.md；
/status：查看当前模型、目录和权限状态；
/permissions：调整 Codex 可以执行的操作；
/model：切换模型和推理强度；
/review：检查当前代码改动。

这些命令已经覆盖了大部分日常开发流程。

3. 多任务并行：使用 Codex 桌面应用

当你同时有多个开发任务时，可以把它们交给不同的 Codex 线程。

例如：

一个任务修复登录问题；
一个任务补充单元测试；
一个任务升级依赖；
一个任务分析性能瓶颈；
一个任务审查最近的代码修改。

Codex 桌面应用支持让多个代理在独立线程中工作，并通过独立 worktree 避免它们直接修改同一份工作目录。你可以分别查看每个任务的修改，再决定采用哪一个结果。

这比让一个 Codex 在同一个对话中连续处理五件事情更可靠。

4. 长时间任务：使用 Codex 云端

例如：

大规模代码迁移；
全仓库测试补充；
多模块重构；
安全扫描；
依赖升级；
批量修复同类型问题。

Codex 云端会为任务创建隔离环境，可以同时运行多个任务，而不占用本地电脑。任务完成后，你可以查看总结和代码差异，再继续修改或创建 Pull Request。

二、不要只描述“做什么”，还要说明“怎样算完成”

下面是一条非常常见的提示词：

<span leaf="">帮我增加用户登录功能。</span><br>

这句话的问题不是不够详细。

而是缺少完成标准。

Codex 不知道：

使用哪种登录方式；
接口放在哪里；
是否需要保存登录状态；
错误如何展示；
是否需要测试；
哪些文件不能修改；
怎样才算任务完成。

一个更稳定的 Codex 提示词，应该包含四部分：

<span leaf="">目标 + 上下文 + 限制条件 + 完成标准</span><br>

OpenAI 的 Codex 最佳实践也建议，在任务中明确目标、相关文件和资料、必须遵守的约束，以及任务完成时应满足的条件。

例如：

<span leaf="">目标：</span><br><br><span leaf="">在现有 Vue 3 项目中增加用户名和密码登录功能。</span><br><br><span leaf="">上下文：</span><br><br><span leaf="">- 登录页面位于 src/views/Login.vue</span><br><span leaf="">- 请求工具位于 src/utils/request.ts</span><br><span leaf="">- 用户状态由 src/stores/user.ts 管理</span><br><span leaf="">- 后端登录接口为 POST /api/login</span><br><br><span leaf="">限制：</span><br><br><span leaf="">- 沿用项目现有的 Element Plus 组件</span><br><span leaf="">- 不引入新的状态管理库</span><br><span leaf="">- 不修改现有接口封装结构</span><br><span leaf="">- 不在 localStorage 中保存用户密码</span><br><span leaf="">- 保持现有代码风格</span><br><br><span leaf="">完成标准：</span><br><br><span leaf="">- 登录成功后保存 token 并跳转到首页</span><br><span leaf="">- 登录失败时展示后端返回的错误信息</span><br><span leaf="">- 按钮提交期间不可重复点击</span><br><span leaf="">- 补充相关测试</span><br><span leaf="">- 运行类型检查和测试</span><br><span leaf="">- 最后总结修改文件、验证结果和剩余风险</span><br>

这类提示词看起来更长，但可以减少大量返工。

三、面对复杂需求，先让 Codex 做计划

不要一拿到复杂需求，就让 Codex 立即修改代码。

尤其是以下任务：

修改核心架构；
跨越多个模块；
涉及数据库迁移；
涉及权限和支付；
需要兼容旧数据；
不确定影响范围；
自己也没有完全想清楚。

这时可以先使用 /plan，或者明确告诉它：

<span leaf="">先不要修改代码。</span><br><br><span leaf="">请先阅读相关代码，完成以下工作：</span><br><br><span leaf="">1. 描述当前实现方式；</span><br><span leaf="">2. 找出会受到影响的模块；</span><br><span leaf="">3. 列出需要修改的文件；</span><br><span leaf="">4. 说明数据流和调用关系；</span><br><span leaf="">5. 分析兼容性风险；</span><br><span leaf="">6. 给出分步骤实施方案；</span><br><span leaf="">7. 列出每一步的验证方法。</span><br><br><span leaf="">在计划通过之前，不要开始实现。</span><br>

Codex 的 Plan 模式可以先收集上下文、分析问题并形成实施计划，再进入代码修改阶段。官方也建议复杂、模糊或难以描述的任务先进行规划。

对于大型任务，还可以要求它生成一个计划文件：

<span leaf="">请把实施方案写入 docs/plans/user-permission-refactor.md。</span><br><br><span leaf="">每个阶段必须包含：</span><br><br><span leaf="">- 目标；</span><br><span leaf="">- 修改范围；</span><br><span leaf="">- 依赖条件；</span><br><span leaf="">- 验证命令；</span><br><span leaf="">- 回滚方式；</span><br><span leaf="">- 完成状态。</span><br>

之后让 Codex 严格按照计划逐步执行。

这样即使中途对话很长，也不容易偏离最初目标。

四、先让 Codex 理解仓库，不要马上写代码

接手一个陌生项目时，很多人会直接问：

这个项目是做什么的？

Codex 可能会给出一段概括，但通常不够具体。

更实用的方式是让它生成一份仓库地图：

<span leaf="">先不要修改任何文件。</span><br><br><span leaf="">请阅读这个项目，并输出一份仓库分析报告：</span><br><br><span leaf="">1. 项目的主要用途；</span><br><span leaf="">2. 使用的技术栈；</span><br><span leaf="">3. 项目启动入口；</span><br><span leaf="">4. 主要目录分别负责什么；</span><br><span leaf="">5. 核心业务模块；</span><br><span leaf="">6. 请求从界面到后端的完整调用链；</span><br><span leaf="">7. 状态管理方式；</span><br><span leaf="">8. 数据存储方式；</span><br><span leaf="">9. 测试和构建命令；</span><br><span leaf="">10. 最值得优先阅读的10个文件。</span><br><br><span leaf="">所有结论都要标注对应的文件路径。</span><br><span leaf="">不确定的内容请明确标记，不要猜测。</span><br>

如果你准备修改某个具体功能，还可以继续缩小范围：

<span leaf="">请跟踪“创建项目”功能的完整执行流程。</span><br><br><span leaf="">从用户点击按钮开始，一直跟踪到数据写入数据库。</span><br><br><span leaf="">请列出：</span><br><br><span leaf="">- 页面组件；</span><br><span leaf="">- 事件处理函数；</span><br><span leaf="">- 状态管理；</span><br><span leaf="">- 前端请求；</span><br><span leaf="">- 后端路由；</span><br><span leaf="">- 业务服务；</span><br><span leaf="">- 数据库操作；</span><br><span leaf="">- 错误处理；</span><br><span leaf="">- 涉及的文件和关键函数。</span><br>

这种提问的目标不是让 Codex 解释代码。

而是让它先建立一张准确的项目地图。

只有理解现有结构，后面的修改才不容易破坏项目。

五、修复 Bug 时，先让它复现问题

很多人看到错误后，会直接把报错发给 Codex：

<span leaf="">帮我修复这个错误。</span><br>

Codex 很可能找到一个看似合理的位置，直接修改代码。

但错误日志只能说明“哪里出错了”，不一定能说明“为什么出错”。

更稳定的 Bug 修复流程是：

<span leaf="">请修复这个问题，但不要立即修改代码。</span><br><br><span leaf="">第一步：分析错误日志和相关代码。</span><br><span leaf="">第二步：找到稳定的复现步骤。</span><br><span leaf="">第三步：判断根本原因，而不是只处理报错位置。</span><br><span leaf="">第四步：先补充一个能够复现问题的失败测试。</span><br><span leaf="">第五步：进行最小范围修复。</span><br><span leaf="">第六步：运行相关测试，确认原测试失败、修复后通过。</span><br><span leaf="">第七步：检查是否可能产生回归。</span><br><br><span leaf="">最后输出：</span><br><br><span leaf="">- 根本原因；</span><br><span leaf="">- 修改文件；</span><br><span leaf="">- 为什么这样修改；</span><br><span leaf="">- 执行过的验证；</span><br><span leaf="">- 仍未覆盖的风险。</span><br>

这里最重要的是两句话：

先补充一个能够复现问题的失败测试。

以及：

进行最小范围修复。

如果没有复现问题，Codex 可能只是让报错暂时消失。

如果不限制修改范围，它可能顺手重构一大片本来没有问题的代码。

六、不要只要求“实现功能”，还要让它自己验证

Codex 修改完代码后，经常会告诉你：

已完成修改。

但“代码已经修改”和“功能已经完成”不是一回事。

你应该明确要求它执行验证闭环：

<span leaf="">完成代码修改后，请继续执行：</span><br><br><span leaf="">1. 安装缺失依赖；</span><br><span leaf="">2. 运行格式检查；</span><br><span leaf="">3. 运行 lint；</span><br><span leaf="">4. 运行 TypeScript 类型检查；</span><br><span leaf="">5. 运行相关单元测试；</span><br><span leaf="">6. 运行完整测试；</span><br><span leaf="">7. 执行项目构建；</span><br><span leaf="">8. 检查最终 diff；</span><br><span leaf="">9. 修复本次修改引入的问题。</span><br><br><span leaf="">不要只告诉我应该运行什么命令，请实际执行能够安全执行的验证命令。</span><br><br><span leaf="">如果某项验证无法执行，请说明具体原因。</span><br>

Codex 官方最佳实践也强调，不要停留在代码生成阶段，而应要求它补充测试、运行检查、确认最终行为，并审查改动中可能存在的回归风险。

对于前端任务，还可以补充可观察的验收标准：

<span leaf="">请验证以下交互：</span><br><br><span leaf="">- 空表单不能提交；</span><br><span leaf="">- 输入错误时显示提示；</span><br><span leaf="">- 请求期间按钮不可重复点击；</span><br><span leaf="">- 请求失败后可以再次提交；</span><br><span leaf="">- 登录成功后只跳转一次；</span><br><span leaf="">- 刷新页面后登录状态仍然正确。</span><br>

对于后端任务，可以补充：

<span leaf="">请验证：</span><br><br><span leaf="">- 正常输入；</span><br><span leaf="">- 缺少参数；</span><br><span leaf="">- 参数类型错误；</span><br><span leaf="">- 无权限访问；</span><br><span leaf="">- 重复请求；</span><br><span leaf="">- 数据不存在；</span><br><span leaf="">- 数据库操作失败；</span><br><span leaf="">- 并发请求。</span><br>

七、把项目规范写进 AGENTS.md

如果你发现自己每次都在重复这些要求：

使用 TypeScript；
不允许使用 any；
不要改变接口结构；
修改后运行测试；
不要直接提交 Git；
保持现有目录结构；
PostgreSQL 才是目标数据库；
所有时间统一使用 UTC；
Vue 组件使用 Composition API；

那么这些规则不应该每次重新输入。

可以把它们写进项目根目录的：

<span leaf="">AGENTS.md</span><br>

Codex 会自动读取 AGENTS.md，把它作为项目长期规范。Codex CLI 还可以通过 /init 生成一个初始版本。

一个实用的 AGENTS.md 可以这样写：

<span><span leaf=""># 项目说明</span></span><br><br><span leaf="">这是一个基于 Vue 3、TypeScript、Electron 和 PostgreSQL 的桌面应用。</span><br><br><span><span leaf="">## 目录</span></span><br><span><br><span leaf="">-&nbsp;</span></span><span leaf="">src/renderer：渲染进程</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">src/main：Electron 主进程</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">src/api：接口请求</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">src/stores：状态管理</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">tests：自动化测试</span><br><br><span><span leaf="">## 开发命令</span></span><br><span><br><span leaf="">-&nbsp;</span></span><span leaf="">npm run dev：启动开发环境</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">npm run lint：代码检查</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">npm run typecheck：类型检查</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">npm run test：运行测试</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">npm run build：生产构建</span><br><br><span><span leaf="">## 编码规范</span></span><br><span><br><span leaf="">-&nbsp;</span></span><span leaf="">使用 TypeScript</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">禁止新增 any</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">Vue 组件使用 Composition API</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">优先修改现有模块，不随意创建重复工具类</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">不改变已有接口返回结构</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">不修改无关代码</span><br><br><span><span leaf="">## 数据库约束</span></span><br><span><br><span leaf="">-&nbsp;</span></span><span leaf="">目标数据库为 PostgreSQL</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">不使用 MySQL 特有语法</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">数据库变更必须提供迁移和回滚脚本</span><br><br><span><span leaf="">## 完成标准</span></span><br><br><span leaf="">每次修改后必须：</span><br><span><br><span leaf="">1.&nbsp;</span></span><span leaf="">运行类型检查；</span><br><span><span leaf="">2.&nbsp;</span></span><span leaf="">运行相关测试；</span><br><span><span leaf="">3.&nbsp;</span></span><span leaf="">运行构建；</span><br><span><span leaf="">4.&nbsp;</span></span><span leaf="">检查最终 diff；</span><br><span><span leaf="">5.&nbsp;</span></span><span leaf="">总结修改内容和风险。</span><br><br><span><span leaf="">## 禁止操作</span></span><br><span><br><span leaf="">-&nbsp;</span></span><span leaf="">不自动提交 Git</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">不自动推送远程仓库</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">不删除用户数据</span><br><span><span leaf="">-&nbsp;</span></span><span leaf="">不修改生产环境配置</span><br>

AGENTS.md 不需要写成几十页文档。

越短、越明确、越接近真实项目，效果越好。

官方建议也指出，简短准确的规则通常比充满模糊要求的长文档更有用；当 Codex 反复出现同一个错误时，再把对应规则补充进去。

八、修改完成后，再开一个任务专门审查

不要让“写代码的 Codex”同时完全相信自己的代码。

一个更可靠的做法是：

第一个任务负责实现；
第二个任务负责审查；
必要时第三个任务负责测试。

在 Codex CLI 中，可以使用：

<span leaf="">/review</span><br>

它可以检查：

当前未提交的修改；
某个提交；
与基础分支之间的差异；
根据自定义规则进行审查。

Codex 官方最佳实践将 /review 作为重要的代码检查方式，并建议将团队审查规范写入单独文件，再通过 AGENTS.md 引用。

可以使用下面的审查提示词：

<span leaf="">请以资深代码审查者的身份检查当前修改。</span><br><br><span leaf="">重点查找：</span><br><br><span leaf="">1. 功能错误；</span><br><span leaf="">2. 边界条件；</span><br><span leaf="">3. 空值处理；</span><br><span leaf="">4. 并发问题；</span><br><span leaf="">5. 资源泄漏；</span><br><span leaf="">6. 安全风险；</span><br><span leaf="">7. 性能退化；</span><br><span leaf="">8. 兼容性问题；</span><br><span leaf="">9. 测试遗漏；</span><br><span leaf="">10. 不必要的修改。</span><br><br><span leaf="">不要总结代码内容。</span><br><br><span leaf="">只报告真实存在、值得修改的问题。</span><br><br><span leaf="">每个问题必须包含：</span><br><br><span leaf="">- 严重程度；</span><br><span leaf="">- 文件和位置；</span><br><span leaf="">- 触发条件；</span><br><span leaf="">- 可能造成的后果；</span><br><span leaf="">- 建议修改方式。</span><br>

“不要总结代码内容”非常重要。

否则 Codex 可能写出一篇很长的代码说明，却没有真正指出问题。

九、把一个大任务拆给多个 Codex

假设你需要完成一个用户权限系统。

不要把所有内容放进同一个超长任务：

<span leaf="">帮我完成整个权限系统。</span><br>

可以拆成几个互相独立的任务：

任务一：分析现有权限结构

<span leaf="">阅读当前认证和权限相关代码。</span><br><br><span leaf="">输出：</span><br><br><span leaf="">- 当前权限模型；</span><br><span leaf="">- 登录流程；</span><br><span leaf="">- 权限校验位置；</span><br><span leaf="">- 数据库结构；</span><br><span leaf="">- 存在的问题；</span><br><span leaf="">- 推荐迁移方案。</span><br><br><span leaf="">不要修改代码。</span><br>

任务二：数据库设计

<span leaf="">根据权限改造方案，设计数据库迁移。</span><br><br><span leaf="">要求：</span><br><br><span leaf="">- 兼容现有用户；</span><br><span leaf="">- 提供升级脚本；</span><br><span leaf="">- 提供回滚脚本；</span><br><span leaf="">- 不删除现有数据；</span><br><span leaf="">- 补充数据库测试。</span><br>

任务三：后端实现

<span leaf="">根据已确认的权限方案，完成后端权限校验。</span><br><br><span leaf="">只修改后端相关模块。</span><br><span leaf="">不修改前端页面。</span><br>

任务四：前端实现

<span leaf="">实现前端权限控制。</span><br><br><span leaf="">包括：</span><br><br><span leaf="">- 路由权限；</span><br><span leaf="">- 菜单权限；</span><br><span leaf="">- 按钮权限；</span><br><span leaf="">- 无权限提示；</span><br><span leaf="">- 登录状态失效处理。</span><br>

任务五：测试和审查

<span leaf="">审查整个权限系统修改。</span><br><br><span leaf="">补充缺失测试，并检查：</span><br><br><span leaf="">- 越权访问；</span><br><span leaf="">- 旧账号兼容；</span><br><span leaf="">- 权限缓存；</span><br><span leaf="">- 并发修改；</span><br><span leaf="">- 接口遗漏；</span><br><span leaf="">- 前后端权限不一致。</span><br>

Codex 桌面应用和云端环境都适合并行执行这类相互独立的任务。桌面应用使用独立 worktree 隔离不同代理的代码修改，云端任务则运行在各自的环境中。

不过，并行任务必须尽量减少重叠。

不要让三个代理同时修改同一个核心文件，否则最后合并代码可能比手写更麻烦。

十、谨慎设置权限，不要一上来就开启完全访问

Codex 能够执行终端命令，也意味着它可能：

修改大量文件；
删除文件；
安装依赖；
访问网络；
执行脚本；
操作 Git；
接触环境变量。

Codex 默认会通过沙箱和操作审批限制可以访问的目录和执行的命令，本地运行时默认网络访问也是关闭的。

第一次使用时，建议保留默认权限。

等你明确知道某个项目需要什么操作之后，再逐步放开。

可以使用：

<span leaf="">/permissions</span><br>

查看和修改当前权限。

对于陌生仓库，尤其不要直接允许：

执行来源不明的安装脚本；
访问生产数据库；
读取整个用户目录；
自动推送远程仓库；
自动发布版本；
修改线上环境；
删除大量文件。

还可以在任务中明确审批边界：

<span leaf="">你可以自行执行：</span><br><br><span leaf="">- 读取当前仓库文件；</span><br><span leaf="">- 修改当前任务涉及的代码；</span><br><span leaf="">- 运行本地测试；</span><br><span leaf="">- 运行 lint 和构建；</span><br><span leaf="">- 查看 Git diff。</span><br><br><span leaf="">执行以下操作前必须先征得我的同意：</span><br><br><span leaf="">- 删除文件；</span><br><span leaf="">- 修改数据库数据；</span><br><span leaf="">- 安装全局依赖；</span><br><span leaf="">- 访问生产环境；</span><br><span leaf="">- 推送 Git；</span><br><span leaf="">- 创建或合并 Pull Request；</span><br><span leaf="">- 发布软件；</span><br><span leaf="">- 执行不可逆操作。</span><br>

好的权限设置不是让 Codex 什么都不能做。

而是让它能够连续完成安全的本地工作，同时在高风险操作之前停下来。

十一、一个可以直接复制的完整任务模板

以后让 Codex开发功能，可以直接套用下面这个模板：

<span leaf="">任务目标：</span><br><br><span leaf="">【描述最终想实现的功能或修复的问题】</span><br><br><span leaf="">相关上下文：</span><br><br><span leaf="">- 相关目录：</span><br><span leaf="">- 相关文件：</span><br><span leaf="">- 错误日志：</span><br><span leaf="">- 参考实现：</span><br><span leaf="">- 接口文档：</span><br><span leaf="">- 业务背景：</span><br><br><span leaf="">限制条件：</span><br><br><span leaf="">- 保持现有架构；</span><br><span leaf="">- 遵守 AGENTS.md；</span><br><span leaf="">- 不修改无关代码；</span><br><span leaf="">- 不引入不必要的依赖；</span><br><span leaf="">- 不改变已有接口行为；</span><br><span leaf="">- 不执行 Git 提交和推送；</span><br><span leaf="">- 遇到不确定信息时先通过代码确认，不要猜测。</span><br><br><span leaf="">执行步骤：</span><br><br><span leaf="">1. 阅读相关代码；</span><br><span leaf="">2. 描述当前实现；</span><br><span leaf="">3. 找出根本原因或实现入口；</span><br><span leaf="">4. 制定修改计划；</span><br><span leaf="">5. 完成最小范围修改；</span><br><span leaf="">6. 补充或更新测试；</span><br><span leaf="">7. 运行 lint、类型检查、测试和构建；</span><br><span leaf="">8. 检查最终 diff；</span><br><span leaf="">9. 修复验证过程中发现的问题。</span><br><br><span leaf="">完成标准：</span><br><br><span leaf="">- 功能满足需求；</span><br><span leaf="">- 原有功能没有明显回归；</span><br><span leaf="">- 所有相关测试通过；</span><br><span leaf="">- 类型检查通过；</span><br><span leaf="">- 项目构建通过；</span><br><span leaf="">- 没有修改无关文件。</span><br><br><span leaf="">最终输出：</span><br><br><span leaf="">1. 问题或需求分析；</span><br><span leaf="">2. 修改过的文件；</span><br><span leaf="">3. 每项修改的原因；</span><br><span leaf="">4. 执行过的验证；</span><br><span leaf="">5. 验证结果；</span><br><span leaf="">6. 仍然存在的风险；</span><br><span leaf="">7. 建议人工检查的内容。</span><br>

它不会适合所有任务，但已经覆盖了大部分真实的软件开发场景。

十二、使用 Codex 最常见的五个错误

1. 一句话让它修改整个项目

任务范围越模糊，Codex 自由发挥的空间越大。

最终修改也越难审查。

2. 只描述功能，不提供业务背景

同样是删除按钮，可能代表：

删除本地临时记录；
软删除数据库数据；
永久删除用户文件；
取消一个任务；
撤销一个发布。

没有业务背景，代码正确也可能是业务错误。

3. 不要求运行测试

Codex 可以写出语法正确、逻辑看似合理的代码。

但只有运行测试和构建，才能发现真实问题。

4. 一个对话连续处理大量无关任务

对话越长，旧任务、临时要求和新目标越容易互相影响。

不同任务最好创建不同线程。

5. 看到“已完成”就直接相信

Codex 的完成说明只能作为参考。

最终仍然要查看：

代码差异；
测试结果；
构建结果；
权限变化；
数据库迁移；
配置文件；
是否修改了无关内容。

最后

Codex 真正改变的，不是程序员写代码的速度。

而是软件开发任务的组织方式。

以前，我们需要自己完成整个流程：

阅读代码、定位问题、设计方案、编写代码、运行测试、检查修改。

现在，可以把其中大量重复性工作交给 Codex。

但前提是，你不能只对它说：

帮我写一下。

而应该告诉它：

目标是什么；
应该阅读哪些内容；
必须遵守哪些限制；
可以执行哪些操作；
怎样验证结果；
达到什么条件才算完成。

把 Codex 当代码生成器，它只能帮你节省几分钟。

把 Codex 当成一个需要管理、约束和验收的开发代理，它才能真正改变你的工作方式。

文章目录