这个 GitHub 爆火的文件规划 Skill 到底能干嘛？实测来了

1. task_plan.md — 任务计划#

这是你的”导航仪”。它记录：

• 任务目标（Goal）
• 阶段划分（Phases），每个阶段标记为 [ ]（未完成）或 [x]（已完成）
• 关键问题（Key Questions）
• 已做出的决策（Decisions Made）
• 遇到的错误（Errors Encountered）

2. findings.md — 研究发现#

这是你的”笔记本”。所有研究过程中发现的内容都写到这里：

• 搜索结果摘要
• 代码分析结论
• API 文档要点
• 设计决策理由

3. progress.md — 进度日志#

这是你的”操作日志”。实时记录：

• 每个操作做了什么
• 测试结果
• 临时想法

🎯 “两步规则”（The 2-Action Rule）#

每进行 2 次浏览/搜索操作后，立即将关键发现保存到文本文件。

这个规则解决了一个痛点：Agent 用浏览器看了 10 个网页，结果第 11 步时已经把前面 10 个网页的内容全忘了。两步规则强制 Agent 定期”存档”，确保信息不丢失。

🔄 “决策前重读计划”模式#

这是 Manus 能执行约 50 次工具调用而不迷失方向的核心秘诀：

1
[已经执行了很多工具调用...]
2
[上下文变得越来越长...]
3
[原始目标可能已经被遗忘了...]
4

5
→ 读取 task_plan.md          ← 这步让目标重新进入注意力窗口！
6
→ 现在做决策                 ← 目标是新鲜的

就像一个飞行员在长途飞行中时不时看一眼导航仪一样。

🛡️ “三次失败协议”#

Agent 犯错不可怕，可怕的是重复犯同样的错。这个 Skill 定义了一个清晰的错误处理流程：

1
第 1 次：诊断并修复（针对性）
2
第 2 次：换方法/换工具/换库（替代方案）
3
第 3 次：质疑假设、搜索方案、更新计划（重新思考）
4
3 次后：升级给用户，说明尝试过什么

📊 读 vs 写决策矩阵#

什么时候该读？什么时候该写？Skill 里有一张清晰的决策矩阵：

场景 1：研究任务#

“调研一下 Next.js 15 的新特性，写一份总结”

Agent 会：

1. 先创建 task_plan.md，列出要调研的方向
2. 搜索每个方向，把结果写入 findings.md
3. 综合所有发现，写总结文档
4. 更新 task_plan.md 标记完成

场景 2：Bug 修复#

“修复登录模块的 Bug”

Agent 会：

1. 创建计划，列出排查步骤
2. 定位代码，记录发现
3. 尝试修复，记录每次错误
4. 验证修复，标记完成

场景 3：功能开发#

“给设置页面加一个深色模式切换”

Agent 会：

1. 先调研现有主题系统，写入 findings.md
2. 制定实施计划到 task_plan.md
3. 分阶段实现，每完成一步更新进度
4. 测试验证，交付成果

✅ 适合用#

• 多步骤任务（3 步以上）
• 研究类任务（需要大量信息搜集）
• 构建/创建项目（需要规划架构）
• 需要大量工具调用的长任务
• 任何需要”保持方向感”的任务

❌ 不适合用#

• 简单问答（“这个函数什么意思？”）
• 单文件小修改（“把这个变量名改一下”）
• 快速查找（“帮我找一下配置文件在哪”）