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

# 别再让 Codex 只帮你写几行代码了：10 个真正实用的开发技巧 很多程序员第一次使用 Codex，通常会这样提问： > 帮我写一个登录页面。 > 帮我生成一个接口。 > 帮我修复这段代码。 Codex 很快就会返回一堆代码。 看起来效率很高，但真正放进项目后，却经常出现各种问题： * 代码风格和原项目不一致； * 修改了不应该修改的文件； * 功能能运行，但破坏了其他逻辑； * 没有补充测试； * 没理解业务，只实现了表面需求； * 改动太大，根本不敢直接合并。 问题不一定出在 Codex 能力不够。 更常见的原因是： **我们仍然把 Codex 当成代码生成器，而不是一个可以阅读仓库、执行命令、修改文件、运行测试和检查结果的编程代理。** Codex 目前可以在终端、IDE、桌面应用和云端环境中使用。Codex CLI 能直接读取本地仓库、修改文件并调用电脑上已经安装的开发工具；云端版本则可以在隔离环境中并行执行多个任务。 真正提高开发效率的关键，不是让它“多写代码”。 而是让它完成一个完整的软件开发闭环。 --- ## 一、先根据任务选择正确的 Codex 使用方式 Codex 并不只有一个聊天窗口。 不同的开发任务，适合放在不同的位置完成。 ### 1. 小范围修改：使用 IDE 插件 例如： * 修改当前组件； * 补充一个接口参数； * 解释一段代码； * 修复一个类型错误； * 调整某个函数的实现。 这类任务需要频繁查看代码和立即检查差异，放在 IDE 中最方便。 你可以一边查看源代码，一边让 Codex 修改，再直接检查它生成的 diff。 --- ### 2. 调试和本地开发：使用 Codex CLI 例如： * 启动项目； * 运行测试； * 查看构建错误； * 搜索代码调用关系； * 执行 Git 命令； * 分析日志； * 修改多个相关文件。 在项目目录中运行： ```bash codex ``` Codex 就可以读取当前仓库，并使用本机已经安装的 Node.js、Python、Rust、Git、测试工具和构建工具。 Codex CLI 还提供了几个很实用的命令： ```text /init /status /permissions /model /review ``` 其中： * `/init`：生成项目的 `AGENTS.md`； * `/status`：查看当前模型、目录和权限状态； * `/permissions`：调整 Codex 可以执行的操作； * `/model`：切换模型和推理强度； * `/review`：检查当前代码改动。 这些命令已经覆盖了大部分日常开发流程。 --- ### 3. 多任务并行：使用 Codex 桌面应用 当你同时有多个开发任务时，可以把它们交给不同的 Codex 线程。 例如： * 一个任务修复登录问题； * 一个任务补充单元测试； * 一个任务升级依赖； * 一个任务分析性能瓶颈； * 一个任务审查最近的代码修改。 Codex 桌面应用支持让多个代理在独立线程中工作，并通过独立 worktree 避免它们直接修改同一份工作目录。你可以分别查看每个任务的修改，再决定采用哪一个结果。 这比让一个 Codex 在同一个对话中连续处理五件事情更可靠。 --- ### 4. 长时间任务：使用 Codex 云端 例如： * 大规模代码迁移； * 全仓库测试补充； * 多模块重构； * 安全扫描； * 依赖升级； * 批量修复同类型问题。 Codex 云端会为任务创建隔离环境，可以同时运行多个任务，而不占用本地电脑。任务完成后，你可以查看总结和代码差异，再继续修改或创建 Pull Request。 --- ## 二、不要只描述“做什么”，还要说明“怎样算完成” 下面是一条非常常见的提示词： ```text 帮我增加用户登录功能。 ``` 这句话的问题不是不够详细。 而是缺少完成标准。 Codex 不知道： * 使用哪种登录方式； * 接口放在哪里； * 是否需要保存登录状态； * 错误如何展示； * 是否需要测试； * 哪些文件不能修改； * 怎样才算任务完成。 一个更稳定的 Codex 提示词，应该包含四部分： ```text 目标 + 上下文 + 限制条件 + 完成标准 ``` OpenAI 的 Codex 最佳实践也建议，在任务中明确目标、相关文件和资料、必须遵守的约束，以及任务完成时应满足的条件。 例如： ```text 目标： 在现有 Vue 3 项目中增加用户名和密码登录功能。 上下文： - 登录页面位于 src/views/Login.vue - 请求工具位于 src/utils/request.ts - 用户状态由 src/stores/user.ts 管理 - 后端登录接口为 POST /api/login 限制： - 沿用项目现有的 Element Plus 组件 - 不引入新的状态管理库 - 不修改现有接口封装结构 - 不在 localStorage 中保存用户密码 - 保持现有代码风格 完成标准： - 登录成功后保存 token 并跳转到首页 - 登录失败时展示后端返回的错误信息 - 按钮提交期间不可重复点击 - 补充相关测试 - 运行类型检查和测试 - 最后总结修改文件、验证结果和剩余风险 ``` 这类提示词看起来更长，但可以减少大量返工。 --- ## 三、面对复杂需求，先让 Codex 做计划 不要一拿到复杂需求，就让 Codex 立即修改代码。 尤其是以下任务： * 修改核心架构； * 跨越多个模块； * 涉及数据库迁移； * 涉及权限和支付； * 需要兼容旧数据； * 不确定影响范围； * 自己也没有完全想清楚。 这时可以先使用 `/plan`，或者明确告诉它： ```text 先不要修改代码。 请先阅读相关代码，完成以下工作： 1. 描述当前实现方式； 2. 找出会受到影响的模块； 3. 列出需要修改的文件； 4. 说明数据流和调用关系； 5. 分析兼容性风险； 6. 给出分步骤实施方案； 7. 列出每一步的验证方法。 在计划通过之前，不要开始实现。 ``` Codex 的 Plan 模式可以先收集上下文、分析问题并形成实施计划，再进入代码修改阶段。官方也建议复杂、模糊或难以描述的任务先进行规划。 对于大型任务，还可以要求它生成一个计划文件： ```text 请把实施方案写入 docs/plans/user-permission-refactor.md。 每个阶段必须包含： - 目标； - 修改范围； - 依赖条件； - 验证命令； - 回滚方式； - 完成状态。 ``` 之后让 Codex 严格按照计划逐步执行。 这样即使中途对话很长，也不容易偏离最初目标。 --- ## 四、先让 Codex 理解仓库，不要马上写代码 接手一个陌生项目时，很多人会直接问： > 这个项目是做什么的？ Codex 可能会给出一段概括，但通常不够具体。 更实用的方式是让它生成一份仓库地图： ```text 先不要修改任何文件。 请阅读这个项目，并输出一份仓库分析报告： 1. 项目的主要用途； 2. 使用的技术栈； 3. 项目启动入口； 4. 主要目录分别负责什么； 5. 核心业务模块； 6. 请求从界面到后端的完整调用链； 7. 状态管理方式； 8. 数据存储方式； 9. 测试和构建命令； 10. 最值得优先阅读的10个文件。 所有结论都要标注对应的文件路径。 不确定的内容请明确标记，不要猜测。 ``` 如果你准备修改某个具体功能，还可以继续缩小范围： ```text 请跟踪“创建项目”功能的完整执行流程。 从用户点击按钮开始，一直跟踪到数据写入数据库。 请列出： - 页面组件； - 事件处理函数； - 状态管理； - 前端请求； - 后端路由； - 业务服务； - 数据库操作； - 错误处理； - 涉及的文件和关键函数。 ``` 这种提问的目标不是让 Codex 解释代码。 而是让它先建立一张准确的项目地图。 只有理解现有结构，后面的修改才不容易破坏项目。 --- ## 五、修复 Bug 时，先让它复现问题 很多人看到错误后，会直接把报错发给 Codex： ```text 帮我修复这个错误。 ``` Codex 很可能找到一个看似合理的位置，直接修改代码。 但错误日志只能说明“哪里出错了”，不一定能说明“为什么出错”。 更稳定的 Bug 修复流程是： ```text 请修复这个问题，但不要立即修改代码。 第一步：分析错误日志和相关代码。 第二步：找到稳定的复现步骤。 第三步：判断根本原因，而不是只处理报错位置。 第四步：先补充一个能够复现问题的失败测试。 第五步：进行最小范围修复。 第六步：运行相关测试，确认原测试失败、修复后通过。 第七步：检查是否可能产生回归。 最后输出： - 根本原因； - 修改文件； - 为什么这样修改； - 执行过的验证； - 仍未覆盖的风险。 ``` 这里最重要的是两句话： > 先补充一个能够复现问题的失败测试。 以及： > 进行最小范围修复。 如果没有复现问题，Codex 可能只是让报错暂时消失。 如果不限制修改范围，它可能顺手重构一大片本来没有问题的代码。 --- ## 六、不要只要求“实现功能”，还要让它自己验证 Codex 修改完代码后，经常会告诉你： > 已完成修改。 但“代码已经修改”和“功能已经完成”不是一回事。 你应该明确要求它执行验证闭环： ```text 完成代码修改后，请继续执行： 1. 安装缺失依赖； 2. 运行格式检查； 3. 运行 lint； 4. 运行 TypeScript 类型检查； 5. 运行相关单元测试； 6. 运行完整测试； 7. 执行项目构建； 8. 检查最终 diff； 9. 修复本次修改引入的问题。 不要只告诉我应该运行什么命令，请实际执行能够安全执行的验证命令。 如果某项验证无法执行，请说明具体原因。 ``` Codex 官方最佳实践也强调，不要停留在代码生成阶段，而应要求它补充测试、运行检查、确认最终行为，并审查改动中可能存在的回归风险。 对于前端任务，还可以补充可观察的验收标准： ```text 请验证以下交互： - 空表单不能提交； - 输入错误时显示提示； - 请求期间按钮不可重复点击； - 请求失败后可以再次提交； - 登录成功后只跳转一次； - 刷新页面后登录状态仍然正确。 ``` 对于后端任务，可以补充： ```text 请验证： - 正常输入； - 缺少参数； - 参数类型错误； - 无权限访问； - 重复请求； - 数据不存在； - 数据库操作失败； - 并发请求。 ``` --- ## 七、把项目规范写进 AGENTS.md 如果你发现自己每次都在重复这些要求： * 使用 TypeScript； * 不允许使用 `any`； * 不要改变接口结构； * 修改后运行测试； * 不要直接提交 Git； * 保持现有目录结构； * PostgreSQL 才是目标数据库； * 所有时间统一使用 UTC； * Vue 组件使用 Composition API； 那么这些规则不应该每次重新输入。 可以把它们写进项目根目录的： ```text AGENTS.md ``` Codex 会自动读取 `AGENTS.md`，把它作为项目长期规范。Codex CLI 还可以通过 `/init` 生成一个初始版本。 一个实用的 `AGENTS.md` 可以这样写： ```markdown # 项目说明 这是一个基于 Vue 3、TypeScript、Electron 和 PostgreSQL 的桌面应用。 ## 目录 - src/renderer：渲染进程 - src/main：Electron 主进程 - src/api：接口请求 - src/stores：状态管理 - tests：自动化测试 ## 开发命令 - npm run dev：启动开发环境 - npm run lint：代码检查 - npm run typecheck：类型检查 - npm run test：运行测试 - npm run build：生产构建 ## 编码规范 - 使用 TypeScript - 禁止新增 any - Vue 组件使用 Composition API - 优先修改现有模块，不随意创建重复工具类 - 不改变已有接口返回结构 - 不修改无关代码 ## 数据库约束 - 目标数据库为 PostgreSQL - 不使用 MySQL 特有语法 - 数据库变更必须提供迁移和回滚脚本 ## 完成标准 每次修改后必须： 1. 运行类型检查； 2. 运行相关测试； 3. 运行构建； 4. 检查最终 diff； 5. 总结修改内容和风险。 ## 禁止操作 - 不自动提交 Git - 不自动推送远程仓库 - 不删除用户数据 - 不修改生产环境配置 ``` `AGENTS.md` 不需要写成几十页文档。 越短、越明确、越接近真实项目，效果越好。 官方建议也指出，简短准确的规则通常比充满模糊要求的长文档更有用；当 Codex 反复出现同一个错误时，再把对应规则补充进去。 --- ## 八、修改完成后，再开一个任务专门审查 不要让“写代码的 Codex”同时完全相信自己的代码。 一个更可靠的做法是： 1. 第一个任务负责实现； 2. 第二个任务负责审查； 3. 必要时第三个任务负责测试。 在 Codex CLI 中，可以使用： ```text /review ``` 它可以检查： * 当前未提交的修改； * 某个提交； * 与基础分支之间的差异； * 根据自定义规则进行审查。 Codex 官方最佳实践将 `/review` 作为重要的代码检查方式，并建议将团队审查规范写入单独文件，再通过 `AGENTS.md` 引用。 可以使用下面的审查提示词： ```text 请以资深代码审查者的身份检查当前修改。 重点查找： 1. 功能错误； 2. 边界条件； 3. 空值处理； 4. 并发问题； 5. 资源泄漏； 6. 安全风险； 7. 性能退化； 8. 兼容性问题； 9. 测试遗漏； 10. 不必要的修改。 不要总结代码内容。 只报告真实存在、值得修改的问题。 每个问题必须包含： - 严重程度； - 文件和位置； - 触发条件； - 可能造成的后果； - 建议修改方式。 ``` “不要总结代码内容”非常重要。 否则 Codex 可能写出一篇很长的代码说明，却没有真正指出问题。 --- ## 九、把一个大任务拆给多个 Codex 假设你需要完成一个用户权限系统。 不要把所有内容放进同一个超长任务： ```text 帮我完成整个权限系统。 ``` 可以拆成几个互相独立的任务： ### 任务一：分析现有权限结构 ```text 阅读当前认证和权限相关代码。 输出： - 当前权限模型； - 登录流程； - 权限校验位置； - 数据库结构； - 存在的问题； - 推荐迁移方案。 不要修改代码。 ``` ### 任务二：数据库设计 ```text 根据权限改造方案，设计数据库迁移。 要求： - 兼容现有用户； - 提供升级脚本； - 提供回滚脚本； - 不删除现有数据； - 补充数据库测试。 ``` ### 任务三：后端实现 ```text 根据已确认的权限方案，完成后端权限校验。 只修改后端相关模块。 不修改前端页面。 ``` ### 任务四：前端实现 ```text 实现前端权限控制。 包括： - 路由权限； - 菜单权限； - 按钮权限； - 无权限提示； - 登录状态失效处理。 ``` ### 任务五：测试和审查 ```text 审查整个权限系统修改。 补充缺失测试，并检查： - 越权访问； - 旧账号兼容； - 权限缓存； - 并发修改； - 接口遗漏； - 前后端权限不一致。 ``` Codex 桌面应用和云端环境都适合并行执行这类相互独立的任务。桌面应用使用独立 worktree 隔离不同代理的代码修改，云端任务则运行在各自的环境中。 不过，并行任务必须尽量减少重叠。 不要让三个代理同时修改同一个核心文件，否则最后合并代码可能比手写更麻烦。 --- ## 十、谨慎设置权限，不要一上来就开启完全访问 Codex 能够执行终端命令，也意味着它可能： * 修改大量文件； * 删除文件； * 安装依赖； * 访问网络； * 执行脚本； * 操作 Git； * 接触环境变量。 Codex 默认会通过沙箱和操作审批限制可以访问的目录和执行的命令，本地运行时默认网络访问也是关闭的。 第一次使用时，建议保留默认权限。 等你明确知道某个项目需要什么操作之后，再逐步放开。 可以使用： ```text /permissions ``` 查看和修改当前权限。 对于陌生仓库，尤其不要直接允许： * 执行来源不明的安装脚本； * 访问生产数据库； * 读取整个用户目录； * 自动推送远程仓库； * 自动发布版本； * 修改线上环境； * 删除大量文件。 还可以在任务中明确审批边界： ```text 你可以自行执行： - 读取当前仓库文件； - 修改当前任务涉及的代码； - 运行本地测试； - 运行 lint 和构建； - 查看 Git diff。 执行以下操作前必须先征得我的同意： - 删除文件； - 修改数据库数据； - 安装全局依赖； - 访问生产环境； - 推送 Git； - 创建或合并 Pull Request； - 发布软件； - 执行不可逆操作。 ``` 好的权限设置不是让 Codex 什么都不能做。 而是让它能够连续完成安全的本地工作，同时在高风险操作之前停下来。 --- ## 十一、一个可以直接复制的完整任务模板 以后让 Codex开发功能，可以直接套用下面这个模板： ```text 任务目标： 【描述最终想实现的功能或修复的问题】 相关上下文： - 相关目录： - 相关文件： - 错误日志： - 参考实现： - 接口文档： - 业务背景： 限制条件： - 保持现有架构； - 遵守 AGENTS.md； - 不修改无关代码； - 不引入不必要的依赖； - 不改变已有接口行为； - 不执行 Git 提交和推送； - 遇到不确定信息时先通过代码确认，不要猜测。 执行步骤： 1. 阅读相关代码； 2. 描述当前实现； 3. 找出根本原因或实现入口； 4. 制定修改计划； 5. 完成最小范围修改； 6. 补充或更新测试； 7. 运行 lint、类型检查、测试和构建； 8. 检查最终 diff； 9. 修复验证过程中发现的问题。 完成标准： - 功能满足需求； - 原有功能没有明显回归； - 所有相关测试通过； - 类型检查通过； - 项目构建通过； - 没有修改无关文件。 最终输出： 1. 问题或需求分析； 2. 修改过的文件； 3. 每项修改的原因； 4. 执行过的验证； 5. 验证结果； 6. 仍然存在的风险； 7. 建议人工检查的内容。 ``` 它不会适合所有任务，但已经覆盖了大部分真实的软件开发场景。 --- ## 十二、使用 Codex 最常见的五个错误 ### 1. 一句话让它修改整个项目 任务范围越模糊，Codex 自由发挥的空间越大。 最终修改也越难审查。 --- ### 2. 只描述功能，不提供业务背景 同样是删除按钮，可能代表： * 删除本地临时记录； * 软删除数据库数据； * 永久删除用户文件； * 取消一个任务； * 撤销一个发布。 没有业务背景，代码正确也可能是业务错误。 --- ### 3. 不要求运行测试 Codex 可以写出语法正确、逻辑看似合理的代码。 但只有运行测试和构建，才能发现真实问题。 --- ### 4. 一个对话连续处理大量无关任务 对话越长，旧任务、临时要求和新目标越容易互相影响。 不同任务最好创建不同线程。 --- ### 5. 看到“已完成”就直接相信 Codex 的完成说明只能作为参考。 最终仍然要查看： * 代码差异； * 测试结果； * 构建结果； * 权限变化； * 数据库迁移； * 配置文件； * 是否修改了无关内容。 --- ## 最后 Codex 真正改变的，不是程序员写代码的速度。 而是软件开发任务的组织方式。 以前，我们需要自己完成整个流程： 阅读代码、定位问题、设计方案、编写代码、运行测试、检查修改。 现在，可以把其中大量重复性工作交给 Codex。 但前提是，你不能只对它说： > 帮我写一下。 而应该告诉它： * 目标是什么； * 应该阅读哪些内容； * 必须遵守哪些限制； * 可以执行哪些操作； * 怎样验证结果； * 达到什么条件才算完成。 **把 Codex 当代码生成器，它只能帮你节省几分钟。** **把 Codex 当成一个需要管理、约束和验收的开发代理，它才能真正改变你的工作方式。** 本文由[mdnice](https://mdnice.com/?platform=6)多平台发布
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成，浏览时请结合常识与多方信息审慎甄别。
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

友情链接更多精彩内容