Codex 做什么，与普通补全工具有什么不同

建议用时：25 分钟（含练习）

学习目标

能够说明 Codex 如何在 CLI、App 或 IDE 中读写项目、执行命令并围绕结果持续工作。

本节产出

一张 Codex 工作界面与执行边界卡

核心知识：补全一段代码与交付一个改动

普通代码补全通常在你编写时提供局部候选，使用者继续负责定位问题、运行程序与组合修改。Codex 作为 OpenAI 的编码 Agent，可以围绕任务使用工具检查代码、编辑文件、执行验证并组织交付。具体可做什么，仍取决于界面、环境、工具与权限；产品名称本身不是无限执行授权。

二者并非互斥。你可以用补全加快局部编写，也可以把一个有明确边界的任务交给 Agent，再审查它产生的 diff。关键区别在于工作责任的组织：

代码补全

补全主要产生候选片段。

Agent 工作流

Agent 工作流会尝试贯穿多个步骤。

步骤更多，意味着需要更清楚的成功标准和证据，而不是更少的人类判断。

使用前先确认任务运行在当前目录、独立 worktree 还是云端环境。相同对话主题可能对应不同代码副本，云端任务也可能缺少本机服务或环境变量。目录和执行环境影响测试是否能运行，以及生成的文件最终在哪里；不能只看任务标题判断这些事实。

图中交付物不只是最后一段总结，还包括实际代码差异、检查结果与尚未解决的限制。一个流畅的摘要不能证明所有文件都已保存，也不能证明代码已经合并或发布。不同动作必须分别有对应证据。

怎样给编码 Agent 一个好任务

可以从用户可观察行为开始：“当列表为空时，页面显示说明文字；有数据时保持原来的列表。”然后提供相关页面、复现步骤、允许修改的范围和必要测试。不要只说“优化一下这个项目”，因为它没有明确终点，也无法判断无关修改是否越界。

对于已有仓库，让 Agent 先读取项目指令、实现与测试，再提出小范围方案。对于全新练习项目，先建立最小能运行的结构与检查，不必一开始就引入数据库、复杂部署或多个服务。任务越具体，越容易看出模型是否理解了你真正需要的行为。

用证据解释环境限制

如果 Agent 无法连接测试数据库，应先检查环境是否按项目要求准备，是否可以运行不依赖数据库的相关检查。不能将这种失败归结为代码一定错误，也不能跳过检查后宣称功能完成。报告应区分代码失败、环境缺失和权限限制，并继续完成不依赖阻碍的工作。

对外部动作尤其如此：修改代码、提交 Git、推送分支、合并和部署是不同的动作。任务要求“修复”不应被随意扩展为修改公开入口或生产数据；已有明确授权时，也不必在每一个可逆步骤反复打断使用者。核心是理解授权范围并保留可审阅结果。

案例：列表为空时显示提示

虚构页面读取一个项目列表，当前空数组会渲染一块空白。期望改动是显示“还没有项目”，同时保留有数据时的链接。Agent 可以先找到列表组件和已有测试，再增加空数组样例与非空样例，修改渲染分支，运行测试并检查页面。

若它顺手更改项目排序、重命名所有字段或升级 UI 依赖，就超出了这次任务所需范围。即使这些修改单独看有价值，也增加审阅负担和回归风险。更好的交付是只处理空态，另行记录发现的其他问题。

验收时，空数组显示提示、非空数组链接仍正确，只覆盖了功能的一部分；如果页面有多主题和移动布局，还应按实际变化检查提示是否可读、是否溢出。测试通过与真实呈现可以互相补充，不能彼此替代。

交付证据	要确认的内容
diff	只修改必要组件和测试
测试输出	空态与原有路径都覆盖
页面观察	提示可见、链接可用、布局正常
状态说明	是否已提交、推送或发布，分别说明

动手练习

1. 为虚构空列表问题写出明确的前后行为，以及一个必须保留的既有行为。
2. 设计三项检查：空列表、有数据、加载或错误状态。对后两者是否属于本次范围作出解释。
3. 阅读一份真实或模拟 diff，标出必要改动与无关改动；用证据写一段交付结论。

参考答案与推演

展开

完成检查

• 能解释补全与多步骤 Agent 工作流的不同。
• 任务从用户行为出发，包含范围和验收。
• 能定位执行环境，区分代码问题与环境限制。
• 交付说明把修改、验证、提交与发布分别说清楚。

参考与来源

• OpenAI：Introducing the Codex app：了解任务、worktree 与审阅的产品组织。
• OpenAI：Using Codex with your ChatGPT plan：核对当前 Codex 产品入口与基本定位。