Claude Code的Skills方法论中有一个值得玩味的细节："优质的Skills通常会聚焦单一类别，跨类别设计的Skills易出现逻辑混乱、触发不精准的问题"。
这句话看似简单，实则触及AI工具设计的深层逻辑。
AI工具的"理解"并非无限。当Skills横跨多个类别时：
Claude Code作为智能体，需要自主发现、探索并操作Skills文件夹内的资源。单一聚焦相当于为其建立清晰的心智模型--"这个Skill解决什么问题"，而非"这个Skill可能解决哪些问题"。
| 场景 | 观察 |
|---|---|
| OpenAI GPTs | 同样强调"一个GPT只做一件事"，多功能GPT往往体验割裂 |
| Cursor Rules | 项目级配置 vs 全局配置分离，避免规则冲突 |
| 传统软件设计 | Unix哲学"Do one thing and do it well" |
| 低代码/无代码平台 | 组件化、原子化设计是主流 |
初步判断：这并非AI独有，但AI放大了"不聚焦"的代价--因为模糊性会直接转化为幻觉和错误执行。
其方法论中提到的9类Skills本身已覆盖"开发全流程"，暗示通过组合而非糅合实现复杂需求--这与微服务架构的逻辑异曲同工。
在你的AI工具使用/设计经验中，"单一聚焦"原则是否成立？有没有成功的"跨类别"反例？
从用户视角：你更愿意调用10个精准的单一Skills，还是1个"全能但偶尔出错"的复合Skill？
技术实现层面：RAG、Agent框架的进步（如更好的路由、规划能力），是否会消解"必须单一聚焦"的约束？
期待看到不同场景下的实战验证。
加入讨论
第三点关于RAG和Agent框架的问题挺有意思。我实际用下来感觉，哪怕路由做得再好，一旦某个Skill本身职责不清，底层模型还是会”自作聪明”地乱调用。技术再进步，设计层面的清晰边界好像还是绕不过去？
微服务架构那个类比挺到位的，但我突然想到——人类大脑本身就是跨类别混在一起的，为啥AI就不能？可能问题不在”跨类别”，而在于我们还没找到合适的”注意力机制”让模型像人一样灵活切换上下文。
“单一聚焦”这个提法让我想到一个反例——我自己写的几个脚本Skill，明明只处理文件操作，但用户总会问”能不能顺便帮我压缩一下”，然后我就开始纠结要不要加功能… 最后往往变成四不像。可能”聚焦”最难的不是技术，是抵抗用户需求的诱惑 😂
说实话我更在意那个”9类Skills覆盖开发全流程”的说法——分类本身会不会就是一种妥协？万一我的需求卡在两类之间，是硬选一个还是干脆不用了😂 感觉设计者和用户的”聚焦”理解经常不在一个频道上。
那个”幻觉和错误执行”的说法太真实了。我之前试过把代码审查和文档生成塞进同一个Skill里，结果它经常把bug描述写成诗，或者给注释里塞满批评😅 后来拆成两个，世界清净了。
突然想到一个问题——Claude Code那9类Skills是谁来定义的？如果是Anthropic官方定的，那用户自定义Skills的时候会不会不自觉往这9类里套，反而限制了真正”单一聚焦”的可能性？有点先有鸡还是先有蛋的感觉🤔
“Do one thing well”这个哲学在AI时代感觉被强化了——以前软件模糊点顶多界面丑，现在AI一模糊直接给你生成幻觉代码。不过我在想，会不会以后出现”元Skill”专门负责判断该调哪个子Skill？那样用户层面还是”一站式”，但底层还是单一聚焦🤔
有点好奇那个”编排层”的想法——如果真有专门的协调者Skill，它自己算不算跨类别？🤔 感觉像是个递归陷阱，搞不好协调者最后也膨胀成全能管家了。
看到”用户更愿意调用10个精准的还是1个全能的”这个问题，我突然想到——这根本取决于调用成本啊。如果每次都要先想”这事该用哪个Skill”，那还不如一个凑合用的。界面设计要是能把”选工具”的摩擦降到零，单一聚焦才有意义。
其实”单一聚焦”在团队协作场景下反而可能成为负担。我们组试过把代码审查Skill拆成三个细粒度的，结果新人根本搞不清该调哪个，最后全在群里@老员工问”这个该用review-code还是check-style还是security-scan”😂 有时候”模糊但可用”比”精准但复杂”更实际。
那个”上下文窗口的隐性约束”让我想到，其实不只是AI，我给人写需求文档的时候也发现——功能描述越杂，开发理解错的可能性越高。可能”单一聚焦”本质是降低沟通熵？不过AI的容错率确实比人低多了，说错就真错😂
突然想到一个现实问题——这9类Skills的划分标准会更新吗？万一明年出了新的编程范式或者工作流，是硬塞到现有分类里，还是直接打破架构？感觉这种”分类即政治”的问题在AI工具里会更头疼😂 毕竟模型迭代那么快，设计哲学却得保持稳定。