1. 引言

在上一篇文章里，我们已经系统梳理了 Codex 的整体能力和使用方式，重点聚焦在“它能做什么”和“怎么快速上手”。如果你还没看过，建议从这里开始——

• 《Codex 完整指南（一）：快速入门｜工程级 AI 编程袋里》

不过，一旦真正把 Codex 引入到日常工程实践中，一个更现实的问题很快就会浮出水面：

怎么从“用工具”过渡到“用智能体”？

所以，这个问题的答案到底是什么？

这篇文章会围绕这个问题，系统整理 Codex 官方文档中提出的一组核心概念与工程方法论。主要涵盖：

• Prompting：如何给 Codex 下达可执行、可验证的工程级指令。
• Threads & Context：如何理解 Codex 的会话模型与上下文管理机制。
• Workflows：在真实开发场景中，如何设计高效、可复用的工作流程。
• Codex Models：不同模型在工程任务中的定位与选择。
• AI-Native Engineering Team：当智能体具备长时推理与执行能力后，工程团队应如何演进。

这篇文章并不是简单翻译文档，而是站在工程实践视角，把 Codex 的能力映射到日常开发中的典型任务——理解代码、修 Bug、写测试、重构、审查 PR 等等。希望通过这些案例，帮你回答一个关键问题：如何把 Codex 从“辅助工具”，真正变成工程流程中的一名“虚拟工程师”？

2. Prompting（提示词）

2.1 与 Codex 袋里的交互

本质上，和 Codex 的交互是通过发送提示词（prompts）来完成的。提示词就是用自然语言描述你希望它做什么的消息，比如：

Explain how the transform module works and how other modules use it.

Add a new command-line option `--json` that outputs JSON.

提交一个提示后，Codex 会循环执行以下过程：

1. 调用模型（生成输出）。
2. 根据模型输出执行相应操作（例如读写文件、编辑文件、调用工具等）。

这个过程会一直持续，直到任务完成或你取消它。就像 ChatGPT 一样，Codex 的效果取决于给出的指令质量。这里有几个实际用下来会觉得很香的技巧：

• Codex 在可以验证其工作的情况下，生成输出的质量更高。所以，在提示中尽量包含复现问题的步骤、验证某个特性的方法，或者运行 lint 或 pre-commit 检查的命令会更有帮助。
• 把复杂任务拆分成更小的步骤。Codex 更擅长处理分解之后、聚焦明确的子任务。对于大型复杂任务，分成小块更容易让 Codex 测试，也便于你逐段审查结果。如果不确定怎么拆分，直接让 Codex 提一个计划出来。

2.2 Threads（线程）

一个线程表示一个独立的会话：包括你的提示、模型输出和随后所有的工具调用。一个线程可以包含多个提示词。

举个例子：第一个提示可能让 Codex 实现某个功能，后面的提示再要求它添加测试。

• 当 Codex 正在处理任务时，这个线程处于“运行中”状态。
• 你可以同时运行多个线程，但要避免多个线程同时修改同一个文件。
• 也可以稍后恢复一个线程——只需继续向该线程发送新的提示就行。所以挂在那里也没关系。

2.2.1 本地线程 vs 云端线程

本地线程（Local threads）

• 在本地机器上运行，Codex 可以读取和编辑本地的文件，并运行命令。你能看到实际更改结果，也能使用现有工具。
• 为了降低意外修改工作区之外内容的风险，本地线程运行在一个沙箱环境中。

云端线程（Cloud threads）

• 在隔离的环境中运行，Codex 会克隆你的仓库并检出正在处理的分支。
• 云端线程适合并行运行任务，或从另一台设备委派任务。
• 使用云端线程之前，需要先将代码推送到 GitHub。也可以委派当前本地工作状态到云端线程。

2.3 Context（上下文）

提交提示词时，如果能让 Codex 利用到更多上下文，结果质量会明显提升。比如引用相关文件、图片等。

