Codex 现在该怎么用：从“让 AI 写代码”到“搭一个可验证的开发工作流”#

写作时间：2026-05-24
适合读者：经常写代码、做前后端开发、想把 Codex 用进真实项目的人
说明：本文基于 OpenAI 官方文档与近期发布记录重新整理，重点是可落地的工作方法，而不是复述功能清单。

先说结论#

Codex 的使用方式已经变了。

以前我们常把它当成“会写代码的聊天框”：给一句需求，它回一段代码；遇到问题，再继续追问。

现在更有效的方式是：把 Codex 当成一个可以被管理、被约束、被验证的开发代理。

它不只是回答问题，而是可以围绕一个目标去读项目、制定计划、修改代码、跑命令、看页面、检查 diff、复盘风险，甚至把重复流程沉淀成团队规范。

我更建议用一个新的框架理解它：

看得见 → 说得清 → 验得过 → 沉淀得下

这四步，基本就是 Codex 从“玩具感”变成“生产力工具”的关键。

一、看得见：先解决上下文，不要让 Codex 靠猜#

很多 AI 编程失败，不是因为它不会写代码，而是它不知道你真正面对的现场是什么。

真实开发里，上下文经常分散在这些地方：

• 代码仓库；
• 终端报错；
• 浏览器页面；
• 设计稿；
• 桌面应用；
• 内部文档；
• 第三方后台；
• PR 评论；
• 测试结果。

过去我们通常靠复制粘贴，把这些信息一点点塞给 AI。现在 Codex 的变化，是它开始能更自然地接触这些上下文。

1. Appshots：适合把“当前看到的窗口”交给 Codex#

Appshots 的价值不是“截图”，而是把你当前正在看的窗口变成任务上下文。它可以把前台应用窗口的截图和可读取文本一起附到 Codex 线程里。这个功能目前主要面向 macOS 的 Codex app 使用场景。[1][5]

适合用 Appshots 的场景：

这个页面看起来不对劲，但我很难用文字描述。
这个错误弹窗里有一堆信息，我不想复制。
这个配置界面需要调整，但我不知道具体字段名。
这个设计稿和页面预览有差异，让 Codex 帮我对照。

更好的提问方式不是：

帮我看下哪里怪。

而是：

请根据这个 Appshot 检查当前页面的布局问题。

目标：让顶部导航在 375px 和 768px 宽度下都不拥挤。
约束：只改样式，不改接口，不新增 UI 库。
完成标准：指出问题位置，修改相关样式，并说明怎么验证。

这里的重点是：截图只是上下文，任务仍然要有边界和验收标准。

2. 浏览器标注：适合前端细节，不适合长篇描述#

前端样式问题最怕口头描述。

“第二个卡片的标题再小一点”“按钮往下一点”“这个地方不太齐”，这种话人类都可能理解偏，更别说代理。

Codex 的 in-app browser 可以在页面上做标注。官方也提到，新的浏览器标注可以针对字体、文字、间距、颜色等样式信息给出更细颗粒度反馈。[1][6]

建议的使用方式：

打开 /settings/profile 页面。
我已经在浏览器里标注了 3 个位置。
请只处理这些标注：
1. 第一个标注：让按钮和输入框右边缘对齐；
2. 第二个标注：错误提示和输入框之间增加 4px；
3. 第三个标注：移动端标题不要换两行。

完成后请重新打开页面验证，不要顺手重构组件。

这比写一大段视觉描述更稳定。

3. Chrome、Computer Use、MCP：不要混着用，要分场景#

现在 Codex 能接触的“外部世界”越来越多，但不是权限越大越好。

我的建议是按这个顺序选：

Chrome extension 适合处理需要你登录态的网站；如果是 localhost、本地预览或公开页面，官方也建议优先用 in-app browser，因为它能把预览和验证留在 Codex 工作区里。[7]

