goal-setter

目标设定器

将粗略请求转化为简洁的 /goal：要实现的结果、证明结果的证据、重要边界，以及 Codex 应在何时完成或停止。Goal 是完成契约，不是实施计划，也不是第二套任务系统。

优先使用最简洁的 Goal，同时保留用户真正想要的结果。每条规则只说明一次。除非用户已明确指定，否则将文件发现、实施顺序、Agent 数量、模型和工具细节留给正在运行的 Codex 任务。

判断是否适合使用 Goal

如果一项目标可能需要多轮检查或交互才能完成，且可以通过测试、产物、运行时状态、截图、测量结果、来源或明确的评判标准来判定是否完成，请使用 Goal。

对于小型编辑、解释或审查，请使用普通提示词。如果请求带有主观性，且没有可用的完成测试，应先帮助定义测试，而不是假装 Goal 可验证。

起草前先了解情况

如果需要使用工具，先用一两句话告诉用户你将检查哪些证据。阅读最少但足够的代码、文档、来源或现有产物。收集 Goal 信息时不要开始实施。

回答三个问题：

1. 用户真正需要什么结果？
2. 什么可观察证据可以证明已实现该结果？
3. 在安全地回答前，还需要了解什么？

对于正在运行的系统或面向用户的产物，应追踪从用户输入到预期输出或状态的真实路径。除非用户允许使用替代方案，否则，用户要求可运行的结果时，模拟对象、截图、脚手架、伪造服务或独立组件都不算满足要求。

只有当缺失的答案可能改变结果、证据、范围、安全边界或停止条件时才提问。如果用户明确要求接受访谈或压力测试，请按同一规则继续提出重要问题。对于可查明的事实，应先自行核实，而不是提问。如果一个答案会决定下一个问题，请逐个提问；否则，将彼此独立的阻碍项合并提问。能够诚实地写出 Goal 后就停止提问。明确说明风险较低且可逆的假设，然后继续。

对于不确定的研究，请说明这项工作应帮助做出什么决策、主要解释及其竞争解释、哪些证据会削弱这些解释，以及何时继续搜索不太可能改变结论。

编写目标

用用户的表达方式写普通文字，不要使用带标签的字段。先说明最终状态和服务对象。只有在删去后会改变结果、证据、边界、迭代或停止决策的内容，才添加相应从句。

本任务需要涵盖的要点：

• 结果与证据。 说明最终状态，以及具体的检查位置。明确列出的要求必须有各自的证据；相邻示例或替代方案只能作为补充证据。
• 实际路径。 对于系统和体验，要求通过真实运行时、数据、服务、存储或生成的产物，完成最小且完整的用户路径。可见的主要控件必须可用、如实标记为不可用，或予以省略。如果一组通过的项目可能掩盖体验中的问题，就要同时检查各个部分和整体。
• 先阅读。 最多指出一两个重要的参考点，然后让 Codex 自行发现相关文件和测试。不要把目标写成文件清单。
• 边界。 将改动限制在满足请求所需的最小范围内。更新现有的主要文档、报告、表格或跟踪表，而不是创建重复内容。只指出本任务确实可能影响的少数几项公共行为、安全规则、权限、数据、计费或兼容性边界。不要为了让检查通过而削弱测试或必要行为。
• 验证。 使用最相关且可信的检查。修复前复现 Bug；使用明确的方法衡量性能；针对代码运行重点测试和集成路径；针对 UI 使用真实浏览器或等效工具；将实质性研究结论对应到来源，并尝试一次推翻主要结论。如果成功、失败、超时或其他不同结果会影响判断，就要求提供证据，证明每种相关结果确实发生；无法失败的检查毫无证明力。如果无法完成全部验证，就要求进行下一项可信的检查，并报告差距。
• 完成。 完成与否以通过或未通过判定，并涵盖整个请求结果。标记为完成前，Codex 要检查自己的差异、输出和证据。正确性、安全性或完成度方面的问题会阻止完成；其他改进由负责人酌情判断。
• 长时间运行。 仅在有用时，使用简短的 execution-notes.md 记录待检查事项、证据、通过／未通过／受阻状态及重要决策。如果尚未完成且没有触发停止条件，就继续检查风险最高或最不确定的未解决事项；不要停在计划或未经验证的后续步骤上。不要记录冗长的活动日志，也不要在 GOAL.md 中重复当前目标。
• 停止。 在三种真正不同的方法均告失败后、无法获得所需访问权限或批准时，或者继续执行会改变约定的结果、范围、架构、身份验证、计费、生产状态或破坏性边界时，停止并报告确切的阻碍。
• 最终报告。 面向不了解本次执行过程的读者撰写。先说明结果和当前证据。指出受阻或尚未检查的要求，以及目标留给 Codex 自行决定的任何重要事项。

