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

很多人开始写 Skill 以后，很快就会遇到第二个问题：不是“要不要写”，而是“写到多细才合适”。写太粗，AI 还是容易自由发挥。写太细，Skill 又会变得很难维护，稍微换个项目就不适用。所以我后来越来越在意的，不是 Skill 写得长不长，而是它的粒度到底对不对。Skill 太粗会发生什么太粗的 Skill，通常像这种风格：“你是一个资深工程师，请帮我高质量完成任务。”这句话当然没错，但它几乎没有真正的约束力。当它过于抽象时，AI 很容易：按自己的默认习惯做忽略你项目里的特殊边界在你没强调的地方自由发挥也就是说，太粗的 Skill 更像一个姿态，而不是一个流程工具。Skill 太细又会发生什么另一个极端，是把所有细节都塞进去。比如：每个步骤都写死每种输出都写死连小的实现偏好都写进去某个项目里临时性的细节也长期保留这样做短期可能很稳，但很快会出现两个问题：第一，维护成本太高。只要项目有变化，Skill 就要跟着改。第二，迁移性很差。你换一个项目、换一个团队、换一种任务，它可能就基本不能复用了。我现在更推荐的粒度是什么我更喜欢把 Skill 写在“够稳定地约束一类任务，但不绑死所有实现细节”的层级。简单说，就是优先固定这三类东西：