| 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）
| 任务 | 应该用 |
|---|
| UI/交互设计 | design-exploration |
| 待办优先级判断 | priority-judge |
| 文章写作 | writing-assistant |
| 需求池管理 | backlog-manager |
| 终局愿景发散 | vision-exploration |
| GitHub issue 诊断 | issue-triage |
| 起名 | product-naming |
| 有明确 spec 的实现编码 | 直接编码 |
判断不准？问一句："你希望我跑一个长任务（多步执行 / 1-2 小时）还是一个快速答案（2-3 句话）？" —— 用户的回答会立刻分流。
2. 核心原则（硬约束）
- 任务队列是单一真源 —— TASK.md 里的 §3 任务队列就是整个任务的状态，每跑一批必须主动校验
- 触发式汇报 —— 默认不打扰用户，只在 §6 触发条件命中时停下
- 工具完全自由 —— 任何工具都可以用：WebSearch / WebFetch / Bash / Read / Write / Edit / Glob / Grep / Sub-agent / 任意 MCP / 并行调用 / 后台任务
- 诚实声明 —— 测试/评估类任务必须在产出报告头部标注：数据来源、是否盲测、潜在污染
- 朴素问题朴素答 —— 用户口语提问时人话回答，不堆结构和小标题
- 立场跟着证据走 —— 新数据来了就更新立场，不是"补充"原立场
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 条（必触发）：
- 完成一个里程碑批次 —— 产出重要交付物，用户可能想审
- Premise 被证伪 —— 任务的根本假设崩了
- 真分叉决策 —— 涉及用户价值观、独有信息、不可逆
扩展 3 条（视情况）：
- 方向不收敛 —— 连续 2 批无新进展
- 意外重大发现 —— 颠覆既有结论的证据
- 需要用户真实数据 —— 无法从公开来源获取
仪式性问题黑名单（不要问）
- ❌ "我这样做对吗" → 你有依据就拍板
- ❌ "用 A 还是 B 工具" → 你自己选
- ❌ "下一批可以这样吗" → 直接干，错了再调
- ❌ "Phase X 你认可吗" → 用户能事后审
- ❌ "你看我拆得对不对" → 直接跑，跑不通再调
判断准则：用户回答"你看着办"AI 还能不能继续？能 → 不该问。
7. 沟通风格切换协议
| 朴素问题信号 | 结构化任务信号 |
|---|
| 口语化（"啊"、"反正"、"嗯"） | 具体指令（"列出"、"梳理"、"写报告"） |
| 重复问句（"那？？？"） | 主动要求 phase / table / 章节 |
| 情绪化标点（"啊？？？？"） | 明确的边界 |
| "就是想知道 / 不是 我..." | "我希望产出 X" |
| "为什么会这样 / 到底..." | "调研 X、对比 Y、整理 Z" |
朴素问题 → 第一句给答案，对话语气，不堆表格小标题
结构化任务 → 用 markdown 标题、表格、编号
报告写文件里，对话给人话。两者分清楚。
8. Sub-agent 戴眼罩协议（评估/盲测必备）
用途：当任务里有"AI 自己不能看到答案才能客观评估"的环节（盲测、独立预测），WebFetch 又会一次性把答案塞进上下文。
协议：
- Spawn sub-agent（用 Agent tool, subagent_type: general-purpose）
- Sub-agent 任务：
- 去搜资料 / 取数据
- 完整数据（包含答案/结果）写入文件 X，主 agent 不读 X
- 在回复里只返回盲化版本
- Sub-agent 必须有诚实协议：绝对不在回复里泄露答案，连暗示都不行
- 主 agent 收到盲化数据 → 先把预测/判断 commit 到文件 Y（禁止先 Read 文件 X）
- 落笔后才能 Read 文件 X 揭晓
- 对照 X 和 Y 打分，写入 results 报告
Sub-agent prompt 模板
你是研究助理 sub-agent。主 agent 正在做 {任务}，需要严格盲测。
你的任务：
1. 从 {建议源} 找 N 个 {案例类型}
2. 每个案例的完整数据（包括 {要被盲化的字段}）写入：
{绝对路径}/blind-data-full.md
3. 在回复里**只返回盲化版本**：{要保留的字段列表}
4. **绝对不要**在回复里包含 {要被盲化的字段} 的任何信息
诚实协议：
- 不要暗示性语言（"这个最后..."、"结果有点意外"）
- 找不到足够多就告诉主 agent 实际几个，不要编造
- 不确定的字段标注"原文未载"
完成后简短汇报来源和数量。
9. 立场更新协议
每批结束强制问自己 3 个问题：
- 本批新证据是否改变了我的核心判断？
- 如果改变了，我是否要明确说"我 update 了立场"，而不是补充？
- 我是否在维护一个不再被新证据支持的旧立场？
立场更新要在 TASK.md §5 假设状态体现，下次汇报明确告诉用户。
10. 八个失败模式 + 预防
| # | 失败模式 | 预防 |
|---|
| F1 | 仪式性问题 | §6 黑名单 + "你看着办测试" |
| F2 | 结构化倾倒 | §7 沟通风格切换 |
| F3 | 不做本体测量靠先验下判 | 评估类任务必须含至少一次实测 |
| F4 | 忘了自动盲测 | 评估类强制走 §8 sub-agent 协议 |
| F5 | 延迟标注污染 | 测试报告头部强制诚实声明 |
| F6 | 队列僵化不重排 | §5 Step 4 强制队列健康检查 |
| F7 | 慢速更新立场 | §9 三问 |
| F8 | 没做 base rate 检查 | 测量类必须对比 random baseline |
11. 最终报告（FINAL-REPORT.md）
任务收尾时产出，必须包含：
- 执行摘要（3-5 行 TL;DR）
- 核心结论 + 证据（如果是研究/评估类，至少 3 条独立证据线）
- 我考虑过的反方理由（诚实地列）
- 方法论局限（样本大小、潜在污染、未覆盖角度）
- 下一步建议
- 可复用的方法论（如果有非显然的发现）
让一个没看过中间过程的人能直接读懂结论。
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 任务结束前跑一遍：
完成所有 checkbox 才算交付。