在任务执行过程中，Codex 也会从文件内容、工具输出以及正在进行的记录中收集上下文信息。所有信息必须适配模型的上下文窗口（context window）大小，它会根据不同模型而变化。

如果任务较长，Codex 可能会自动通过总结相关信息并丢弃不相关的细节来压缩上下文。经过反复压缩，Codex 可以在很多步骤中持续处理复杂任务。

3. Workflows（工作流程）

Codex 在上下文明确、完成标准清晰的情况下效果最好。建议每个工作流程都包含以下内容：

• 【适用场景】：什么时候用这个流程，以及最适合的 Codex 入口（IDE / CLI / 云端）。
• 【步骤与示例提示】：实际操作步骤和可以直接拿来用的示例提示。
• 【上下文说明】：Codex 自动能看到哪些内容，哪些需要你显式提供。
• 【校验方法】：怎么确认 Codex 的输出是正确的。

说明：

• 在 IDE 扩展中，当前打开的文件会自动作为上下文。
• 在 CLI 中，通常需要在提示中显式写出路径，或使用 @路径 / /mention 来附加文件。

3.1 案例一：解析代码库

IDE 扩展工作流程（最快的本地探索方式）：

Step 1. 打开最相关的文件。
Step 2. 选中你关注的代码段（推荐）。
Step 3. 向 Codex 提示，并要求它包含：

• 各模块的职责总结。
• 数据在哪里被校验。
• 修改代码时需要注意的一到两个“坑”。

Explain how the request flows through the selected code.

Step 4. 校验提示（Verification）：用于快速验证 Codex 是否理解正确。

Summarize the request flow as a numbered list of steps. Then list the files involved.

CLI 工作流程（适合需要 Shell 命令与执行记录）：

Step 1：在仓库根目录启动 Codex：

codex

Step 2：附加文件并提示：

I need to understand the protocol used by this service.
Read @foo.ts @schema.ts and explain the schema and request/response flow.
Focus on required vs optional fields and backward compatibility rules.

上下文说明：在 CLI 中使用 @ 或 /mention 附加文件路径。

3.2 案例二：Bug 修复

CLI 工作流程（快速复现 → 修复 → 验证）：

Step 1. 启动 Codex。

codex

Step 2. 提供清晰的 Bug 描述与复现步骤。

问题描述：点击设置页的 “Sa ve” 有时显示 “Sa ved”，但实际上没有保存。

复现步骤：

1) npm run dev
2) 打开 /settings
3) 切换 “Enable alerts”
4) 点击 Sa ve
5) 刷新页面，设置被重置

约束条件：

• 不修改 API 结构。
• 修复尽量最小化。
• 尽可能添加回归测试。

Step 3. 校验。

• 修复后再次执行复现步骤。
• 运行 lint / 测试并汇报结果。

IDE 扩展工作流程：

Step 1：打开你认为有问题的文件及其调用方。
Step 2：提示词。

Find the bug causing "Sa ved" to show without persisting changes.
After proposing the fix, tell me how to verify it in the UI.

3.3 案例三：编写测试用例

IDE 扩展（基于选区）：

Step 1. 打开函数所在文件。
Step 2. 选中函数定义。
Step 3. 通过命令面板选择 Add to Codex Thread。
Step 4. 提示词。

Write a unit test for this function.
Follow conventions used in other tests.

CLI 工作流程：

Step 1. 启动 Codex。

codex

Step 2. 提示词。

Add a test for the invert_list function in @transform.ts.
Cover the happy path plus edge cases.

3.4 案例四：从截图原型生成代码

CLI 工作流程（图片 + 提示）：

Step 1：将截图保存为本地文件（如 ./specs/ui.png）。
Step 2：启动 Codex。

codex

Step 3：将图片拖入终端作为提示的一部分。
Step 4：提示词。

Create a new dashboard based on this image.
Constraints:
- Use react, vite, and tailwind in typescript.
- Match spacing, typography, and layout as closely as possible.
Deliverables:
- A new route/page that renders the UI
- Any small components needed
- README.md with instructions to run it locally

