在 Claude Code、Cursor 等环境里，Skill（通常是一组带说明的 SKILL.md 与配套资源）常被说成「给模型加外挂」。更务实的一种看法是：它可以把业务能力拆成边界清楚、可复用、可演进的单元——和微服务里「按限界上下文切服务」是同一类思路，只是载体从进程变成了「提示词 + 约定 + 少量脚本/模板」。
1. Skill 确实能服务于「业务能力拆分」
业务系统里我们习惯按领域拆模块：订单、库存、计费各自有接口与不变量。Agent 侧如果只有一个巨型系统提示词，等价于把所有领域揉进一个单体——短期省事，长期难维护、难测试、难交接。
Skill 提供了一条中间道路：
- 按场景加载：只在相关任务挂载对应 Skill，减少无关指令干扰。
- 显式边界：在 Skill 里写清输入期望、禁止事项、验收口径，相当于给模型一份「轻量级契约」。
- 组合而非堆叠：多个 Skill 可以像能力积木一样组合，而不是把全部规则抄进一个文件。
因此，若你的问题本来是「这块业务能不能模块化」，答案往往是：能；Skill 只是把模块化的结果翻译成模型可读、团队可协作的格式。
2. 有 SOP 和清晰边界时，拆分会比想象中容易
真正拖慢进度的通常不是「写 Markdown」，而是说不清：
- 谁对结果签字？
- 什么算完成、什么算越权？
- 异常走哪条路径、找谁 escalation？
一旦这些在 SOP（标准作业程序）里已有定论，Skill 的工作就退化为把 SOP 改写成模型友好的步骤、检查清单与反例。此时拆分粒度会自然浮现：一步一检查点、一段一责任方，和写 runbook 没有本质区别——只是读者从值班同事换成了 Agent。
反过来，若边界模糊，Skill 会变成「写得很长的愿望清单」，模型仍会猜。结论很朴素：Skill 放大了你流程上的清晰度；流程糊，Skill 也救不了。
3. 「蒸馏同事」听起来唬人，本质是提高效率的手段
行业里偶尔能听到「蒸馏同事的经验」之类说法——名字略夸张，容易让人联想到训练神经网络里的 distillation。更接地气的解释是：
- 把隐性经验（口口相传的坑、默认前提、客户特例）显性化；
- 把一次性对话变成可版本化的资产；
- 让新同事或新会话不必从零复述上下文。
这不是要替代同事，而是减少重复解释与口径漂移。当 Skill 与真实工单、真实复盘挂钩，并随业务迭代更新时，它才配得上「效率工具」四个字；否则只是又一叠无人问津的文档。
4. 用 Git 管起来：参考开源项目与协作方式
Skill 最适合与代码、配置一样进仓库：Pull Request 评审、变更记录、回滚、谁在什么时间改了哪条规则，一目了然。团队可以约定目录（例如 .claude/skills/ 或项目统一的 skills/），把「谁能 merge」「哪些变更必须双人 review」写进工程规范，而不是停留在聊天里。
若要对照业界已有的结构与示例，可以按需翻看下面几类仓库——重点仍是对照目录与文档粒度，而不是照搬业务规则：
- 官方基线：Anthropic 维护的 github.com/anthropics/skills 提供 Agent Skills 的参考实现与说明，适合弄清「目录长什么样、说明写到哪一层」；更系统的概念与用法见该仓库链出的官方文档。
- 多角色 / Agency 编排：github.com/msitarzewski/agency-agents 以「完整 AI agency」为卖点，可看角色如何拆分、多代理如何协作——与本文「按能力边界拆 Skill」是同一类问题在不同抽象层上的呈现。
- 「同事经验」技能化命名：github.com/titanwings/colleague-skill 在社区里常与「把协作者经验落成 Skill」的讨论一起被引用；可读其自述与仓库结构，对照第三节里说的「显性化、可版本化」究竟落盘成哪些文件与约定。
你不必 fork 全盘照抄，但用同一套思路做版本化与评审，会少走很多弯路。
小结：Skill 是业务能力模块化在 Agent 时代的一种落盘形式；SOP 与边界决定拆分难度；所谓「蒸馏同事」不必神化，工程化与 Git 协作才是可持续提效的关键。若你手头已经有一份像样的 runbook，不妨挑一条最高频、最易出错的流程，试着写成第一个 Skill——通常比从零构思「万能助手」更有价值。