experience-to-skill

name	experience-to-skill
description	将经验提炼为 Skill。当用户分享方法论、工作流程、最佳实践、经验贴，或说"把这个变成 Skill"/"总结一下"时使用。自动执行：理解经验 → 跑通验证 → 复盘正负向 → 封装为 Skill → 安排回溯测试。核心原则：先跑通再封装，不要凭空设计。

经验提炼为 Skill

触发条件

• 用户分享经验贴、方法论、最佳实践
• 用户说"把这个变成 Skill"、"总结成 Skill"、"以后也这样做"
• 用户分享一个可复用的工作流程

核心原则

先跑通，再封装。不是先设计，再验证。

Skill 本质是人把场景 SOP 化的能力。不是设计出来的，是从成功执行中提炼出来的。

四步流程

Step 1: 跑通（Execute）

• 理解经验的核心目标
• 在当前真实场景中执行一遍
• 不求完美，拿到一个认可的结果
• 记录每一步做了什么、遇到什么问题

Step 2: 复盘（Review）

• 哪些流程是正向的（保留）
• 哪些流程是负向的（改进）
• 哪些是浪费时间的（删除）
• 识别当前流程中的 2-3 个关键问题

Step 3: 封装（Package）

• 创建 skills/<skill-name>/SKILL.md
• 遵循三层结构：
  • 第一层：name + description（触发条件，要写清具体场景）
  • 第二层：SKILL.md 主流程（Step by step，可执行）
  • 第三层：参考资料（scripts/assets/references，按需）
• description 要明确告诉模型"什么时候用"，不要写太泛

Step 4: 回溯测试（Backtest）

• 安排下一次触发时验证
• 检查：能否稳定复现？哪里不稳定？
• 不稳定 → 定位问题 → 优化 Skill → 再测
• 稳定 → 标记为可用

Skill 迭代规则

像做产品一样迭代，每个版本只解决一个最关键的问题：

版本	目标
1.0	能不能跑通（60分）
2.0	解决最明显的问题（70分）
3.0	引入高级特性如 subagent（80分）
4.0	减少人工干预，更自动化（90分）

不要一开始就追求完美。先跑起来，一轮轮解决关键问题。

两种场景的处理

1. 用户熟悉的领域 → 经验蒸馏，把用户的经验拆成 AI 能执行的流程
2. 用户不熟悉的领域 → 建立回溯验证机制（能判断对不对才重要）

如果无法建立验证机制（如六爻占卜），坦诚告知用户这个场景不适合 Skill 化。

Skill 目录结构

skills/<skill-name>/
├── SKILL.md          # 主流程（必须）
├── scripts/          # 辅助脚本（可选）
├── assets/           # 素材/模板（可选）
└── references/       # 参考文档（可选）

命名规范

• 目录名：英文短横线分隔，如 knowledge-archive
• SKILL.md 的 name 字段：与目录名一致
• description：一句话说清场景，如"当用户发送知识链接时，自动存档并汇报"

输出汇报

完成封装后，告知用户：

1. 创建了什么 Skill
2. 解决什么问题
3. 下一步回溯测试计划