如果只让 Codex 补一个函数，它当然能做。可这跟编辑器里的代码补全没有拉开多大差距。
更能说明问题的任务是：“找出支付回调偶发重复入账的原因，修复后补回归测试。”Codex 会进入项目，阅读说明和相关代码，搜索调用链，跑测试或诊断命令，再修改文件。做完以后，你拿到的是一组实际改动和验证结果，不只是聊天框里的一段建议。
把它理解成一个能使用开发工具的编程 Agent，会更接近它的工作方式。
一次任务是怎么跑的
典型过程大概如下：
读目标和限制
-> 查看仓库结构与项目说明
-> 搜索相关代码和测试
-> 选择改动方案
-> 编辑文件，运行验证
-> 检查差异，继续修正
-> 汇报结果和剩余风险
模型负责理解与推理，Codex 的运行环境提供文件、终端、Git 和其他工具。每次操作都会留下文件差异或命令结果，出错时还有东西可查。这一点比“回答听起来像对的”有用得多。
Codex 可以在哪儿运行
根据 OpenAI 当前官方文档，Codex 有桌面应用、命令行、IDE 扩展、Cloud 和 SDK 等入口。桌面应用里，一项任务还能选择不同环境：
| 环境 | 用法 |
|---|---|
| Local | 直接处理当前项目目录，适合手头正在做的本地任务 |
| Worktree | 在独立的 Git worktree 中改代码，多个任务可以并行，文件互不覆盖 |
| Cloud | 放到配置好的远程环境执行，不需要一直占用当前电脑 |
命令行适合终端工作流，也能通过非交互模式接进脚本和 CI。IDE 扩展会围绕当前打开的文件提供上下文。SDK 留给内部平台或自动化流程。入口不同，给 Codex 的仍然是同一组东西：代码环境、任务目标、可用工具和权限。
什么任务比较合适
边界清楚、结果能检查的任务，通常做得更稳。例如：
- 沿着真实调用链查 Bug，补测试再修复。
- 按项目现有风格实现一个小功能。
- 迁移 API、补类型，或者完成重复性重构。
- 读一个陌生仓库，画出入口、模块和数据流。
- 审查一组改动，找回归、权限和并发问题。
- 跑测试、构建和静态检查，根据失败继续改。
“把这个项目优化一下”就很难做。什么算优化，哪些文件可以动，速度和可维护性冲突时选哪个，Codex 都只能猜。它也许会改很多，但改得多不是完成度。
提示词不用写成咒语
把目标、上下文、边界和验收方式交代清楚就够了：
修复订单详情页在刷新后丢失筛选条件的问题。
先检查路由状态和现有前端测试，只修改这个问题涉及的文件。
不要升级依赖，也不要重构其他页面。
补一个能复现问题的测试，完成后运行相关测试和构建。
这段要求没有指定它必须改哪个函数，仍然给出了复现方向、修改范围和完成标准。大型改动可以先让 Codex 只读调查，方案确认后再实施。数据库修改、删除、发布和对外发送这类动作，也应在任务里明确要求先停下来确认。
它有权限，所以权限要收住
OpenAI 官方文档把本地安全控制分成两层。Sandbox 限制命令实际能访问的文件和网络资源；approval policy 决定哪些动作需要暂停，等用户批准。
默认情况下，本地 Agent 关闭网络访问，写入通常限制在当前工作区。Codex Cloud 运行在隔离的托管容器中。权限可以调整，但没有必要为了少点一次确认，就长期开放完整磁盘和网络。
解释代码时用只读，正常开发只开放当前工作区，安装依赖时临时放开网络。密钥、生产数据库和不可逆操作继续留给人确认。这套做法有点保守，返工时会感谢它。
人还要看什么
Codex 不知道团队没写进仓库的业务约定，也无法替产品负责人定义需求。测试通过可能只是把错误理解一起写进了测试。重要改动依然要检查需求、diff、测试范围和发布风险。
程序员可以少花一些时间搜索文件、重复编辑和等命令，把精力留给范围判断和验收。这个分工比较实际，也不需要讨论“AI 会不会彻底代替程序员”。
第一次用时，找一个有复现步骤、有相关测试、人工一两个小时能做完的问题。让 Codex 调查、修改、验证，然后认真看一遍差异。这个小循环跑稳了，再交给它跨文件重构或更长的任务。