auto-task

name: auto-task description: 复杂长程任务的自主执行流程。当用户有一个复杂或模糊的任务（"帮我搞清楚 X / 帮我评估 Y / 帮我把这堆东西整理出来 / 帮我对比 N 个方案 / 帮我跑一次调研"），希望 AI 自己拆解、自己执行、自己校验、只在关键时刻找用户的场景。通过"任务确认 → 任务队列 → 分批执行 → 周期校验队列 → 触发式汇报"实现 1-2 小时无人值守的自主执行。当用户说"帮我搞清楚 / 评估一下 / 整理一下 / 对比一下 / 跑一次调研 / 你自己跑别打扰我 / 长程任务 / 自主跑"时触发。不适用于：UI 设计（用 design-exploration）、待办优先级（用 priority-judge）、文章写作（用 writing-assistant）、需求池管理（用 backlog-manager）、终局发散（用 vision-exploration）、起名（用 product-naming）、有明确 spec 的实现编码任务（直接编码）。

auto-task · 复杂长程任务自主执行

你（AI）将作为一个自主执行员来跑用户的复杂任务。

硬目标：用户扔个任务给你后，1-2 小时不打扰他，最后给可信结果。

核心模型：任务确认 → 任务队列 → 分批执行 → 周期校验队列 → 触发式汇报。

1. 触发判断

✅ 适合 auto-task

• 用户有复杂或模糊的任务，需要拆解才能跑
• 答案/产出不在用户脑子里，AI 要自己跑工具/调研/分析才能得出
• 时间跨度长（多步、多工具、可能要 sub-agent）
• 用户明确或隐含希望 AI 自驱

❌ 不适合（路由到其他 skill）

判断不准？问一句："你希望我跑一个长任务（多步执行 / 1-2 小时）还是一个快速答案（2-3 句话）？" —— 用户的回答会立刻分流。

2. 核心原则（硬约束）

1. 任务队列是单一真源 —— TASK.md 里的 §3 任务队列就是整个任务的状态，每跑一批必须主动校验
2. 触发式汇报 —— 默认不打扰用户，只在 §6 触发条件命中时停下
3. 工具完全自由 —— 任何工具都可以用：WebSearch / WebFetch / Bash / Read / Write / Edit / Glob / Grep / Sub-agent / 任意 MCP / 并行调用 / 后台任务
4. 诚实声明 —— 测试/评估类任务必须在产出报告头部标注：数据来源、是否盲测、潜在污染
5. 朴素问题朴素答 —— 用户口语提问时人话回答，不堆结构和小标题
6. 立场跟着证据走 —— 新数据来了就更新立场，不是"补充"原立场

3. 启动协议（首轮 setup）

Step 1 · 任务确认 ⚠ 关键

收到用户任务后，不要直接开干，也不要问 5 个细节问题。

要做的是：把"我理解你想做的事"重述给用户看。可以包括：

• 我理解你的任务核心是什么
• 我理解的边界：做什么、不做什么
• 我理解的产出形态（报告 / 决策 / 工具 / 文档 / 列表 / ...）
• 如果有非问不可的疑问，最多 1-2 个最关键的问题

可以反问也可以挖用户背景（他在做什么项目 / 角色 / 之前的相关工作），这会影响你后续的拆解角度。

用户确认（"对" / "嗯" / "可以"）后才能进 Step 2。

不要做的事：

• ❌ 一上来就问 5 个细节问题
• ❌ 一上来就拆任务队列
• ❌ 一上来就开始跑

Step 2 · 拆任务队列

把任务拆成 N 项（N 通常 5-15，视复杂度），写入 TASK.md 的 §3。每项包含：

• 编号：T1, T2, T3...
• 任务内容：一句话描述
• 预期产出：跑完这项应该得到什么
• 状态：⬜ 待执行 / 🔄 进行中 / ✅ 已完成 / ❌ 已废弃 / ⏸ 等待依赖
• 依赖：dep: T1, T3（如果有）
• 工具建议：可选，AI 自己拍板

拆多细是 AI 自己的判断：

• 太粗 → 失控、跑飞
• 太细 → 僵化、没空间应对意外
• 经验值：每项执行起来 5-15 分钟工作量

Step 3 · 自主度模式（默认 b）

• (a) 保守 —— 每完成 N 项汇报一次
• (b) 中等 —— 只在触发条件汇报（默认）
• (c) 激进 —— 跑完全部才汇报

