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