defining-goals

name	defining-goals
description	当一个模糊需求、自动化想法、/goal、Agent 任务、OKR、成功指标、停止条件或用户意图需要先澄清成有边界、可验证、可执行的目标时使用。

定义目标

概述

在把任务交给 Agent loop、自动化、子 Agent 或类似“员工”的执行者之前，先使用本 skill。它把模糊意图转成明确的成功条件、边界、资源、失败处理和证据来源，让执行者知道什么时候该停、什么事情不能为了达标而做。

核心规则

好目标不是更漂亮的 prompt。好目标是一份契约，至少包含：

• 期望达成的结果
• 可机器验证的完成标准
• 明确边界和禁止走的捷径
• 可用资源和权限
• 失败处理和升级规则
• 可供下次恢复的状态记录
• 来自对话、项目和当前上下文的证据

如果目标不能通过命令输出、可观察产物、外部系统状态或明确的人类评审门槛来验证，它就还不适合交给无人值守的 loop。

工作流

1. 抽取真实结果。

   • 把用户的意图改写成终态，而不是动作。
   • 差：优化一下这个应用。
   • 好：test/auth 目录下所有测试通过，tsc --noEmit 零报错，npm run lint 零违规。

2. 通过反问澄清。

   • 在执行前把模糊词变成问题：更好、完成、质量、快、安全、最近、全部、生产可用、优化。
   • 只问最少但最高杠杆的问题。能从项目证据里低成本查到的，不要先问用户。
   • 如果用户强调先推进，就把假设写进目标，而不是默默猜。

3. 该能查到的，先查上下文。

   • 在问用户前，先检查当前对话、用户提到的文件、repo docs、AGENTS/CLAUDE 规则、测试、脚本、issue、PR、日志、设计文件或连接器。
   • 用真实项目代码推导命令、文件边界、公开 contract、既有约定和验证方式。
   • 当前状态证据优先于记忆和通用经验。
   • 记录检查过什么，让目标可追溯。

4. 定义可机器验证的完成标准。

   • 优先使用命令、API 检查、截图、断言、数据库查询、CI 状态或生成产物路径。
   • 尽量写出明确阈值：延迟、错误率、数量、日期、测试范围、质量门槛。
   • 说明 warning 是否可以接受。

5. 把边界和完成标准放在一起。

   • 禁止破坏性捷径：删除测试、削弱断言、忽略 lint、改公共 contract、跳过评审、伪造数据。
   • 禁止范围扩散：无关重构、大改架构、依赖 churn、非必要视觉改动。
   • 已知时写明哪些文件、模块或系统不能碰。

6. 补充资源和权限。

   • 列出可用工具、连接器、repo 路径、凭证、文档、skills、数据源和运行环境。
   • 如果权限或上下文缺失，把发现或升级作为第一步。

7. 补充失败处理。

   • 定义重试次数、时间或 token 预算。
   • 定义什么时候暂停并请求帮助。
   • 定义完整完成被阻塞时，哪些部分产物可以接受。

8. 分层目标。

   • 顶层写业务、产品或工程结果。
   • 下面拆执行里程碑。
   • 每个里程碑下面写验证检查。
   • 停止条件要窄到 Agent 可以自己判断。

反问清单

把这些问题问自己或问用户。先从上下文里回答；只有剩下模糊或高风险的问题才问用户。

• 什么可观察状态能证明这件事完成了？
• 这里的“好”指什么：正确性、UX、速度、成本、可靠性、可维护性、收入，还是别的？
• 哪些命令、测试、路由、截图、指标或外部系统可以验证？
• 为了通过检查，哪些事情绝对不能做？
• 哪些文件、模块、API、数据、用户或环境在范围内？
• 哪些项目约定、文档或历史决策应该约束这个目标？
• 失败几次、花费多少预算、遇到什么不确定性就必须停？
• 需要记录什么，才能让下一轮不重新发现同一批上下文？

Anti-Goodhart 检查

Agent 会优化验证器。接受目标前先问：

• Agent 有没有可能通过检查，但违背真实意图？
• Agent 有没有可能删除、跳过、mock 或削弱被衡量的东西？
• 这个指标是否奖励速度，却掩盖质量下降？
• 高风险工作有没有独立检查者或评审步骤？
• 理解是否被保留下来，还是 loop 会交付一批没人真正理解的改动？

如果答案是“有可能”，就补边界、补第二指标，或增加独立验证者。

输出格式

按这个结构输出目标：

## 目标
[一句话写清楚终态。]

## 完成标准
- [可机器验证的检查。]
- [可机器验证的检查。]

## 已检查证据
- [检查过的对话、文件、文档、代码、测试、日志、issue、连接器或外部来源。]

## 待确认问题
- [只能列无法从现有上下文回答的问题。]

## 边界
- [禁止的捷径或范围外动作。]
- [受保护的文件、模块或系统。]

## 资源
- [允许使用的工具、skills、连接器、路径、文档、环境。]

## 失败处理
- [重试、预算、暂停或升级规则。]

## 需要记录的状态
- [下一轮必须知道的信息。]

就绪检查

不要把目标交给 loop，除非以下条件都成立：

• 另一个 Agent 或脚本不用猜意图也能判断通过或失败。
• 模糊词已经被澄清、从上下文搜索过，或被记录成明确假设/待确认问题。
• 执行者不能靠削弱系统来满足指标。
• 执行者知道什么时候停止。
• 执行者知道什么时候暂停。
• 执行者知道要为下一轮记录什么。