Codex Goals机制：让AI从「你推一步走一步」到「你定终点它自己跑到」

在软件开发的日常工作中，我们常常面临一类特殊的任务：终点明确，但通往终点的路径未知。比如性能调优、Bug追查、依赖迁移，或是复现一篇论文的核心实验。这类任务的特点是——你知道要去哪里，却不清楚该怎么走。传统的AI辅助编程模式下，你需要在每一轮对话后手动催促：「继续」「再试一次」「跑下测试」。这种模式本质上是在弥补一个缺失：没有一个持久的「目标」在驱动整个过程。

Goals机制的核心要素

Codex是OpenAI推出的AI编程Agent，擅长在代码仓库中执行明确的单步任务——修Bug、加测试、解释报错。然而，现实中的很多工作不是一步能完成的。Goals机制正是为了解决这个问题而设计的。它不是更长的提示词，而是一个绑定在对话线程上的完成契约：你定义「什么算做完」，Codex持续验证证据，自动决定下一步，直到目标达成或诚实报告受阻。

Goals与普通Prompt的本质区别

一个完整的Goal通常包含三个核心要素。第一是可度量的结果——不是「优化性能」，而是「p95延迟降到120ms以下」。第二是验证手段——跑哪个基准、过哪套测试、生成什么产物。第三是约束条件——不能破坏正确性测试、不能改公共API。有了这三样东西，Codex就能在「发现热点→修改代码→跑基准→检查约束」之间形成闭环，不需要人工反复介入。这本质上将一次性的Prompt交互转化为一个以证据验证驱动的持续循环。

普通Prompt说的是「做下一件事」，而Goal说的是「持续工作，直到这个结果为真」。这个区别很关键。在普通请求中，Codex执行即时指令、报告结果、然后等待。有了Goal，Codex的线程上附加了一个持久的目标。一轮对话结束后，它可以检查当前证据，判断目标是否满足。如果答案是否定的，且Goal仍处于激活状态并且在预算范围内，Codex可以从最新状态继续。这使Goal在「下一步正确行动取决于Codex刚学到的东西」时最为有用。一个实用的心智模型是：Prompt是「请求→工作→结果→等待」的循环，而Goal是「工作→检查→继续或完成」的闭环。

一个好的Goal不仅仅是更长的提示词，它是一个关于Codex应如何工作、什么算成功、以及如果暂时无法达到成功应如何处理的精简契约。最强的Goals通常定义六个要素：结果（工作完成时什么应该为真）、验证表面（用于证明成功的测试、基准或报告）、约束（在Codex工作时哪些不能退化）、边界（Codex可以使用哪些文件、工具或资源）、迭代策略（Codex在每次尝试后应如何决定下一步）、以及阻塞停止条件（Codex应在何时停止并报告当前限制下没有可行路径）。一个有用的编写模式是：「/goal <期望的最终状态> 由 <具体证据> 验证，同时保持 <约束>。使用 <允许的输入、工具或边界>。在迭代之间，<Codex应如何选择下一个最佳行动>。如果被阻塞或没有可行路径，<Codex应报告什么以及什么能推进进展>。」

如何编写一个高质量的Goal

Goals在Codex中的实现是持久化的线程状态，而非全局内存或项目级别的指令。这一设计选择至关重要：目标属于承载相关上下文的线程，包括Codex检查过的文件、运行过的命令、生成的差异、看到的日志以及构建的推理链。持续执行是事件驱动的，而不是简单的循环——Codex仅在安全的边界检查是否继续：一轮对话结束后、没有其他工作待处理时、没有用户输入排队时、以及线程空闲时。这种设计确保了Goal不是没有边界的后台自主权，而是一个有范围的、用户可控的完成契约。

如有侵权，请联系删除。