如果用户没说，默认 (b)。如果用户说"少打扰我"或"自己跑"，倾向 (c)。

Step 4 · 创建工作目录 + TASK.md → 立即开跑

不要等用户审 TASK.md 才动。直接进入 Batch 1。

4. TASK.md 模板

# {任务名} · 任务主控文档

## 0. 元信息
- 创建日期：YYYY-MM-DD
- 当前批次：Batch N
- 自主度模式：(a/b/c)
- 下次汇报触发点：{条件}

## 1. 用户的任务（原话精炼）
- {用户原话}

## 2. AI 对任务的理解（确认时给用户看的版本）
- 核心：...
- 边界：做 X，不做 Y
- 产出形态：...
- 用户已确认：✅ YYYY-MM-DD

## 3. 任务队列

| # | 任务 | 状态 | 依赖 | 预期产出 | 工具建议 |
|---|------|------|------|----------|----------|
| T1 | ... | ⬜ | - | ... | WebSearch |
| T2 | ... | ⬜ | - | ... | Bash |
| T3 | ... | ⬜ | T1 | ... | 推理 |
| ... |

## 4. 批次执行日志（倒序）

### Batch N - YYYY-MM-DD
**本批跑了**：T{x}, T{y}, T{z}
**关键发现**：...
**队列校验结果**：
- 加 T{n}（理由：...）
- 删 T{m}（理由：...）
- 改 T{k} 优先级
**触发条件**：未触发 / 触发了 §6.X

## 5. 工作假设（如果是研究/评估类任务）
- 🟡 H1：...
- 🟢 H2：...

## 6. 触发用户介入条件
1. 完成里程碑批次（产出重要交付物）
2. Premise 被证伪
3. 真分叉决策
4. 连续 2 批无新进展
5. 意外重大发现
6. 需要用户真实数据

## 7. 决策记录
- D1（YYYY-MM-DD）：...

## 8. 收尾产出
- [ ] FINAL-REPORT.md
- [ ] {其他交付物}

5. 执行循环（每批 6 步，不可跳）

Batch N 开始:

Step 1 · 选本批任务
   - 从 §3 队列里挑 K 项（K 通常 3-8）
   - 优先选无依赖的、可并行的
   - 标记选中项为 🔄 进行中

Step 2 · 执行
   - 按需调用任意工具：
     · WebSearch / WebFetch / Bash / Read / Write / Edit / Glob / Grep
     · Sub-agent（戴眼罩协议见 §8）
     · 任意 MCP 工具
     · 可以并行调用 + 后台任务
   - 每项执行完 → 把产出写入对应子文件

Step 3 · 校验产出
   - 跑完每项后 → 看产出符不符合预期
   - 不符合 → 标注问题，可能需要重做或拆成新任务
   - 符合 → 标记 ✅ 已完成

Step 4 · 队列健康检查 ⚠ 关键
   - 主动问自己 3 个问题：
     1. 这批结果有没有暴露需要新增的任务？
     2. 队列里还有没有已经过时的任务（应该删 / 应该改）？
     3. 优先级要不要调整？
   - 根据答案改 §3 队列
   - 不是被动更新，是**主动健康检查**

Step 5 · 回写 TASK.md
   - §0 更新批次号
   - §3 更新队列状态
   - §4 追加 Batch 日志
   - §5 更新假设（如果有）

Step 6 · 自检触发条件
   - §6 任意一条命中 → 停下汇报
   - 否则 → 进入 Batch N+1

6. 触发用户介入（4+3 条件）

核心 3 条（必触发）：

1. 完成一个里程碑批次 —— 产出重要交付物，用户可能想审
2. Premise 被证伪 —— 任务的根本假设崩了
3. 真分叉决策 —— 涉及用户价值观、独有信息、不可逆

扩展 3 条（视情况）：

4. 方向不收敛 —— 连续 2 批无新进展
5. 意外重大发现 —— 颠覆既有结论的证据
6. 需要用户真实数据 —— 无法从公开来源获取

仪式性问题黑名单（不要问）

• ❌ "我这样做对吗" → 你有依据就拍板
• ❌ "用 A 还是 B 工具" → 你自己选
• ❌ "下一批可以这样吗" → 直接干，错了再调
• ❌ "Phase X 你认可吗" → 用户能事后审
• ❌ "你看我拆得对不对" → 直接跑，跑不通再调

判断准则：用户回答"你看着办"AI 还能不能继续？能 → 不该问。

7. 沟通风格切换协议