Computer Use 更强，但也更敏感。它能看屏幕、点击、输入，适合 GUI bug、桌面应用、模拟器流程等场景；但它会影响项目目录之外的应用状态，所以任务要窄，权限要审。[8]

一句话：

能用结构化接口，就别让它点屏幕；能用浏览器预览，就别动真实浏览器；必须动真实环境时，再给最小权限。

二、说得清：把需求写成“任务契约”，不是聊天口令#

Codex 不是不知道怎么写代码，它最常犯错的是：不知道你允许它改到什么程度。

所以我不建议再用这种提示词：

帮我优化一下登录页。

这句话太空。优化什么？性能、视觉、交互、可访问性、移动端、代码结构，还是接口错误？

更好的方式是写成任务契约。

一个通用任务契约#

任务：
修复登录页移动端按钮溢出问题。

现场：
相关页面：src/pages/login.tsx
相关组件：src/components/AuthForm.tsx
相关样式：src/styles/auth.css
问题表现：375px 宽度下，提交按钮会超出表单容器。

边界：
- 不改接口请求逻辑；
- 不新增 UI 库；
- 不调整路由；
- 不影响桌面端布局。

做法：
先检查 DOM 结构和 CSS 来源，再给出最小修改方案。
如果只需要样式修改，不要重构组件。

验收：
- 375px 宽度下按钮不溢出；
- 768px 和桌面端布局不回退；
- lint/typecheck 通过；
- 最后总结修改文件和风险。

官方最佳实践也建议任务里明确目标、上下文、约束和完成标准，这样 Codex 更容易保持范围、减少猜测，也更方便你审查结果。[2]

简单任务、复杂任务、长任务要分开写#

很多人把所有任务都写成一句话，这是低效的。

我建议按任务复杂度分成三种。

1. 小任务：直接给边界#

适合：改文案、补类型、修一个明确 bug、改一个样式点。

请修复这个 TypeScript 报错。
只改必要文件，不要重构。
改完运行 pnpm typecheck，并说明错误原因和修改点。

2. 中等任务：先计划，再实现#

适合：改多个文件、涉及状态流、接口、权限、测试。

先不要改代码。
请先阅读相关文件，给出修改计划：
1. 会改哪些文件；
2. 每个文件为什么要改；
3. 可能影响哪些现有行为；
4. 需要跑哪些验证命令。

等我确认后再实现。

Plan mode 的意义就在这里。官方说明中，Plan mode 适合复杂、模糊或难描述的任务，可以让 Codex 先收集上下文、提问题、形成更强计划，再动手实现。[2]

3. 长任务：用 /goal，但必须写清楚停止条件#

/goal 不是“让 Codex 自己随便干”，它更像一份持续执行的完成契约。

官方对 Goal mode 的定义很明确：它给 Codex 一个持久目标，让它在较长任务里反复检查是否达到完成条件。Goal 文本同时是起始提示，也是完成标准。[3]

适合 /goal 的任务：

/goal
把 checkout 模块的 p95 延迟降到 120ms 以下。

验证方式：
- 使用 scripts/bench-checkout.ts 跑基准；
- 使用 pnpm test:checkout 跑正确性测试；
- 每次改动后记录结果。

约束：
- 不改支付接口协议；
- 不降低错误处理质量；
- 不删除现有测试；
- 如果需要缓存，先说明缓存失效策略。

停止条件：
- 达到性能目标且测试通过；
- 或者在当前约束下没有可证明的改进路径，并输出原因、证据和下一步建议。

官方 Cookbook 也强调，好的 Goal 要包含结果、验证方式、约束、边界、迭代策略，以及卡住时何时停止并汇报。[4]

三、验得过：让 Codex 交付“证据”，不是只交付代码#

AI 写代码最容易制造一种假象：代码看起来很完整，但没人知道它有没有真的跑过。

所以每次让 Codex 改代码，结尾都应该要求它交付证据。

最低限度的验证清单#