Step 5：校验。如果允许，让 Codex 启动 dev server 并给出访问地址。

IDE 扩展（图片 + 项目风格）：

Step 1：在 Codex 聊天中粘贴或拖入截图。
Step 2：提示词。

Create a new settings page.
Use the attached screenshot as the target UI.
Follow design and visual patterns from other files in this project.

3.5 案例五：迭代 UI

CLI 工作流程：

Step 1：启动 Codex。

codex

Step 2：在另一个终端启动开发服务器。

npm run dev

Step 3：提示词。

Propose 2-3 styling improvements for the landing page.

Step 4：选择方案并继续细化。
Step 5：在浏览器中实时预览并决定是否提交。

3.6 案例六：将重构任务委派到云端

本地规划（IDE）：

Step 1：确保代码已 commit 或 stash。
Step 2：让 Codex 生成计划。

$plan
We need to refactor the auth subsystem to:
- split responsibilities
- reduce circular imports
- improve testability
Constraints:
- No user-visible beha vior changes
- Keep public APIs stable
- Include a step-by-step migration plan

Step 3：审查并调整计划。

云端执行（IDE → Cloud）：

Step 1：选择云环境。
Step 2：提示。

Implement Milestone 1 from the plan.

Step 3：审查云端 diff。
Step 4：直接创建 PR 或拉取到本地测试。

3.7 案例七：本地代码审查

CLI 工作流程：

Step 1：启动 Codex。

codex

Step 2：执行。

/review

Step 3：可选增强提示。

/review Focus on edge cases and security issues

3.8 案例八：审查 PR

GitHub 评论工作流程：

Step 1：打开 PR。
Step 2：评论。

@codex review

Step 3：或指定方向。

@codex review for security vulnerabilities

3.9 案例九：更新文档

IDE / CLI 工作流程：

Step 1：打开或 @ 引用目标文档。
Step 2：提示。

Update the "advanced features" documentation to provide authentication troubleshooting guidance.
Verify that all links are valid.

Step 3：审查并渲染确认。

4. Codex 模型（Codex Models）

4.1 推荐模型

推荐：gpt-5.2-codex

面向真实工程任务的最先进的智能编码模型，适用于 Codex CLI & SDK、IDE 扩展、云端任务、ChatGPT 积分和 API 调用。

codex -m gpt-5.2-codex

推荐：gpt-5.1-codex-mini

更小、更具成本效益的版本，但能力较 gpt-5.2-codex 略弱。

codex -m gpt-5.1-codex-mini

4.2 替代模型

gpt-5.1-codex-max：针对长期、智能编码任务优化。

codex -m gpt-5.1-codex-max

gpt-5.2：最佳通用智能体模型，适用于各类任务。

codex -m gpt-5.2

gpt-5.1：优秀的跨领域编码与智能体任务模型。

codex -m gpt-5.1

gpt-5.1-codex：针对长期智能编码任务的模型（已由 gpt-5.1-codex-max 更新替代）。

codex -m gpt-5.1-codex

gpt-5-codex 和 gpt-5-codex-mini：分别是 GPT-5 系列的编码优化版及更小成本版本。

codex -m gpt-5-codex
codex -m gpt-5-codex-mini

gpt-5：用于编码与智能体任务的基础版本（已被后续版本取代）。

codex -m gpt-5

4.3 其他模型支持

Codex 支持调用其他任意符合 Responses API 或 Chat Completions API 的模型与提供者，以满足特定使用需求。

注意：Chat Completions API 支持即将弃用。

4.4 配置模型

设置默认本地模型：在 config.toml 文件中添加模型名称，例如：

model = "gpt-5.2"

临时切换模型：

• 在 CLI 活动线程中使用 /model 命令。
• 或在 IDE 扩展下拉菜单选择模型。
• 也可以在启动命令中指定模型：

codex -m gpt-5.1-codex-mini

云任务模型：目前无法更改 Codex Cloud 任务的默认模型。

5. 构建 AI 原生工程团队（AI-Native Team）

