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

Wu 等（2026）在论文审查领域做了一个闭环系统：

review → verdict → revise → verify

论文提交后，先审查、再裁决、再修订、再验证——四轮之后才允许进入下一环节。

这个闭环的核心设计，不是让 AI 自由裁量。

而是把**"负载承载的安全逻辑"从模型手里拿走，放到确定性编排**中。

一、审查可以交给 Agent，但裁决不能

审查可以交给 Agent。

判断可以交给 Agent。

修复也可以交给 Agent。

但——

什么时候停止？
什么时候阻断？
什么绝对不能改？

这些由硬逻辑说了算。

不由模型说了算。

这意味着：概率性生成的不确定性，被确定性规则锁在边界之内。Agent 在边界里面发挥理解力，边界本身不容谈判。

二、Code-Text-Code 的启示

《Specification-Based Code-Text-Code Reengineering》在代码层验证了一件事：

在转换链条中插入一层受控的规范层，把意思和语法解耦。

源代码和目标代码的语法完全不同，但中性文本规范把"意思"固定下来——无论怎么转换，意思不会漂移。

我在语义层做同样的事。

设计意图 → 语义契约 → Agent 生成 Web UI

设计意图是设计师脑子里的"这个场景下不能做什么"：

• 删除账户必须是红色空心
• 必须二次确认
• 文案必须说明不可恢复

Agent 生成 Web UI 时，样式可以变，框架可以变，但语义必须先被规范锁住。

两者都在做同一件事：在生成之前，先把意思固定下来。

论文用自然语言规范来解耦代码语法和代码语义。我用 YAML 语义契约来解耦 Web UI 样式和 Web UI 语义。

样式可以变，但语义必须被规范锁住。

三、Agent = Model + Harness

阿里云原生在拆解 Agent 底座时，给了一个等式：

Agent = Model + Harness

Model 是大脑。Harness 是缰绳。

没有 Harness 的 Agent 是脱缰的——它能跑，但不知道往哪跑，更不知道什么不能跑。

这比"安全对齐"更诚实。安全对齐试图让模型"自己知道什么该做、什么不该做"，但概率性生成的不确定性决定了，模型不可能 100% 自律。

Harness 不依赖模型的自律。它在外部给模型套上一层规矩——

你不需要懂为什么，你只需要按规矩执行。

Harness 的核心是约束基建。规矩必须：

• 可审计——写了什么、什么时候改的、谁改的，有迹可循
• 可进化——业务变了，规矩跟着变，版本化管理，Diff 可见

阿里云在业务逻辑层和数据层做了这件事。

但当 Agent 的输出流向 Web UI 时，约束链断了。

四、约束链的断层

想象一条流水线：

数据层定义了字段语义
    ↓
业务层定义了规则语义
    ↓
策略层定义了模型标签语义
    ↓
Agent 生成了一段文案、一个按钮、一个错误提示
    ↓
用户看到了

数据层有约束：status_code=500 → "服务器错误"

业务层有约束："服务器错误" → 值班员立即响应

策略层有约束："Critical" → 情绪权重最高

但到生成 Web UI 这一步，约束链断了。

Agent 把 status_code=500 渲染成界面时，可能写成：

• "Something went wrong"（语义降级）
• 按钮做成蓝色实心（样式错误）
• 四种错误全部用红色（分级缺失）

后端的规矩再严密，语义层没有约束，等于零。

这不是前端的锅。前端按设计稿实现了，设计稿按规范画了，但规范写在文档里，Agent 生成内容时没读。

Agent 按概率生成，每次输出的文案、颜色、样式可能不同——语义在生成过程中漂移了。

约束链止于业务逻辑层，语义层是空白。

这是端到端可信的缺口。

五、语义闸口：在转换链条中插入受控的规范层

这个解耦方法在语义层有三个实现环节。

发现意思在哪里可能跑偏——模式库

不是截图记笔记。

是按组件类型做结构化归档：

当 Agent 生成的输出与组件手册中的语义定义出现偏差时，记录为模式。

把意思写成机器能懂的规矩——契约库

规矩不是写在文档里让人读。

是写在代码里让机器执行。

# contract/ACT-001.yaml
组件: Button
组件手册依据:
  Props:
    - type: primary / default / dashed / link / text
    - danger: true / false
    - ghost: true / false
绝对不能碰的红线:
  - 禁止: semantic_domain=destructive 时，type 不是 primary 或 danger=false
  - 禁止: 缺少 Modal.confirm 二次确认
颜色背后的意思:
  destructive_action:
    组件手册映射:
      Button: { type: "primary", danger: true, ghost: true }
      Modal: { type: "confirm", okType: "danger" }

删除按钮的 type 必须是 primary，danger 必须是 true，ghost 必须是 true——这些不是建议，是约束。

契约买的不是"生成能力"，是**"可审查性"**。

证明意思没有被跑偏——验证工具集

输入一段文案或 Web UI 描述，自动判断是否符合契约，给出通过/不通过。

不是人眼走查，是机器自动审查。

不是"感觉好多了"，是有明确的测试标准和通过准则：

• 单元测试：单组件语义合规性 → 准确率 ≥ 90%
• 集成测试：多组件语义一致性 → 100% 匹配
• 回归测试：规范迭代后兼容性 → 通过率 100%

三个环节叠加，形成语义层的 Harness：

发现漂移（模式库）
    ↓
裁决契约（契约库）
    ↓
修订生成（Prompt 注入）
    ↓
验证锁定（验证工具集）

意思在生成之前被固定，样式在规范之内被允许漂移。

这才是端到端可信——从决策到呈现，每一层都有约束、每一层都可审计。

六、为什么现在必须做

以前 Web UI 是人画的。

设计师画什么，前端做什么，语义不会变。

现在 Web UI 是 Agent 生成的。

同一个需求，Agent 每次生成的文案、颜色、样式可能不同——语义一致性从"确定性"变成了"概率性"。

传统设计系统管的是像素级一致性：

• 颜色
• 字体
• 间距

但 Agent 生成时，像素对了，语义可能错了：

这些不是视觉回归能捕获的问题。

视觉回归检查"长什么样"。

语义闸口检查"意味着什么"。

Agent 时代，约束基建必须从业务逻辑层延伸到语义层。

否则后端的规矩再严密，Web UI 的语义没有闸口，用户看到的仍然是"意思跑偏了"的界面。

一句话

Agent = Model + Harness。

Harness 不能只套在业务逻辑层，必须延伸到语义层——从决策到呈现，每一层都有约束、每一层都可审计。

review-verdict-revise-verify 的闭环不是论文审查专属，是任何概率性生成系统的通用原则：负载承载的安全逻辑，必须放在确定性编排中。

语义也需要一道闸门。