/Goal 模式的正确用法：明确目标、缩短反馈、记录过程

随着 Codex 和 Claude Code 都已经正式支持 /Goal 模式，来自 OpenAI、长期关注生命科学与 AI 工程实践的 @Chris Hayduk，分享了他使用 Codex Goal 模式的一些经验。Codex Goal 模式适合处理需要持续迭代的复杂任务。它的价值不只是让 AI 智能体自动工作更久，而是让 Codex 在一个可验证、可追踪、可复盘的闭环中推进任务。

他的建议可以概括为三点：目标要清晰，反馈要足够快，过程要用 Markdown 文件持续记录。对开发者来说，Goal 模式不是普通 prompt 技巧，而是一套更接近工程实验的智能体工作流。

Codex Goal 模式不是自动干活按钮

Goal 模式的核心是循环。Codex 会执行动作、评估结果，再判断当前状态是否已经达到目标。如果没有达到目标，它就会继续执行下一轮。

问题在于，循环系统最怕目标不清楚。

很多人习惯对 AI 写宽泛指令，比如“帮我优化代码”“让这个项目更好”“把文档改得专业一点”。在普通对话里，这类指令有时也能得到不错结果。但在 Goal 模式里，它们容易成为失败源头。

原因很简单：Codex 不知道什么时候该停。

“更好”不是一个可以稳定判断的终点。它可能只改几分钟就认为任务完成，也可能不断修改，最后偏离原始目标。Chris Hayduk 在原文中提到，模糊目标会带来两类失败：一种是过早停止，另一种是无休止地乱改。

目标要写成可判断的完成条件

更适合 Goal 模式的目标，应该同时包含对象、指标和限制条件。

不要写：

/goal
帮我优化这段代码。

更好的写法是：

/goal
将 specific_file 中的代码运行时间降低 20%，同时不能导致现有单元测试和集成测试失败。

这个目标清楚很多，因为它有三个关键元素：

• 目标对象：specific_file
• 量化指标：运行时间降低 20%
• 约束条件：不能引入单元测试和集成测试回归

这才是适合智能体循环的任务。Codex 可以不断尝试不同方案，也可以通过测试和 benchmark 判断当前结果是否达标。

对开发者来说，写 Goal prompt 时最重要的不是多写几句描述，而是把“完成”的定义写清楚。

模糊任务要先变成检查清单

并不是所有任务天生都有数字指标。比如论文格式转换、文档整理、项目规范化、前端细节调整，这些任务都带有一定主观性。

Chris Hayduk 给出的做法是：先把模糊目标转成 checklist。

原文中的例子是把 NeurIPS 论文预印本转换成 ICML workshop 格式。ICML 的格式要求很多，如果只是告诉 Codex “改成 ICML 格式”，任务仍然偏模糊。更稳的做法是：

• 先让 Codex 从 LaTeX 格式文件中提取规则。
• 把规则整理成 checklist.md。
• 让 Codex 按清单逐项修改论文。
• 每完成一项就在清单中标记。

这样，“改成 ICML 格式”就变成了“完成 200 多条规则检查”。即使单条规则仍然需要理解，Codex 也更容易判断整体进度。

这个思路很适合迁移到日常开发中。例如，想让 Codex 重构一个模块，可以先让它生成 REFACTOR_CHECKLIST.md；想让它改文章结构，可以先生成 CONTENT_CHECKLIST.md；想让它修 UI 细节，可以先生成 UI_CHECKLIST.md。

重点不是清单有多复杂，而是让 Codex 有一个可以逐项推进的外部参照物。

反馈循环越短，Goal 模式越稳定

Goal 模式能不能跑得好，很大程度取决于反馈速度。

Codex 每完成一次修改，都需要知道这次修改有没有变好。如果反馈太慢，它就很难快速试错；如果验证方式不清楚，它就容易只靠主观判断继续推进。

Chris Hayduk 举了一个蛋白质结构模型架构搜索的例子。完整训练可能需要数天，但他使用 NanoFold 这样更小、采样更好的数据集，把评分时间从数天缩短到数分钟。

这其实是实验设计思路：先用低成本实验验证方向，再决定是否扩大投入。

普通开发者也可以这么做：

• 性能优化时，先准备小型 benchmark。
• 重构代码时，先准备可快速运行的测试集。
• 前端修改时，先准备截图或视觉检查路径。
• 数据处理任务中，先用小样本验证逻辑。
• 模型实验中，先用小模型和子采样数据集试方向。

