语义审查判决修订验证需要一道闸门

先说一个核心判断：当AI Agent开始承担审查工作时，负载承载的安全逻辑必须交由确定性编排层来管，而不是丢给模型去自行裁量。这并不是要束缚AI的能力，而是为它的能力划定边界——能力有多大，边界就得有多清晰。

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

PaperJury 提出了一套审查模型，结构非常清晰：review → verdict → revise → verify。

审查并非到此结束。审完必须裁决，裁决完必须修订，修订完还得验证——四个环节环环相扣，缺一不可，否则就会出现漏洞。

• review：首先把问题找出来。
• verdict：接着对问题定性。
• revise：然后动手进行修改。
• verify：最后确认修改是否到位。

这套模型最初在论文审查领域得到了验证，但它绝非论文审查的专属——代码审查、设计走查、语义验证，所有审查类工作本质上都遵循同一套动作流程：看 → 判 → 改 → 查。

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

PaperJury 的架构设计相当简洁，主要分为两层：

• 确定性编排层：负责分解、冻结、路由、停止、补丁应用。这些步骤全部采用硬逻辑写死，不依赖AI的“判断力”。
• 语义Agent层：负责审查、判断、修复。这些任务需要真正的理解力，因此交给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可以写文案、调颜色、生成组件，但有一件事它绝对做不好：决定“什么绝对不能变”。

你有没有想过，Critical 能不能写成“严重”？以模型自由裁量的能力来看，它会说“可以，它们是同义词”。但确定性规则会立刻否决：“不可以，在这个场景下情绪权重不同。”

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

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

五、一句话总结

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