19｜Skills与路由：怎样加载刚好需要的专业能力
本章目录
本章预备知识
Skill是可复用任务指导，路由决定是否提供，工具负责真实操作。说明文字可以帮助模型判断，但无法代替权限和验证；专业不等于每次读全部技能。
本章各题列出所需基础。可先完成相应基础课，也可通过自检确认掌握程度。
进入深读前的小检查：构造一个明显该加载、明显不该加载和边界模糊的任务，分别写出错误加载与遗漏的实际代价。
术语带虚线时可点击速查。公式中的字母先看定义；不要用猜缩写替代推导。
技能不是模型参数，也不是自动执行的程序。它通过可发现的元数据、任务说明和资源，为模型提供专业方法。路由要同时避免漏加载与过度加载。
沿着对象与状态理解本章
技能路由不是文件有无的二选一。名称可发现、描述匹配、正文读取、资源可访问、执行正确，各自都可能失败。按这条证据链排查，比只增加一条“必须使用Skill”更能找到具体原因。
下方图解的固定输入在“输入与适用条件”中声明。它用于解释本章机制，不与本章其他独立例子的数值暗中接续。
Skill存在，为什么仍可能完全没用？
从“安装了技能”到“写出了更好的代码”，中间经过什么？
技能像可按需展开的工作说明，不是新训练的一层神经网络。只有它被发现、匹配、读取，并真正影响行动，才可能改善结果。把“加载成功”当作能力已经应用，会把中间几道故障都遮住。
输入与适用条件：通用Skill运行示意，不假定Codex、Claude Code和Copilot的实现细节完全相同。
1 / 6 · 磁盘上有Skill
窄屏可左右滑动图形，或点击“放大图形”。文字解释紧随图后。
文件没在搜索路径里，下一步就可能看不到。
本步状态由图形与说明共同给出。默认静止。用“下一步”看完解释再继续；播放到最后一步自动停止。键盘聚焦播放器后，可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分，含义同时用文字注明。
为什么需要
在需要时提供专业步骤，避免所有规则常驻上下文。
怎样实现
按发现→匹配→加载→执行→验证逐段诊断。
可能的代价与误解
过度加载引入冲突和成本；漏加载导致关键专业要求缺失。
如何判断是否做对
用该加载与不该加载的真实任务双向测路由，再测最终工程质量。
Q073｜一个Skill从存在于磁盘到真正影响输出，经历哪些阶段？
核心回答
至少有发现、候选选择、正文加载、资源获取、实际执行与验证。文件存在不代表被发现，描述命中不代表正文读取，正文读取不代表关键步骤执行。应该用这条链解释“技能没生效”，而不是只看结果猜测。[SKILLS][COPILOTSKILL]
每个阶段都有独立失败
发现阶段扫描支持目录、解析元数据。路径不支持或格式错误会让技能完全不可见。选择阶段模型看到名称与描述，决定是否与当前任务相关；描述过泛可能误选，过窄可能漏选。加载阶段读正文，若文件太长、引用坏掉或上下文被裁剪，实际有效内容可能不完整。
执行阶段需要工具、权限和当前证据。一个数据库性能Skill要求查询执行计划，但子Agent没有数据库工具，就不能完成关键步骤。验证阶段检查最终代码或分析是否体现相关约束，而不是要求答案里必须出现技能名称。
因此路由日志可记录“发现了哪些候选、选了哪个、读了什么、执行了什么、为何停”。这不必暴露内部完整思维链；记录可观察动作和依据即可。
一个Skill怎样从磁盘文件进入当前动作
输入与条件。目录里有Python测试技能，名称/描述声明“适用于Python测试失败诊断”，正文引用pytest命令与失败分类。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1发现 | 扫描或加载元数据 | 只知道技能存在。 |
| 2匹配 | 任务是pytest断言失败 | 候选具有关联；若任务是改文档错字则不应强行加载。 |
| 3正文加载 | 读取执行步骤和所需资料 | 从“知道名字”进入“知道方法”。 |
| 4能力核对 | 环境无pytest或只读 | 调整验证方案并说明缺口，而非声称已运行。 |
| 5结果验收 | 测试运行对应当前修改版本 | Skill被读过不是任务完成证明。 |
把过程连起来。技能生命周期最终落在真实动作与证据上，而不是一个“已加载”标签。
边界与反例。具体发现/自动匹配由产品实现；本例依开放Skill组织概念，不保证所有工具自动执行同一流程。
依据与适用范围：[SKILLS]。示例输入和场景由本书明确设定。
追问：为什么让模型在回答中声明“我使用了X技能”不是好评测？
它可能声明但没执行，也可能执行了却没提名字。应看实际读取、工具调用和产物行为。关键词测试只适合检查显式格式要求，不适合证明专业能力应用。
追问：渐进式加载有什么隐藏成本？
额外发现和读取轮次、错误选择、上下文切换与引用失效。对短小且几乎每次都要用的规则，直接默认加载可能更便宜。渐进式适合大量长尾内容，不是无条件把每一句规则拆成单独文件。
追问：Skill脚本运行成功就意味着Skill完成了吗？
不。脚本可能只生成候选或中间文件，任务还需解释结果、验证适用性、处理错误和交付。要区分机械执行成功与用户目标完成。
Q074｜怎样写路由Description，既不漏边界任务又不过度触发？
核心回答
描述应表达明确任务意图、适用对象和关键边界，避免只堆专业名词或无限扩大适用范围。路由质量来自真实任务分布上的正例、负例和边界例验证，不是文案看起来全面。
看一个容易误路由的例子
“用于所有存储、数据库、缓存、文件、性能、安全与架构任务”覆盖太广，几乎任何后端修改都会触发。相反，“仅在用户明确说优化SQL索引时使用”又可能漏掉“接口查询太慢，帮我定位”的自然表达。
更有用的描述可围绕意图：“在任务需要分析数据库查询计划、索引选择、事务隔离或持久化一致性时使用；普通文件读写和无数据库语义的字段改名通常不需要。”这仍是示例，不是通用最佳文本。应让专业边界由实际证据修正：任务初看简单，读代码发现涉及事务，再升级专业技能。
评测集包括明显正例、明显负例和模糊边界。除了选择是否正确，还看漏选会造成什么具体错误、误选增加多少Token和流程。一个误加载但不影响输出的场景，与漏掉事务一致性导致重复扣款，风险不同。
“所有开发任务都适用”的描述会怎样误加载
输入与条件。候选A描述“提升工程质量，适用所有代码任务”；B描述“分析并发共享状态、竞态与锁顺序”。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1任务1 | 改README拼写 | A容易宽泛匹配，B不相关。 |
| 2任务2 | 余额并发扣减出现负数 | B明确相关。 |
| 3任务3 | 新增普通纯函数测试 | 质量相关不等于必须加载并发分析。 |
| 4调整 | 收紧A的具体触发与不适用例 | 不是把描述压成难懂缩写。 |
| 5评测 | 用必要召回和不必要加载双指标 | 只减少加载量可能把B该触发的任务也漏掉。 |
把过程连起来。路由描述的边界需要正例和相邻反例，而不是一堆“专业、全面、最佳”的形容词。
边界与反例。教学例不能证明真实LLM选择概率；需用目标模型与固定任务集实测。
追问：是否需要很多硬性分类等级？
不一定。可以保留“简单直接做，证据显示复杂再深化”的原则，让模型在证据支持下判断。硬分类只有在反复出现可预测错误且确有收益时才值得增加，否则可能把开放任务挤进不合适的格子。
追问：多个Skill重叠时该全部加载吗？
先确定主问题和必要专业边界。重叠可能需要组合，也可能只是描述重复。加载后要检查指令冲突和重复工作。若两个技能都要求完整独立分析与Review，直接叠加可能让任务成本翻倍而没有新证据。
追问：修改Description怎样证明没有降低专业召回？
在固定任务集比较旧/新版本，重点看原来应命中的任务是否丢失，同时增加真实误触发负例。不要只验证“之前那个误加载消失了”，否则可能靠把描述写得极窄获得虚假的精度提升。
Q075｜Skill、Instruction、Hook、Tool和Agent分别应该承担什么？
核心回答
Instruction表达持续约束；Skill提供按需专业方法；Tool执行具体动作；Hook在确定节点运行程序化逻辑；Agent承载独立任务执行与上下文。用职责选择机制，避免把同一逻辑重复写五遍。
一个验证需求的合适位置
“所有代码遵循项目格式”可在项目指令中说明；“遇到数据库迁移时核对回滚与兼容”可作为技能；“运行迁移检查器”是工具；“提交前自动运行确定性格式检查”可由合适hook/workflow执行；“独立审查迁移方案”在风险足够时可委派Agent。
自然语言适合开放判断，确定性程序适合可机械验证的条件。例如文件是否存在、schema是否合法、命令退出码是否为零，不需要模型猜。模型适合判断哪些测试相关、证据是否支持根因，但结论仍应受工具事实约束。
技能引用资源需保证相对路径、版本和权限可用。工具权限不能因为Skill正文写“允许访问”而被扩展。Hook也不天然安全，它执行的脚本可能拥有进程权限，需要同样审查。
想强制格式检查，写进Prompt还是用Hook
输入与条件。规则是提交前必须运行格式检查；任务另需Python专家建议和文件读取工具。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1普通指令 | 向模型说明约束与目标 | 模型能够理解但并非确定性执行保证。 |
| 2Skill | 提供Python问题的专业处理流程 | 只在相关任务加载。 |
| 3Tool | 提供format_check()实际执行能力 | 调用后产生退出码与日志。 |
| 4Hook或固定流程 | 在提交事件前确定性触发检查 | 对必须发生的机械步骤更合适。 |
| 5Agent | 在失败时决定检查文件、修改与重试 | 负责动态行动，不代替格式工具自身。 |
把过程连起来。选择机制看它承担的是解释、方法、动作、强制时机还是动态决策。
边界与反例。Hook可用事件与阻断行为依产品；不能假设某任意CLI都提供相同能力。
追问：为什么不把所有检查都放Hook强制执行？
频繁且昂贵的全量检查可能拖慢简单任务，部分检查需要业务判断而非固定脚本。Hook适合便宜、确定、关键的机械边界。风险驱动的深度审查不应被固定触发频率替代。
追问：Skill可否独立于某个框架复用？
可以把领域原理、操作步骤与资源尽量写成平台无关内容，再为具体工具提供轻量适配。但工具名称、权限、路径和调用协议往往需要适配。所谓可移植不等于原封不动复制到所有CLI即可运行。
追问：什么时候需要拆成独立Agent？
任务有独立上下文、可并行目标或确有独立审查价值时；仅仅说明较长不一定需要子Agent。子Agent增加交接、成本和状态管理，不能把它当文件加载机制的默认替代。
Q076｜多模型路由怎样优化成本而不牺牲质量？为什么不能只按Prompt长度选模型？
核心回答
路由应考虑任务难度、风险、需要的工具/上下文能力和真实成功率。Prompt长度只反映输入规模，不能代表推理复杂度。目标是满足质量约束下的成功任务成本，而不是单次调用最便宜。
从总成本写决策
模型A单次成本1，成功率0.9；模型B单次成本0.2，成功率0.5。如果失败可独立重试且条件理想，粗略成本/成功约为c/p，但真实Agent失败可能需要返工、人工检查和副作用恢复，不能直接套几何分布。
更实用的教学估算是：总成本=初次执行+验证+失败概率×预期返工成本。还要把高风险错误损失作为质量约束，而非轻易换算成可以接受的便宜概率。强模型可用于难以验证的核心判断，较轻模型用于格式转换、独立可验证的小任务，但分派本身也需要评测。
升级触发可来自证据：连续失败、跨模块不变量、检索后仍存在多种解释、工具参数频繁错误。不要每次先调用一个大模型分析应该用什么模型，再把微小任务交给小模型，路由开销可能超过节省。
便宜模型一次省钱，返工后每个成功任务却更贵
输入与条件。在同一批100个任务上，方案A总成本100元，成功80个；方案B总成本70元，成功40个。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1单任务尝试成本 | A=1，B=0.7 | 只看这项B更便宜。 |
| 2每成功任务成本 | A=100/80=1.25，B=70/40=1.75 | 以实际成功计，B更贵。 |
| 3纳入返工 | 若失败还消耗人工时间 | B的总体成本可能进一步上升。 |
| 4分层路由 | 简单任务B成功率可能足够，高风险任务用A | 需要按任务层测，不从全局均值猜。 |
| 5质量约束 | 先满足正确性和风险底线 | 再在合格方案之间比较费用、延迟。 |
把过程连起来。模型选择应对成功结果负责，而不仅对一次API报价负责。
边界与反例。费用为虚构统一单位，不是当前厂商价格；此比率统计包含失败花费，不能当成单任务成功概率模型。
依据与适用范围：[DERIVE]。示例输入和场景由本书明确设定。
追问：候选模型列表从哪里来？
从当前CLI/API配置、可用模型目录和权限，不应让模型凭记忆编名称。不同工具可能不暴露相同模型集合。路由器必须知道实际可用能力，不应把不存在的模型写入计划。
追问：小模型负责Review是否一定足够？
取决于错误类型与验证方式。格式和确定性检查可廉价完成；复杂并发或跨模块设计可能需要更强推理。若Reviewer比执行者更难发现同类错误，增加Review只是增加一段赞同文字。应测真实缺陷检出和误报。
追问：何时不值得做自动模型路由？
任务量少、统一模型成本可接受、路由难判断或错误切换频繁时，简单固定模型加明确升级可能更好。复杂路由要有足够任务量和稳定收益支撑，不能为一个理论优化建长期维护负担。