企业官网建设流程全解析

1. 从一次失败的Skill上线说起

去年年底，我给团队内部的一个文档处理Agent加了个"合同条款抽取"的Skill。逻辑很简单：读PDF、定位关键条款、结构化输出。本地测试跑了二十来条样本，准确率看着还行，我就直接推到了线上。

结果第一周就翻车了。用户反馈说，Agent在处理某些合同时会把"违约责任"和"争议解决"两个条款搞混，输出结构也偶尔错位。我一开始以为是模型能力问题，换了更强的底座模型，情况好转了一点，但没根治。后来我把加Skill前后的日志拉出来做了逐条对比，才发现问题根本不在模型——是我加Skill的方式有问题。Skill本身引入了新的指令层级，和Agent原有的系统提示产生了冲突，导致模型在"听谁的"这件事上摇摆不定。

这件事让我意识到一个很现实的问题：给Agent装上Skill，结果真的变好了吗？这个问题不能靠感觉回答，得靠对照评测。今天这篇文章，我就把这段时间做Agent Skill对照评测的完整方法论、踩过的坑、以及一套可复现的评测流程分享出来。不管你是刚接触Agent开发的新手，还是已经在做Skill编排的老手，应该都能从中找到能直接用的东西。

先明确一下本文的讨论范围：这里说的Skill，指的是给Agent挂载的可复用能力单元，它可能是一段提示词模板、一个工具调用封装、一段脚本逻辑，或者几者的组合。对照评测，指的是在控制变量的前提下，对比"有Skill"和"无Skill"（或者"Skill A"和"Skill B"）两种配置下Agent的表现差异。核心关键词包括Agent、Skill、对照评测、Claude Skills、skill-creator，这些概念我会在正文里逐一拆解。

2. Skill到底给Agent加了什么：先搞清楚变量

2.1 Skill不是"插件"，它改的是决策路径

很多人把Skill理解成插件，觉得装上就多一个功能。这个理解在简单场景下没错，但在复杂Agent里会误导你。插件通常是"被调用时才生效"的被动能力，而Skill往往会改变Agent的决策路径——它会影响模型在每一步"要不要用这个能力""怎么用""用完怎么继续"的判断。

举个具体例子。一个没有Skill的Agent处理"帮我总结这份财报"时，它的路径可能是：读文件→分段→总结→输出。你给它加一个"财务指标提取"Skill之后，路径可能变成：读文件→判断是否财报→调用指标提取→判断是否需要对比→总结→输出。注意，这里多出来的不只是"提取"这个动作，还有两个判断节点。判断节点越多，出错概率越高，这就是为什么加了Skill反而可能变差。

所以做对照评测时，你要控制的变量不只是"有没有Skill"，还包括Skill引入的判断节点数量、指令优先级、以及它和原有系统提示的关系。

2.2 三类Skill的评测重点完全不同

我在实操中把Skill分成三类，每类的评测重点不一样：

提示词型Skill最容易做，也最容易出隐性冲突。工具型Skill的评测要看"调用决策"而不只是"调用结果"。混合型Skill的评测必须做端到端，因为中间任何一环的偏差都会放大。

提示：如果你刚开始做Skill评测，建议从提示词型入手，因为它的变量最少，最容易定位问题。等这套流程跑顺了，再上工具型和混合型。

2.3 为什么"感觉变好了"是最危险的信号

我见过太多团队用"感觉"来评估Skill效果。测试几个case，觉得输出更专业了，就上线。这种做法的问题在于：你测试的case往往是你精心挑选的，而线上遇到的是长尾分布。

更隐蔽的问题是，Skill带来的提升可能集中在某几个维度，而损害出现在你没关注的维度。比如一个"专业术语增强"Skill，可能让术语准确率从70%提到90%，但同时让回答长度增加了40%，用户阅读成本上升。如果你只盯着术语准确率，就会得出"变好了"的错误结论。

对照评测的价值就在于，它强迫你把"好"拆解成可测量的维度，并且在每个维度上做有Skill和无Skill的对比。没有对照，就没有真相。

3. 搭建一套能复现的对照评测流程

3.1 评测集怎么建：别用你自己造的题

这是我最想强调的一点。很多人的评测集是自己手写的几十条case，这些case天然偏向于Skill擅长的场景，因为你在写题时脑子里想的就是"这个Skill能解决什么"。这样的评测集测出来的结果必然好看，但没有参考价值。

正确的做法是从真实流量里采样。具体步骤：

