何时该做成 Skill

要解决的问题

在 Agent 的日常协作里，很多流程其实是可复用的，但发现这件事的责任默认落在了人身上。结果就是：同一个多步骤任务被交代了一遍又一遍，AI 每次都从零开始；用户在过程中反复纠正同一个错误，却没有机制把它沉淀下来；甚至某个操作被设成了定时任务，执行细节仍散落在脚本和记忆里，没有显式定义。

何时该做成 Skill（元技能） 就是用来补这个缺口的。它不教你怎么技术性地创建 skill（机制已经存在），而是教 AI 识别信号、在合适时机主动提议，把「发现可复用流程」从人类的认知负担转移到 AI 的主动观察上。

核心能力

五个触发信号，命中任意一个就值得考虑固化：

• 重复信号：同一任务被人类交代了第二次。如果第三次还在手动做，算 AI 的失职。
• 多步骤信号：任务涉及 ≥3 步且顺序固定，做完值得提一句「这个流程可以固化」。
• 纠错信号：人类反复纠正同一个错误，说明正确做法该写进 skill，下次不用再纠。
• 模式识别信号：在不同任务里重复执行相同操作模式，比如总是从某格式提取数据再转成另一种格式。
• 定时任务信号：一个操作被设成定时任务时，它的执行流程本身就该是一个 skill。定时任务定义「什么时候做」，skill 定义「怎么做」，两者分离更清晰。

怎么提议比提什么更重要。核心铁律：永远不要先说「skill」这个词。让人类感受到「省事」，而不是「又多了一个技术概念」。任务完成后再提，不要中途打断；用户说「以后再说」就尊重判断，不要反复建议。

落地与边界

人类同意后的步骤：

1. 把命中的触发信号与固化理由写进 skill 的 SKILL.md。
2. 每次完成任务后快速扫描是否命中信号，形成习惯。
3. 命中后用人类友好的语言提议固化，被拒绝就简短回应、不再追问。
4. 同意后按机制实际创建 skill：默认 user-level（~/.workbuddy/skills/），仅当需要团队共享时才用 project-level（.workbuddy/skills/）。

注意边界：不要为了用而用，仅在真正命中触发信号时提议，避免噪音。过度建议会制造反感。这个技能本身的粒度就是一个范例——它只解决「识别 skill 创建时机」这一个具体、可重复的场景，而不是堆砌抽象方法论。