为什么你的 skill 总不好使？

如果你给 AI 写过 skill，大概率撞过这两堵墙：

• AI 压根不用它。你明明写了一个“代码审查 skill”。结果让它 review 代码时它该怎么干还怎么干，根本没翻你写的那份东西。
• 它用了但做得不对。skill 是被加载了可输出跟你想要的差了十万八千里你只好在文档里不停加“必须”“一定”“禁止”。越加越长，效果却越来越玄学。

这两堵墙背后其实是同一个误解：很多人把“写 skill”当成“写一篇说明文档”——以为只要把要求写清楚、写全，AI 自然会照办。

至于但真相是，写 skill 更像是在给一位很聪明、但记性和注意力都有限的新同事设计一份“会被翻开、翻开后能照着做”的工作手册。 文档写得全等于被读，被读等于被执行。

它不是程序，是“手册 + 工具箱”

很多人第一次接触 skill。会下意识觉得它是某种后台运行的小程序：我装上它，AI 就多了一个功能模块，像手机装 App 一样。

再看使用者常说，“我装完后却连一次都没用。”这就是对 “手册” 的误解。

• No dedicated model：a skill runs on current AI.
• No compiler/runtime：a code block never executes line‑by‑line.

"上下文"是 AI 当前对话的工作记忆。 skill 的全部作用，就是在合适的时候。把预先写好的文字塞进这块工作记忆里让 AI 照着这段文字去做事。

从痛点来看。若没有可视化工具，你就无法让 AI 在正确时机阅读正确指令。说起来，

说到一个真实例子，skill-creator 被触发的那一刻

1. Ai 扫描所有 skill 的一句话简介。找到叫 skill-creator" 的，接下来决定是否翻开手册。
2. Ai 把整个 SKILL.md 正文塞进上下文；接下来不是 PDF 知识。而是一份操作流程 SOP—先问清楚需求，再草稿，再验证…​​​​​​​​​​** ​​.
3. Ai 并没有执行任何脚本，只是读到了 SOP 并按流程扮演起 “skill 作者”。

这就是技能运作全貌。说起来，把这个直觉立住你会发现所有原则都顺理成章——因为它们本质上都是回答同一个问题：

``

说到第二章。原理一——三层加载，决定 skill"读不读得动"