AI编程 on Codexer

Codex 实战心法：6 个经过验证的高效协作模式

Thu, 04 Jun 2026 09:00:00 +0800

从「能用」到「用好」，中间差了什么？

你大概率已经用过 Codex 了。装上 CLI 或 VS Code 扩展，给它一段需求描述，看着它噼里啪啦生成代码，心里觉得「嗯，不错」。但用了一周之后，你开始觉得哪里不对：它有时候自信满满地跑偏了方向，有时候改了不该改的文件，有时候在一个已经烂掉的会话里越陷越深。

问题不在 Codex 本身。2026 年的 Codex 已经是一个成熟的 Agentic 编码系统，周活跃开发者超过 400 万，Cisco、Nvidia、Ramp 这样的公司都在生产环境中依赖它。真正的差距在于使用方式。

这篇文章拆解 6 个经过实战验证的协作模式。它们不是什么玄学理论，而是工程团队在日常使用中反复验证过的方法论。

模式一：四要素 Prompt 结构

大多数人给 Codex 的指令长这样：

帮我重构一下 UserService，加上缓存逻辑。

这种指令缺了三样东西：上下文、约束条件和完成标准。Codex 面对这样的指令，只能靠自己猜「缓存逻辑」具体指什么，用什么方案实现，哪些文件不能动，做到什么程度算完成。

更有效的做法是用四要素结构组织 Prompt：

Goal（目标）：用结果而非步骤描述你想要什么。「让 UserService 的查询响应时间降到 50ms 以下」比「加个 Redis 缓存」好得多，因为前者给了 Codex 选择方案的空间。

Context（上下文）：用 @ 引用相关的文件、文件夹、文档或错误日志。别让 Codex 自己去猜哪些文件相关，直接告诉它。

Constraints（约束）：列出必须遵守的架构规范、安全要求和编码约定。「不要改动数据库 schema」「保持向后兼容」「所有新函数必须有 JSDoc 注释」这类约束越明确，Codex 跑偏的概率越低。

Done When（完成条件）：定义一个可验证的结束状态。「所有现有测试通过，新增的缓存命中率测试覆盖率达到 80%」这种条件比「做完了告诉我」强一百倍。

这个模式的核心价值不是让 Prompt 变长，而是消除歧义。团队中反复出现「Codex 自信地解决了错误的问题」这个投诉，根本原因几乎都是 Prompt 缺少四要素中的某一个。

模式二：AGENTS.md 作为项目的真相源

AGENTS.md 是 Codex 驱动的仓库中最重要的配置文件，没有之一。把它放在仓库根目录（或特定子目录下），Codex 会自动发现并将内容注入到对话上下文中。模型经过专门训练，会严格遵循 AGENTS.md 中的指令。

Codex Goal Mode：让 AI 自主编程数小时，开发者只需要定义目标

Wed, 03 Jun 2026 09:00:00 +0800

从「一问一答」到「给我一个任务，我干完叫你」

你有没有这样的经历？用 Codex 或其他 AI 编程助手写代码，每次都是「提一个需求，等它完成，检查结果，再提下一个需求」。一个涉及几十个文件的迁移任务，你可能要手动循环二十多次，每次都要重新告诉它上下文、目标和约束。

这种「请求，响应」的交互模式，本质上把 AI 当成了一个更聪明的自动补全。它能帮你写一个函数、解释一个 bug、生成一段测试，但当任务需要跨多个文件规划、反复执行测试、自动修复失败、再重试时，这种模式就力不从心了。

2026 年 5 月 21 日，OpenAI 发布了被称为「Codex Thursday」的重大更新。其中最引人注目的功能，就是 Goal Mode 从实验阶段正式毕业，成为 Codex App、VS Code 扩展、JetBrains 扩展和 CLI 的稳定功能。

简单来说，Goal Mode 把 Codex 从「响应指令的工具」变成了「领受任务的自主 Agent」。你给它一个长期目标，定义好成功条件，设定一个 token 预算，然后就可以锁屏走人了。等你回来时，任务可能已经完成了。

Goal Mode 的五层架构

要真正用好 Goal Mode，理解它的内部工作机制很重要。这个功能并不是简单的「循环执行」，而是由五个独立的层协作完成的。

状态层（SQLite）

每个线程有一个活跃目标，存储在本地 SQLite 数据库中。字段包括目标文本、状态（active、paused、budget_limited、complete）、token 预算（可选）和运行中的用量计数器。关键设计：一个线程同一时间只能有一个活跃目标。

应用服务器 API（JSON-RPC）

Codex 应用服务器暴露了 thread/goal/set、thread/goal/get 和 thread/goal/clear 三个方法。你在 TUI 里输入的 /goal pause 或 /goal clear 命令，底层就是调用这些接口。

模型工具层

模型可以访问三个工具：create_goal、update_goal（包括设置 complete 状态）和 get_goal。有一个重要设计决策：模型无法自行暂停或恢复目标，这些状态转换由系统控制。这防止了模型陷入死循环时自行「续命」，或者在遇到困难时过早放弃。

运行时事件总线

生命周期钩子会追踪每轮的 token 消耗和墙钟时间，在收到中断信号时自动暂停，在线程恢复时自动重新激活，并在接近预算限制时向模型的响应流注入「该收尾了」的引导信号。

别什么都让 Codex 干：五个场景告诉你什么时候该收手

Tue, 02 Jun 2026 09:00:00 +0800

你以为 Codex 无所不能？先回答四个问题

用 Codex 写代码久了，很容易产生一种错觉：既然它能帮我重构模块、写测试、甚至修复安全漏洞，那是不是什么任务都能甩给它？

答案是不能。

一位在 Towards Data Science 上分享经验的开发者 Eivind Kjosbakken，最近两周从 Claude Code 切换到了 Codex，用 GPT-5.5 处理各种真实项目任务。他的结论是：Codex 在很多场景下比 Claude Code 更快、更精准，但它有一个致命的盲区。另一位来自 freeCodeCamp 的技术作者 Tatev Aslanyan 则在一份长达数万字的 Codex 手册中，专门用一整章来讨论「什么时候不该用 Codex」。

把他们的经验和 OpenAI 官方的最佳实践放在一起，我提炼出了一套判断框架。

在决定让 Codex 接手任务之前，先问自己四个问题：

产出物是否有人能审查？（如果没人检查，AI 的自信就成了唯一的质量门槛）
这是已知模式还是全新的架构决策？（Codex 擅长应用模式，不擅长选择模式）
影响范围是否局限在一个仓库或服务内？（跨团队的事它看不到全貌）
犯错的代价是否可控？（测试失败可以 revert，生产数据丢失不行）

四个问题都回答「是」，Codex 大概率能胜任。任何一个回答「否」，你就需要重新考虑任务拆分方式，或者干脆自己动手。

场景一：没人审查的「一次性脚本」

Codex 的核心价值在于它产出的东西可以被人类审查。diff 可以看，测试可以跑，review 可以做。如果你让 Codex 写一个直接操作生产数据库的一次性脚本，写完就跑，没有人 review，那 AI 的「自信」就成了你唯一的质量保障。

这不是模型能力的问题，而是流程设计的问题。

Kjosbakken 在文章中提到一个有趣的观点：他之所以敢给 Codex 开 YOLO 模式（允许它在工作目录内自由执行任何操作），是因为他的基础设施设计得好。Agent 不应该有能力永久删除数据库或造成不可逆的破坏。如果一个 Agent 或者一个人能做到这些，那说明基础设施本身就有问题。

反过来说，如果你的环境还不够安全，那就别急着给 Codex 自由。先加固基础设施，再谈自动化。