Skills 是什么：可复用的能力包
你大概已经有一份「常用提示词」文档：写周报的、改文案的、做代码评审的，每次用就翻出来复制粘贴。问题也很明显——粘贴 40 行、替换材料、还要记得把上次补的约束也带上，一次不落就会翻车。Skill（技能包/指令包）就是把这件事固化下来：把成熟的提示词、判断标准和参考资料打包成一份可被自动读取的文件，让 AI 在该用它的时候自己用上，实现跨会话复用。
从「复制粘贴」到「装进工具里」
| 维度 | 每次复制粘贴提示词 | 沉淀成 Skill |
|---|---|---|
| 复用范围 | 当前这段对话 | 跨会话、跨项目、多客户端通用 |
| 一致性 | 靠记忆，常常漏掉约束 | 标准固定，不会因为赶时间缩水 |
| 维护 | 散落在笔记与聊天记录里 | 一份文件即唯一版本，可迭代可回溯 |
| 触发方式 | 你手动贴 | 可按规则自动生效，或一句「用 XX 技能」唤起 |
| 参考资料 | 要么没有，要么每次重贴 | 与做法一起存放，随时被引用 |
一句话区别：提示词是「说一次」，Skill 是「立个规矩」。凡是「我每周都要交代一遍」的事，都值得做成 Skill。
常见形态：名字不同，本质相同
不同产品叫法不一样，但都在做同一件事——把稳定指令放进 AI 的工作目录里。
| 形态 | 常见叫法 | 生效范围 | 典型用途 |
|---|---|---|---|
| 全局自定义指令 | 自定义指令 / 个人偏好设置 | 所有会话 | 语言习惯、称呼、默认输出格式 |
| 项目级规则文件 | 项目规则 / Rules 文件 | 当前项目 | 技术栈约定、目录规范、禁止改动的文件 |
| 技能包 | Skills / 技能 | 装好后按需触发 | 一整套带流程与标准的专业能力 |
| 项目说明文件 | 仓库内的说明文档（如 README 类约定文件） | 当前仓库 | 给 AI 交代项目背景与协作方式 |
选型经验：跨项目通用的写全局，跟代码库绑定的写项目级，需要完整流程和判断标准的做成技能包。
Skill 的三段结构
一份能用的 Skill，核心只有三块。
第一段 · 触发条件（什么时候用它）
- 什么时候该用：用户提到「周报」「本周进展」并要求汇总成给上级的格式时
- 什么时候不该用：用户只是问某条待办的进度，不要启动整套流程
- 需要什么输入：本周的零散记录；缺记录时先向用户索要，不要自行编造
第二段 · 做法与约束（怎么做，不许做什么）
1. 先按「事项 / 结果 / 数据」三要素整理记录，缺哪项就标注「待补充」
2. 结构固定三节：本周进展、风险与阻塞、下周计划
3. 进展每条一行，动词开头；风险只写需要上级协调的事
4. 禁止：客套话、感想总结、形容词包装、编造数据与时间
5. 总长控制在 400 字内，超长时优先砍「下周计划」的细节
第三段 · 参考资料（判断标准与示例）
- 好例子：完成订单导出功能，覆盖 3 个区域，平均耗时从 9 秒降到 2 秒
- 坏例子：完成了订单导出功能，效果很好，用户反馈不错
- 判断标准：能从一句话里读出「做了什么、结果如何、有无数字」
三段的分工是：第一段决定「会不会被用上」，第二段决定「做得稳不稳」，第三段决定「做得好不好」。很多人只写了第二段，结果 Skill 做出来了却总是没人（没模型）用上。
一个最小可用的 Skill 长什么样
名称：周报生成
何时用：用户提到「周报 / 本周进展」，且要求汇总成给上级看的格式
何时不用：用户只是问某条待办的进度
做法：按「事项 / 结果 / 数据」归一 → 输出三节（进展 / 风险 / 下周计划）→ 全篇 400 字内
约束：不编造数据与时间；不写客套话与感想；数字原样保留
标准：每一行都能读出「做了什么、结果如何、有没有数字」
十五行以内就能起步。先写短版本用起来，遇到问题再往里加条款，比一次写三百行更容易活下去。
什么场景值得沉淀成 Skill
判断标准很简单：同一件事你交代过三次以上。再补两条加分项：这件事有稳定的验收标准，或者你每次都手写一堆同样的约束。
| 场景 | 是否值得 | 理由 |
|---|---|---|
| 每周写周报 | 值得 | 高频 + 格式固定 + 有明显好坏标准 |
| 代码提交前评审 | 值得 | 检查项固定，且漏项代价高 |
| 把会议记录整理成待办 | 值得 | 已重复三次以上，格式稳定 |
| 一次性查资料、随便问问 | 不值得 | 没有可复用的流程 |
| 改一段文案的语气 | 一般不值得 | 一次做完，需求每回都不同 |
| 把内部术语口径统一 | 值得 | 属于长期稳定的「规矩」，适合放全局指令 |
一个反直觉的建议：先做最烦的那一件，不要一上来做十个。做第一个 Skill 会花你半小时，但之后每周省十分钟；十个一起做，多半写完就忘。
与提示词、工作流、MCP 的边界
- 提示词：一次性的口头交代，用完即弃。
- Skill：稳定的做法与标准，沉淀成文件，按需调用。
- 工作流：步骤写死的自动化流程，追求稳定可预期（如定时代跑批处理）。
- MCP：给 AI 接上外部工具与数据的手脚（见后续章节）。
四者常配合使用：用 Skill 定义「怎么干」，用 MCP 提供「能碰到什么」，用工作流保证「按时干」，用提示词做「这次的特殊要求」。
常见坑
| 坑 | 后果 | 改法 |
|---|---|---|
| 只写「要专业、要详细」这类形容词 | 模型无法执行，等于没写 | 换成可检查的动作与判断标准 |
| 触发条件写得过宽 | 聊什么都触发，干扰正常对话 | 明确「仅当用户提到 X」才算 |
| 塞进 20 条互相冲突的规则 | 每次遵守不同的几条 | 精简到 5~8 条，冲突的删掉 |
| 写完从不用也从不改 | 慢慢过期，反而误导 | 每次用后记一句「哪里不好用」，季度复盘 |
| 把敏感信息写进 Skill | 文件被共享时泄露 | 只写方法与口径，不写密钥、真实客户数据 |
小结：Skill 是把「说过三次以上」的提示词固化成可复用的能力包，形态上可以是自定义指令、项目规则或技能包，结构上分触发条件、做法与约束、参考资料三段；先做最烦的那一件，用起来再迭代。