评估驱动、失败优先：让 Skill 越改越好

写 Skill 最怕什么？怕写完之后不知道好不好用，怕改了这里坏了那里，怕花了大力气结果智能体还是不听话。

今天分享一个让 Skill 越改越好的方法论：先观察失败，再针对性解决；先定义标准，再验证效果。

先让智能体「裸跑」

很多人一上来就想把 Skill 写得面面俱到，恨不得把所有可能的情况都考虑进去。这种做法往往事倍功半，你花了大量时间写的规则，可能根本不是智能体真正需要的。

更聪明的做法是：先让智能体不用任何 Skill，直接做一遍任务。

比如你想做一个产品卖点提炼的 Skill。先别急着写，找一个真实的产品，直接让智能体提炼卖点，看看它会输出什么。

你可能会发现这些问题：卖点写得太泛，比如「质量好」、「性价比高」，放到任何产品上都适用；抓不住核心差异化，没有突出这个产品和竞品的区别；卖点之间有重复，换个说法其实是同一个意思；没有考虑目标用户，卖点和用户痛点对不上。

这些问题，就是你的 Skill 要解决的问题。

失败点就是需求清单

把观察到的失败点记录下来，它们就是你的需求清单。

拿上面的例子来说，你的需求清单可能是：卖点必须具体，不能用「质量好」这类万能词；必须对比竞品，突出差异化；卖点之间不能重复；必须结合目标用户的痛点。

有了这个清单，你就知道 Skill 里该写什么了。每一条需求，对应 Skill 中的一条规则或一个步骤。

这种方法的好处是：你写的每一条规则都是有的放矢的，都是针对真实问题的解决方案，而不是凭空想象的「可能有用」。

先写考题，再写答案