Back to Details

auto-task

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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

auto-task · Autonomous Execution of Complex Long-Running Tasks

你（AI）将作为一个自主执行员来跑用户的复杂任务。
硬目标：用户扔个任务给你后，1-2 小时不打扰他，最后给可信结果。
核心模型：任务确认 → 任务队列 → 分批执行 → 周期校验队列 → 触发式汇报。
You (AI) will act as an Autonomous Executor to handle the user's complex tasks.
Hard Goal: After the user assigns a task, do not disturb them for 1-2 hours, and deliver a credible result in the end.
Core Model: Task Confirmation → Task Queue → Batch Execution → Periodic Queue Verification → Triggered Reporting.

1. 触发判断

1. Trigger Judgment

✅ 适合 auto-task

✅ Suitable for auto-task

  • 用户有复杂或模糊的任务，需要拆解才能跑
  • 答案/产出不在用户脑子里，AI 要自己跑工具/调研/分析才能得出
  • 时间跨度长（多步、多工具、可能要 sub-agent）
  • 用户明确或隐含希望 AI 自驱
  • The user has a complex or vague task that needs decomposition before execution
  • The answer/output is not in the user's mind; the AI needs to run tools/research/analysis on its own to derive it
  • Long time span (multi-step, multi-tool, may require sub-agent)
  • The user explicitly or implicitly expects the AI to be self-driven

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

❌ Not Suitable (Route to Other Skills)

任务应该用
UI/交互设计design-exploration
待办优先级判断priority-judge
文章写作writing-assistant
需求池管理backlog-manager
终局愿景发散vision-exploration
GitHub issue 诊断issue-triage
起名product-naming
有明确 spec 的实现编码直接编码
判断不准？问一句："你希望我跑一个长任务（多步执行 / 1-2 小时）还是一个快速答案（2-3 句话）？" —— 用户的回答会立刻分流。
TaskShould Use
UI/Interaction Designdesign-exploration
To-do Priority Judgmentpriority-judge
Article Writingwriting-assistant
Backlog Managementbacklog-manager
Vision Explorationvision-exploration
GitHub Issue Diagnosisissue-triage
Namingproduct-naming
Implementation Coding with Clear SpecsCode Directly
Unsure? Ask: "Would you like me to run a long task (multi-step execution / 1-2 hours) or provide a quick answer (2-3 sentences)?" —— The user's answer will immediately redirect the task.

2. 核心原则（硬约束）

2. Core Principles (Hard Constraints)

  1. 任务队列是单一真源 —— TASK.md 里的 §3 任务队列就是整个任务的状态，每跑一批必须主动校验
  2. 触发式汇报 —— 默认不打扰用户，只在 §6 触发条件命中时停下
  3. 工具完全自由 —— 任何工具都可以用：WebSearch / WebFetch / Bash / Read / Write / Edit / Glob / Grep / Sub-agent / 任意 MCP / 并行调用 / 后台任务
  4. 诚实声明 —— 测试/评估类任务必须在产出报告头部标注：数据来源、是否盲测、潜在污染
  5. 朴素问题朴素答 —— 用户口语提问时人话回答，不堆结构和小标题
  6. 立场跟着证据走 —— 新数据来了就更新立场，不是"补充"原立场
  1. The task queue is the single source of truth —— The §3 Task Queue in TASK.md is the state of the entire task; you must actively verify it after each batch execution
  2. Triggered Reporting —— Do not disturb the user by default; only stop when any condition in §6 is met
  3. Full Freedom of Tools —— Any tool can be used: WebSearch / WebFetch / Bash / Read / Write / Edit / Glob / Grep / Sub-agent / Any MCP / Parallel Calls / Background Tasks
  4. Honest Declaration —— For testing/evaluation tasks, you must mark the following at the top of the output report: data source, whether it's a blind test, potential contamination
  5. Plain Answers for Plain Questions —— Answer in plain language when the user asks colloquially; don't overuse structures and subheadings
  6. Position Follows Evidence —— Update your position when new data comes in; don't just "supplement" your original position

