AI Coding 实践半年后，关于 Skill 的自迭代和效果评估的思考

前几天，团队有人给我提了个 skill 的变更。

我盯着看了半天。

逻辑写得很细，挑不出什么毛病。当我想要点击合并的那一刻，心里有个声音：这条优化，到底有没有用，我说不清了。 😅

以前不是这样的。

9 个 skill 的简单日子

我刚搞这个工作流那会儿，一共 9 个 skill，对应 9 个关键研发节点。

那时候加东西很简单。没有现成的内容，谁想往 skill 里塞一段逻辑，直接写进去就行。也不需要评估——那时候是"有"和"没有"的区别。从 0 到 1，加进去就一定有用，谁都看得见。

后来 skill 从 9 个变成了 69 个。

数量多了是一方面，更要命的是每个 skill 都越长越复杂。我们最重要的那个 skill——从 PRD 出技术方案的"Plan"——它不止分前端、后端、客户端，还在好几个特殊业务域里做了专门的落地。

往里加一个优化点，容易。 但加完之后问一句：这条逻辑，是真的有效，还是我以为它有效？对谁有效？只对我，还是对所有人？只对 B 端，还是对 C 端也行？只对某个业务域，还是对所有需求？

这些问题，现在很难答。

我自己都判断不明白了

以前评估 skill，分两个阶段。

前期，全量新增。 加进去，合并，完事。 中期，靠人判断。 我看一眼，逻辑"还行"，过。

可现在不行了。

我们已经趟过了大部分常见需求，剩下的全是更深、更难的边角。大家提上来的变更，一个个都做得很细、很深。

我刚开始还能判断明白。现在，我自己都判断不明白了。

不是它写得不对，是我看不出来它"对到什么程度"。

到这一步，靠人脑子拍板，已经兜不住了。

先得知道哪里差，才谈得上改

既然自己看不出毛病，那就让历史来告诉我们。

我们手上有一座金矿：从Zeus工作流体系开始使用，直到到现在为止，已经跑过 300 多个需求，每一个都是真实评审过、纠错过、最后上线了的。

挑一批有代表性的——大的、中的、小的，各个业务域都来几个——当用例集。然后干一件事：回放。

把现在的 skill 拉回来，重新跑一遍这些老需求的"Plan"环节。跑出来的技术方案，跟当时真正上线的那份文档，摆在一起比。

一比，差异就出来了。

哪里漏了，哪里错了，哪里没当时周全——一条条列成差异项。

光列差异还不够。每条差异，再追问一句：当时为什么那么定？是 skill 的逻辑有洞，还是知识库里少了某块内容？

顺着这条线，就能给出具体的优化建议——不是"再完善一下"这种空话，而是"在 Plan 的第几步、补一个什么样的判断"。

然后照着改。

这才是真正的迭代——让历史需求反过来告诉你，skill 该往哪儿改。

改完，还得验证它是不是真变好了

但改完不能拍拍屁股走人。

因为经常有一种情况：你为了补一个洞，顺手把别的地方弄松了。修好一个，弄坏俩，太常见了。

所以改完之后，还有一道专门的关卡——一个评估 skill 的 skill。

用 skill，去测 skill。听起来绕，道理很简单：既然人判断不明白了，就让一套固定流程来判。

它怎么测，说几个我觉得最有意思的点。

第一，考试不能泄题。 🙈 我们给每个需求备了三样东西：一份 PRD 摘编，一份标准答案，一份"屏蔽清单"。回放的时候，标准答案全部遮住，skill 看不见。零探针，不给任何指向答案的提示——否则测的是它背题的能力，不是真本事。

第二，新老版本同卷同题。 老 skill 和新 skill 跑同一批需求，prompt 除了 skill 文件不一样，其他逐字相同。

第三，跑两遍。 模型有随机性，跑一遍不准。单次差异在一个服务以内的，当噪音扔掉。

最后看什么？先看覆盖率——比如一个方案最后要改 19 个服务，新老 skill 分别认出了几个，一目了然。

但光看覆盖率不够，找全服务只是第一步。我们在深度上又分了几层：决策点有没有识别对、跨服务链路跟上线实现一不一样、PRD 每个功能点有没有明确处置、字段时限这些口径对不对。

评分这步最怕偏心。所以我们让模型盲评——答卷匿名，老 skill 答的叫 A，新 skill 答的叫 B，评审的根本不知道哪个是哪个，一道道按标准判。

这样判出来的分，才作数。

裸分打平，不代表没差异

整个流程里，我最喜欢的是最后这一步——机制归因。

经常出现一种情况：新老 skill 跑下来，分数打平。

打平了，是不是说明这次优化没用？

不一定。

裸分打平，不代表无差异。 我们会一个服务一个服务去抠：这个服务，老 skill 怎么找的、新 skill 怎么找的，差在哪儿。

有一次跑下来，19 个服务里 15 个打平。但细看才发现——有一个，老 skill 是"三选一"含糊带过的，新 skill 是清清楚楚独立点名的；还有一个，老 skill 直接漏了，新 skill 命中了。

分数一样，质量天差地别。 🎯

这一步光靠机器的数字给不出来，得靠人去对。但有了前面的分数打底，人对起来就有方向、有边界了。

评估 skill，不只评估回放出来的改动

还有一件事得说清楚。

前面那个"回放 → 找差异 → 改"的闭环，是 skill 迭代的一条主线。但评估 skill 不是只为这条线服务的。

团队里任何人，因为任何原因改了 skill——可能是新接了个业务域，可能是补了个边界场景，也可能就是觉得某段逻辑不顺——改完，都过同一套评估。

评估 skill 是个公共出口。它不在乎你是怎么改的、为什么改，它只看一件事：改完之后，到底有没有变好。

这样一来，整个 skill 的迭代就转起来了：

回放找差距 → 改 → 评估验证 → 再回放……

每转一圈，都知道自己是往前走了，还是在原地打转，甚至退步。

skill 本身，也是要工程化建设的

做完这一圈，我突然反应过来一件事。

做 skill，跟做系统架构设计，是一回事。

刚开始搭建系统，5 个接口、10 个接口，简单得很。越往后越复杂，越复杂越要规矩，最后就到了工程化建设的阶段。

skill 也一样。它本身就是个工程，而且是个更难、更高维度的工程——因为它要约束的，是 AI 的行为。

我们现在这套工作流，本质就是在做工程化建设：一步步把规矩、把质量体系、把回归机制搭起来。

这次搭的这套"迭代 + 评估"机制，就是其中一块拼图。它能让 skill 的每一次迭代，变得稍微可控一点——从"我觉得更好了"，变成"bench 上 +N%"。

最后

9 个 skill 的时候，我想的是"怎么让它能用"。 69 个 skill 的时候，我想的是"怎么知道它有没有变好"。

很多同学觉得 AI 代替了我们，我们未来怎么办。其实 AI 代替的不是我们，只是我们现在做的工作，而我们未来要去做在 AI 时代更有价值的新的工作。

祝好