导读
Codex 是 OpenAI 推出的 AI 编程 Agent，擅长在代码仓库中执行明确的单步任务——修 Bug、加测试、解释报错。但现实中的很多工作不是一步能完成的：你需要反复跑基准、排查不稳定的测试、迁移一批依赖、或者复现一篇论文的核心实验。这类任务的特点是——终点明确，路径未知。
过去，你得在每一轮对话后手动催促："继续""再试一次""跑下测试""还没完"。这本质上是在弥补一个缺失：没有一个持久的"目标"在驱动整个过程。
Goals 就是为了解决这个问题而设计的。它不是更长的提示词，而是一个绑定在对话线程上的完成契约。你定义"什么算做完"，Codex 持续验证证据，自动决定下一步，直到目标达成或诚实报告受阻。
具体来说，一个 Goal 通常包含三个核心要素：
- • 可度量的结果：不是"优化性能"，而是"p95 延迟降到 120ms 以下"
- • 验证手段：跑哪个基准、过哪套测试、生成什么产物
- • 约束条件：不能破坏正确性测试、不能改公共 API
有了这三样东西，Codex 就能在"发现热点→修改代码→跑基准→检查约束"之间形成闭环，不需要你反复介入。
Goals 的典型应用场景包括：
- • Bug 追查：复现问题、定位根因、验证修复，全程有证据链
- • 依赖迁移：批量升级、修复兼容性问题、确保测试通过
- • 研究复现：逐声明验证论文结果，区分精确复现和近似重建
最佳实践也很有意思：如果你描述不清 Goal，可以直接让 Codex 帮你写——把任务用大白话说出来，Codex 会帮你补全验证标准和阻塞条件。Goal 还可以在执行中暂停、恢复，预算用完会自动停止并汇报进展。
简单说：Goals 让 Codex 从"你问一步它走一步"变成"你定终点它自己走到"。对开发者来说，这是从手动驾驶到设定导航的跃迁。
Codex Goals 机制使用指南
Goals 是 Codex 中的持久化目标，让对话线程持续朝着一个预先定义的结果努力。Goal 为 Codex 提供了一个完成条件：目标状态应该是什么、如何验证成功、以及哪些约束必须保持不变。
对于范围明确的编码任务，Codex 已经表现出色：检查仓库、修复 Bug、添加测试、解释失败原因或实现一个聚焦的改动。但 Goals 是为那些需要探索的任务设计的——下一步行动取决于 Codex 在过程中学到什么：性能分析、补丁修复、基准测试、复现不稳定测试，或者将研究问题转化为有证据支持的审计报告。
这些任务不需要更长的提示词。它们需要一个持久化的目标。有了 Goal，Codex 可以将目标时刻放在视野中，评估工作是否完成，并选择下一个有用的行动——无需你在每个中间结果后重新陈述目标。
Goal 不是没有边界的后台自主权。它是一个有范围的、用户可控的完成契约。你定义结果，Codex 依据线程中的证据展开工作，而 Goal 可以被暂停、恢复、清除、完成或触达预算上限后停止。
你将学到什么
完成本指南后，你将能够：
- • 编写具有可度量结果、可验证表面和约束条件的 Goal
- • 使用
/goal、/goal pause、/goal resume 和 /goal clear 管理 Goal 生命周期
前提条件
- • 支持 Goals 的 Codex 版本（0.128+）
- • 带有明确终点的任务，以及可检查的证据源（如测试、基准测试或最终产出物）
- • 足够多的仓库或研究上下文，使 Codex 能够实际验证进展，而不是仅做叙述
概览
图 1：Goal 将单次交互转化为一个以证据验证驱动的持续循环。
快速开始：使用 Goals
当任务有明确的终点但通往终点的路径不确定时，使用 Goal。
适合的场景包括：性能优化、不稳定测试排查、依赖迁移、需要复现的 Bug 追查、多步骤重构、基准驱动调优，以及需要最终产出物的研究任务。对于一次性编辑，普通提示仍然是正确的选择。
要使用 Goals，请安装或更新 Codex 并确认版本。Goals 从 Codex 0.128.0 版本开始可用。
使用 npm 安装：
npm install -g @openai/codex@latest
codex --version
使用 Homebrew 安装：
brew update
brew upgrade --cask codex
codex --version
然后使用 /goal 加上期望结果来设置 Goal：
/goal 在不破坏正确性测试的前提下，将 p95 延迟降低到 120ms 以下
你可以从同一个命令界面管理生命周期：
/goal 查看当前 Goal
/goal pause 暂停当前 Goal
/goal resume 恢复暂停的 Goal
/goal clear 移除当前 Goal
一旦 Goal 激活，Codex 可以检查代码、运行相关命令、做出修改、测试结果，并持续进行直到达到停止条件。停止条件可能是：成功、暂停、清除、中断、预算上限，或需要用户输入的阻塞点。
当你发现自己在每一轮对话后都在重复类似的话时，就应该使用 Goal：
继续。试下一个可能的修复。再跑一次基准测试。现在检查测试。继续直到真正完成。
Goal 让这些意图变得明确。
Goal 与 Prompt 的区别
普通 Prompt 说：做下一件事。
Goal 说：持续工作，直到这个结果为真。
这个区别很关键。在普通请求中，Codex 执行即时指令、报告结果、然后等待。有了 Goal，Codex 的线程上附加了一个持久的目标。一轮对话结束后，它可以检查当前证据，判断目标是否满足。如果答案是否定的，且 Goal 仍处于激活状态并且在预算范围内，Codex 可以从最新状态继续。
这使 Goal 在"下一步正确行动取决于 Codex 刚学到的东西"时最为有用。例如：
/goal 在结账基准测试中将 p95 延迟降至 120ms 以下，同时保持正确性测试套件为绿色通过状态
这不只是改善性能的请求。它给了 Codex 一个可度量的结果、一个验证表面和一个约束条件。Codex 可以运行基准测试、检查热点路径、做出有针对性的修改、再次运行基准测试、运行正确性测试套件，并在结果不够好时继续。
实用的心智模型很简单：
Prompt: 请求 → 工作 → 结果 → 等待
Goal: 工作 → 检查 → 继续或完成
Goal 给了 Codex 一条终点线。但工作成果仍需要对照证据进行审计。
如何编写一个 Goal
一个好的 Goal 不仅仅是更长的提示词。它是一个关于 Codex 应如何工作、什么算成功、以及如果暂时无法达到成功应如何处理的精简契约。
最强的 Goals 通常定义六个要素：
- • 结果 (Outcome)：工作完成时什么应该为真
- • 验证表面 (Verification surface)：用于证明成功的测试、基准、报告、产物、命令输出或源材料
- • 约束 (Constraints)：在 Codex 工作时哪些不能退化
- • 边界 (Boundaries)：Codex 可以使用哪些文件、工具、数据、仓库或资源
- • 迭代策略 (Iteration policy)：Codex 在每次尝试后应如何决定下一步做什么
- • 阻塞停止条件 (Blocked stop condition)：Codex 应在何时停止并报告当前限制下没有可行的路径
一个有用的模式是：
/goal <期望的最终状态> 由 <具体证据> 验证，同时保持 <约束>。使用 <允许的输入、工具或边界>。在迭代之间，<Codex 应如何选择下一个最佳行动>。如果被阻塞或没有可行路径，<Codex 应报告什么以及什么能推进进展>。
例如，这个 Goal 可用但偏单薄：
/goal 在不破坏正确性测试的前提下，将 p95 延迟降低到 120ms 以下
一个更强的版本给了 Codex 一个更完整的操作契约：
/goal 将结账 p95 延迟降低到 120ms 以下，由结账基准测试验证，同时保持正确性测试套件为绿色。仅使用结账服务、基准测试夹具和相关测试。在迭代之间，记录每次变更的内容、基准测试的结果和下一个最佳实验。如果基准测试无法运行或没有可行路径，则停止并报告尝试过的路径、收集到的证据、阻塞点和所需的下一步输入。
对于研究和调查，同样的原则适用。在工作开始前定义证据标准，尤其是在精确证明可能不可得的情况下：
/goal 使用可用材料和本地资源，产生对该论文最有力的、有证据支持的重现。在可行的范围内尝试主要结果，在可能的地方验证输出，最终生成一份区分确认发现、近似重建、被阻塞声明和剩余不确定性的报告。
这种 Goal 给了 Codex 探索的空间，同时确保最终结果的诚实性。它不仅说"继续"，它说明了"完成"、"被阻塞"和"仍不确定"的实际含义。
当任务明确但 Goal 不明确时，Codex 可以帮助编写 Goal 本身。一个简单的两步工作流很有效：首先，用通俗语言描述工作，让 Codex 将其转化为 Goal 草稿；其次，审查草稿，收紧成功条件、验证表面、约束和阻塞停止条件，然后再激活它。
例如：
帮我把这个变成一个强有力的 /goal：我希望 Codex 持续处理这个不稳定的结账测试，直到我们要么用证据修复它，要么能清楚解释是什么在阻碍进展。
然后 Codex 可以提出一个更完整的 Goal，询问任何确实必要的缺失细节，最终给出一个更干净的 /goal 供你使用。
Goal 激活后会发生什么变化
当 Goal 激活时，有三件事发生变化。
第一，目标保持可见。如果 Codex 运行测试但失败了，线程仍然有最初的目标。如果基准测试改善了但未达到阈值，Codex 可以继续。如果研究路径遇到缺失数据，Codex 可以调整证据计划而不失去研究标准的视野。
第二，从空闲线程开始持续执行成为可能。Codex 不会在另一轮对话活跃时、有用户输入排队时、或有其他线程工作待处理时继续。它仅在线程空闲且 Goal 处于激活状态且在预算内时继续。
第三，完成必须是基于证据的。Goal 不应因为模型认为"可能完成了"就被标记为完成。它应在目标已被对照相关文件、测试、日志、基准输出、生成的产物或其他具体证据进行验证后才标记为完成。
这是设计的核心：Codex 可以持续行动，但由证据决定何时完成。
Goals 在 Codex 中的设计原理
Goals 被实现为持久化的线程状态，而不是全局内存或项目级别的指令。这一设计选择很重要：目标属于承载相关上下文的线程，包括 Codex 检查过的文件、运行过的命令、生成的差异、看到的日志以及构建的推理链。
图 2：Goal 为当前线程增加了持久状态、持续执行机制、生命周期控制和证据检查能力。
在架构层面，Goal 是一个持久的、线程作用域的状态。它记录了 Codex 需要随时间评估线程的目标、生命周期、预算和进度核算。关键边界是作用域：Goal 属于当前线程，不属于全局内存或项目指令。
Codex 将该状态视为用户、模型和线程之间的契约。Goal 可以是激活、暂停、完成或预算受限状态。 这些状态决定了 Codex 是否允许继续、是否应等待用户、以及是否应总结进展而不是开始新工作。
持续执行是事件驱动的，而不是简单的循环。Codex 仅在安全的边界检查是否继续：一轮对话结束后、没有其他工作待处理时、没有用户输入排队时、以及线程空闲时。
调度器的行为刻意保守。仅计划的工作不会触发持续执行。中断会暂停目标。恢复线程可以在适当时恢复目标。如果一次持续执行轮次没有进行工具调用，下一次自动持续执行将被抑制，防止 Codex 空转。
图 3：Codex 仅在 Goal 激活、线程空闲且无用户输入排队时继续执行。
提示层强化了同样的架构。持续执行的提示引导 Codex 围绕活跃目标展开工作，但同时也要求在完成前进行审计。Codex 必须将目标与具体证据进行对比：已更改的文件、已运行的命令、已通过的测试、基准测试输出、生成的产物或研究证据。
预算处理是显式的。当预算用完时，Codex 应停止实质性工作，总结进展和阻塞点，并确定下一个有用的步骤。达到预算上限与完成目标并不是一回事。
工具契约保持了生命周期权限的界限。模型可以启动一个 Goal，并且仅在证据支持完成时才能将现有 Goal 标记为完成。暂停、恢复、清除和预算受限的转换仍由用户或系统控制。
这就是需要记住的架构：Goal 是一个线程作用域的完成契约。它结合了持久目标状态、生命周期控制、持续执行策略、预算核算和基于证据的完成。其意义不是让 Codex 永远循环，而是让目标持续存在，直到证据表明工作已完成。
将薄弱的 Goal 转化为强大的 Goal
薄弱：
/goal 提升性能
强大：
/goal 在结账基准测试中将 p95 延迟降至 120ms 以下，同时保持正确性测试套件为绿色
示例：性能调优
图 4：强大的 Goal 明确了最终状态、验证方法和约束条件。
更强的版本给了 Codex 三样东西：一个结果、一个验证方法和一个约束。 它也给了 Codex 一个知道何时不应停止的标准。如果 p95 从 180ms 改善到 135ms，Goal 尚未完成。如果延迟降至 120ms 以下但正确性测试失败，Goal 同样未完成。如果基准测试无法运行，Codex 必须暴露这个阻塞点，而不是宣布成功。
同样的规则也适用于性能工作之外的场景：Goal 应该足够具体以允许验证，但又足够开放以支持探索。
Goal 应该足够狭窄以允许审计，但又要足够宽泛，让 Codex 可以选择下一步行动。修复失败的结账测试可能过于狭窄——如果真正的问题是上游依赖呢？改进整个系统又过于宽泛，因为没有审计表面。在当前分支上让结账测试套件通过，且不改变公共 API 行为则好得多。
同样的原则适用于生成的产物。一个薄弱的 Goal 说：
/goal 为此功能撰写文档
一个更强的 Goal 说：
/goal 编写一份关于 Goals 的文档页面，解释生命周期、命令界面和两个示例。验证页面可以在本地构建，所有引用的命令与当前 CLI 行为一致。
第二个 Goal 给了 Codex 一些可以检查的东西：一个页面、一个构建命令和命令行为。
同样的严谨对于研究型 Goals 更为重要。在调查开始前定义证据标准：什么算精确复现、什么算部分重建、什么算代理支持、什么应被标记为阻塞。
一个强大的研究型 Goal 应该要求 Codex 构建一个声明清单，将声明映射到证据，实现可行的部分，标记阻塞点，并生成一份区分确认声明、仅支持性证据、被阻塞声明和剩余不确定性的审计报告。
这使 Goal 足够狭窄以允许审计，而不必预先规定整个路径。Codex 可以选择下一步行动，但完成标准是固定的。
将 Goals 用于复杂研究：复现一篇量化金融论文
以下是一个遵循上述原则的研究型 Goal 的具体示例。
案例研究是 Buehler、Gonon、Teichmann 和 Wood 的《Deep Hedging》（深度对冲）。该论文探讨了神经交易策略能否在不同风险偏好、交易成本和高维市场设置下复现基于模型的对冲。正确的 Goal 不是笼统地"复现论文"。它是尝试论文的主要数值声明，将精确的机制重建与近似的训练替代品区分开来，并对哪些内容无法从可用材料中精确重放做出明确的说明。
一个薄弱的研究型 Goal 是：
/goal 复现 Buehler 等人的《Deep Hedging》
这过于模糊。它没有说明哪个章节重要、什么算复现、如何处理不可用的训练状态、或者如何区分接近的数值匹配与精确重放。
一个更好的 Goal 是：
/goal 使用可用的论文材料和本地资源，产生对 Buehler 等人《Deep Hedging》最有力的、有证据支持的重现。尝试每一个主要结果，验证输出，最终生成一份区分已复现机制、近似训练结果、被阻塞的精确重放和剩余不确定性的报告。
更强的版本之所以有效，是因为它明确了证据标准和最终产物。Codex 不仅要努力完成一个令人印象深刻的重现，还要在不过度陈述可用证据所支持的内容的情况下，最小化不确定性。
图 5：研究型 Goal 在声明状态前先将论文分解为不同的证据通道。
在实践中，这个 Goal 给了调查工作一个具体的操作契约。
Codex 用它来：
几个部分是可实现的。Codex 重建了定价和对冲机制，复现了 Heston 参考价格，为 CVaR 对冲实验训练了策略，重建了主要的直方图和对冲曲面图，复现了 Black-Scholes 交易成本斜率，并为 Heston 交易成本和高维示例运行了训练检查。
一些声明由于缺失源材料而仍然受阻。论文没有提供确切的随机种子、生成的训练路径、TensorFlow 图、优化器状态、检查点或完整的原始模拟状态。这意味着最诚实的结论是部分且近似的复现，而非精确的神经重放。
这就是 Goal 的价值所在。它在阻塞点出现后仍能推动工作继续，同时保持最终表述的诚实性。一个训练出的替代品可以支持某项声明，一个接近的数值匹配可以提高置信度，一个重建的图表可以验证部分结果——但这些都不应被描述为"精确恢复"了原始实验。
图 6：最终输出应保留不同层级的认知支持，而非合并为单一的成功声明。
最终报告应保留这些不同层级的支持，而不是将它们扁平化为单一的成功声明。
例如，一条记录条目可能如下所示：
声明: 深度对冲在无交易成本下近似完全市场 Heston 对冲
路径: 重建的模型机制、参考对冲对比和训练的神经策略
证据表面: 价格检查、直方图和对冲曲面
状态: 接近的近似复现
剩余不确定性: 原始训练路径、随机种子和检查点不可用
这就是 Goals 在研究中的演示价值。它们让 Codex 在模糊性中持续工作，同时防止一个看似合理的结果变成过度声明的结论。Goal 不仅仅是要求 Codex 完成，它还定义了"完成"意味着什么：一个逐声明的、基于证据的审计，明确近似之处，并诚实面对复现与重放之间的界限。
何时不使用 Goals
Goals 并非适用于所有任务。
以下场景不要使用 Goal：
- • 只需一个答案然后停止的问题
对于上述场景，普通的 Codex 提示更好。
当终点线模糊时不要使用 Goal：
- • "把它变得更好" 没有给 Codex 可靠的完成条件
- • "重构这段代码" 同样薄弱，除非你定义了预期的最终状态、测试和约束
不要用 Goal 来隐藏不确定性：
Goals 在任务具备三个特性时最为强大：一个持久的目标、一个基于证据的终点线、以及一个可能需要多轮调查的路径。
结论：让目标持续，但让证据决定
Goals 改变了 Codex 的运作模式。它们将线程从一系列孤立的提示转变为围绕定义结果的有状态工作循环。
架构被刻意设定了边界。Goal 局限于线程范围，携带生命周期状态和预算核算，可以被暂停、恢复、清除、完成或被预算中断。Codex 可以持续行动，但仅限在用户定义的契约范围内。
这使得 Goals 在 Codex 已经最有价值的领域中特别有用：调试、优化、迁移、测试和研究。用户提供目标，Codex 追随证据，Goal 将二者联系在一起，直到工作要么完成、要么诚实地陷入阻塞。
对于复杂的研究，这就是"生成一个答案"和"生成一份审计报告"之间的区别。一个好的 Goal 不仅仅是要求 Codex 完成。它告诉 Codex "完成"意味着什么。
粤ICP备14082021号
免费POC，
零成本试错
