你的 AI 品控规则三个月就失灵，问题出在「黄金样本集」上

我做了三年 sharp-skills，最常被问的一个问题是：「我的品控规则第一周跑得挺好，怎么过两个月 AI 输出又变烂了？」

99% 的答案都指向同一个东西——你那个黄金样本集是凑出来的，不是设计出来的。

什么是黄金样本集

简单说：它就是品控规则的「测试用例」。

任何工程化的规则系统都需要两样东西——规则本身，以及用来验证规则是否还在线的样本集。规则告诉你「什么样的输出才算合格」，样本集告诉你「现在的输出还合不合格」。两者缺一不可。

在 sharp-skills 里，每个模块（tech-writing / dataviz / copywriting / api-design / interview / presentation）都配套一组黄金样本集。规则改一版，用样本集跑一遍，能立刻看出来这条规则到底有没有真的约束住 AI。

很多团队做品控只做了一半——规则写了一堆，但样本集是临时从历史输出里捞几个当例子。这就是问题的根源。

真实样本为什么不能用

我观察到的最常见的错误：开发者在搭建品控规则时，从过去几周的 AI 输出里「挑了些好的」放进样本集。

听起来很合理——这是 AI 的真实输出啊。但问题在于：

真实样本噪声太大。一个 AI 生成的 API 文档可能同时违反了 5 条规则（路径命名飘忽 / 错误码不统一 / 示例不可运行 / 被动语态泛滥 / 章节失衡），你拿它当样本，规则 A 改完之后输出还是不合格，团队就开始怀疑规则 A 的有效性——其实问题在规则 B，你根本定位不到。

真实样本无法支撑反向验证。一条品控规则被设计出来，是为了让 AI「不要这样输出」。但你从历史里捞的样本大部分是「AI 已经这样输出了」的实例——它们是失败案例。你没有它「原本应该这样输出」的对照，怎么知道规则定义的「合格」长什么样？

真实样本的代表性是幻觉。你以为「我存了 50 个真实输出，足够代表 AI 的能力分布了」。但这 50 个真实输出背后是你的 prompt、你的上下文、你的运气。你的下一次输出可能完全不是这个分布。真实样本的分布 = 你历史经验的分布，不是 AI 真实能力的分布。

所以，黄金样本集必须是人工构造的——针对每条规则去设计。

黄金样本集的三种样本类型

一组合格的样本集至少包含三种类型，缺一不可：

类型一：合规样本（Positive）

这是规则定义的「好的输出应该长什么样」。

举例：你有一条规则是「API 文档必须包含完整的 cURL 示例」。合规样本就是一篇标准文档，里面有一段 curl -X POST 'https://api.example.com/v1/users' -H 'Authorization: Bearer xxx' -d '{...}'，完整可运行。

合规样本的作用是测试规则有没有被过度收紧。如果 AI 输出明明长得很像合规样本，但规则系统把它判为违规，那说明规则写得过头了。

每个品控模块至少需要 5-8 个合规样本，覆盖该模块最常见的「合格形态」。

类型二：违规样本（Negative）

这是用来测试规则能否真的识别「不合格输出」的。

举例：同一条「API 文档必须包含 cURL 示例」规则。违规样本可以设计成以下几种：

• 完全没示例（最严重违规）
• 有示例但是 Python SDK 调用代码（不是 cURL）
• 有示例但是伪代码，参数用 <placeholder>
• 有示例但 URL 写错（/v1/user 少了 s）

违规样本不能只造一种「明显的违规」。一个有效的违规样本集应该覆盖违规的不同严重程度——轻微违规（标注缺失）、中度违规（关键信息缺失）、严重违规（整个章节缺失）。

每条 MUST 级别的规则至少需要 3-5 个违规样本。

类型三：边界样本（Edge）

这是真正考验品控规则质量的样本。

举例：还是那条规则。边界样本可以是：

• 文档里既有 cURL 示例，也有 Python SDK 示例——应该判合规还是违规？
• 文档里只有一个 cURL 示例，但其他 SDK 有详细说明——算违规吗？
• 文档在「调用流程」章节提了一句「可通过 cURL 调用」，但没给完整示例——这算合格还是不合格？

边界样本回答的问题是：当规则碰到需要解释的情况时，它应该怎么判？

边界样本是品控规则从「能跑」走向「可用」的关键。没有边界样本，你的规则就是个机械的字符串匹配器；有了边界样本，规则才有了真正的判断力。

黄金样本集的设计原则

构造样本集不是越多越好。三条原则比数量更重要：

正交性——每个样本只测一条规则。

新手最容易犯的错误：一个样本里塞了五六个违规，企图一次测五条规则。结果是规则 A 改完之后整个样本还是红的，你完全定位不到是哪条规则失效了。

正确的做法是：一个样本只触发一条规则的判定。改 A 之后这个样本变绿了，说明 A 生效了；改完还是红的，说明 A 没改对。

确定性——样本的判定结果不能有歧义。

一组样本集应该有「人工 review 出的标准答案」——每个样本应该被判定为合规、违规中的哪一种，由人来标注，而不是交给 AI 来标注。

为什么？因为 AI 标注的样本集存在自循环偏差——规则系统用 AI 标注的样本来验证 AI 生成的输出，相当于让 AI 既当运动员又当裁判。人工标注的成本必须花。

可维护性——样本要带元数据，方便后续 review。

一个样本至少包含：输入 prompt、预期输出（或预期违规点）、违反/符合的规则 ID、判定的难易程度（简单/中等/困难）、最后 review 时间。

最后一项尤其重要。品控规则会腐烂，样本也需要 review。每季度至少跑一遍样本集，删掉已经过时的样本，加上新发现的边界情况。

一个实际的反信号

去年我做过一个 sharp-api-design 模块的黄金样本集，迭代到第三版的时候出现了典型的反信号——样本集过大。我之前觉得「样本越多越能覆盖场景」，结果堆到了 200 多个样本，review 一次要花一周。

后来我停下来分析：200 个样本里，有 60 个是「路径命名飘忽」这一条规则的样本，而这条规则的违规模式只有 5-6 种——剩下 54 个都是同一个违规模式的微小变种。

砍掉重复样本后，路径命名这条规则只留 8 个样本就够用了——一个典型合规、一个完全没用路径前缀（违规）、一个混合大小写（违规）、一个跟动词资源混用（违规）、三个边界样本（路径里带数字 / 路径里有中文 / 路径很长）。

这就是「样本不是越多越好」的真实含义：样本的价值在于正交性，不在于数量。

写在最后

黄金样本集是品控规则的生命线。一个没有样本集支撑的品控规则，就是个「感觉不对就改 prompt」的工程化外壳——比不写强一点，但撑不过模型迭代。

如果你刚开始搭建 sharp-skills 类似的品控系统，先花一周时间设计黄金样本集，再花一周写规则。这个顺序不要反过来。规则写得再漂亮，没有样本去验证它，它就是写在墙上的口号，不是工程化的约束。

我在做一个用卡皮巴拉讲设计模式的微信小程序「爪爪代码冒险记」，23 个设计模式用漫画 + 答题的方式讲，目前正在开发中。如果你觉得这类内容有意思，搜一下「爪爪代码冒险记」，或者等我后面的文章。