结论先说
Codex 最值得关注的变化，不是“它又会写更多代码了”，而是它正在从一次性问答工具，变成一个可以围绕工程任务持续工作的工作台。
对开发者来说，真正的分水岭也不再是“提示词写得多漂亮”，而是你能不能把任务写成一个 Codex 可以执行、验证、恢复和审查的工程闭环。简单说，ChatGPT 更适合帮你讨论思路、解释概念、推演方案；Codex 更适合进入仓库，把方案变成代码、测试、文档和可审查的 diff。
这篇文章适合三类读者：
- 已经在用 Codex、ChatGPT 或其他 coding agent 写代码，但经常觉得任务半路跑偏的人
- 想把 AI 编程从个人效率工具升级为团队工程流程的人
- 正在维护复杂代码库，希望让 AI 能稳定接手小型修复、重构、文档和验证工作的人
不适合直接交给 Codex 的任务也要先说清楚：需求本身还没有判断标准、涉及高风险生产操作、需要访问敏感数据、或者没有任何测试与回滚路径的任务，都不应该靠一句“帮我搞定”来启动。
为什么一次性 Prompt 容易断线
很多人使用 AI 编程助手的方式仍然停留在一轮对话里：
帮我改一下这个功能。
这种写法对小改动可能够用，但一旦任务跨越多个文件、多个检查步骤、多个反馈轮次，就会出现几个典型问题：
- 背景散在聊天记录里，模型下一个回合不一定还抓得住重点
- 成功标准太模糊，做完以后只能靠人肉判断
- 测试、lint、构建、截图、日志没有被纳入任务定义
- 经验没有沉淀，下次类似任务还要重新解释
- 人不在电脑前时，任务遇到决策点就停住
OpenAI 在 2026 年 2 月发布的 Harness Engineering 实践里给了一个很强的信号：当 coding agent 的代码产出速度变快后，稀缺资源不再是“写代码的手”，而是人的注意力、工程环境的可读性，以及验证闭环。到了 2026 年 6 月的 Codex 长任务白皮书，这个方向进一步被具体化为持久工作空间、可验证步骤和人工审查边界。
换句话说，问题不只是“Codex 能不能写代码”，而是“你的仓库是否足够让 Codex 工作”。
一个可运行的 Codex 工作台由五层组成
把 Codex 用好，不是把提示词写长，而是把工作现场搭出来。可以先从五层看。
第一层：持久线程，给任务一个固定位置
复杂任务不要散落在临时聊天里。一个长期推进的需求、一个产品发布、一组待修复问题，都应该有固定线程或固定工作上下文。
Codex 的线程模型允许你在同一任务中继续追问、追加约束、恢复上下文。长任务还可能经历上下文压缩，所以更应该把关键事实放进文件，而不是只留在聊天里。
实用做法：
- 一个线程只服务一个工作域，例如“支付模块重构”或“文档站发布检查”
- 每次让 Codex 继续工作前，先要求它复述当前目标、已完成事项和下一步
- 关键决策不要只写在对话里，要同步到仓库文档或计划文件
第二层：仓库地图，让 Codex 知道去哪找答案
Codex 官方最佳实践反复强调 AGENTS.md 的价值。它不是装饰性 README，而是给 agent 的仓库入口。
一个有效的 AGENTS.md 不需要很长，但必须可执行。至少应该包含：
- 仓库目录结构和重要模块
- 本地启动、构建、测试、lint 命令
- 代码风格、架构边界和禁止事项
- PR 或发布前必须完成的检查
- 什么情况下任务才算完成
这里有一个关键取舍：AGENTS.md 应该像地图，不应该像百科全书。真正详细的架构说明、执行计划、API 契约、排障文档，可以放到 docs/、plans/ 或其他明确目录里，再由 AGENTS.md 指过去。
这样做的好处是渐进披露：Codex 先读短入口，知道路线，再根据任务打开更深的资料，而不是一上来被几千行规则淹没。
第三层：工具触达，让 Codex 能验证真实世界
只让 Codex 改文件是不够的。它要能跑命令、看测试、读日志、打开页面，才能从“生成代码”进入“完成任务”。
一个比较稳的工具边界是：
- 代码任务优先用 CLI、测试命令和本地脚本验证
- UI 任务需要截图、浏览器预览或可复现的页面路径
- 外部系统通过 MCP、连接器或受控脚本接入
- 重复流程沉淀成 Skills，而不是每次重新口述
OpenAI 的 Codex Skills 文档把 skill 定义为可复用工作流的载体。对团队来说，最值得先做成 skill 的不是“万能助手”，而是那些输入输出稳定、经常重复、验收明确的流程，比如：
- 发布前检查
- PR 复查
- 文档链接校验
- 依赖升级核对
- UI 截图回归
越是稳定的流程，越适合让 Codex 反复执行；越是依赖主观判断的环节，越应该停下来交给人。
第四层：目标契约，把愿望改成可验收任务
Codex 的 Goal mode 让长任务有一个持续目标。即使暂时不用 /goal，也应该用同样的写法定义任务。
差的目标通常是这样：
把这个模块优化一下。
好的目标应该带有范围、约束和验收条件：
Goal:
把 blog/content/post 下新增文章的 Hugo 构建问题修复好。
Scope:
- 只修改新增文章、对应静态资源和必要的配置。
- 不改主题模板，除非先解释原因。
Constraints:
- 不引入新的 npm 依赖。
- 不使用未来日期。
- 保持现有 permalink 结构。
Done when:
1. hugo --gc --minify 构建通过。
2. 新文章 URL 可以按 /post/{slug}/ 渲染。
3. git diff 中没有无关文件变更。
Stop if:
- 构建失败原因来自主题缺陷且需要大范围改模板。
- 需要访问未授权的外部服务。
这种写法的重点不是格式，而是把“做完”的判断权前置。Codex 不是读心工具，它需要明确知道哪里是终点，哪些路不能走，以及遇到什么情况要停。
第五层：人工审查，把控制权留在人手里
长任务不等于放任。越是能跑很久的 agent，越需要清晰的审查边界。
至少保留三类人工节点：
- 需求判断：这个问题是否值得做，目标是否定义正确
- 风险判断：是否涉及数据、权限、生产环境或不可逆操作
- 发布判断：diff 是否可接受，测试是否足够，是否需要回滚准备
Codex 官方安全文档也把 sandbox 和 approval policy 放在核心位置。默认情况下，应该让 Codex 在工作区内自动完成低风险动作；涉及网络、工作区外写入、破坏性操作、敏感连接器时，要明确审批。
一个实用原则是：让 Codex 尽量多准备证据，尽量少替你做不可逆决策。
一套可复制的实践流程
如果你想把 Codex 从“会写代码”用到“能接手任务”，可以先从下面这套流程开始。
1. 先挑一个低风险但完整的任务
不要一上来就让 Codex 重写核心架构。更适合的起点是：
- 修一个能稳定复现的 bug
- 补一组缺失测试
- 清理一个小模块的类型问题
- 给已有功能补文档和示例
- 修复构建、lint、链接检查这类机械问题
关键是任务要小，但流程要完整：读代码、改代码、跑验证、解释 diff。
2. 把仓库入口写清楚
至少补一个简短的 AGENTS.md：
# AGENTS.md
## Commands
- Build: npm run build
- Test: npm test
- Lint: npm run lint
## Rules
- Do not change public API without updating docs.
- Add or update tests for behavior changes.
- Keep generated files in sync.
## Done
- Relevant checks pass.
- Diff contains no unrelated formatting churn.
- Final response lists changed files and verification result.
这份文件不需要一次到位。更好的方式是让它随着真实问题迭代：Codex 犯过两次的错误，就沉淀成一条规则；团队反复争论的检查项，就变成一个命令或 lint。
3. 让 Codex 先计划，再执行
复杂任务先用计划模式或普通 prompt 要求 Codex 做三件事：
- 读取相关文件
- 列出它认为的风险点
- 写出最小执行计划和验证方式
计划阶段不要急着让它改代码。你要看的是它有没有找到正确现场。如果它连入口文件、测试命令、数据流都没找准，后面写得越快，偏得越远。
4. 执行时要求自测和自审
执行 prompt 里直接写清楚：
完成修改后，请运行相关测试和构建。
如果无法运行，说明原因和替代验证方式。
最后审查自己的 diff，指出潜在风险。
这一步很重要。Codex 的价值不是只产出 patch，而是把“改完以后怎么证明它是对的”一起交出来。
5. 把复盘写回仓库
任务结束后，不要只接受结果。让 Codex 输出一段复盘：
- 这次问题根因是什么
- 哪些检查有效
- 哪些信息一开始缺失
- 下次应该更新哪份文档、测试或脚本
如果复盘里出现可复用内容，就把它写进 AGENTS.md、docs/、测试脚本或 skill。这样下一次 Codex 不是从零开始，而是在一个更清楚的工作现场里继续。
常见误区
误区一：把 Codex 当成更强的自动补全
自动补全只关心下一段代码，Codex 工作流关心整个任务闭环。你应该让它读上下文、执行命令、跑验证、解释风险，而不是只让它补一个函数。
误区二：把所有知识都塞进一个超长 AGENTS.md
长文件会挤占上下文，也更容易过期。入口文件保持短，把深层资料放到可链接的文档目录里，再用测试和 lint 保证它们没有漂移。
误区三：没有验收条件就启动长任务
没有 Done when 的任务，本质上只是愿望。Codex 可能做了很多事，但你很难判断它是不是更接近目标。
误区四：让后台自动化直接碰高风险资源
Codex Automations 适合定期检查、整理、生成候选 diff 或报告。涉及生产环境、密钥、资金、用户数据的动作，必须有更严格的权限、日志和人工确认。
ChatGPT 和 Codex 应该如何分工
一个自然的分工是：
- ChatGPT 用来讨论问题、解释技术、比较方案、整理需求
- Codex 用来进入仓库、读取代码、修改文件、运行验证、生成可审查 diff
- 团队文档用来承接长期规则，让下一次任务不用重新解释
也就是说，ChatGPT 更像讨论桌，Codex 更像工作台。真正高效的流程不是二选一，而是先在讨论桌上把问题想清楚，再把可验证目标交给工作台执行。
下一步建议
如果你今天只做一件事，就先给自己的仓库补一个短 AGENTS.md，再挑一个低风险任务按“目标、范围、约束、Done when”格式交给 Codex。
如果你已经开始团队化使用 Codex，下一步不是加更多提示词，而是补齐三类资产：
- 可读的仓库地图：
AGENTS.md、架构说明、模块索引 - 可执行的验证入口：测试、lint、构建、截图、日志查询
- 可复用的流程资产：Skills、发布检查、PR 审查模板、自动化巡检
当这些资产齐了，Codex 才不只是一个会写代码的聊天框，而是一个能持续工作的工程系统。
来源与进一步阅读
- OpenAI：Codex-maxxing for long-running work
https://openai.com/index/codex-maxxing-long-running-work/ - OpenAI：Harness engineering: leveraging Codex in an agent-first world
https://openai.com/index/harness-engineering/ - Codex 官方文档：Best practices
https://developers.openai.com/codex/learn/best-practices - Codex 官方文档：Prompting 与 Goal mode
https://developers.openai.com/codex/prompting - Codex 官方文档：Automations
https://developers.openai.com/codex/app/automations - Codex 官方文档：Agent Skills
https://developers.openai.com/codex/skills - Codex 官方文档：AGENTS.md
https://developers.openai.com/codex/guides/agents-md - Codex 官方文档：Agent approvals and security
https://developers.openai.com/codex/agent-approvals-security
