为什么 Skills 突然火了
这段时间大家都在聊 Skills，但很多讨论停留在“怎么写 SKILL.md”。从工程视角看，更关键的问题是：Skills 在大模型里到底如何被执行。搞清这个问题，才能判断一个方案是“能上线”，还是“看起来很酷”。
先把底层认知统一：Tools 才是执行入口
无论是 Claude Code、Cursor 还是其他 IDE Agent，核心都绕不开工具调用。模型不直接执行系统操作，真实执行发生在宿主侧。
- 用户请求 + tools 定义 一起发给模型。
- 模型返回 tool_calls：调用哪个工具、参数是什么。
- 宿主执行工具，回传 tool_result，模型再生成最终回复。
一句话：模型负责“决策与编排”，宿主负责“落地执行”。
Skills 的本质：工具中的“按需知识索引”
抓包后你会发现，Skills 常常只是 tools 列表里的一个可调用项（例如 Skill）。它的主要职责不是直接回答问题，而是把模型引导到正确的知识和动作入口：
- 先定位 Skill 主文档（通常是
SKILL.md）。 - 再根据主文档指引，按需读取 references。
- 必要时继续调用 Read/Bash/WebSearch 等工具完成任务链。
这是一种“先索引、后加载、再执行”的机制，而不是一次性把全部知识塞进上下文。
一次典型执行链路（简化版）
- 用户提问：如“Laravel 里怎么对比规范与不规范代码”。
- 模型识别相关 Skill，发起
Skill(...)调用。 - 宿主回传 Skill 主文档内容。
- 模型继续发起
Read(references/examples.md)。 - 宿主回传详细文档，模型输出最终答案。
这解释了为什么高质量 Skill 会显著提升结果：它给了模型“去哪找答案”的稳定路径。
工程价值：为什么它比纯提示词更实用
- 降低成本：默认只加载索引，减少无效 token 消耗。
- 提高命中率：按任务分层读取，减少上下文噪声。
- 便于团队治理：Skill 文档可版本化、可审查、可复用。
冷静一点：Skills 也有边界
1) 仍然依赖推理，存在不稳定性
只要流程依赖“模型自己判断下一步读什么/调什么”，就会有概率偏航，这和硬编码工作流不同。
2) 文档层级太深会失焦
Skill 不是越碎越好。层级过深、引用过多，模型更容易在多轮后偏离目标。实践里建议“浅层目录 + 关键文档直达”。
可落地的设计建议（实战版）
- 主文档只做导航：目标、边界、入口，不写成长篇百科。
- 引用命名可判定：让模型一眼知道“该读哪份”。
- 工具描述写触发条件：避免模型误调用。
- 保留调用日志：可回放每轮 tool_call/tool_result，方便排错。
- 提供兜底路径：读取失败时要有降级策略。
结论
Skills 不是黑科技，而是大模型时代的“知识索引 + 工具编排”工程方法。真正决定质量的，是你对工具边界、上下文预算、失败回退和执行可观测性的系统设计，而不是文档写得多花哨。