当策略改变概率：LLM代码审查中的模块化决策 · When Policies Change Probabilities: Modular Decision-Making for LLM Code Review

概率论的基本原则是：一个事件的概率应该只取决于证据，不该因为"接受错误的代价有多大"而改变——代价只该决定基于这个概率之上采取什么行动，不该反过来污染概率本身。但当LLM被一体化地要求"评估这个代码补丁的失败风险，并且要考虑到误接受的代价是XX倍"时，这个提示词设计本身就在让同一个模型同时承担"证据评估"和"策略决策"两个角色。作者提出的核心问题是：当前把LLM当作代码审查（是否合并某个补丁）风险评分器使用的系统，是否真的实现了"概率估计与决策代价函数相互独立"这一基本要求，还是策略信息（如误接受的相对代价）会系统性地渗透并扭曲模型汇报的失败概率本身。

基于 SWE-rebench 的 Python 仓库构建评测集：360个issue，每个issue配一对候选补丁（一个通过、一个未通过归档测试用例），共720个候选补丁。数据划分为校准集A（80个issue/45个仓库）、校准集B（80个issue/42个仓库）与测试集（200个issue/114个仓库），各划分间仓库不重叠以避免泄漏。四个被测LLM审查系统（DeepSeek-V4-Pro、Grok-4.3、Mistral-medium-3.5、GPT-5.5/Codex）在此任务上共产生15,792条响应；另有Gemini 3.5 Flash作为独立"监控器"，只输出连续的失败风险分数，不接触任何策略/代价信息。

实验设计了四种提示条件，逐步改变提示词中隐含的失败先验和误接受代价：等代价基线（先验.50，决策阈值.50）、低先验对照组（先验.10，阈值.50）、10:1高代价策略（阈值≈.091）、20:1高代价策略（阈值≈.048）。**关键操纵**在于：同一模型面对同一批补丁，只是提示词里声明的"误接受代价倍数"不同，理论上模型汇报的失败概率不该随代价倍数变化——变了就说明概率和策略没有解耦。

作为修复方案，作者构建了一个模块化流水线：审查LLM在完全不知晓任何策略/代价信息的情况下单独汇报风险概率；独立的监控模型（Gemini 3.5 Flash）给出第二个风险分数；两个分数在代码层面（而非提示词层面）合并，再由外部逻辑根据代价阈值做出接受/拒绝决策。这把"证据评估"和"策略执行"从同一次LLM调用里剥离成两个独立、可分别校准和审计的步骤。

把提示词里的策略从等代价切换到10:1高代价后，同一模型对同一补丁给出的失败概率平均漂移了13.6-16.9个百分点；两种提示条件下的匹配响应精确一致率仅8.5%-31.0%。更极端的是Mistral：在10:1代价提示下，有37/80的案例直接复述了提示词里打印出来的决策阈值数字本身，而在等代价对照组这一现象是0/80——说明模型有时不是在"估计概率"，而是在"回读策略参数"。

在10:1高代价策略提示下，四个被测审查系统给出的实际接受/拒绝决策，其造成的期望损失全部劣于直接拒绝所有补丁这个零智能基线。而如果反过来，用等代价条件下采集到的（未被策略污染的）概率，事后再套用10:1的代价阈值做决策，所有系统的损失都下降——这直接证明了问题出在"概率采集方式本身被策略污染"，而不是模型的底层风险判断能力不行。

分离概率估计和代价应用之后，在等代价条件下，模块化流水线相比一体化基线将每个issue的平均损失降低了0.073，同时接受58%-68%的补丁（意味着系统仍在正常工作，而非退化成"什么都不接受"）。但在10:1高代价条件下，模块化流水线同样收敛到拒绝所有补丁，与reject-all基线打平——说明在极端高代价场景下，无论架构如何，谨慎拒绝可能确实是当前风险区分能力下的合理策略，模块化的价值主要体现在代价适中、需要精细区分风险等级的场景。

这篇论文戳中了一个几乎所有把LLM当"风险评分器+决策器"一体化使用的agent系统都会踩的坑：只要提示词里同时塞入"给出概率"和"这里的代价函数是XX"，就等于默认信任模型会严格做贝叶斯式的证据推理再套代价函数决策——但15,792条响应的实证表明这个假设经常不成立，模型会把策略信息本身当成影响概率判断的"证据"，甚至直接复读策略参数。对duplex agent这类需要LLM实时对交互质量/中断风险/任务完成度做概率判断并据此触发不同代价的动作（比如是否打断用户、是否需要重新规划）的架构而言，这是一个结构性警示：如果"这次误判的代价很高"这类信息以自然语言形式混进了同一次判断请求里，返回的置信度分数可能已经被污染，无法再拿去做独立的下游代价-收益计算，也无法跨场景复用或校准。

论文给出的修复思路——把"打分"和"用分数做决策"拆成两个不共享提示词上下文的独立步骤，代价函数完全在代码里而非提示词里实现——本质上是一种架构层面的关注点分离（separation of concerns），比事后校准或调阈值更根本，也更符合可审计、可复用的系统设计原则。局限也很明显：实验里代价倍数和决策阈值是同步变化的（存在混杂），基准数据集用了人为的50/50通过/失败配比，不代表真实部署环境下的补丁质量分布；被测的四个审查器加一个监控器规模有限，且都没有工具访问权限（无法真正运行测试、读取更多上下文），这些都限制了结论直接外推到生产级、有工具增强能力的代码审查agent上的强度，但核心的"概率-策略耦合会系统性扭曲风险估计"这一发现本身，方法论足够扎实，值得任何设计"LLM给分+规则决策"架构的团队认真对待。