你的 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 个设计模式用漫画 答题的方式讲目前正在开发中。如果你觉得这类内容有意思搜一下「爪爪代码冒险记」或者等我后面的文章。