最早用 WorkBuddy 的时候，我每次让它干同一类活，都得把那段说明从头打一遍：背景是什么、输出要什么格式、别碰哪些文件。后来发现它能把这种说明固化成一个 skill，写一次就能反复调用。我前前后后写了四五个，中间踩的坑比想象的多，也让我对"可复用提示词"这件事改了点看法。
一、我为什么会去写 skill
起因很具体。我们内部有个生成接口文档的小流程：先让我把控制器里的路由和参数贴过去，再要求它按固定模板输出，末了还得提醒它"不要擅自改源码，只改文档目录下的文件"。这套话说一遍就要两百多字，一周要用三四次，每次都重写一遍，打字打到烦。
第一次写 skill 时我想得简单：把那段话原样塞进去就行。结果跑起来完全不是那么回事，它该问的没问，该限制的没限制。下面三个坑是我在头两个 skill 上实实在在栽过的。
二、第一个坑：没设权限，它动了不该动的目录
我那个文档 skill 没声明可访问范围，它默认就按自己的能力去读项目根目录。有一次它为了"核对接口"，顺手把我本地还没提交的几个配置文件也读了，还在输出里把里面的连接串打了出来。虽然没造成损失，但把我吓一跳——我根本没告诉它能看那些。
后来我每个 skill 第一句都写清"只能读取 docs/ 和 src/Controllers/，禁止读取任何含 secret、appsettings 的文件"。这句约束加上之后，再没出过类似问题。
三、第二个坑：范围写太宽，它开始乱改
另一个 skill 我想让它"帮忙整理代码"，描述里写了"优化相关文件"。这下好了，它把三个完全无关的文件都动了一遍，理由是"看起来可以顺手重构"。我 review 的时候差点没认出来哪些是我写的、哪些是它加的。
从那以后我把范围压到最小：每次只说"本次只修改我指定的那一个文件"。宁可多叫几次，也不让它自由发挥。
四、第三个坑：忘了给示例输入输出
最关键的一个坑是示例。我前面两个 skill 都说"按模板输出"，但没给模板长什么样。它每次生成的格式都不太一样，我得手动调。第三个 skill 我老老实实贴了一段期望的输入和输出样例，结果一次就对了，基本不用返工。
现在回头看，给示例这一步最省时间。当时嫌麻烦没写，后来返工花的功夫比写示例多三倍都不止。
五、我现在的看法：skill 不是银弹
写了四五个之后，我对"可复用提示词"的态度反而变保守了。它确实好用，但只适合三类任务：高频（一周用几次以上）、步骤固定（每次流程差不多）、解释成本高（说清楚要费半天劲）。这三条缺一条，我宁愿当场现写一段话，也不值得专门抽成 skill。
那种"把什么都做成 skill"的思路我试过，后来一半都荒废了——因为流程一变，维护 skill 本身也成了负担。所以现在我新增 skill 之前会先问自己：这个月还会用第三次吗？不会的话，就不写。
（写完这篇我又去翻了下，年初那个"自动生成周报"的 skill 其实已经两个月没碰了，正好印证上面这句。准备这周把它删掉。）
六、一个我留着没删的 skill
说一个反过来成功的例子，免得整篇都在讲坑。我有个"给接口补中文注释"的 skill 一直留着，因为它刚好满足前面三条：高频（每次加新接口都要用）、步骤固定（读方法签名、读参数类型、按模板写三行说明）、解释成本高（得说清我们注释的措辞规范）。这个 skill 我连示例都给了两段，运行半年基本零返工。
对比之下，那个"自动生成周报"的 skill 失败，恰恰是因为步骤不固定——每周做的事不一样，模板套不进去，最后还是得我一句句改。所以现在我判断一个任务值不值得做成 skill，先拿这三条卡一遍，卡不过的就老实现写，不勉强。