什么是 Skill：把 AI 从“会说”变成“会做”的可维护能力包
TL;DR：
- Skill：把“做一类事的最佳实践”封装成可维护的能力包（说明书 + 脚本 + 资源）。
- 为什么现在重要：AI 开始进入真实生产流程，大家需要稳定、可复用、可审计的产出，而不只是一次性的 Prompt。
- 读完你能获得：搞清楚 Skill / Tool / MCP 的区别，并能照着做出你的第一个 Skill（附目录结构与示例）。
过去两年，我们见证了 LLM 从“聊天”走向“干活”：从 Prompt 工程、到 Function Calling、再到工具协议（如 MCP），工程化能力越来越强。但很多团队很快遇到同一个问题：能调用工具 ≠ 能稳定把事情做对。
Skill（技能/能力包）之所以突然火热，本质上是在解决“把 AI 纳入流程”的问题：把“如何完成某类任务的 SOP/Runbook”沉淀下来，让模型按需加载并遵循。
1）先从一个真实场景说起：内容运营流水线
假设你是掘金上的普通创作者（或者团队运营号），每周要稳定产出一篇 AI 技术文章。你会发现最痛的不是“写不出来”，而是：
- 选题容易跑偏、同类文章重复；
- 资料检索不系统，引用不规范；
- 草稿结构不稳定，每次排版都重来；
- 发完后互动（评论、收藏、点赞）没有节奏。
如果只靠 Prompt，你大概率会：每次重新描述需求、重新提醒格式、重新补约束。于是“经验”散落在对话里，很难复用。
Skill 的价值就在这里：把整套流程写成一个能力包。
举个最小可用版本（MVP）的 Skill：
- 输入：
本周选题：Claude Skills / MCP / Agent 工程化+目标读者：掘金普通工程师 - 输出：
文章大纲+参考链接清单+草稿 Markdown+发布前检查清单
这样你每周只需要给“变量”，流程本身由 Skill 固化。
2）Skill 是什么？
一句话定义：Skill 是可被语义触发的能力包，包含领域知识、执行步骤、输出规范与约束条件。
一个 Skill 通常是一个文件夹，里面至少包含：
SKILL.md：说明书（何时用、怎么用、注意事项、输出格式）scripts/：脚本（需要“动手”时执行）references/：参考资料/模板（让经验可维护）
你可以把 Skill 理解成：
公司规章制度 + 操作手册 + 工具箱。
3）为什么 Skill 会火？（更“工程化”的理由）
我认为主要有四个推动力：
(1) 复用与维护需求爆发
当 AI 进入团队协作后，“口口相传的 Prompt”会失控。Skill 把最佳实践变成可审查资产：能评审、能迭代、能版本化。
(2) 上下文越来越贵
长对话容易漂移、也更贵。Skill 的“按需加载”减少上下文污染：需要的时候再把规则注入。
(3) 一致性与审计要求更高
AI 参与到发版、运维、数据同步时，容错率变低。Skill 通过步骤化、结构化的护栏提高一致性，并更容易复盘。
(4) 生态推动：能力包开始可分发
当出现“技能市场/仓库”（例如 Claude Skills 与类似 clawhub 这样的分发平台）后，Skill 会像 npm 包一样被复用、安装、更新，热度自然会被推高。
4）Skill vs Tool vs MCP：到底有什么不同？
4.1 Tool：一个动作按钮
- Tool 更像一把“锤子”：执行一个明确动作（查日历、写表格、发请求、跑脚本）。
- 它解决的是“能不能做某个动作”。
4.2 MCP：统一工具的“插座标准”
- MCP 更像“工具协议/接口标准”：让不同系统的工具以统一方式被模型调用。
- 它解决的是“工具怎么接入、怎么互操作”。
4.3 Skill：把动作组织成流程的“施工方案”
- Skill 更像一套“施工方案”：把多个 Tool + 规则 + 输出格式组织成稳定流程。
- 它解决的是“怎么稳定做对一类事”。
一句话总结：
- Tool 负责“做动作”
- MCP 负责“让动作接得上”
- Skill 负责“把动作串成 SOP，并保证产出一致”
5）推荐 8 个我觉得投入产出比极高的 Skill（附典型输入→输出）
下面我用“你今天就能用起来”的方式来写。
- 文档生成与规范化（create-doc / update-doc）
- 输入：
把这段会议记录整理成 PRD，并生成到文档 - 输出：
结构化 PRD（含标题、背景、目标、方案、风险、TODO）
- 日程/会议自动化（calendar）
- 输入：
下周三 14:00-15:00 和张三对齐需求，提醒提前 10 分钟 - 输出：
日程创建 + 视频会议链接 + 提醒设置
- 任务拆解与追踪（task）
- 输入：
把“上线 A 功能”拆成任务，给出负责人/截止时间/依赖 - 输出：
可执行任务清单（可直接落到任务系统）
- 知识库检索与归档（doc/wiki search + fetch）
- 输入：
找一下我们之前关于 MCP 的方案，给我 5 条结论并附引用 - 输出：
结论摘要 + 来源链接/引用
- 多维表格/数据台账自动化（bitable）
- 输入：
把本周 10 个选题写入内容排期表，标记负责人和状态 - 输出：
台账自动更新 + 状态流转
- 消息审计与关键信息回溯（im-read）
- 输入：
上周群里关于“Claude Code 源码泄露”的结论是什么？ - 输出：
关键消息串联 + 结论摘要
- 故障排查 Runbook（troubleshoot）
- 输入：
授权失败/接口 400/权限异常，按 Runbook 给排查步骤 - 输出：
排查步骤 + 可验证结论 + 修复建议
- 内容运营流水线（juejin-user）
- 输入：
为“技能系统/Agent 工程化”生成草稿，发布前给检查清单，发布后做互动节奏 - 输出：
草稿 + 标题/摘要建议 + 发布前 checklist + 评论互动建议
6）边界与风险：Skill 不是什么“银弹”
为了避免踩坑，下面这几条建议非常重要：
- 最小权限原则：Skill 声明允许的工具越少越好（allowed-tools），避免“过度能力”。
- 避免“带毒技能”：不要盲装来路不明的 Skill；外部脚本/链接要可审计。
- 依赖与组合要克制：Skill 之间隐式调用会引入复杂度（token 预算、冲突指令、依赖地狱）。
- 不适合的场景：一次性探索任务、强创意任务，可能更适合临时 Prompt 而不是固化 Skill。
7）结语：Skill 让 AI 真正进入可持续的生产流程
Prompt 更像临时口头指令，Tool 是单个动作按钮，MCP 是工具接口标准，而 Skill 更接近“把组织知识封装成可维护的执行系统”。
当你发现同一种任务一周要做 3 次、一个月要做 10 次、而且每次都要重新解释“怎么做”，那就是你该把它写成 Skill 的信号。
