很多人开始写 Skill 以后，很快就会遇到第二个问题：
不是“要不要写”，而是“写到多细才合适”。
写太粗，AI 还是容易自由发挥。
写太细，Skill 又会变得很难维护，稍微换个项目就不适用。
所以我后来越来越在意的，不是 Skill 写得长不长，而是它的粒度到底对不对。
Skill 太粗会发生什么
太粗的 Skill，通常像这种风格：
“你是一个资深工程师，请帮我高质量完成任务。”
这句话当然没错，但它几乎没有真正的约束力。
当它过于抽象时，AI 很容易：
- 按自己的默认习惯做
- 忽略你项目里的特殊边界
- 在你没强调的地方自由发挥
也就是说，太粗的 Skill 更像一个姿态，而不是一个流程工具。
Skill 太细又会发生什么
另一个极端，是把所有细节都塞进去。
比如：
- 每个步骤都写死
- 每种输出都写死
- 连小的实现偏好都写进去
- 某个项目里临时性的细节也长期保留
这样做短期可能很稳，但很快会出现两个问题：
第一，维护成本太高。
只要项目有变化，Skill 就要跟着改。
第二，迁移性很差。
你换一个项目、换一个团队、换一种任务，它可能就基本不能复用了。
我现在更推荐的粒度是什么
我更喜欢把 Skill 写在“够稳定地约束一类任务，但不绑死所有实现细节”的层级。
简单说，就是优先固定这三类东西：
- 流程
- 边界
- 输出
比如：
- 先列测试矩阵，再写测试
- 不做无关重构
- 先说明影响范围，再动代码
- 输出按风险等级排序
这些内容的好处是：
- 对同类任务长期有效
- 不会因为项目小变化就全部失效
- 仍然能明显提升稳定性
怎么判断一个 Skill 是否已经足够可用
我通常会看三个信号。
第一个，同类任务是不是能重复执行。
第二个，AI 的输出是不是比以前稳定很多。
第三个，我是不是不用每次再补一大段解释。
如果这三个信号都出现了，说明这个粒度大概率已经合适。
反过来，如果你还是经常要临场补很多规则，就说明它可能还太粗。
如果你每次项目一变都得大改 Skill，就说明它可能太细。
Skill 应该怎么持续更新
我不太建议一开始就想把 Skill 写到完美。
更现实的方式是：
- 先写一版最小可用
- 每次踩坑后补规则
- 把高频失误转成明确约束
比如你发现 AI 老是：
- 直接写测试，不先列矩阵
- 顺手改无关文件
- 输出没有验证方式
那就把这些都写回 Skill。
这样它会越来越像一份真实工作经验沉淀，而不是一份空泛说明。
粒度合适的 Skill，长什么样
我现在心里有一个很简单的标准：
它不需要写到每个动作都僵硬，但至少要让 AI 明白：
- 这类任务的正确顺序是什么
- 哪些事绝对不能越过
- 最后要交付什么样的结果
只要这三件事清楚，Skill 通常就已经有用了。
最后
一个 Skill 到底应该写到多细，才真的能复用？
我现在的答案会比较明确：
不是越多越好，也不是越少越高级。
真正合适的粒度，是它能稳定约束一类任务，又不会被某个项目的临时细节彻底绑死。
Skill 最重要的不是写得满，而是写得刚好足以让经验被重复执行。 到底应该写到多细，才真的能复用？
我现在的答案会比较明确：
不是越多越好，也不是越少越高级。
真正合适的粒度，是它能稳定约束一类任务，又不会被某个项目的临时细节彻底绑死。
Skill 最重要的不是写得满，而是写得刚好足以让经验被重复执行。