Goal 模式不是越能跑越好，而是越能快速得到有效反馈越好。

Markdown 文件是长任务的外部记忆

长任务还有一个问题：上下文会变长，思路会变散。

Chris Hayduk 建议给 Codex 准备几个 Markdown 文件，让它把计划、实验和过程写进文件里。这样，Codex 不需要把所有状态都记在上下文中，而是可以随时回看文件。

最推荐准备三个文件：

• PLAN.md：记录整体计划和当前路线。
• EXPERIMENTS.md：记录每次尝试、改动、结果和结论。
• EXPERIMENT_NOTES.md：记录实时想法、判断和过程备注。

其中最重要的是 EXPERIMENTS.md。它能帮助 Codex 避免重复尝试失败方案，也方便人类开发者快速查看当前进度。

一个简单的 EXPERIMENTS.md 可以这样写：

# EXPERIMENTS

## Experiment 1: Replace nested loop with indexed lookup

Goal:
Reduce parser runtime.

Change:
Replaced repeated array scan with Map-based lookup.

Result:
Runtime reduced from 12.4s to 8.1s.

Tests:
Unit tests passed.
Integration tests passed.

Conclusion:
Partially successful. Runtime improved, but memory usage increased.

Next:
Try streaming approach to reduce memory usage.

这类记录看起来简单，但对长时间运行的 agent 很重要。它把“AI 做过什么”变成了可审计的过程，而不是只留下最终代码 diff。

一个更适合 Codex Goal 模式的 prompt 模板

可以把 Goal prompt 写成下面这种结构：

/goal

目标：
将 src/parser.ts 中的数据解析性能提升至少 20%。

约束：
1. 不允许改变现有 API 行为。
2. 所有单元测试和集成测试必须通过。
3. 不要重写整个模块，优先做局部优化。
4. 每次修改后运行测试和 benchmark。

验证方式：
1. 运行 npm test。
2. 运行 npm run benchmark:parser。
3. 将优化前后的结果记录到 EXPERIMENTS.md。

工作记录：
1. 在 PLAN.md 中写下整体计划。
2. 在 EXPERIMENTS.md 中记录每次尝试、结果和结论。
3. 在 EXPERIMENT_NOTES.md 中记录关键判断。
4. 如果连续 3 次尝试没有改善，请停止并总结原因。

这个模板比“帮我优化 parser”稳定得多。

它告诉 Codex 五件事：

• 要完成什么。
• 不能破坏什么。
• 如何验证结果。
• 如何记录过程。
• 什么时候应该停止。

这也是 Goal 模式和普通聊天式 prompt 最大的区别。普通 prompt 追求一次回答可用，Goal prompt 追求多轮执行可控。

适合 Goal 模式的任务类型

Goal 模式更适合那些有明确终点、可以重复验证、需要多次尝试的任务。

比较适合的场景包括：

• 性能优化
• 测试补全
• 代码重构
• 文档迁移
• 论文格式转换
• 批量修复 lint 问题
• 根据 checklist 修改长文档
• 在小数据集上尝试多个实验方案

不太适合的场景是完全开放、没有完成标准的任务。例如：

• “让项目更高级”
• “把 UI 改好看点”
• “优化一下整体架构”
• “看看还能做什么改进”

这些任务不是不能交给 AI，而是最好先转成计划或检查清单，再进入 Goal 模式。

记住这三件事就够了

Codex Goal 模式的正确用法，可以压缩成三句话。

第一，目标要明确。最好有数字指标，至少要有可判断的完成条件。

第二，反馈要够快。测试、benchmark、lint、截图检查都要尽量容易执行。

第三，过程要记录。用 PLAN.md、EXPERIMENTS.md 和 EXPERIMENT_NOTES.md 给 Codex 提供外部记忆。

Chris Hayduk 的经验之所以值得参考，是因为它不是单纯在讲 prompt，而是在讲如何把工程实验的思路搬进 AI 智能体工作流。让 Codex 长时间运行并不难，难的是让它在长时间运行中不跑偏、不重复试错，并且每一步都能被验证和复盘。

对开发者来说，Goal 模式真正值得记住的不是 /goal 这个命令本身，而是它背后的工作方式：用明确目标定义终点，用快速反馈修正方向，用过程记录保持长期一致性。