只对真正不可变的要求使用强硬措辞。不要添加笼统警告、穷尽所有边缘情况、制定固定阶段计划或安排普通的命令级并行。

仅在有帮助时使用子代理

当独立调查、隔离的繁杂工作、单独的实现范围或独立验证可能实质性影响“完成”判定时，子代理会很有用。风险低且有明确自动化检查的工作通常不需要子代理。

需要委派时，目标应直接要求委派指定工作，并要求在判定“完成”前考虑其证据。不要将运行时工具架构、模型设置、Agent 名称、数量或调度说明复制到目标中。

执行期间：

• 一名负责人对用户要达成的结果、集成、重要决策、最终验证和“完成”判定负责。
• 为每个 Agent 分配一项范围明确的任务，说明其范围、相关约束、需返回的证据和停止条件。上下文足够精简时，不要传递完整对话。
• 如果下一项任务依赖现有 Agent 已掌握的信息，就继续使用该 Agent。只有在工作线确实独立或需要进行独立审查时，才启动新 Agent。
• 如果能减少上下文或时间，Agent 可以委派较小的独立部分。明确责任归属，避免增加协调成本却不改变结果的委派链。
• Agent 工作期间，负责人继续处理不依赖其结果的工作。只有在后续决策、集成或完成声明需要其结果时才等待。
• Agent 共享工作文件。并行写入必须明确划分负责区域，并分别检查。每个区域由一名 Agent 及其委派的小任务负责；有重叠或紧密耦合的写入应由同一负责人处理。
• 独立验证应由新的只读 Agent 执行，并提供实际产物和验收标准，而不是作者的推理或期望的结论。重大修复后，重新运行受影响的检查；如果验收仍取决于主观判断，则再进行一次新的独立审查。

灵活调整。不要规定固定的工作者数量、层级深度、角色清单或顺序。根据当前证据、依赖关系、成本和剩余不确定性，为当前任务选择最精简有效的方案。

create_thread 不同：它会创建一个由用户单独拥有的 Codex 任务。只有用户明确要求创建单独的任务、线程或工作树时才使用或提及它。对于多个并行写入任务，必须确保责任范围稳定且互不重叠、分别验证、共享接口明确、Git/工作树基础可用，并且节省的时间足以抵消集成成本。为每项任务指定一项负责的结果、相关证据和集成规则。不要仅仅因为工作可以拆分就创建单独任务，也不要只为启用这些任务而创建仓库结构。

Claude Code 可以使用自身的委派功能实现相同的结果和证据要求。不要将 Codex 专属的工具细节强加到可移植的目标文本中。

长度

以一句话或一小段文字开头。复杂目标通常控制在 800–1,800 个字符；达到 2,500 个字符时应再进行一次精简。运行时硬性上限为 4,000 个字符。

条件允许时，运行一次 python3 -B scripts/validate_goal_length.py <file>。通过长度检查并不能证明目标写得好。

激活

如果运行时提供原生 Goal 工具，就使用它。在 Codex 中，先检查 get_goal；如果已有匹配的活动 Goal，就复用而不是重复创建。然后使用 create_goal，除非用户只要求草稿。如果没有原生 Goal 工具，则返回准确的 /goal ... 行。除非 Goal 确实已设置，否则绝不要声称已设置。

激活前，确认结果、证据、重要边界、停止条件以及任何必要的委派都清晰且适度。删除所有不会影响本次执行的内容。