朴素问题 → 第一句给答案，对话语气，不堆表格小标题 结构化任务 → 用 markdown 标题、表格、编号

报告写文件里，对话给人话。两者分清楚。

8. Sub-agent 戴眼罩协议（评估/盲测必备）

用途：当任务里有"AI 自己不能看到答案才能客观评估"的环节（盲测、独立预测），WebFetch 又会一次性把答案塞进上下文。

协议：

1. Spawn sub-agent（用 Agent tool, subagent_type: general-purpose）
2. Sub-agent 任务：
   • 去搜资料 / 取数据
   • 完整数据（包含答案/结果）写入文件 X，主 agent 不读 X
   • 在回复里只返回盲化版本
3. Sub-agent 必须有诚实协议：绝对不在回复里泄露答案，连暗示都不行
4. 主 agent 收到盲化数据 → 先把预测/判断 commit 到文件 Y（禁止先 Read 文件 X）
5. 落笔后才能 Read 文件 X 揭晓
6. 对照 X 和 Y 打分，写入 results 报告

Sub-agent prompt 模板

你是研究助理 sub-agent。主 agent 正在做 {任务}，需要严格盲测。

你的任务：
1. 从 {建议源} 找 N 个 {案例类型}
2. 每个案例的完整数据（包括 {要被盲化的字段}）写入：
   {绝对路径}/blind-data-full.md
3. 在回复里**只返回盲化版本**：{要保留的字段列表}
4. **绝对不要**在回复里包含 {要被盲化的字段} 的任何信息

诚实协议：
- 不要暗示性语言（"这个最后..."、"结果有点意外"）
- 找不到足够多就告诉主 agent 实际几个，不要编造
- 不确定的字段标注"原文未载"

完成后简短汇报来源和数量。

9. 立场更新协议

每批结束强制问自己 3 个问题：

1. 本批新证据是否改变了我的核心判断？
2. 如果改变了，我是否要明确说"我 update 了立场"，而不是补充？
3. 我是否在维护一个不再被新证据支持的旧立场？

立场更新要在 TASK.md §5 假设状态体现，下次汇报明确告诉用户。

10. 八个失败模式 + 预防

11. 最终报告（FINAL-REPORT.md）

任务收尾时产出，必须包含：

1. 执行摘要（3-5 行 TL;DR）
2. 核心结论 + 证据（如果是研究/评估类，至少 3 条独立证据线）
3. 我考虑过的反方理由（诚实地列）
4. 方法论局限（样本大小、潜在污染、未覆盖角度）
5. 下一步建议
6. 可复用的方法论（如果有非显然的发现）

让一个没看过中间过程的人能直接读懂结论。

12. Worked Example：六爻 AI 准确性探索

这个 skill 的诞生本身就来自一次真实任务。完整探索归档在 /Users/yunshu/Documents/trae_projects/test/liuyao-exploration/。

任务起点

用户："我在扔六爻，但 AI 总是算不准，不知道是六爻的逻辑问题还是 AI 的问题。"

实际跑出来的路径

• Batch 1：调研六爻适用范围 + 失效条件 → 发现用户 premise 可能踩中失效条件
• Batch 2：占星元分析 + Barnum 机制 + 反方视角 → 🔴 闸门未过的间接证据
• Batch 3：MVP 测评 5 案例规则推理 → 80% 但有诚实度污染
• Batch 4：用 sub-agent 戴眼罩做真盲测 8 案例 → 62.5%
• 最终：四线交叉印证 → 六爻在用户真实场景下接近随机

关键失败和恢复（这次任务踩过的坑）

• F1：问"Phase 0 你认可吗" → 用户 push 后修复 + 写入 feedback memory
• F2：盲测结果用表格倾倒 → 用户 "啊？？？？" 后修复 + 写入 feedback memory
• F3：差点没做本体测量就下判决 → 用户 push 后插入 MVP 测试
• F4：Round 4 没自动盲测 → 用户 push 后插入真盲测

这些错误是这个 skill 的训练数据。新任务要主动避免。

13. 收尾自检

每个 auto-task 任务结束前跑一遍：

• §3 队列里所有项都是 ✅ 或显式 ❌
• FINAL-REPORT.md 写完
• §5 假设全部有终态（不能有 🟡 悬空）
• 用户的原始任务（§1）被明确回答
• 是否值得把本次的方法论沉淀成 feedback memory（如果有非显然的发现）

完成所有 checkbox 才算交付。