你写的 AI 品控规则三个月就过期——不是规则错了，是你没给它做“回归测试“

用了半年 sharp-skills我发现一个很少有人聊的问题品控规则会腐烂。不是规则本身写错了而是规则写完那一刻是对的三个月后就不对了。模型升级了业务场景变了团队成员换了一茬——规则文件还躺在那里像一份没人维护的测试用例表面上覆盖着实际上已经漏了。很多人把 sharp-skills 的规则文件当成写一次就搞定的配置装上就不管了。这跟写完单元测试再也不跑是一个性质的问题。规则腐烂的三个信号我维护着一套 12 条 MUST 规则的技术文档品控配置。三个月前效果很好AI 输出的文档结构清晰、用词规范。三个月后我发现输出质量开始往下掉但规则一条都没改。第一个信号同一规则同一输入输出变了。这条规则是MUST: 所有代码示例必须包含错误处理逻辑。三个月前 AI 生成的示例里会加 try-catch 或 Optional 处理。三个月后模型升级了它开始把错误处理写在示例后面的文字说明里代码块本身还是裸的。规则没变但模型对包含的理解变了。第二个信号规则之间开始打架。我有两条规则一条是MUST: 段落不超过 5 行另一条是SHOULD: 技术概念必须配代码示例。三个月前这俩和平共处。后来模型变得更听话了每段都硬塞一个代码示例导致段落虽然不超 5 行但全是碎代码块可读性反而下降。规则没错但模型的执行策略变了原来不冲突的规则开始冲突。第三个信号新增规则效果递减。前 10 条规则上线时输出质量从 60 分提到 85 分。后来加了第 11 条、第 12 条效果几乎看不出来。不是规则写得不好是前面 10 条已经覆盖了 80% 的问题场景后面加的规则要么跟已有规则重叠要么场景太边缘。但你不知道因为没有回归测试机制。品控规则需要回归测试代码有回归测试品控规则也该有。做法不复杂。我给每套规则配了一个黄金样本集——10 到 20 个有代表性的输入每个输入配一个期望输出特征清单。每次模型升级或者规则修改后拿这批样本跑一遍看期望特征是否仍然满足。举个具体的例子。我的技术文档品控规则里有一条MUST: API 文档必须包含请求示例和响应示例。黄金样本集里有一个输入是写一个用户注册接口文档期望特征是输出包含 POST 请求示例和输出包含 JSON 响应示例。模型升级后我跑了一遍黄金样本发现 AI 开始把请求示例写成 curl 命令而不是 JSON body。特征包含 POST 请求示例还在但实际质量已经偏离了我的预期。我需要把特征细化成包含 JSON body 格式的 POST 请求示例。这就是回归测试的价值不是验证规则是否被遵守而是验证规则被遵守的方式是否符合预期。黄金样本集不需要多正式一个 Markdown 文件就够样本 3用户注册接口文档输入写一个用户注册接口文档 期望特征 - [x] 包含 POST 方法的请求示例 - [x] 请求示例使用 JSON body 格式 - [x] 响应示例包含成功和失败两种情况 - [x] 字段说明使用表格 每次跑完手动打勾就行。20 个样本大概花 30 分钟比你重新审一遍规则文件高效得多。规则的保质期模型迭代速度比业务快得多。我的经验是小版本更新同一代模型的调优规则基本不用动跑一次黄金样本确认就行。大版本更新换了一代模型至少 30% 的规则需要调整。模型变强了有些原来需要的约束变得多余模型的行为变了有些规则的执行方式需要收紧。业务场景变化如果业务方向调整了比如从 To B 文档变成 To C 文案那不是调整规则的问题是换一套规则配置的问题。很多人忽略的一个事实sharp-skills 的规则文件是绑在模型上的不是绑在业务上的。你换了个更强的模型原来的规则可能变成了过度约束。一个能自己处理段落长度的模型你还强加MUST: 段落不超过 5 行反而限制了它的发挥。我的做法是每个季度做一次规则 review三步跑黄金样本集标出不通过的样本。对不通过的样本判断是规则需要修改还是规则需要删除。对通过的样本判断是否有规则已经冗余——如果删掉某条规则输出质量没变化这条规则就可以退休了。第三步很重要。规则只增不减是品控配置腐烂的主要原因。你加了 20 条规则3 个月后可能只有 12 条还有效但你不删那 8 条死规则就在浪费模型的注意力预算。版本管理不是可选项我们团队踩过一个坑。两个人同时改了同一套品控规则一个加了MUST: 禁止使用被动语态另一个加了一条SHOULD: 技术描述使用被动语态以增加客观性。两个人都不知道对方改了直到输出结果变得精神分裂。品控规则文件必须走版本管理。不是用 Git 管一下就行而是要跟代码 review 一样改规则得有人看。具体做法规则文件放 Git每次修改提交 PR至少一个人 review。PR 描述里必须写为什么改这条规则——是因为模型升级了还是因为业务场景变了还是因为规则之间冲突了。修改合并后跑一次黄金样本集结果贴在 PR 里。这套流程跟代码管理没本质区别。品控规则就是代码它有逻辑、有依赖、有副作用凭什么不需要 review从写规则到养规则sharp-skills 的核心理念是把领域品控标准编码成可执行规则。但很多人停在编码这一步就不管了。规则不是写完就交付的产品是种下去需要持续维护的植物。模型在变业务在变规则也得跟着变。写规则花了你 2 小时养规则可能要花你每个月 30 分钟——但这 30 分钟决定了你那 2 小时的投入是不是还值钱。如果你用了 sharp-skills 三个月以上建议做一件事打开你的规则文件逐条问自己这条规则现在还有效吗。你会惊讶地发现有些规则你已经不需要了有些规则该改了有些规则从来就没起过作用。npx skills add https://github.com/zhouhuijia/sharp-skills 装一套规则只要 5 分钟但让这套规则持续有效需要的是一套生命周期管理的方法。我在做一个用卡皮巴拉讲设计模式的微信小程序「爪爪代码冒险记」23 个设计模式用漫画 答题的方式讲目前正在开发中。如果你觉得这类内容有意思搜一下「爪爪代码冒险记」或者等我后面的文章。