review-verdict-revise-verify：语义也需要一道闸门

当 AI Agent 做审查时，负载承载的安全逻辑必须放在确定性编排层，不能交给模型自由裁量。这不是限制 AI 的能力，是给 AI 的能力加上边界。

一、审查不是开环，是闭环

PaperJury 给了一个审查模型：review-verdict-revise-verify。

不是审完就完，是审完要裁决，裁决完要修订，修订完要验证。四个环节闭环，缺一个就漏。

review：发现问题。verdict：判定问题性质。revise：修改问题。verify：验证修改是否到位。

这个模型在论文审查领域跑通了。但它不是只给论文审查用的，它是所有审查类工作的通用骨架——代码审查、设计走查、语义验证，本质都是同一套动作：看 → 判 → 改 → 查。

二、负载承载的安全逻辑：必须放在确定性层

PaperJury 的架构里有两层：

确定性编排：管分解、冻结、路由、停止、补丁应用。这些步骤用硬逻辑写死，不依赖 AI。

语义 Agent：管审查、判断、修复。这些步骤需要理解力，交给 AI。

关键设计：负载承载的安全逻辑在确定性层，不在模型自由裁量中。

什么意思？停止审查、应用补丁、记录账本——这些动作如果交给 AI 自由决定，AI 可能漏停、漏补、漏记。不是 AI 故意，是概率性生成的内禀属性：同一个输入，两次输出可能不同。

所以 PaperJury 把"绝对不能错"的硬逻辑抽出来，用确定性代码保证。AI 只负责需要理解力的软任务。

三、语义层的 review-verdict-revise-verify

这套审查模型搬到语义层，就是 Schema-As-Code 的三阶段：

review → 模式库（Pattern Library）

看组件语义快照，比对手册定义，提取偏差。不是截图记笔记，是机器按规则扫描。Alert 的 type 必须是 success/info/warning/error，不在范围内就标记。

verdict → 契约库（Contract Library）

判定偏差性质，生成 YAML 契约。这是规矩文件：这个组件在这个场景下不能做什么、必须做什么。不是建议，是约束。

revise → Prompt 前缀注入

把契约编译成 AI 能读的指令，贴在生成前面。AI 生成时自动按规矩执行，不是生成完再改。

verify → 验证工具集（Validation Toolkit）

单元测试、集成测试、回归测试。输入文案或界面描述，自动判断是否符合契约，给出通过/不通过。不是人眼走查，是机器按固定标准审查。

四个环节闭环，缺一个就漏。review 了没 verdict，不知道问题性质；verdict 了没 revise，规矩没落地；revise 了没 verify，不知道改没改对。

四、为什么模型自由裁量不够

AI 能写文案、能调颜色、能生成组件，但 AI 不能决定"什么绝对不能变"。

Critical 能不能写成严重？模型自由裁量会说"可以，它们是同义词"。但确定性规则会说"不可以，在这个场景下情绪权重不同"。

删除按钮能不能做成蓝色实心？模型自由裁量会说"可以，蓝色是主按钮的默认颜色"。但确定性规则会说"不可以，destructive_action 必须是红色空心"。

模型自由裁量管的是"怎么生成更好"，确定性规则管的是"什么绝对不能碰"。两者不是替代，是分工：AI 负责在边界内发挥创造力，规则负责守住边界。

五、一句话

review-verdict-revise-verify 不是论文审查的专利，是所有审查工作的通用骨架。语义层也需要这套闭环：发现漂移、判定性质、生成契约、验证有效。负载承载的安全逻辑在确定性层，理解力在 AI 层。这才是端到端可信——从决策到呈现，每一层都有约束、每一层都可审计。