define-goal

定义目标

概述

将用户的意图塑造成 Agent 能够诚实追求的目标。相比活动描述，优先采用可衡量的结果、明确的证据和有限的范围。

此技能仅涵盖目标定义和目标工具创建。不要使用此技能创建中间规划材料、持久快照、台账、决策日志或恢复文件。

工作流

1. 确认是否确实需要定义目标。

   • 用户请求 $define-goal、要求创建或设定目标、请求目标工具，或希望将某个意图转化为明确目标时，使用此技能。
   • 如果用户只要求常规实现工作，就直接执行，不要强行创建目标。

2. 用具体措辞重述可能的目标。 一个可用的目标应说明：

   • 将实现的具体结果
   • 涉及的主要制品、系统、代码库、环境或面向用户的行为
   • 如何验证是否完成
   • 工作范围
   • 在歧义可能造成影响时，明确不在范围内的事项
   • 何时应停止并询问用户，而不是继续埋头处理

3. 在适用的领域中进行量化。 优先使用能体现实际成功的数字，而非装饰性的精确度：

   • 通过/未通过验证：具体测试、检查、CI 任务、评估、命令或验收标准
   • 质量阈值：延迟、错误率、成本、准确率、召回率、精确率、覆盖率、波动率、包大小、内存、运行时间、完成率或人工审核标准
   • 制品约束：文件路径、受影响模块、允许的命令、输出格式、目标环境、截止日期或最大影响范围
   • 证据数量：已复现的失败、成功重跑、已审核示例、迁移记录、已处理评论或已验证案例的数量

4. 在设定目标前完善薄弱目标。

   • 如果本地上下文足以安全地重写含糊目标，就将其改写为可衡量的目标。
   • 如果缺失的信息会改变预期结果或验证方式，就提出一个简洁的澄清问题。
   • 拒绝“取得进展”“继续调查”“改进一下”或“处理 X”之类纯粹描述活动的目标，除非将其细化为可验证的结果。

5. 创建目标前检查当前目标状态。

   • 调用 get_goal。
   • 如果没有活动目标，且目标符合质量标准，就调用 create_goal。
   • 如果活动目标仍符合用户的意图，就继续使用该目标，不要创建重复目标。
   • 如果活动目标与新请求冲突，就询问用户是要完成当前目标、在已完成时将其标记为完成，还是启动一个单独的目标工作线程。

6. 只有通过质量标准后才创建目标。

   • 使用简洁的单一目标陈述。
   • 在目标陈述中包含验证证据。
   • 在范围限制会约束工作时，将其写入目标。
   • 仅当用户明确要求时，才包含令牌预算。
   • 对于普通的多步骤任务，不要调用 create_goal，除非用户明确要求以目标为依据开展工作。

目标质量标准

调用 create_goal 前，目标应回答以下问题：

• 完成后会实现什么具体结果？
• 什么证据能够证明这一点？
• 哪个量化或二元阈值定义了成功？
• 哪些范围边界需要明确？
• 什么情况应导致 Agent 停下并询问用户？

良好示例：

将文档说明的慢速路径上的结账 API p95 延迟降至 250 ms 以下：通过最小且安全的服务端改动实现，并使用 npm run test:checkout 和现有本地延迟基准进行验证，确保连续 3 次运行的 p95 均低于 250 ms。

良好示例：

解决 PR 123 中要求代码修改的未处理评审意见，仅更新受影响的 auth 文件和测试，并通过指定的 auth 测试命令以及 gh pr view 123 进行验证，确认没有未解决的变更请求讨论串。

薄弱示例：

提高结账速度。

薄弱示例：

继续调查 PR 评论。

量化启发式

• 对于 bug，首先将复现定义为成功标准，其次才是修复；在可行时，要求验证器先失败后通过。
• 对于测试，写明确切的命令和必需的通过条件。
• 对于性能，写明指标、目标阈值、测量方法和运行次数。
• 对于质量工作，定义可观察的验收标准，例如经过评审的示例、lint/typecheck/test 通过，或用户批准的产物。
• 对于研究，定义研究必须支持的决策、涉及的来源或系统，以及证据标准。
• 对于运维，定义健康状态、监控时段、故障阈值，以及回滚或升级处理的触发条件。

澄清问题

只有在合理改写可能导致追求错误结果时才提问。问题应简短，并围绕缺失的验证器或范围边界。

实用的问题形式：

• “应以什么指标定义成功：延迟、成本、准确性，还是用户可见行为？”
• “我应针对哪个环境进行验证：本地、预发布，还是生产？”
• “在我将此目标标记为完成之前，你希望看到的最低证据是什么？”

如果用户无法提供指标，请提出当前最诚实可用的二元验证方式，并征求确认。