做内容、写产品、带团队的这些年，我跟 AI 的关系经历了“蜜月—抱怨—复婚”的循环。蜜月期全靠提示词工程，讲明身份、风格、步骤，AI 就能干活；抱怨期每次开新对话都要重复“你是一位资深XX”，像在对着失忆的临时工复述 SOP；复婚，是我把这套经验塞进了一个更像“长期工”的容器——Skill。

Skill 的本质：不是黑科技，是把经验结构化

我喜欢用一个很生活化的比喻：招了个聪明的实习生，第一次手把手教写会议纪要，效果不错；第二次又忘了，只能再教一遍。要么你决定写一份清晰得不行的“工作说明书”，摆在他桌上，他再来翻一下就会做。这个“说明书”，就是 SKILL.md。

技术形态几乎极简：

• 一个文件夹，承载你这门手艺的资料。
• 一个 SKILL.md，写清两件事——
  • 什么时候该用：触发条件、适用范围、反触发（不适用的情况）。
  • 具体怎么做：步骤、规则、注意事项、输出格式、质量标准。

对 AI 而言，这不是“神奇提示”，而是“可复用的工作说明书”。对你而言，这是把个人经验沉淀成可移植资产。

它和普通 Prompt 的真正差别：复用与上下文效率

多数人对比的视角停留在“写得更长更细”。可真正的分水岭只一个词：复用。

• 提示词是一次性的，像飞到空中的口令，说完就散，下次还得找、得粘。
• Skill 是常驻的，摆在系统里等待被触发，不需要你每次“自我介绍”。

更隐蔽但更致命的差别是上下文管理。大模型的上下文再大，也怕“指令汤”。把所有提示塞进来，容易互相干扰，推理也会被噪声牵着走。Skill 的正确打开方式是“渐进式加载”：

• 未触发时，只保留 Skill 的名称与一句话用途（十几到几十字）。
• 触发后，加载完整的 SKILL.md。
• 执行到具体步骤，再按需读取参考资料。

像手机 App 不打开就不占内存。这套机制让我可以在同一个工作区挂几十个 Skill，互不打架，按需激活。

顺带一提，Skill 和“记忆”不是一回事。记忆更像个人偏好与事实档案（我叫啥、公司风格偏好），Skill 则是可执行的 SOP。二者相互补位，别混在一起。

真实场景里，Skill 如何把“临时工”变“长期工”？

我这两年在内容和产品上跑过一批 Skill，味道很对：

• 公众号写作：风格词表、禁用词、段落结构、引用规范写进 Skill。每次丢一句“写一篇 XXX 的深度稿”，风格稳定，合规不踩雷。
• 封面图生成：七种模板、配色、构图规范放进资料夹，Skill 只接受主题与受众两个输入。不再来回形容“极简风、对称构图”。
• 选题机制：关注方向、搜索路径、评估维度、输出卡片格式全封装。给一句“本周 B 端增长相关选题”，自动搜集、筛选、打分，产出候选池。
• 用户访谈整编：定义抽取字段、冲突合并逻辑、证据链要求，自动生成洞察和反假设列表。
• 代码评审辅助：限定只看改动范围，按风险等级输出意见，禁止“风格之争”，避免嘴炮。
• 数据分析：输入数据字典与指标口径，固定分析流程，输出包括异常解释与后续实验建议的报告。

本质上，这是把“我会如何做、怎么判断好坏、遇到坑如何兜底”翻译成机器可执行的步骤。经验越具体，AI 越像你。

写第一个 Skill，用不上半天

从那件你一周至少复述两次的任务开始就好。给你一个轻量模板，照着写：

# SKILL: 公号稿件生成

【意图与触发】
- 适用：需要生成面向职场读者的深度稿（1500-2500字）
- 触发信号：包含“写稿/深度/行业/读者画像”等关键词
- 不适用：纯口播文案、硬广、诗歌

【输入要求】
- 主题：一句话
- 目标读者：一句话
- 立场：正向/中立/反向
- 必带素材：若干要点（可为空）

