严格评审模型的发散性：如何通过规则约束而非提示词突破

居然在规则层锁死就解决了？赶紧把那几条漂移的 prompt 删了，太浪费 token 了。

我也遇到过类似的问题，用双 LLM 协作模式，有个写计划的，有个评审员挑刺。我原本只想拦截四类真正的安全隐患——乱序、回滚薄弱、依赖未验证以及不可行，但评审员一看到 You are an adversarial plan reviewer 就把所有 16 个严格目标都判定为 blocker，结果全是误报。

评审员不是在找安全缺陷，而是在找“遗憾”。比如跨账号 VPC 对等连接方案，回滚逻辑写得清楚，但评审员非要说“还得考虑 DNS 故障回切场景”，这明显是完整性建议，不是结构性缺陷。又比如嵌入索引迁移方案，评审员看到切换窗口可能有延迟，就笼统地标了个 risk 当 blocker。按设计，这两类情况应该是 warning，在已知风险下放行就行。

单纯改提示词没用。即便在 system prompt 里加了 "only block on concrete defects"，还是有 30% 的 completeness 问题被判定为 blocker。LLM 就是无法稳定内化“严重到必须拦截”这条界线，轻易受模型、temperature 及方案措辞影响。

最后我也用代码兜底解决了，照着你的思路加了个白名单：

_BLOCKER_ELIGIBLE_FAMILIES = frozenset({
    "unsafe_sequencing",
    "weak_rollback",
    "unverified_dependencies",
    "feasibility",
})
if severity == Severity.BLOCKER and item.heuristic_family not in _BLOCKER_ELIGIBLE_FAMILIES:
    severity = Severity.WARNING

改动后跑了 92 次 strict 目标，没有任何 advisory 类 findings 冒充 blocker。剩下的 132 个 blocker 都是实打实的结构缺陷或确定性门控拦截。这样 balanced 模式能过的依然能过，strict 模式拦截的理由也终于正确了。

这次经历让我深有感触：如果判断标准不能落地为可枚举、可校验的规则集，仅靠 prompt 里的形容词是压不住模型发散性的。frozenset 这一层守卫，才是真正的合同。

仅仅因为在提示词里加了 adversarial，模型就立刻切换到战斗模式，这种诱导实在太强。为防止它把完整性建议误判为缺陷，我在代码层加入了白名单，只让 unsafe_sequencing、weak_rollback、unverified_dependencies、feasibility 四类真正的安全问题保持 blocker，其他被评审员标记的 blocker 都会被自动降级为 warning，这样才能真正抑制模型的过度拦截。

换个词能降误报？赶紧把我的评审脚本改一遍，之前报错率高得离谱——参考 PlannerCritic 里的做法，直接加个白名单兜底：

_BLOCKER_ELIGIBLE_FAMILIES = frozenset({
    "unsafe_sequencing", "weak_rollback", "unverified_dependencies", "feasibility",
})
if severity == Severity.BLOCKER and item.heuristic_family not in _BLOCKER_ELIGIBLE_FAMILIES:
    severity = Severity.WARNING

这样即便评审员瞎判 blocker，也直接降级为 warning，稳了。