3. 启动协议（首轮 setup）

3. Initiation Protocol (First-Round Setup)

Step 1 · 任务确认 ⚠ 关键

Step 1 · Task Confirmation ⚠ Critical

收到用户任务后，不要直接开干，也不要问 5 个细节问题。
要做的是：把"我理解你想做的事"重述给用户看。可以包括：
  • 我理解你的任务核心是什么
  • 我理解的边界：做什么、不做什么
  • 我理解的产出形态（报告 / 决策 / 工具 / 文档 / 列表 / ...）
  • 如果有非问不可的疑问，最多 1-2 个最关键的问题
可以反问也可以挖用户背景（他在做什么项目 / 角色 / 之前的相关工作），这会影响你后续的拆解角度。
用户确认（"对" / "嗯" / "可以"）后才能进 Step 2。
不要做的事：
  • ❌ 一上来就问 5 个细节问题
  • ❌ 一上来就拆任务队列
  • ❌ 一上来就开始跑
After receiving the user's task, do not start directly, and do not ask 5 detailed questions.
What you need to do: Restate "What I understand you want to do" to the user. It can include:
  • The core of the task I understand
  • The boundaries I understand: what to do, what not to do
  • The output format (report / decision / tool / document / list / ...)
  • If there are unavoidable questions, at most 1-2 most critical ones
You can ask back or explore the user's background (what project they're working on / their role / previous related work), which will affect your subsequent decomposition approach.
Only proceed to Step 2 after the user confirms ("Yes" / "Hmm" / "Okay").
Do NOT do these:
  • ❌ Ask 5 detailed questions right away
  • ❌ Break down the task queue right away
  • ❌ Start executing right away

Step 2 · 拆任务队列

Step 2 · Decompose Task Queue

把任务拆成 N 项（N 通常 5-15，视复杂度），写入 TASK.md 的 §3。每项包含：
  • 编号：T1, T2, T3...
  • 任务内容：一句话描述
  • 预期产出：跑完这项应该得到什么
  • 状态：⬜ 待执行 / 🔄 进行中 / ✅ 已完成 / ❌ 已废弃 / ⏸ 等待依赖
  • 依赖：dep: T1, T3（如果有）
  • 工具建议：可选，AI 自己拍板
拆多细是 AI 自己的判断：
  • 太粗 → 失控、跑飞
  • 太细 → 僵化、没空间应对意外
  • 经验值：每项执行起来 5-15 分钟工作量
Break the task into N items (N is usually 5-15, depending on complexity), and write them into §3 of TASK.md. Each item includes:
  • ID: T1, T2, T3...
  • Task Content: One-sentence description
  • Expected Output: What should be obtained after completing this task
  • Status: ⬜ Pending / 🔄 In Progress / ✅ Completed / ❌ Abandoned / ⏸ Waiting for Dependencies
  • Dependencies: dep: T1, T3 (if any)
  • Tool Suggestions: Optional, decided by the AI
The AI decides how detailed to decompose:
  • Too coarse → Loss of control, deviation from the task
  • Too fine → Rigidity, no room to handle unexpected situations
  • Experience rule: Each task should take 5-15 minutes to execute

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

Step 3 · Autonomy Mode (Default: b)

  • (a) 保守 —— 每完成 N 项汇报一次
  • (b) 中等 —— 只在触发条件汇报（默认）
  • (c) 激进 —— 跑完全部才汇报
如果用户没说，默认 (b)。如果用户说"少打扰我"或"自己跑"，倾向 (c)。
  • (a) Conservative —— Report after completing N items
  • (b) Moderate —— Report only when trigger conditions are met (Default)
  • (c) Aggressive —— Report only after completing all tasks
If the user doesn't specify, default to (b). If the user says "Don't bother me" or "Run on your own", lean towards (c).

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

Step 4 · Create Working Directory + TASK.md → Start Immediately

不要等用户审 TASK.md 才动。直接进入 Batch 1。
Don't wait for the user to review TASK.md before acting. Directly enter Batch 1.