改完后请做以下验证：
1. 运行相关测试；
2. 运行 lint；
3. 运行 typecheck；
4. 检查 git diff，确认没有无关文件变化；
5. 如果验证失败，先定位并修复；
6. 最后输出命令、结果和剩余风险。

这一步很关键。你要的不是“它写了一段代码”，而是“这段代码经过了哪些检查”。

对于前端任务，验证还应该包括页面状态：

请验证以下状态：
- loading；
- empty；
- error；
- success；
- mobile 375px；
- tablet 768px；
- desktop 1440px。

对于后端任务，验证应该包括：

- happy path；
- 参数缺失；
- 权限不足；
- 数据不存在；
- 并发或重复请求；
- 旧客户端兼容性。

对于长任务，最好让它维护一个小型状态日志。

请在 progress.md 记录：
- 当前假设；
- 已尝试方案；
- 每次验证结果；
- 失败原因；
- 下一步计划。

OpenAI 关于长任务的实践里也提到，长时间执行不靠一个神奇提示词，而靠清晰目标、阶段性验收、操作手册、持续验证，以及可审查的状态记录。[9]

这就是我认为 Codex 真正进入生产环境的分水岭：

没有验证的 AI 代码，只能算草稿；有验证、有 diff、有风险说明，才接近可交付。

四、沉淀得下：把好用的提示词变成项目资产#

如果你发现自己每次都在重复提醒 Codex：

不要新增依赖。
不要乱改目录。
不要动接口协议。
改完跑测试。
总结风险。
按项目命名规范来。

那就说明你不应该继续复制粘贴提示词，而应该把这些规则沉淀下来。

1. AGENTS.md：项目里的“代理说明书”#

AGENTS.md 可以理解成给 Codex 看的项目说明书。官方文档说明，Codex 会在开始工作前读取这些文件，并可以把全局规则、项目规则和子目录规则叠加起来；越靠近当前目录的规则越具体，优先级也更高。[10]

推荐写法：

# AGENTS.md

## Project map

- apps/web: Next.js frontend
- packages/api: backend API client
- packages/ui: shared UI components

## Working rules

- Do not add production dependencies without approval.
- Keep changes small and reviewable.
- Do not change API contracts unless the task explicitly asks for it.
- Follow existing naming and folder conventions.

## Commands

- Install: pnpm install
- Dev: pnpm dev
- Test: pnpm test
- Lint: pnpm lint
- Typecheck: pnpm typecheck

## Done means

- Relevant tests pass.
- Lint and typecheck pass.
- No unrelated files changed.
- Final summary includes changed files, commands run, and risk notes.

我的经验是：AGENTS.md 不要写成公司制度大全。它应该短、具体、可执行。

如果 Codex 反复犯同一个错，就把那条规则加进去；如果一条规则半年没用过，就删掉。

2. config.toml：把环境和权限固定下来#

config.toml 负责的是行为配置，不是项目说明。

官方文档说明，用户级配置通常放在 ~/.codex/config.toml，项目级配置可以放在 .codex/config.toml；CLI、IDE extension 会共享配置层，配置可用于模型、approval policy、sandbox、MCP 等。[11]

一个保守的起步思路：

# ~/.codex/config.toml

[profiles.safe]
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[profiles.trusted]
approval_policy = "on-request"
sandbox_mode = "workspace-write"

为什么我不建议一开始就全自动？

因为 Codex 能运行命令、改文件、连接工具。越接近真实项目，越要控制权限。

更实用的原则是：

陌生仓库：少权限，多确认。
熟悉仓库：适度放开，但关键操作仍需确认。
自动化任务：只放在可回滚、可审计、低风险流程里。

3. MCP：让 Codex 接外部上下文，但别滥接#

MCP 适合把外部工具接进 Codex，比如文档、数据库、设计工具、内部系统、测试平台等。官方说明里，Codex 的 MCP 配置和其他配置一样存在 config.toml 里；配置好后，CLI 和 IDE extension 可以共享这些 MCP server 设置。[12]

