我的写作 Skill 写到第三版，限制条目超过二十条。

格式约束、语气约束、禁用词清单，全塞进一个文件。逻辑朴素：越精确越好，AI 照着来就不会出错。但结果越写越烂

AI 读完那堆规则，工作内存先填满一半，正式写作还没开始。后来才发现——那些约束里，有一半是在对付它早期的缺陷，它早就进化过去了，我的 Skill 还停在原地限制它。

那不是 Skill，是围着提示词堆起来的篱笆。

---

大多数人搭的 Skill，只是把提示词存起来加了一层仪式感。

什么是好的skill，就这么几个点

---

它能在该出现的时候出现吗？

它能在该出现的时候出现吗

Skill 文件里有一段自我介绍，系统里叫 description（决定「什么时候该用我」的那几行字）。平时只让这段自我介绍参与匹配，整个 SKILL.md 不占位。

用户说的话触碰到了，完整文件才加载进来。没触碰到，Skill 就一直在后台睡觉。

有人做了一个生成封面图的 Skill，自我介绍只写了 Create an image.，然后发现它从来不工作。

用户说的是"帮我做一张小红书封面"、"给这篇文章配个图"、"做一张科技感海报"。自我介绍里的语言和用户开口的语言对不上，Skill 一直休眠。

反过来：自我介绍太宽，用户随便说句"帮我写点什么"，不该出现的 Skill 跳出来，用错误的流程处理了不该处理的任务。

还有一类：年终总结、简历重写这类一年用不了几次的 Skill，一直在后台占着匹配成本。可以在文件顶部配置区加一行 disable: true，关掉自动触发，需要时手动叫它。

测试方式：准备一批用户真实可能说的话，挨个试。大多数人从来不测，因为自己主动叫它的时候看起来都能用。

---

权限给少了跑不动，给多了是风险

Skill 可以限定自己能用哪些工具。

如果只需要读文件、整理笔记的 Skill，给了执行命令行的权限——风险敞口白白放大，能力却没变强。
权限给少了同样出问题：跑到需要真正操作的步骤，发现工具不够，模型绕路自己想办法，结果就开始飘。

因此需要保持skill的能力最小够用就好。

---

主文件是门，不是仓库

主文件是门，不是仓库

Skill 的入口文件通常叫 SKILL.md。超过 500 行，通常说明你把不该在这里的东西塞进来了。

该放的：触发条件、执行步骤、所需工具、参考资料去哪找。不该放的：参考资料本身、完整案例、脚本代码、模板文件。

更好的结构是三层分开：

writing-skill/
  SKILL.md          ← 主文件，流程入口
  references/       ← 长文档、风格参考、案例对比
  scripts/          ← 可执行的确定性操作（检查字数、批量导出）
  assets/           ← 模板、类型定义、示例文件

references/ 里的东西，AI 只在需要细节时才读。scripts/ 里的操作写死成脚本，比每次让 AI 现场生成稳定得多。

AI 先读主文件，知道流程，需要细节时再取。一开始就把所有东西倒进来，能跑的空间越来越小。

我的写作 Skill 就是这个问题。限制全堆在主文件，减掉大半、把风格参考挪出去之后，反而稳了。

---

模型和任务，得对上

Skill 可以为不同任务单独指定模型。

整理笔记、抽取信息，便宜的够用。写需要判断力的长文，便宜的不够。

一律用最强的：成本白花。一律用便宜的：能力不够的地方结果飘，然后怪 Skill 没写好。

任务难度和模型成本对上了，这件事本身说明这套系统已经成熟了一些。

---

"能跑"和"有用"是两件事

"能跑"和"有用"是两件事

写完就觉得完了，这是最常见的状态。

同一个任务跑两次：不用 Skill，AI 自由发挥，得 4 分。用了 Skill，还是 4 分——那这个 Skill 只是加了一层仪式感。

---

我现在衡量一个 Skill，就问五件事：自我介绍够不够准？权限是最小够用的吗？主文件控制住大小了吗？模型选对了吗？有没有验证过真的有用？

都过了，才算 Skill。有一件没过，在那个维度上，它还是提示词。

包括我自己的。写作 Skill 迭代到第四版，才开始认真减限制。AI 变强了，我还用旧规则约束它，不自知。

今天让 AI 稳定的约束，明天可能是让它跑不快的枷锁。

我把这套标准做成了一个工具，叫 skill-doctor，开源在 GitHub。把你的 Skill 文件夹路径传进去，它帮你跑一遍体检，告诉你哪里没过关。

https://github.com/yiyi13769-cmd/skill-doctor