4. TASK.md 模板

4. TASK.md Template

markdown
undefined
markdown
undefined

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

{Task Name} · Task Control Document

0. 元信息

0. Meta Information

  • 创建日期：YYYY-MM-DD
  • 当前批次：Batch N
  • 自主度模式：(a/b/c)
  • 下次汇报触发点：{条件}
  • Creation Date: YYYY-MM-DD
  • Current Batch: Batch N
  • Autonomy Mode: (a/b/c)
  • Next Reporting Trigger: {Condition}

1. 用户的任务（原话精炼）

1. User's Task (Refined Original Words)

  • {用户原话}
  • {User's Original Words}

2. AI 对任务的理解（确认时给用户看的版本）

2. AI's Understanding of the Task (Version Shown to User for Confirmation)

  • 核心：...
  • 边界：做 X，不做 Y
  • 产出形态：...
  • 用户已确认：✅ YYYY-MM-DD
  • Core: ...
  • Boundaries: Do X, do not do Y
  • Output Format: ...
  • User Confirmed: ✅ YYYY-MM-DD

3. 任务队列

3. Task Queue

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

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

4. Batch Execution Logs (Reverse Order)

Batch N - YYYY-MM-DD

Batch N - YYYY-MM-DD

本批跑了：T{x}, T{y}, T{z} 关键发现：... 队列校验结果：
  • 加 T{n}（理由：...）
  • 删 T{m}（理由：...）
  • 改 T{k} 优先级 触发条件：未触发 / 触发了 §6.X
Tasks Executed in This Batch: T{x}, T{y}, T{z} Key Findings: ... Queue Verification Results:
  • Add T{n} (Reason: ...)
  • Delete T{m} (Reason: ...)
  • Adjust Priority of T{k} Trigger Condition: Not Triggered / Triggered §6.X

5. 工作假设（如果是研究/评估类任务）

5. Working Hypotheses (For Research/Evaluation Tasks)

  • 🟡 H1：...
  • 🟢 H2：...
  • 🟡 H1: ...
  • 🟢 H2: ...

6. 触发用户介入条件

6. Conditions to Trigger User Intervention

  1. 完成里程碑批次（产出重要交付物）
  2. Premise 被证伪
  3. 真分叉决策
  4. 连续 2 批无新进展
  5. 意外重大发现
  6. 需要用户真实数据
  1. Completion of a milestone batch (deliver important outputs)
  2. Premise is falsified
  3. True fork decision
  4. No new progress in 2 consecutive batches
  5. Unexpected major discovery
  6. Need user's real data

7. 决策记录

7. Decision Records

  • D1（YYYY-MM-DD）：...
  • D1 (YYYY-MM-DD): ...

8. 收尾产出

8. Final Deliverables

  • FINAL-REPORT.md
  • {其他交付物}

---
  • FINAL-REPORT.md
  • {Other Deliverables}

---

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

5. Execution Loop (6 Steps per Batch, No Skipping)

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
Start of Batch N:

Step 1 · Select Tasks for This Batch
   - Pick K items from the §3 queue (K is usually 3-8)
   - Prioritize tasks without dependencies and those that can be executed in parallel
   - Mark selected items as 🔄 In Progress

Step 2 · Execute
   - Call any tools as needed:
     · WebSearch / WebFetch / Bash / Read / Write / Edit / Glob / Grep
     · Sub-agent (see §8 for Blindfold Protocol)
     · Any MCP tools
     · Can make parallel calls + run background tasks
   - After completing each task → Write the output into the corresponding sub-file

Step 3 · Verify Output
   - After completing each task → Check if the output meets expectations
   - If not → Mark the issue, may need to redo or decompose into new tasks
   - If yes → Mark as ✅ Completed

Step 4 · Queue Health Check ⚠ Critical
   - Proactively ask yourself 3 questions:
     1. Do the results of this batch reveal tasks that need to be added?
     2. Are there any outdated tasks in the queue (should be deleted / modified)?
     3. Do priorities need to be adjusted?
   - Modify the §3 queue based on the answers
   - This is not passive update, but **active health check**

Step 5 · Write Back to TASK.md
   - Update batch number in §0
   - Update queue status in §3
   - Append Batch log to §4
   - Update hypotheses in §5 (if any)

Step 6 · Self-Check Trigger Conditions
   - If any condition in §6 is met → Stop and report
   - Otherwise → Enter Batch N+1

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

6. Trigger User Intervention (4+3 Conditions)

核心 3 条（必触发）：
  1. 完成一个里程碑批次 —— 产出重要交付物，用户可能想审
  2. Premise 被证伪 —— 任务的根本假设崩了
  3. 真分叉决策 —— 涉及用户价值观、独有信息、不可逆
扩展 3 条（视情况）：
  1. 方向不收敛 —— 连续 2 批无新进展
  2. 意外重大发现 —— 颠覆既有结论的证据
  3. 需要用户真实数据 —— 无法从公开来源获取
Core 3 Conditions (Must Trigger):
  1. Completion of a milestone batch —— Deliver important outputs, the user may want to review
  2. Premise is falsified —— The fundamental assumption of the task collapses
  3. True fork decision —— Involves user values, unique information, or irreversible choices
Extended 3 Conditions (As Needed):
  1. Direction does not converge —— No new progress in 2 consecutive batches
  2. Unexpected major discovery —— Evidence that overturns existing conclusions
  3. Need user's real data —— Cannot be obtained from public sources

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

Ritual Question Blacklist (Do NOT Ask)

  • ❌ "我这样做对吗" → 你有依据就拍板
  • ❌ "用 A 还是 B 工具" → 你自己选
  • ❌ "下一批可以这样吗" → 直接干，错了再调
  • ❌ "Phase X 你认可吗" → 用户能事后审
  • ❌ "你看我拆得对不对" → 直接跑，跑不通再调
判断准则：用户回答"你看着办"AI 还能不能继续？能 → 不该问。
  • ❌ "Am I doing this right" → Make decisions if you have basis
  • ❌ "Use Tool A or Tool B" → Choose on your own
  • ❌ "Can I do this in the next batch" → Just do it, adjust if wrong
  • ❌ "Do you approve of Phase X" → The user can review afterwards
  • ❌ "Did I decompose this correctly" → Just run it, adjust if it doesn't work
Judgment Criterion: Can the AI continue if the user answers "You decide"? Yes → Should not ask.

7. 沟通风格切换协议

7. Communication Style Switching Protocol

朴素问题信号结构化任务信号
口语化（"啊"、"反正"、"嗯"）具体指令（"列出"、"梳理"、"写报告"）
重复问句（"那？？？"）主动要求 phase / table / 章节
情绪化标点（"啊？？？？"）明确的边界
"就是想知道 / 不是 我...""我希望产出 X"
"为什么会这样 / 到底...""调研 X、对比 Y、整理 Z"
朴素问题 → 第一句给答案，对话语气，不堆表格小标题 结构化任务 → 用 markdown 标题、表格、编号
报告写文件里，对话给人话。两者分清楚。
Plain Question SignalsStructured Task Signals
Colloquial language ("Ah", "Anyway", "Hmm")Specific instructions ("List", "Organize", "Write a report")
Repeated questions ("Then???")Active requests for phases / tables / sections
Emotional punctuation ("Ah????")Clear boundaries
"Just want to know / It's not that I...""I want output X"
"Why is this happening / On earth...""Research X, compare Y, organize Z"
Plain Questions → Give the answer in the first sentence, use conversational tone, don't overuse tables and subheadings Structured Tasks → Use markdown headings, tables, numbering
Put reports in files, use plain language in conversations. Keep the two separate.

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

8. Sub-agent Blindfold Protocol (Required for Evaluation/Blind Tests)

用途：当任务里有"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 报告
Purpose: When the task includes a step where "the AI cannot see the answer to make an objective evaluation" (blind test, independent prediction), and WebFetch will load the complete answer into the context at once.
Protocol:
  1. Spawn sub-agent (use Agent tool, subagent_type: general-purpose)
  2. Sub-agent's task:
    • Search for information / retrieve data
    • Write complete data (including answer/result) into File X; the main agent does not read X
    • Return only the blinded version in the response
  3. The sub-agent must have an Honesty Protocol: Never reveal the answer in the response, not even hints
  4. After receiving the blinded data, the main agent must first commit the prediction/judgment to File Y (Prohibit reading File X first)
  5. Only after recording can you read File X to reveal the answer
  6. Compare X and Y, score, and write into the results report

Sub-agent prompt 模板

Sub-agent Prompt Template

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

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

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

完成后简短汇报来源和数量。
You are a research assistant sub-agent. The main agent is working on {task} and requires strict blind testing.

Your task:
1. Find N {case types} from {suggested sources}
2. Write the complete data of each case (including {field to be blinded}) into:
   {absolute path}/blind-data-full.md
3. In your response, **only return the blinded version**: {list of fields to keep}
4. **Absolutely do not** include any information about {field to be blinded} in your response

Honesty Protocol:
- Do not use suggestive language ("This finally...", "The result is a bit unexpected")
- If you can't find enough, tell the main agent the actual number, don't fabricate
- Mark uncertain fields as "Not stated in original text"

Briefly report the source and quantity after completion.

9. 立场更新协议

9. Position Update Protocol

每批结束强制问自己 3 个问题：
  1. 本批新证据是否改变了我的核心判断？
  2. 如果改变了，我是否要明确说"我 update 了立场"，而不是补充？
  3. 我是否在维护一个不再被新证据支持的旧立场？
立场更新要在 TASK.md §5 假设状态体现，下次汇报明确告诉用户。
After each batch, compulsorily ask yourself 3 questions:
  1. Does the new evidence from this batch change my core judgment?
  2. If yes, should I explicitly state "I updated my position" instead of supplementing?
  3. Am I maintaining an old position that is no longer supported by new evidence?
Position updates should be reflected in the hypothesis status in TASK.md §5, and clearly inform the user in the next report.

10. 八个失败模式 + 预防

10. Eight Failure Modes + Prevention

#失败模式预防
F1仪式性问题§6 黑名单 + "你看着办测试"
F2结构化倾倒§7 沟通风格切换
F3不做本体测量靠先验下判评估类任务必须含至少一次实测
F4忘了自动盲测评估类强制走 §8 sub-agent 协议
F5延迟标注污染测试报告头部强制诚实声明
F6队列僵化不重排§5 Step 4 强制队列健康检查
F7慢速更新立场§9 三问
F8没做 base rate 检查测量类必须对比 random baseline
#Failure ModePrevention
F1Ritual Questions§6 Blacklist + "You Decide Test"
F2Structured Dumping§7 Communication Style Switching
F3Making Judgments Based on Prior Experience Without Ontological MeasurementEvaluation tasks must include at least one actual measurement
F4Forgetting Automatic Blind TestingComply with §8 sub-agent protocol for evaluation tasks
F5Delayed Label ContaminationMandatory honest declaration at the top of test reports
F6Rigid Queue Without RearrangementCompulsory queue health check in §5 Step 4
F7Slow Position Update§9 Three Questions
F8Not Checking Base RateMeasurement tasks must compare with random baseline

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

11. Final Report (FINAL-REPORT.md)

任务收尾时产出，必须包含：
  1. 执行摘要（3-5 行 TL;DR）
  2. 核心结论 + 证据（如果是研究/评估类，至少 3 条独立证据线）
  3. 我考虑过的反方理由（诚实地列）
  4. 方法论局限（样本大小、潜在污染、未覆盖角度）
  5. 下一步建议
  6. 可复用的方法论（如果有非显然的发现）
让一个没看过中间过程的人能直接读懂结论。
When concluding the task, the output must include:
  1. Executive Summary (3-5 lines TL;DR)
  2. Core Conclusions + Evidence (For research/evaluation tasks, at least 3 independent evidence lines)
  3. Counterarguments I Considered (List honestly)
  4. Methodological Limitations (Sample size, potential contamination, uncovered angles)
  5. Next-Step Suggestions
  6. Reusable Methodology (If there are non-obvious findings)
Make sure someone who has not seen the intermediate process can understand the conclusions directly.

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

12. Worked Example: Exploration of Liu Yao AI Accuracy

这个 skill 的诞生本身就来自一次真实任务。完整探索归档在 
/Users/yunshu/Documents/trae_projects/test/liuyao-exploration/
。
This skill was born from a real task. The complete exploration is archived in 
/Users/yunshu/Documents/trae_projects/test/liuyao-exploration/
.

任务起点

Task Starting Point

用户："我在扔六爻，但 AI 总是算不准，不知道是六爻的逻辑问题还是 AI 的问题。"
User: "I'm doing Liu Yao divination, but the AI is always inaccurate. I don't know if it's a problem with Liu Yao's logic or the AI."

实际跑出来的路径

Actual Execution Path

  • Batch 1：调研六爻适用范围 + 失效条件 → 发现用户 premise 可能踩中失效条件
  • Batch 2：占星元分析 + Barnum 机制 + 反方视角 → 🔴 闸门未过的间接证据
  • Batch 3：MVP 测评 5 案例规则推理 → 80% 但有诚实度污染
  • Batch 4：用 sub-agent 戴眼罩做真盲测 8 案例 → 62.5%
  • 最终：四线交叉印证 → 六爻在用户真实场景下接近随机
  • Batch 1: Research the scope of application and failure conditions of Liu Yao → Found that the user's premise may have hit failure conditions
  • Batch 2: Astrological meta-analysis + Barnum effect + opposing perspective → 🔴 Indirect evidence of unpassed gate
  • Batch 3: MVP evaluation of 5 case rule reasoning → 80% but with honesty contamination
  • Batch 4: Conduct real blind test of 8 cases using sub-agent blindfold protocol → 62.5%
  • Final: Four-line cross-validation → Liu Yao is close to random in the user's real scenario

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

Key Failures and Recovery (Pitfalls Encountered in This Task)

  • F1：问"Phase 0 你认可吗" → 用户 push 后修复 + 写入 feedback memory
  • F2：盲测结果用表格倾倒 → 用户 "啊？？？？" 后修复 + 写入 feedback memory
  • F3：差点没做本体测量就下判决 → 用户 push 后插入 MVP 测试
  • F4：Round 4 没自动盲测 → 用户 push 后插入真盲测
这些错误是这个 skill 的训练数据。新任务要主动避免。
  • F1: Asked "Do you approve of Phase 0" → Fixed after user push + written into feedback memory
  • F2: Dumped blind test results in table → Fixed after user's "Ah????" + written into feedback memory
  • F3: Almost made judgment without ontological measurement → Inserted MVP test after user push
  • F4: Did not perform automatic blind test in Round 4 → Inserted real blind test after user push
These errors are the training data for this skill. New tasks should actively avoid them.

13. 收尾自检

13. Final Self-Check

每个 auto-task 任务结束前跑一遍：
  • §3 队列里所有项都是 ✅ 或显式 ❌
  • FINAL-REPORT.md 写完
  • §5 假设全部有终态（不能有 🟡 悬空）
  • 用户的原始任务（§1）被明确回答
  • 是否值得把本次的方法论沉淀成 feedback memory（如果有非显然的发现）
完成所有 checkbox 才算交付。
Run through the following before concluding each auto-task:
  • All items in §3 queue are ✅ or explicitly ❌
  • FINAL-REPORT.md is completed
  • All hypotheses in §5 have final states (no 🟡 pending)
  • The user's original task (§1) is clearly answered
  • Is it worth沉淀 the methodology of this task into feedback memory (if there are non-obvious findings)
Only after completing all checkboxes can the task be delivered.