你有没有过这种经历——
想改好一个东西，改了半天，最后发现还不如原来的版本。
问题往往不在能力。在你一上来就动手了。
这两天我读到一个挺有意思的开源项目：skill-evolve。它不干别的，专门改别的 skill。整个项目只有一个文件，266 行，没脚本、没依赖。
读完最大的感受是：它不是一本「怎么写 skill」的说明书，而是一套能照着走的流程。
它最反常识的地方，是给你立了两条禁令——不许凭直觉动手，不许一次改完。

▲ 全景拆解
一、它到底是什么说白了，它是个「元 skill」：别的 skill 负责干活，它负责进化别的 skill。
核心哲学就一句话：好 skill 是总结出来的，不是设计出来的。
它和官方那个 skill-creator 正好接力——skill-creator 负责从 0 到 1 写出初版，skill-evolve 接在后面，负责从 1 到 N 持续打磨。
最省心的是它极简：不产出知识，只提供方法。
二、五步循环，一步都不能跳整套方法，就是一个五步循环。
冷启动。读完目标 skill 的全部内容，回答四个问题，把直觉先记下来。但别急着改——直觉只是假设。
观察。挑 3-5 个真实 prompt 去跑：至少一个核心场景、一个边缘场景、一个「本不该触发」的场景。每跑完一个就立刻记观察，不等全部跑完。
提炼模式。最关键的一步。不逐个修 bug，要找共性——同类问题出现两次以上，就值得提炼成一条模式。
改写。每轮只动优先级最高的一到两条模式。原则就三条：最小改动、解释清楚为什么、改完可验证。
验证。用同一批 prompt 重跑，看问题是不是真的少了。连续两轮没有新模式，就算收敛。

▲ 五步循环
三、撑起方法的，是三条底层机制OTF，边做边总结。不等全做完再回头——发现模式的那一刻，就记录、归纳、应用。
JIT，小步快跑。不追求一次到位，先交付能用的版本，拿反馈再迭代。
Bootstrap，自举。每一轮的笔记，是下一轮的燃料。跑满三轮做一次递归压缩：十五个问题压成五条模式，再压成两三条原则，最后压成一句洞察。
它还配了一张收敛判断表：问题消失就是有效；减轻但没消失，同方向再改一轮；出现新问题，就得回滚。
一句话点透：不追求完美——60% 到 90% 的性价比，远高于 90% 到 95%。

▲ 三条底层机制与收敛判断
四、真正拉开差距的，是这些细节翻完整份文件，最有意思的几处：
它禁止你一次改完。理由很实在：改太多，你就分不清哪个改动起了作用、哪个引入了副作用。克制，是为了可归因。
它要的是模式，不是补丁。两条模式比八个补丁更有价值——因为模式能覆盖未来还没出现的新 prompt。
它反复解释「为什么」，而不是堆规则。它明确写：给 AI 讲清原因，比让它记住一堆 MUST / NEVER 更有效。
它把笔记当成资产。观察、模式、改动记录都不许扔，是下一轮的上下文。改完就扔，等于每轮从零开始。
它划清了人和 AI 的分工。提炼模式是执行者的事，质量好不好，是用户说了算。

▲ 设计巧思与实战
五、但别把它神话三个边界，说在明面上：
它不创造 skill。那是 skill-creator 的活，它只改已有的。
测试样本决定上限。你喂什么 prompt，它就只能提炼出什么模式。样本选歪了，功夫全白费。
改三轮还不收敛，该收手。多半是 skill 职责太宽，或已超出模型能力——这时候硬改没用。
写在最后拆完最有触动的，不是它的五步，而是一个很朴素的判断：
凭直觉改东西，只会越改越乱。
先跑起来，观察，再动手，然后小步验证。这套顺序，改的其实不只是 skill。
你最近有没有「越改越乱」的经历？或者你最想拿这套方法，改进自己的哪个工具？评论区聊聊。
本文为开源项目的技术拆解，仅供参考。项目结构与案例引自仓库文档（github.com/OrangeViolin/skill-evolve，MIT 协议）。文中观点仅代表作者个人解读。
本文文字与图片部分由AI辅助生成，特此声明。