AI 模型所能执行的任务范围正在快速扩展，这对工程领域有深远影响。最先进的系统现在可以维持多小时连续推理。截至 2025 年 8 月，METR 发现领先模型能够以大约 50% 的准确率完成连续 2 小时 17 分钟的任务。这项能力正在迅速提升——任务长度约每七个月翻倍。几年前，模型只能处理约 30 秒的推理（足够提供小段代码建议），如今由于能维持更长连贯的推理，整个软件开发生命周期（SDLC）都可以引入 AI 辅助，让编码智能体在规划、设计、开发、测试、代码审查和部署等阶段发挥作用。

这里会展示 AI 智能体如何在 SDLC 各阶段提供帮助，并给出工程领导者可以立即采用的实践建议，帮助团队构建 AI 原生工程流程与团队结构。

5.1 AI 编程：从自动补全到智能体

AI 编程工具已经远远超越了最初作为自动补全助手的角色。早期工具只能处理简单任务，例如建议下一行代码或填充函数模板。随着模型推理能力增强，开发者开始通过 IDE 中的聊天界面与智能体互动，用于结对编程和代码探索。如今的编程智能体能够：

• 生成完整文件。
• 搭建新项目结构。
• 将设计方案转换成代码。
• 推理复杂多步问题，如调试或重构。
• 在云端或多智能体环境中执行流程。

这改变了工程师的工作方式：不再在 IDE 内部与智能体逐行写代码，而是能将整个工作流程交给它处理，让工程师集中精力于高价值任务。

智能体的能力包括：统一跨系统上下文、结构化工具执行、持久项目记忆、自动评估循环等。

5.2 SDLC 各阶段导入智能体

以下按照软件开发生命周期的主要阶段，说明智能体如何帮助提升效率，以及工程师在各阶段仍须承担的核心角色。

5.2.1 阶段一：规划（Plan）

问题：传统上，团队需要工程师判断功能可行性、开发时长及涉及系统。这通常需要对代码库有深入理解并多轮迭代才能明确范围。

智能体如何帮助：

• 与任务追踪系统集成，读取规范文档。
• 与代码库交叉比对，标出不明确或冲突项。
• 拆解任务、估算复杂度。
• 快速追踪代码路径，展示涉及的服务及依赖关系。

工程师如何转变：

• 工程师审核智能体分析结果，以验证准确性与完整性。
• 人类负责故事点分配、难度评估与战略规划。
• 决策仍由人主导，如优先级确定与关键路径决策。

入门清单：

• 实现需求与源码对齐流程。
• 自动化工单标签、去重和初步分解。
• 在任务进入特定阶段时，触发智能体运行补充信息。

5.2.2 阶段二：设计（Design）

问题：设计往往被样板代码、项目骨架搭建、和 UI 组件初始化等基础工作拖慢。

智能体如何帮助：

• 自动生成样板代码与项目结构。
• 将设计 mockups 转换成可运行组件代码。
• 即时应用设计 token 或样式指南。
• 提出可访问性改进建议。

工程师如何转变：

• 审核智能体输出的组件是否符合设计规范及可访问性要求。
• 专注于可扩展架构设计与质量标准维护。
• 设计师可探索更多设计方案，加速验证迭代。

入门清单：

• 使用支持文本+图像输入的多模态智能体。
• 将设计工具集成到智能体工作流。
• 建立从设计 → 组件 → 实现的自动化流程。

5.2.3 阶段三：构建（Build）

问题：工程师常花大量时间将规范转换为代码结构、串联服务、生成样板、处理构建错误等机械工作。

智能体如何帮助：

• 编写完整功能实现，包括数据模型、API、UI、测试与文档。
• 跨文件搜索与一致性修改。
• 生成错误处理、遥测、安全包装等样板。
• 处理构建错误并即时修复。
• 与测试一体化写代码和测试。

工程师如何转变：

• 审核 AI 生成代码的架构、安全与性能影响。
• 设计模式、规则和约束，指导智能体输出。
• 关注正确性、可维护性与长期质量。