【输出格式】
- 标题（3个备选，含角度说明）
- 大纲（3级）
- 正文（含小标题）
- 参考与引用（列表，保留原链接）
- 自查清单（是否触发禁用词、是否含可验证数据）

【写作流程】
1. 校对输入 → 复述需求 → 澄清缺失项（最多2条）
2. 生成大纲 → 与禁用词表对照 → 如冲突则调整
3. 按段落写作，严格遵循“观点-证据-反驳-结论”
4. 收尾加自查清单与引用

【禁用词与风格】
- 禁用：夸大承诺、贬损性形容、模糊时间表达
- 风格：克制、有证据、短句优先，避免口头禅

【质量标准】
- 事实可追溯（至少2个外部引用）
- 段落平均长度 < 120 字
- 结论可落地（含下一步行动建议）

【失败模式与补救】
- 如素材不足 → 先产出大纲并列出“待补证据”清单
- 如主题过宽 → 提议收窄的两个角度，征询选择

先用起来，别追求一稿封神。每次偏了就补两行，流程冗余就删一段。迭代三四轮，稳定度会明显提升。

让 Skill 真正可用的工程化细节

很多人卡在“写了个说明书，但跑着跑着就散了”。我更看重以下几个工程环节：

• 命名规范与目录结构：Skill 名字要像动词短语（draft_blog、score_leads），资料放在 /references，例子放在 /examples，版本号写在头部。
• 正负触发：把“不触发”的条件写清，减少误激活；再补充 3-5 条正反例子。
• 输入/输出 Schema：像写接口文档一样约束字段，这比长篇说教更能稳住模型。
• 质检自评：在输出尾部自查关键项（是否覆盖要求、是否含引用、是否越权）。
• 版本化与回滚：改动大规则前先分支验证，保留 changelog。
• 评测集与 A/B：挑10个典型任务做回归测试，量化通过率与修改成本。
• 冲突治理：多 Skill 并存时，声明优先级与互斥关系，减少“指令打架”。
• 隐私与合规：资料分级，敏感数据只给需要的 Skill；输出里自动做脱敏检查。

用什么工具更顺手？

如果你想直接上手，我会推荐把 Skill 管理起来再用。我这边常用的是 腾讯 workbuddy，上手门槛低，写 Skill 就像填表，触发逻辑、资料挂载、版本管理都比较顺滑。懒得折腾时，几句话就能把一个 SOP 跑起来。谷歌工程团队的 Superpowers（获得大量开发者认可的项目）走的也是这条路：把资深工程师的最佳实践沉淀为可执行的 Skill，团队成员共享，协作效率显著提升。

常见坑与应对

• 触发太宽：动不动就激活，结果产出不对题。加“反触发示例”立刻见效。
• 指令汤：规则越写越多，互相矛盾。上 Schema、拆步骤、移出非关键装饰语。
• 输出失控：字数爆炸或跑题。硬性限制段落与字数，设置“清单式收尾”。
• 资料腐烂：引用失效、口径变动。给 reference 加日期与来源，定期巡检。
• 与记忆混淆：把个人偏好塞进每个 Skill。把偏好放“记忆层”，Skill 只保留通用规则。

什么时候不需要 Skill？

探索式、一次性任务，或者你本人也没想清楚要啥，只是需要“碰撞灵感”。这时开个干净对话、丢几句 prompt 足够。等模式稳定了，再抽象成 Skill，收益才大。

一句收尾：别让经验只活在嘴上

Skill 的门槛不在技术，而在你是否愿意把“凭感觉”拆成可复用的结构。我常对团队说：哪件事你还在每周反复跟 AI 交代？那就是你的第一个 Skill 起点。写个 SKILL.md，把自己装进去，一次把话说明白。你会惊讶，AI 突然像个靠谱同事。

去试一件小事，哪怕是“每周选题卡”。等它稳定产出，你就再也回不去一遍遍粘贴提示词的日子了。