1. 从线上日志里随机抽取最近两周的用户请求，去掉重复和明显无效的。
2. 按任务类型分层，确保每类任务都有足够样本（建议每类至少30条）。
3. 对每条请求标注"期望输出"或"可接受输出范围"，这一步最费时间，但省不得。
4. 把评测集分成两组：调优集（用来改Skill）和留出集（只用来最终验证）。

如果实在没有线上流量，退而求其次的做法是：找3个以上不参与Skill开发的人，让他们按真实使用场景提需求，你只负责记录，不引导。这样能最大程度避免"自己出题自己答"的偏差。

3.2 控制变量：除了Skill，其他都得一样

对照评测的核心是控制变量。我列一下必须锁死的项：

• 底座模型：同一个模型、同一个版本、同一组采样参数（temperature、top_p等）。
• 系统提示：除了Skill引入的部分，其余系统提示必须完全一致。
• 上下文长度：输入的历史对话轮数、检索到的文档数量要一致。
• 运行环境：同一台机器、同一批次运行，避免网络和负载波动影响。
• 评测脚本：评分逻辑、评分模型（如果用模型打分）必须一致。

我踩过的一个坑是：第一次做对照时，有Skill组用了新版的系统提示，无Skill组还是旧版，结果差异里混进了系统提示的贡献，白测了一轮。后来我养成了一个习惯——每次评测前，把两组的完整输入（系统提示+Skill+用户请求）打印出来逐字对比，确认只有Skill这一处不同。

3.3 评分维度：别只算一个准确率

单一准确率会掩盖很多问题。我建议至少覆盖以下维度：

注意"响应长度"和"延迟"这两个维度。Skill经常会让输出变长、变慢，如果你的产品对这两项敏感，它们就是硬指标。我见过一个Skill把任务完成率提了8个点，但延迟翻了一倍，最后被产品否掉了。

3.4 用模型打分时，怎么避免"自己评自己"

如果用模型做自动评分，有个陷阱：评分模型可能和被测模型是同一个，它会偏向于自己风格的输出。规避方法有两个：

一是用不同的模型做评分，比如被测用A模型，评分用B模型。二是设计评分提示时，把评分标准写得极其具体，比如"输出中必须包含X、Y、Z三个字段，缺一个扣一分"，而不是"请评价输出质量"。越具体的标准，模型的主观偏差越小。

还有一个实操技巧：让评分模型先输出理由，再输出分数。这样你能抽查理由是否合理，也能发现评分标准里模糊的地方。

4. 实测数据：Skill到底在哪些场景下真的有用

4.1 一个反直觉的结论：Skill对简单任务可能是负收益

我拿一个文档问答Agent做了对照实验，评测集按任务复杂度分了三层。结果如下（数值为任务完成率）：

简单任务上，加Skill反而掉了3个点。原因不难理解：简单任务本来就不需要额外能力，Skill引入的判断节点反而增加了出错机会。这3个点的差距在统计上不算显著，但方向是明确的。

这个结论对我的启发是：Skill不是越多越好，也不是所有任务都该挂Skill。正确的做法是在Agent的路由层做判断，简单任务走轻量路径，复杂任务才加载Skill。这也是后来我调整架构的主要方向。

4.2 工具型Skill的"该调不调"问题

工具型Skill最典型的失败模式不是调用出错，而是该调用的时候没调用。我统计过一个数据提取Skill的调用情况：

• 应该调用且调用了：72%
• 应该调用但没调用：21%
• 不该调用却调用了：7%

那21%的漏调用，大部分发生在用户表述比较口语化的时候。比如用户说"帮我看看这份材料里有没有提到钱的事"，Skill的触发条件写的是"提取财务数据"，模型就没触发。解决办法是在Skill描述里补充口语化的触发示例，或者降低触发阈值，让模型更倾向于"先调用再说"。

但降低阈值会带来7%那部分的上升。这里有个权衡：漏调用的代价通常是任务失败，误调用的代价通常只是多花一点token。所以在大多数场景下，我倾向于让Skill更容易被触发，然后通过后处理过滤掉误调用的结果。

4.3 提示词型Skill的冲突检测

提示词型Skill最隐蔽的问题是和你原有的系统提示冲突。我做过一个实验：系统提示里写"回答要简洁，不超过三句话"，然后加了一个"详细解释"Skill。结果模型在两者之间摇摆，有时简洁有时详细，一致性很差。

检测这种冲突有个笨办法但很有效：把系统提示和Skill提示拼在一起，逐句找矛盾。凡是出现"要A"和"不要A"这种对立表述的，就是冲突点。找到之后，要么在Skill里显式声明优先级（比如"当与系统提示冲突时，以本Skill为准"），要么修改系统提示给Skill留出空间。

