Appearance
什么时候把任务沉淀成 Skill
第四部 · Skill · 第42章
撰写日期：2026-07-13
结论
Skill 评估框架 讲的是"一个 Skill 好不好"。这篇讲更靠前的两个决定：要不要把这件事做成 Skill，以及做了之后怎么保证它真的会被触发。
Twice, Skill——同一类操作做到第二次，就值得沉淀。而
description是运行时被自动匹配的唯一依据，宁可覆盖过宽，也别欠触发。
1. 触发线：重复两次
| 次数 | 判断 |
|---|---|
| 第一次 | 照做。模式还没显现，此时抽象容易把接口做错 |
| 第二次 | 沉淀成 Skill / 脚本。重复成本已被实证，模式也清晰到可抽象 |
| 第三次及以后 | 如果还没沉淀，纯属在浪费重复劳动 |
"第二次"是重复成本已被验证、且模式刚好清晰的最早时点：早于此，容易做错抽象；晚于此，重复劳动已经白费。不要等"以后可能常用"的模糊预感——那个预感常常是错的。
2. description 决定生死
Skill 会不会被调起，取决于 description 和当前请求的自动匹配。这里的偏置很明确：
欠触发的代价远大于偶尔误触发。欠触发 = 把"用最新能力解决问题"的机会，让位给了过时的默认行为，而且你根本不会发现它本该触发。
所以 description 要：
- 穷举自然语言触发说法——同一个意图用户会怎么说，尽量列全，包括口语和同义表达；
- 写清不适用场景——用边界防误触发，比把描述写窄更可控；
- 具体到关键词和任务，而不是笼统一句"处理某类问题"。
3. Skill 还是留作一次性 Prompt
不是所有重复都值得封装。对照 Skill 评估框架 里的 D 级：
| 情况 | 归宿 |
|---|---|
| 有稳定流程、明确输入输出、可验证、会反复用 | 沉淀为 Skill |
| 逻辑简单、每次都要人临场解释才能跑对、复用面窄 | 留作普通 Prompt 即可 |
Skill 化的主要成本是维护（它会一直在，写偏了会一直误触发或该触发不触发）；收益是复用时的确定性。当收益（确定性）已经被"第二次"实证、且流程稳定到能写清触发边界，就该沉淀。
我的判断
判断要不要做 Skill，用"重复两次"这条硬线，避免过早抽象和过度封装；判断做完管不管用，先看 description 覆盖够不够宽。把这两个决定分开，比纠结"这个够不够格当 Skill"更实用。