Codex 完整指南（二）：核心概念详解｜工程级 AI 编程智能体

AI2周前发布 beixibaobao
10 0 0

文章目录

  • 1. 引言
  • 2. Prompting（提示词）
    • 2.1 与 Codex 代理的交互
    • 2.2 Threads（线程）
      • 2.2.1 本地线程 vs 云端线程
    • 2.3 Context（上下文）
  • 3. Workflows（工作流程）
    • 3.1 案例一：解析代码库
    • 3.2 案例二：Bug 修复
    • 3.3 案例三：编写测试用例
    • 3.4 案例四：从截图原型生成代码
    • 3.5 案例五：迭代 UI
    • 3.6 案例六：将重构任务委派到云端
    • 3.7 案例七：本地代码审查
    • 3.8 案例八：审查 PR
    • 3.9 案例九：更新文档
  • 4. Codex 模型（Codex Models）
    • 4.1 推荐模型
    • 4.2 替代模型
    • 4.3 其他模型支持
    • 4.4 配置模型
  • 5. 构建 AI 原生工程团队（AI-Native Team）
    • 5.1 AI 编程：从自动补全到智能体
    • 5.2 SDLC 各阶段导入智能体
      • 5.2.1 阶段一：规划（Plan）
      • 5.2.2 阶段二：设计（Design）
      • 5.2.3 阶段三：构建（Build）
      • 5.2.4 阶段四：测试（Test）
      • 5.2.5 阶段五：审查（Review）
      • 5.2.6 阶段六：文档（Document）
      • 5.2.7 阶段七：部署与维护（Deploy & Maintain）
    • 5.3 小结
  • 6. 文末

1. 引言

在上一篇博客中，博主已经系统性地介绍了 Codex 的整体能力与使用方式，重点放在 “它能做什么” 和 “如何快速上手”，如果你还没有阅读，建议先从这里开始：

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

当真正把 Codex 引入到日常工程实践中，一个更现实的问题很快会出现：

Codex 并不仅仅是一个“会写代码的模型”，而是一个具备状态、工具调用能力和工作流意识的工程智能体。
那么，我们究竟应该如何与它协作，才能真正发挥它的价值？

本文将围绕这一问题，系统整理 Codex 官方文档中提出的一组 核心概念与工程方法论，帮助大家从“用工具”过渡到“用智能体”，主要包括：

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

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

在这里插入图片描述

2. Prompting（提示词）

原文地址：https://developers.openai.com/codex/prompting

2.1 与 Codex 代理的交互

当通过发送 提示词（prompts） 与 Codex 进行交互，提示词就是用自然语言描述你希望它做什么的消息，例如：

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 IDE 插件会自动将打开的文件列表和选中的文本范围作为上下文发送。

在这里插入图片描述

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

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

3. Workflows（工作流程）

原文地址：https://developers.openai.com/codex/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 描述与复现步骤

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

复现步骤：

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

约束条件：

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

Step 3. 校验

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

IDE 扩展工作流程

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

Find the bug causing "Saved" 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 案例四：从截图原型生成代码

当你有设计稿或截图，希望快速生成可运行 UI 时使用。

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 behavior 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 案例七：本地代码审查

在提交或创建 PR 前进行质量检查。

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）

原文地址：https://developers.openai.com/codex/models

在这里插入图片描述

4.1 推荐模型

推荐：gpt-5.2-codex

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 支持即将弃用。([developers.openai.com][1])

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）

如何让编码智能体加速软件开发生命周期：https://developers.openai.com/codex/guides/build-ai-native-engineering-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 文件以设定智能体规则与循环反馈
  • 确保智能体执行命令可成功运行 ([developers.openai.com][2])

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

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 的开发方式，也欢迎在评论区分享你在 Codex 使用过程中的经验与思考。感谢阅读，本文完！

© 版权声明
文章版权归作者所有，未经允许请勿转载。

相关文章

标签云