品控规则越严AI 输出越差——假阳性正在吃掉你的规则收益去年把 sharp-skills 的 MUST 规则从 20 条扩到 60 条本想着覆盖率上去了漏判应该能压下来。结果跑了一个月发现了一个反直觉的现象坏输出确实少了但好输出也开始被拦截。不是 AI 变笨了是规则产生了假阳性——把好输出当成了坏输出。假阳性比漏判更隐蔽漏判好发现。用户一眼就能看出 AI 输出有问题反馈链路很短。假阳性则完全相反AI 生成了一段质量不错的内容被规则拦下来要求重写工程师按规则改完后输出反而变平庸了。这个损失没人记录。因为规则通过了输出合规了但质量下降了。你以为是模型能力问题其实是规则在反向筛选——把有灵气、有创造性的输出按不符合规范处理掉了。更麻烦的是假阳性会训练团队妥协。工程师发现按规则来的输出总是被打回来改慢慢就会往最不可能触发规则的方向写 prompt。prompt 越来越保守AI 的输出越来越像模板。三种典型的假阳性场景场景一过度具体化。sharp-tech-writing 有一条规则代码示例必须包含输入输出注释。本意是防止示例不完整。但 AI 写一行logger.info(User logged in)也要强行加注释说明输入是用户对象、输出是日志记录——反而让示例变得臃肿可笑。规则把必要注释具体成了必须注释AI 为了合规对所有代码行一视同仁。好输出被无差别拦截。场景二语义漂移。sharp-copywriting 有一条 SHOULD避免使用行业黑话。早期运行良好。但后来模型对黑话的理解泛化了把正常的行业术语也当成黑话拦截。缓存穿透被建议改成大量请求直接打到数据库——准确性下降了可读性也没提升。问题出在规则描述用了模糊词黑话。模型在不同版本对模糊词的理解会漂移今天不拦截的明天可能就拦截。场景三边界僵化。sharp-dataviz 有一条 MUST图表必须有标题。这个规则对正式报告没问题。但 AI 给内部技术评审写的快速分析图加标题反而占用空间、打断思路。规则没有区分正式交付物和内部草稿把好用的快速输出也按正式标准卡死了。边界僵化的本质是规则缺少上下文感知能力一刀切处理所有场景。用黄金样本集检测假阳性检测假阳性的方法跟检测漏判正好相反不是拿坏样本测试规则能不能拦住而是拿好样本测试规则会不会误伤。我的做法是在黄金样本集里分两个池子A 池已知的好输出质量经过人工确认代表这条线以上的内容应该放行。B 池已知的坏输出代表这条线以下的内容应该拦截。规则迭代时除了跑 B 池看拦截率必须同时跑 A 池看误伤率。A 池通过率低于 95%这条规则就不能上线。这个数字不是拍脑袋。A 池通过率 95% 意味着每 20 个好输出里最多误伤 1 个。如果低于这个值规则对创作空间的挤压就太严重了。A 池的构建比 B 池更难。B 池的 badcase 是被动收集的——出了错就记下来。A 池需要主动搜集把团队公认的优秀 AI 输出归档定期标注这条好在哪。没有 A 池假阳性问题永远发现不了。三条降低假阳性的策略策略一给规则加置信度。不是每条规则都要硬拦截。把规则分成硬规则和软规则两级硬规则触发直接拦截软规则触发只打标签、不拦截由人决定是否修改。软规则的作用是指引而非约束。比如建议避免长句作为软规则AI 输出后系统标注第 3 段含 3 个超过 40 字的长句但不强制重写。工程师根据上下文判断要不要改。策略二规则描述必须带上下文条件。把图表必须有标题改成正式交付的图表必须有标题内部草稿和快速分析图除外。把避免使用行业黑话改成面向非技术读者的内容避免使用行业黑话技术文档保留标准术语。上下文条件多了规则会变长但能显著降低假阳性。这比事后修正好得多。策略三保留人工仲裁通道。再完善的规则也会有灰色地带。在品控流程里留一个申诉环节如果工程师认为规则误伤了可以标记此输出被规则 X 拦截但人工判定为优质直接放行并记录。这个记录非常重要。积累到一定数量就说明规则 X 需要修订。没有仲裁通道假阳性的损失被沉默掉了规则永远得不到反馈。规则的终极目标不是零漏判品控规则的优化是一个多目标平衡漏判率低、假阳性低、执行成本低。三者不可能同时最优。很多团队把零漏判当成唯一目标不断加规则、收紧边界。结果假阳性飙升AI 输出变得千篇一律。用户抱怨AI 写的都是套话根因往往是规则太严把有差异化的好表达都过滤掉了。合理的品控体系应该接受一个事实一定比例的漏判比大面积的假阳性更容易修复。漏判是明确的错误有反馈、有数据、有优化方向。假阳性是隐形的质量损失你发现不了、量化不了、也优化不了。我在做一个用卡皮巴拉讲设计模式的微信小程序「爪爪代码冒险记」23 个设计模式用漫画 答题的方式讲目前正在开发中。如果你觉得这类内容有意思搜一下「爪爪代码冒险记」或者等我后面的文章。