我为什么开始把 Skill 当成工程资产，而不是提示词

有一次我让 Claude 帮我改 LoginForm.tsx 里的邮箱校验正则。它找到了组件，也改对了规则。然后它继续翻到 formStore.ts，开始分析要不要把 useFormState 迁到统一的 FormProvider，还顺手打开了 ProfileForm.tsx。这些文件都和"表单"有关，但和那次 bug 没有关系。那次问题不是它不会改，而是它不知道应该停在哪里。

模型经常缺的不是能力，是任务尺度

那次改表单校验，我真正需要的只有三步：找到规则在哪，改掉错误条件，确认测试能过。

但在没有额外约束时，Claude 把请求理解成了"既然都看到表单相关文件了，就顺便看看有没有更大的优化空间"。于是它分析状态管理，翻架构文档，还对比了几个方案。这些分析单独看并不离谱，问题是它们已经离开了那次 bug 的边界。

后来我发现，这类偏移不是某一个模型的问题。模型每次接到任务，都在重新判断自己这次该用什么工作模式：普通实现、架构治理、代码审查、构建排障，还是顺手做一轮整理。

如果没有清晰信号，它很容易按更积极、更宽的方式行动。对一个小 bug 来说，这种积极反而会变成成本。

我开始用 Skill，就是为了解决这个问题。不是让模型多记几句提示词，而是让它在进入任务时先拿到边界：这次该做到哪里，什么不该碰，最后交付到什么程度。

单靠长 prompt 很难稳定

我最早的做法很直接：每次开头多写一点 prompt。

比如：

你是一个资深前端工程师，请只关注实现本身，不要做架构改动，不要重构无关模块，如果需要改测试请先问我……

短期看，这能缓解一些问题。但用几次之后就暴露出两个麻烦。

第一个麻烦是稳定性。每次手写出来的约束都不完全一样。上次记得写"不要重构"，这次忘了写，模型就可能又把无关文件带进来。

第二个麻烦是上下文成本。很多元指令会跟着每次请求一起进入上下文，但当前任务未必真的需要它们。写得越长，越像把一个常驻说明书塞进每次对话。

所以我对 Skill 的期待，不是把 prompt 写得更长，而是把那些经常重复、经常遗漏、又会影响任务边界的规则，放到合适的工作流里。

模型触发某个 Skill 后，应该先看到这个领域的任务边界、处理步骤和交付标准。这样它不用每次从零开始猜，也不容易把一个小修复做成一次架构巡检。

没有触发边界的 Skill，会自己扩范围

我写的第一批 Skill，其实就是把一段 prompt 存进文件。description 写得很宽：

前端专家，用于所有前端开发任务。

这句话看起来没什么问题，但实际使用时很容易误触发。

只要任务里出现前端文件，它就可能进入这个 Skill。改一行 CSS 会进入，修一个 HTML 标签会进入，甚至聊后端接口设计时，因为提到了前端字段名，也可能被带进去。

这时 Skill 并没有帮模型收敛任务，反而给了它一个更大的身份。它会觉得自己已经进入"前端专家模式"，于是开始补充分析、扩展范围、顺手检查相关模块。

后来我改 description 时，会让它至少回答清楚三件事：

• 这个 Skill 负责什么。
• 哪类任务应该触发它。
• 哪类任务不该触发它，应该交给哪个更合适的 Skill。

比如 frontend-expert，我会把它限定在普通页面实现、组件开发和交互修复上。同时明确写出：架构治理、状态体系设计、疑难攻坚，不应该走这个 Skill，而应该转给 frontend-architecture-expert。

这个边界写清以后，效果会稳很多。普通页面任务更容易落到实现工作流里，深层架构问题也不再总是被前端实现 Skill 抢走。

Skill 写坏了，问题会很具体

我后来回看自己的 Skill 库，发现坏 Skill 带来的问题通常不是抽象的"效果不好"，而是几个很具体的行为。

误触发。 一个技术写作任务触发了 product-expert，因为 description 里写了"需求分析和方案设计"。但技术写作里的"方案"，和产品专家里的"方案"，语境完全不一样。模型只抓到了关键词，没有抓到任务类型。

职责重叠。 两个 Skill 的描述都覆盖了类似场景，模型同时触发后，输出就开始摇摆。一个让它"先看代码再看设计"，另一个让它"先分析业务需求再给方案"。两个方向都对，但放在同一次任务里就互相拉扯。

输出过重。 有个 Skill 的默认交付标准写得太满，要求每次都给背景分析、方案对比、风险评估和 checklist。结果一个改一行 bug 的任务，也被写成了一份架构分析文档。

这些问题最后都能追到几个地方：触发条件太宽，和其他 Skill 的边界没拆开，交付标准没有按任务大小收住。

把 Skill 当成需要维护的工程资产

后来我看 Skill 的方式变了。它不是写好就放着的提示词模板，更像一个小型工程资产：会误触发，会老化，会和其他 Skill 抢职责，也会因为交付标准过重而拖慢任务。

我现在判断一个 Skill 要不要改，通常看两个信号。

一个信号是它经常在不该出现的时候出现。比如只是聊写作，它却把产品方案工作流带进来。

另一个信号是它应该出现时没出现。比如明显是构建排障，它却还停留在普通前端实现流程里。

如果我在对话里反复纠正模型同一种行为，就会回头看 SKILL.md：description 有没有把任务范围说清楚？正文有没有把模型带去读正确的 reference？交付标准有没有让小任务变成大报告？有没有明确写出哪些事不要做？

所以现在我看一份 SKILL.md，不会先看它写了多长。我会先看它能不能让模型少猜，能不能把任务范围收住，能不能在合适的时候把工作交给更合适的 Skill。

表面上，Skill 像是一份提示词文件。真正用起来，它更像工程里的边界文件：规定什么时候进入，进入后怎么做，做到哪里停。