一个 Skill 到底应该写到多细，才真的能复用

很多人刚开始写 Skill 的时候，很快就撞上了第二个问题：

不是"要不要写"的纠结，而是——"写到多细才够用"。

写太粗吧，AI 撒欢儿地自由发挥；写太细呢，Skill 本身又变得臃肿难维护，换个项目基本就废了。

后来很多人越来越在意的，根本不是 Skill 的长度，而是它的粒度到底对不对。

Skill 太粗会发生什么

太粗的 Skill 长什么样？通常是这样一种风格：

"你是一个资深工程师，请帮我高质量完成任务。"

这话没错，但几乎没有任何真正的约束力。

一旦过于抽象，AI 就很容易：

• 按自己的默认习惯走老路
• 忽略你项目里那些特殊边界
• 在你没强调的地方尽情自由发挥

说白了，太粗的 Skill 更像一个姿态，而不是一个流程工具。

Skill 太细又会发生什么

另一个极端是，把所有细节一股脑全塞进去。

比如：

• 每个步骤都写得死死的
• 每种输出格式都固定住
• 连小的实现偏好都写进去
• 某个项目里临时性的细节也长期保留

这样做短期看可能很稳，但很快暴露出两个问题：

第一，维护成本急剧攀升。项目稍有变化，Skill 就得跟着改一轮。

第二，迁移性极差。换一个项目、换一个团队、换一种任务类型，它基本就废了，没法复用。

现在更推荐的粒度是什么

更推荐的做法，是把 Skill 写在"够稳定地约束一类任务，但不绑死所有实现细节"这个层级上。

简单说，就是优先固定这三类东西：

• 流程
• 边界
• 输出

举个例子：

• 先列测试矩阵，再动手写测试
• 不做无关重构
• 先说明影响范围，再碰代码
• 输出按风险等级排序

这些内容的好处很明显：

• 对同类任务长期有效
• 不会因为项目小变化就全部失效
• 仍然能显著提升稳定性

怎么判断一个 Skill 是否已经足够可用

通常从三个信号来判断。

第一个，同类任务是不是已经可以重复执行了。

第二个，AI 的输出是不是比以前稳定很多。

第三个，是不是不用每次再补一大段额外解释。

如果这三个信号都出现了，说明这个粒度大概率已经对了。

反过来，如果还经常要临场补很多规则，说明它可能还太粗。

如果每次项目一变就得大改 Skill，说明它可能太细了。

Skill 应该怎么持续更新

不推荐一开始就把目标定在完美上头。

更现实的方式是：

• 先写一版最小可用的版本
• 每次踩坑后补一条规则
• 把高频失误转成明确的约束

比如发现 AI 老是：

• 直接上手写测试，不先列矩阵
• 顺手改掉无关的文件
• 输出里没有验证方式

那就把这些都写回 Skill 里。

这样它就会越来越像一份真实工作经验的沉淀，而不是一堆空泛的说明。

粒度合适的 Skill，长什么样

现在有一个很简单的衡量标准：

它不需要写到每个动作都僵硬，但至少要让 AI 明白：

• 这类任务的正确顺序是什么
• 哪几件事绝对不能越过
• 最后要交付什么样的结果

只要这三件事清楚了，Skill 通常就已经能发挥作用了。

最后

一个 Skill 到底应该写到多细，才能真的复用？

答案其实很明确：

不是越多越好，也不是越少越高级。

真正合适的粒度，是它能稳定约束一类任务，又不会被某个项目的临时细节彻底绑死。

Skill 最重要的不是写得满，而是写得刚好足以让经验被重复执行。