Claude Skills的设计里有个值得借鉴的点：它把Skill的元信息（名称、描述、触发条件）和Skill正文分开，元信息常驻上下文，正文按需加载。这样既保证了Skill能被正确触发，又不会让所有Skill正文都挤占上下文。如果你在做自己的Skill系统，这个分层思路值得抄。

5. 那些评测报告不会告诉你的坑

5.1 评测集泄露：你的Skill可能"背题"了

如果你在调优过程中反复用同一个评测集，Skill会逐渐"过拟合"到这个评测集上。表现是：调优集分数一路涨，留出集分数不动甚至下降。这就是评测集泄露。

我的做法是：调优集可以反复用，但每次改完Skill，必须在留出集上跑一遍。留出集只在两个时刻打开——最终验证，以及你怀疑过拟合的时候。另外，留出集要定期更新，从新的线上流量里补充样本，淘汰旧样本。

5.2 评分者偏差：人工评分的一致性怎么保证

如果用人做评分，不同评分者的标准会不一致。我试过一个办法：先让所有评分者独立评20条，然后对比结果，把分歧大的case拿出来讨论，统一标准后再正式评。这个过程大概花半天，但能让后续评分的信度提升很多。

还有一个细节：评分时不要告诉评分者哪组是实验组。如果评分者知道哪组加了Skill，潜意识里会倾向于给实验组高分。盲评是基本要求。

5.3 统计显著性：别被小样本骗了

我见过有人用10条case的对比结果就下结论说"Skill有效"。10条样本的随机波动可能就有10个点，这种结论没有意义。经验法则是：每个维度至少30条样本，如果要做分层分析，每层至少30条。如果资源有限，宁可减少维度，也不要减少样本量。

对于比例类指标（如完成率），可以用简单的显著性检验判断差异是否可信。如果两组差异在5个点以内，样本量又不到100，基本可以认为是噪声。

5.4 长尾case：平均值好看不代表没问题

平均值会掩盖长尾问题。我建议在评测报告里专门列一节"最差case分析"，把两组里表现最差的各10条拿出来对比。很多时候，Skill带来的最大价值不是提升平均值，而是消灭了某些灾难性失败。反过来，Skill也可能引入新的灾难性失败，这些只有看长尾才能发现。

6. 从评测到迭代：Skill该怎么改

6.1 先定位问题层级，再动手改

Skill效果不好时，别急着改提示词。先定位问题出在哪一层：

• 触发层：Skill该触发没触发，或不该触发乱触发。
• 执行层：Skill触发了，但执行逻辑有问题。
• 集成层：Skill执行没问题，但结果和Agent其他部分衔接有问题。
• 表达层：结果都对，但输出格式或风格不符合要求。

不同层级的修法完全不同。触发层问题改Skill描述和触发条件；执行层问题改Skill正文逻辑；集成层问题改Agent的编排逻辑；表达层问题改输出约束。我见过有人明明是触发层问题，却一直在改执行层提示词，改了半天没效果。

6.2 小步迭代 + 回归测试

每次只改一个变量，改完立刻在调优集上跑，确认方向对了再继续。同时维护一个回归测试集，包含那些已经修好的case，确保新改动不会把它们弄坏。这个流程听起来笨，但比"大改一版再看"靠谱得多。

6.3 什么时候该放弃一个Skill

不是所有Skill都值得保留。我的判断标准是：如果连续三轮迭代，Skill在留出集上的核心指标都没有显著提升，或者提升的代价（延迟、成本、复杂度）超过了收益，就该考虑放弃。沉没成本不是理由，一个拖后腿的Skill比没有Skill更糟。

7. 我现在的Skill评测清单

最后把我现在每次做Skill对照评测都会过一遍的清单分享出来，你可以直接拿去用：

1. 评测集是否来自真实流量，是否分层，是否有留出集。
2. 两组输入是否逐字对比过，确认只有Skill一处不同。
3. 评分维度是否覆盖完成率、正确性、格式、长度、延迟。
4. 评分是否盲评，评分者标准是否统一。
5. 样本量是否足够，差异是否做过显著性判断。
6. 是否分析了最差case，是否检查了长尾。
7. 是否在留出集上验证过，是否检查了过拟合。
8. 迭代是否小步进行，是否有回归测试。

这套流程跑下来，一轮评测大概需要两到三天，比我早期拍脑袋上线慢得多。但慢有慢的价值——它让我在Skill上线前就知道它到底行不行，而不是等用户来告诉我。回到标题那个问题：给Agent装上Skill，结果真的变好了吗？我的答案是，只有当你用对照评测把"好"量化出来，这个问题才有意义。否则，你只是在赌。