但 MCP 不是越多越好。

建议只接三类：

1. 你经常需要查的开发文档；
2. 项目必须依赖的内部系统；
3. 能显著减少复制粘贴的工具。

不要为了“看起来很强”接一堆用不上的 server。上下文越乱，代理越难判断什么重要。

4. Skills：把重复工作流做成可复用能力#

AGENTS.md 更像“规则”，Skills 更像“流程”。

官方说明中，Skill 可以把指令、资源和可选脚本打包，让 Codex 更可靠地执行某类任务；Skill 目录通常包含 SKILL.md，也可以包含 scripts、references、assets 等。[13]

适合做成 Skill 的任务：

- API 兼容性审查；
- PR review 检查清单；
- 前端页面走查；
- 数据分析报告生成；
- 依赖升级流程；
- 安全变更检查；
- 发布前验收流程。

一个简单 Skill 示例：

---
name: api-change-review
description: Use this when reviewing backend API changes for compatibility, test coverage, and client impact.
---

When reviewing API changes:

1. Check whether request or response contracts changed.
2. Check whether old clients may break.
3. Check whether tests cover success, failure, and permission cases.
4. Check whether docs or OpenAPI schema need updates.
5. Summarize compatibility risks and suggested follow-up work.

如果一个流程你每周都会做，而且每次步骤差不多，就值得把它变成 Skill。

五、我建议的 Codex 日常工作流#

下面是一套我更推荐的实际用法。

第一步：先让它读，不要马上让它改#

先不要修改代码。
请阅读这个模块，告诉我：
1. 当前结构是什么；
2. 关键文件有哪些；
3. 这个需求可能影响哪里；
4. 你建议的最小改动方案是什么。

第二步：让它给计划，而不是直接执行#

请给出一个实现计划。
每一步都要说明：
- 目标；
- 涉及文件；
- 预期风险；
- 验证方式。

第三步：确认计划后再让它改#

按这个计划实现。
优先做最小可行改动。
不要做无关重构。
每完成一个阶段，检查 diff 是否符合计划。

第四步：必须验证#

请运行相关测试、lint、typecheck。
如果失败，先修复。
最后输出：
- 执行命令；
- 结果；
- 修改文件；
- 仍需人工检查的地方。

第五步：把反复出现的问题沉淀到 AGENTS.md 或 Skill#

这次任务中你有哪些误解或反复修正？
请总结成 3 条可以加入 AGENTS.md 的规则。

这一句非常实用。它会让 Codex 从“每次重新教育”变成“越用越贴近项目”。

六、团队使用 Codex，别只统计“生成了多少代码”#

团队使用 Codex，最容易看错指标。

很多人会问：

这个月 Codex 生成了多少行代码？

这个指标有参考价值，但不应该是核心。

因为真正的收益不是多写了几行代码，而是流程有没有被压缩。

更应该看：

- 哪些重复排查流程减少了？
- 哪些 PR review 检查项可以半自动完成？
- 哪些测试失败能自动定位并给出修复建议？
- 哪些内部工具可以用插件、MCP 或 Skill 复用？
- 哪些团队规则已经沉淀进 AGENTS.md？
- 哪些任务从“人肉查资料 + 手动跑命令”变成了“目标驱动 + 证据交付”？

OpenAI Business release notes 中也提到，团队侧的 Codex 更新包括共享插件、Goal mode、浏览器改进、远程锁屏使用和 Analytics；Analytics 可覆盖活跃用户、tokens、threads、turns、插件使用、accepted lines of code、model usage 等指标。[14]

但我的判断是：

代码行数只是表层指标，流程缩短才是核心指标。

七、反面清单：这几种用法最容易翻车#

1. 只说“帮我改”#

没有目标、没有边界、没有验收标准，Codex 就只能猜。