入门清单：

• 从明确任务开始。
• 智能体生成 PLAN.md 并纳入代码库。
• 管理 AGENTS.md 文件以设定智能体规则与循环反馈。
• 确保智能体执行命令可成功运行。

示例：有企业每天用智能体将规范转成可运行代码，几分钟交付新功能。

5.2.4 阶段四：测试（Test）

问题：写测试既占时间又需深入理解边界情况，而测试维护常随代码变化而成为负担。

智能体如何帮助：

• 基于需求与代码逻辑自动生成测试用例。
• 建议边界条件和故障场景。
• 随代码演进自动维护测试。

工程师如何转变：

• 审查生成测试以确保其有效性。
• 把握整体测试覆盖与质量目标。
• 指导智能体理解测试工具和标准。

入门清单：

• 把测试作为独立步骤引导智能体生成。
• 在 AGENTS.md 设定测试覆盖要求。
• 给智能体示例代码覆盖工具以提高测试质量。

5.2.5 阶段五：审查（Review）

问题：代码审查耗时，且需要在深度审核与快速反馈之间权衡。

智能体如何帮助：

• 提供一致的基础审查。
• 理解运行时行为并追踪跨文件逻辑。
• 发现关键错误或逻辑缺陷。

工程师如何转变：

• 最终判断代码是否可合并。
• 审查架构一致性、模式使用与功能匹配性。
• 持续定义审查质量衡量标准。

入门清单：

• 收集并保存优秀审查案例用于评估工具。
• 选择针对代码审查训练过的模型。
• 定义团队高质量审查指标。

5.2.6 阶段六：文档（Document）

问题：文档更新常被忽略且滞后于代码变更。

智能体如何帮助：

• 自动基于代码生成结构化说明。
• 生成系统架构图（例如 Mermaid）。
• 持续纳入发布流程，自动产出变更摘要。

工程师如何转变：

• 审核核心文档的准确性。
• 决定文档组织结构与关键内容。
• 设置标准模板与智能体应遵循规则。

入门清单：

• 在输出中包含自动生成文档的提示。
• 与发布流程集成文档自动化。

5.2.7 阶段七：部署与维护（Deploy & Maintain）

问题：线上问题排查通常需要在多个工具间切换，查看日志与历史代码。

智能体如何帮助：

• 访问日志和遥测数据。
• 快速关联错误与代码变更。
• 提供修复建议。

工程师如何转变：

• 验证诊断结果的可靠性及符合安全规范。
• 决定修复与发布策略。
• 在关键决策上保持最终控制权。

入门清单：

• 将智能体集成至日志与部署工具。
• 准备标准提示模板用于分析异常。
• 做模拟演练测试智能体准确性。

5.3 小结

AI 编程智能体正在重塑软件开发生命周期。它们能承担传统上耗时、重复的多步骤工作，让工程师专注于架构、设计、产品意图等高价值任务。成功打造 AI 原生工程团队不需要彻底重写流程，而是以小型、精确的自动化开始积累效益，逐步扩大智能体责任范围，从而提升整体效率、质量与创新能力。

6. 文末

通过上面的讨论，相信大家已经系统理解了 Codex 在工程场景中的核心设计理念与实践价值：它并不是一个“更聪明的自动补全工具”，而是一个以提示词为接口、以线程与上下文为状态、以工作流为执行边界的工程级编程智能体。

Codex 的关键意义在于：将真实的软件工程能力（代码库、构建工具、测试系统、代码审查与云端执行环境）有序、可验证地引入到模型的推理与行动闭环中。通过合理的 Prompt、Context 与 Workflow 设计，Codex 不再只停留在“生成代码”，而是能够理解现有系统、执行多步任务、验证结果并持续迭代，从而真正参与到完整的软件开发生命周期中。

希望这篇文章能帮助大家建立对 Codex 的正确认知，并在实际工程中逐步落地 AI-Native 的开发方式。感谢阅读。