我给自己的博客写过一份发布检查清单，放在备忘录里。每次发文章前照着走一遍：改日期、确认封面文件名、检查 front matter 的字段、本地跑一次构建。清单用了半年，我还是会漏，而且每次漏的都是同一步——封面路径里的 slug 和实际文件名对不上。
后来我把这份清单写成了一个 SKILL.md。变化不在于模型变聪明了，而在于写这个文件的时候，我被逼着把“检查封面”拆成了“用文件名里的 slug 拼出路径，再确认文件存在”。以前我知道自己该检查，但从没想过检查这个动作具体长什么样。
我对这类“提示词库”一直有偏见。之前试过几次 prompt 集合，建的时候很兴奋，两周后就不打开了，因为真正麻烦的从来不是找不到模板，是模板和当下的事情对不上。Skills 让我改观的地方不在复用，在于它要求你把流程写到可执行的程度，而这个要求本身就会暴露流程里的含糊之处。
一个 Skill 就是一个文件夹
结构比想象中简单：一个目录，里面必须有 SKILL.md，可以再带脚本和资源文件。文件名的大小写是严格的，写成 skill.md 或者 README.md 都不会被认出来。
目录名我习惯用英文小写加连字符，和 name 字段保持一致。这不是强制的，但两边不一致的时候，每次改动都要停下来确认自己改的是哪个，这种小摩擦累积起来很消耗耐心。
文件头部是一段 YAML 元数据，下面是正文指令：
1 | --- |
真正有意思的是加载方式。模型启动时并不会读完整份文件，只读 name 和 description。只有当当前任务看起来匹配，才会把正文和附件读进来。所以正文可以写得很细，写长了也不心疼，代价只在命中之后才产生。
这个设计解决了一个实际问题：我以前的习惯是把所有规矩塞进一个系统提示，几千字，每次对话都要付一遍 Token。现在这些规矩可以散在十几个文件里，各自等待被触发。
脚本的边界我也摸索了一阵。凡是能用代码算准的东西，我都不写在正文里让模型照着做——遍历目录、拼路径、解析 YAML、比较时间戳，全部放进脚本，正文只写“什么时候调用、传什么参数、结果怎么判断”。让模型用自然语言描述一个确定的计算过程，每次都会有一点偏差，而偏差在流程类任务里会累积。
反过来，判断类的工作我不写脚本。比如“这段改动是否影响接口兼容性”，写成规则会漏掉太多情况，写成一句判断标准再给几个例子，效果更好。这条界线我一开始划错了，把太多判断写成了 if-else，维护得很痛苦。
代价是调试变难。这条链路里没有日志，没有“已加载”的提示，只有行为和预期不符。Skill 没生效的时候，可能是描述没命中，可能是 YAML 写坏了，可能是正文里的步骤被模型忽略了，三者从外部看一模一样。我现在的排错顺序是：先手写一句完整指令看模型能不能照做，再检查元数据，最后才怀疑描述。顺序反过来的话，会在描述上改很多遍，而问题根本不在这里。
真正难写的是 description
写第一个 Skill 的时候，我以为正文是重点。后来发现正好相反，description 才是那个接口。
它不是给人看的简介，是路由条件。写“处理数据”，模型不知道什么时候该用它；写成“当用户提供 CSV 或 Excel 文件时，清洗缺失值、统一日期格式，并输出变更摘要”，命中率立刻不一样。差别不在措辞漂不漂亮，在于它有没有说清两件事：什么时候用，用来做什么。
我踩过的几个坑都在这一个字段上。
一是只写能力，不写触发条件。模型知道它能做这件事，但不知道现在是不是该做。
二是几个 Skill 的描述长得太像。“代码审查”和“代码质量检查”同时存在，模型会犹豫，结果要么选错，要么一个都不选。这种时候我宁愿合并成一个，在正文里分场景。
三是描述写得太宽，什么都沾一点，结果每次对话都被加载，Token 省不下来，行为还变得不稳定。
四是 YAML 写坏了。缩进用了 Tab，或者 description 后面少一个空格，整个文件会被静默忽略——不报错，只是不生效。第一次遇到的时候我查了半小时，一直以为是自己描述写得不够好。
还有一个反复出现的问题：描述写成了否定句。“不要用于图片处理”这种写法几乎不起作用，因为路由时模型看到的是语义匹配，不是规则表。真要排除某个场景，得给另一个 Skill 写清楚它该管的范围，靠排除法是不行的。
我现在验证描述的办法只有一个：拿三五个真实任务去跑，看它该命中时命中、不该命中时安静。写的时候觉得自己写清楚了没有用，跑一遍才知道。这个测试很土，但它比反复改措辞有效。
正文也有写法上的讲究，只是比描述宽容一些。我现在的习惯是把步骤写成可判定的动作，而不是形容词。写“仔细检查代码质量”没有用，写“检查每个数据库调用是否有异常处理，没有就标为高优先级”才有用。步骤数尽量控制在十步以内，超过十步的流程，通常是可以拆成两个的。
它和 Project、MCP 不是一回事
这三个东西经常被放在一起讲，好像在同一层，其实处理的是不同的问题。
Project 装的是背景材料：文档、规范、写作风格、代码库的约定。它给的是“知道什么”。
MCP 接的是外部世界：文件系统、数据库、某个服务的 API。它给的是“能碰到什么”。
Skill 写的是流程：先做什么，再做什么，什么情况下算完成。它给的是“怎么做事”。
我自己的判断很直接：要给的是一堆材料，放 Project；要的是访问某个系统，接 MCP；要的是一套每次都一样的步骤，写 Skill。它们当然可以叠着用，一个 Skill 里调用 MCP 工具，读 Project 里的规范，都很正常。但如果一开始就把三者混成一团，后面就分不清是上下文不够、权限不够，还是流程没写对。
这三样的成本也不在一个量级。写一个 Skill 是几十分钟的事，接一个 MCP 要跑服务、配鉴权、处理凭据，坏了自己修。所以我的顺序通常是：先看能不能用 Skill 把流程说清楚，说不清楚的再接工具。很多时候流程写清楚之后会发现，根本不需要外部系统。
我见过的一个误区是把 Skill 当成“长期记忆”用，把所有背景资料都塞进去。结果是每次命中都要读一大段和当前任务无关的内容，Token 省不下来，回答还变慢。资料该放 Project，Skill 里只留流程和判断标准，这条分界线我踩过才记住。
三者叠用的样子大概是：Project 里放着这个站的写作规范和历史选题，MCP 接的是本地文件系统和构建脚本，Skill 管的是“从草稿到发布”的那串检查。同一件事里三层各管一段，改动的时候也知道该动哪一层。如果只有一个大提示词，这三层会永远粘在一起，想改一处就得重读全部。
我现在的用法，和不确定的部分
放进 Skill 的，基本是三类：格式固定的转换，比如把结构化数据生成一张表；检查清单，比如发布前、评审前要走的那几步；我关心的评审规则，比如哪几类问题必须提。
不放的也有两类。一是需要判断的，比如“这段代码写得好不好”，这种交给 Skill 只会得到一份模板化的意见。二是变化快的流程，一周改三次的东西写成文件，维护成本比收益高。
维护成本是我最在意的一点。流程变了要改文件，改完还得确认它真的被加载到当前环境。网页端、API、Claude Code 各有一套加载机制，同一个 Skill 想在三个地方都用，实际要维护三份。这件事没什么优雅的解法，只能接受，或者干脆只在一个环境里用。
写我那个发布检查 Skill 的过程，本身就是一次清理。第一版有七步，跑了几次之后发现其中两步从来没触发过，因为我把“检查站内链接”和“检查图片路径”写成了两个动作，而实际上后者是前者的前置条件。合并之后剩五步，行为反而更稳。流程类文件的一个好处就在这里：含糊的地方写不下来，写不下来就会暴露。
团队分发是另一个问题。把 Skill 放进 Git 仓库确实比发文档好，但版本一旦分叉，行为就不可预期了——有人用的是上周的评审规则，有人用的是这周的，同一段代码审出来的结论不一样，还很难查。我暂时没有好的方案，只能约定“改了就发通知”这种很土的办法。
也不是所有流程都值得写。判断标准我用了两条：它会不会重复出现，以及每次做的时候我需不需要想一下顺序。两条都不满足的，写了也是放着。真正需要判断力的事，写下来反而会把它压成一份清单，清单执行得很好，判断却没有了。
另一个是安全。Skill 里的脚本是真的会被执行的，从网上随手抄一个下来跑，风险和自己 curl | bash 差不多。allowed-tools 里的授权是给自动化的便利，也是给自己挖的坑：它能省掉一次次确认，也意味着一个写错的脚本可以不受阻拦地跑完。我现在的做法是只用自己写的，或者逐行读过的。
推广上也别期待太高。写 Skill 比写文档贵，读它的人还得懂一点 YAML 和目录结构，改了要重新分发。我在一个小团队里试过一次，最后常用的只有两个人，其余人还是习惯直接说需求。这不算失败，流程类工具的受众本来就很窄。
至于这套东西会不会变成长期标准，我没有答案。它现在解决的是一类很具体的问题：重复流程的固化和分发。如果以后模型自己能稳定记住长期工作习惯，这部分价值会缩水。我暂时按“会长期存在但形态会变”来准备。
我现在的标准很简单：一个流程如果已经重复了五遍以上，而且每次都要在脑子里过一遍顺序，我就把它写下来。不是为了给模型用，是为了让我自己知道它到底有几步。写下来之后经常发现，有三步是多余的。
没写下来的那些，就继续在脑子里过。偶尔漏一步，算是提醒我这套东西还没覆盖完。
评论