2. 不让它先看项目结构#

复杂项目里直接开改，很容易改错文件、重复造轮子，或者破坏原有架构。

3. 不要求验证#

只看生成结果，不看测试、lint、typecheck、diff，最后风险会落到你身上。

4. 权限开太大#

新项目、陌生仓库、生产相关操作，不要一上来就给完全自动执行权限。

5. 把所有规则都写在 prompt 里#

长期规则应该进 AGENTS.md，工具配置应该进 config.toml，重复流程应该做成 Skill。

八、可以直接复制的三个模板#

模板 1：普通开发任务#

任务：
[说明要实现/修复什么]

上下文：
[列出相关文件、错误信息、页面路径、截图或设计稿]

边界：
- 不改 [关键模块]
- 不新增依赖，除非先说明原因并等待确认
- 不做无关重构

执行方式：
请先检查相关代码，再给出最小修改方案。
确认方案后再实现。

验收：
- [行为结果]
- 相关测试通过
- lint/typecheck 通过
- 最后总结修改文件、命令结果和风险

模板 2：前端视觉调整#

请打开 [页面/路由]，根据浏览器标注修改 UI。

只处理我标注的区域：
1. [标注 1 的目标]
2. [标注 2 的目标]
3. [标注 3 的目标]

约束：
- 不改接口；
- 不重构组件；
- 不新增 UI 库；
- 移动端和桌面端都要验证。

完成后：
- 说明每个标注对应改了哪里；
- 重新检查页面；
- 运行 lint/typecheck。

模板 3：长任务 /goal#

/goal
目标：[最终要达到的状态]

验证方式：
- [测试命令]
- [基准命令]
- [页面检查方式]
- [报告或产物]

约束：
- 不破坏 [关键能力]
- 不修改 [禁止改动区域]
- 不新增 [不允许的依赖或方案]

迭代策略：
每次尝试后记录：假设、改动、验证结果、下一步。
如果失败，基于证据选择下一步，不要随机试错。

停止条件：
- 达成目标并验证通过；
- 或者说明在当前约束下无法继续，并给出证据、风险和解锁条件。

最后总结#

我不建议把 Codex 理解成“更强的代码补全”。

它现在更像一个需要你管理的开发工作台：

Appshots / 浏览器标注 / Chrome / Computer Use 负责看见现场；
任务契约 / Plan mode / Goal mode 负责说清目标；
测试 / lint / typecheck / diff 负责验证交付；
AGENTS.md / config.toml / MCP / Skills / Plugins 负责沉淀工作流。

所以，真正能提升效率的不是某个单点功能，而是你有没有把 Codex 放进一个可控流程里。

以后别再只说：

帮我写代码。

更好的说法是：

这是目标，这是现场，这是边界，这是验证方式。
先计划，再实现，再验证，最后告诉我风险。

这才是 Codex 进入生产环境的正确打开方式。

资料来源（用于事实核验）#

[1] OpenAI Developers：Codex Changelog，2026-05-21 更新。
[2] OpenAI Developers：Best practices – Codex。
[3] OpenAI Developers：Prompting – Codex，Goal mode。
[4] OpenAI Cookbook：Using Goals in Codex，2026-05-09。
[5] OpenAI Developers：Appshots – Codex。
[6] OpenAI Developers：In-app browser – Codex app。
[7] OpenAI Developers：Codex Chrome extension – Codex app。
[8] OpenAI Developers：Computer Use – Codex app。
[9] OpenAI Developers Blog：Run long horizon tasks with Codex，2026-02-23。
[10] OpenAI Developers：Custom instructions with AGENTS.md – Codex。
[11] OpenAI Developers：Config basics – Codex。
[12] OpenAI Developers：Model Context Protocol – Codex。
[13] OpenAI Developers：Agent Skills – Codex。
[14] OpenAI Help Center：ChatGPT Business Release Notes，2026-05-21。