94 lines
2.4 KiB
Markdown
94 lines
2.4 KiB
Markdown
---
|
|
description: 用 goal-driven 方法推动一个复杂任务持续执行，直到明确成功标准被满足
|
|
argument-hint: 建议填写任务目标；若同时给出成功标准更好
|
|
allowed-tools: ["Read", "Edit", "Bash", "Grep", "Glob"]
|
|
---
|
|
|
|
# /goal-driven — 目标驱动执行模式
|
|
|
|
使用 `lidangzzz/goal-driven` 的核心思想来推进复杂任务：先固定目标与成功标准，再持续执行和反复验收，直到标准真正满足。
|
|
|
|
适用场景：
|
|
|
|
- 长周期实现任务
|
|
- 高复杂度工程任务
|
|
- 可被明确验收的研究、实现、迁移、验证类工作
|
|
|
|
不适用场景：
|
|
|
|
- 纯脑暴
|
|
- 无法定义成功标准的模糊任务
|
|
- 很小的一次性修改
|
|
|
|
## 输入要求
|
|
|
|
若 `$ARGUMENTS` 只包含目标，没有成功标准，先补全一版可执行的成功标准再开始。
|
|
|
|
启动时先输出：
|
|
|
|
```md
|
|
Goal
|
|
- ...
|
|
|
|
Criteria for success
|
|
- ...
|
|
|
|
Plan
|
|
1. ...
|
|
2. ...
|
|
3. ...
|
|
|
|
Verification
|
|
- ...
|
|
```
|
|
|
|
## 执行规则
|
|
|
|
1. 先把任务固化为两个核心块：
|
|
- `Goal`
|
|
- `Criteria for success`
|
|
|
|
2. 成功标准必须尽量客观，可验证，可落地。
|
|
优先写成：
|
|
- 需要交付什么
|
|
- 需要通过哪些测试或验证
|
|
- 如何判断结果真的完成
|
|
|
|
3. 进入持续执行循环：
|
|
- 完成一个阶段
|
|
- 检查当前结果是否满足成功标准
|
|
- 若未满足，明确剩余差距并继续推进
|
|
|
|
4. 任何“完成了”“差不多了”“已实现”之类的结论，都必须经过验证，不能直接接受。
|
|
|
|
5. 如果验证失败：
|
|
- 明确指出哪条成功标准没满足
|
|
- 继续工作，不要把阶段性进展误判为完成
|
|
|
|
6. 只有在以下情况之一才能停止：
|
|
- 成功标准已满足
|
|
- 用户明确要求停止
|
|
|
|
## 执行风格
|
|
|
|
- 重证据，轻口头判断
|
|
- 优先使用确定性工具证据：`rg`、`git diff --stat`、`git diff -- <path>`、测试、构建、lint、`curl`、数据库查询等能直接证明成功标准的方式
|
|
- 不把大段命令输出粘进回复；保留在工具调用里，回复只总结关键证据
|
|
- 重验收，轻自我感觉
|
|
- 优先用测试、日志、产物、对比结果来证明完成
|
|
- 对长期任务保持“未达标就继续”的节奏
|
|
|
|
## 简版模板
|
|
|
|
```md
|
|
Goal: [[[[[在此填写最终目标]]]]]
|
|
|
|
Criteria for success: [[[[[在此填写成功标准]]]]]
|
|
|
|
循环执行：
|
|
1. 推进任务
|
|
2. 检查是否满足成功标准
|
|
3. 若未满足，继续工作
|
|
4. 直到满足标准或用户明确停止
|
|
```
|