编译管线是语义一致性的机器翻译层

本文是 Schema-As-Code 治理框架的关键设计，与阶段一"结构化诊断"方法论平行。

阶段一（结构化诊断）的核心路径是 Token → 字段 → 快照 → 模式，回答"怎么发现语义断层"；阶段二（语义契约）的核心路径是 YAML 契约 → 编译管线 → 消费格式，回答"怎么把修复规则翻译成机器可执行的约束"。阶段二由三部分组成：语义契约、编译管线、语义字典与操作手册。

本文聚焦阶段二（语义契约）的编译管线的核心机制：如何把设计意图从 YAML 翻译为不同角色可直接消费的机器约束。

快速阅读：阶段一：组件语义快照与模式诊断：AI 生成界面的第一道检查

阶段二：设计师作为"语义翻译者" 当AI生成界面时我怎么用规则锁住设计意图

方法论总纲与开源仓库：把设计规范写成代码格式，是所有 AI 工具的上游约束方法论

---

一、编译管线全景：四个阶段与一条流水线

Schema-As-Code 治理框架不是一套分散的文档，而是一条结构化编译流水线。每个阶段的上游产出，自动成为下游的输入，最终确保设计意图从"人脑中的想法"到"机器执行的约束"不丢失、不漂移。

编译管线的核心机制：

• 阶段一（结构化诊断） 产出模式库，6 个跨产品的通用漂移模式
• 阶段二（语义契约） 将模式写成YAML 契约，机器可读的设计意图定义
• 阶段二（编译管线） 将 YAML 编译为4 种消费格式，Prompt 前缀、JSON Schema、Checklist、CI 规则
• 阶段二（语义字典与操作手册） 提供配套资产，术语定义、使用指南、最佳实践
• 阶段三（验证闭环） 让 5 类角色消费这些格式，确保语义一致性落地

本文聚焦阶段二的编译管线。 它与阶段一的"结构化诊断"是同一层级的方法论设计：诊断回答"怎么发现断层"，编译管线回答"怎么把修复规则变成机器约束"。理解这一点，才能理解编译管线在治理框架中的核心位置。

---

二、阶段一回顾：结构化诊断与模式库（上游输入）

2.1 设计路径：Token → 字段 → 快照 → 模式

编译管线的上游，是阶段一通过结构化诊断产出的模式库。详见：《组件语义快照：我观察 AI 产品界面时用的 6 字段记录法》诊断路径如下：

Token（语义单元）↓ 聚合为
Field（语义字段）：error_severity / process_phase / boundary_action↓ 实例化为
Snapshot（语义快照）：6 字段记录法记录单个界面↓ 聚类为
Pattern（漂移模式）：跨产品、跨场景的通用语义断层类型

Token 层：识别界面中最小语义单元，如 "Critical"、"严重"、"确认"。Field 层：将 Token 聚合为语义字段，回答"这个界面缺少什么语义定义"。Snapshot 层：用结构化记录法（组件类型、语义字段、视觉表达、文案、用户行动、上下文）固化单个实例。Pattern 层：对 20+ 个快照聚类，提炼出6 个跨产品通用模式。

2.2 结构化的跨产品一致性记录方式

6 个漂移模式不是"截图收集"，而是一套结构化的跨产品一致性记录方式。每个模式用同一张表格记录：症状描述、根因分析、通用场景分类、以及跨产品的一致性证据。详见：《6 个漂移模式：AI 生成界面的语义断层证据库》

以下以 ERR-001（错误状态 ， 后果差异未分级） 为例，展示这套记录方式：

记录维度	ERR-001 内容
症状描述	同一产品内多种错误状态（流式中断、网络故障、限流提示、服务异常）共用红色视觉语言，文案只描述现象（如"Error in message stream"），不说明后果严重程度，用户无法判断"这是刷新一下就好，还是对话已经丢了"。
根因分析	系统层面缺少 error_severity 语义字段。前端只接收 isError=true 的布尔值，不接收错误性质（致命/抖动/限流/降级），因此只能统一渲染为红色。
通用场景分类	① 流式输出中断（对话上下文可能丢失）；② 网络层故障（系统可自动恢复）；③ 限流/流控（用户可自助恢复）；④ 服务端兜底（部分功能可用）
跨产品一致性证据	国内外主流 AI 对话产品（包括通用型 LLM 助手、企业级 AI 客服、垂直领域 AI 应用）均存在此现象：流式输出中断、网络错误、请求频率限制、服务端异常等场景共用同一种红色视觉表达，未按后果严重程度分级。

2.3 诊断方法：三层判定模型

阶段一用于从"症状"到"根因"的诊断逻辑，详见《结构化诊断：三层判定模型与模式匹配机制》。三层判定模型提供了一套可复用的诊断流程：

• 第一层：症状层 —— 观察界面现象（颜色、文案、用户行动）
• 第二层：字段层 —— 判断缺少哪个语义字段（error_severity？process_phase？）
• 第三层：根因层 —— 定位系统缺失的语义令牌定义

该模型是阶段一到阶段二的桥梁：诊断出模式后，即可进入 YAML 契约编写。

2.4 模式总表：6 个漂移模式（按组件类型分类）

模式 ID	组件类型	漂移模式	缺少的语义字段	通用场景
ERR-001	错误状态	后果差异未分级	error_severity	流式中断、网络故障、限流提示、服务异常等场景共用同一种视觉表达
PRO-001	过程状态	认知阶段未显化	process_phase	AI 生成内容时显示"搜索中/阅读中/总结中"，用户无法判断可信度阶段
BND-001	边界动作	权利差异未区分	boundary_action	AI 拒绝请求时，"拒绝继续"和"终止会话"在界面上无区分
ACT-001	操作按钮	高危操作未约束	action_type	删除/转账/清空等不可逆操作按钮被做成普通样式，无二次确认
ALR-001	告警/状态	语义降级	synonym_firewall	告警级别词（如 Critical）被 LLM 降级为低情绪权重同义词
FRM-001	表单/输入	验证语义缺失	validation_semantics	表单错误只显示"格式不对"，不说明具体规则（如密码必须 8 位）

模式库的价值：结构化的跨产品一致性证据。

---

三、阶段二：YAML 契约，设计意图的身份证（编译输入）

编译管线的直接输入，是阶段二第一部分产出的YAML 语义契约。详见：《YAML契约格式：理解了语义规范体系后怎么写语义规则》

一份 YAML 契约由 6 个顶层字段组成，回答 6 个核心问题：

intent_id:  "我是谁？"→ 契约唯一标识，如 ERR-001
description:"我解决什么问题？" → 一句话说明语义问题
version:    "我是哪个版本？" → 语义版本，变更触发重编译
applicable_products: "我在哪些产品生效？"    → 防止规则误用
semantic_tokens:     "我定义了什么语义？"     → 核心：级别、视觉、行动
immutable_boundaries: "我画了什么红线？" → 绝对不能做什么
llm_constraints:     "我对 AI 有什么强制要求？" → 必须包含什么、禁止省略什么

YAML 契约是编译管线的唯一输入源。 所有下游消费格式（Prompt 前缀、JSON Schema、Checklist、CI 规则）都从这份 YAML 编译而来。

契约库的价值：当契约数量从 1 份增长到 20 份、50 份时，需要像管理代码一样管理契约，Git 版本、Diff 对比、分支并行、依赖追踪。编译管线消费契约库中的 YAML，输出消费格式。详见《契约库：让设计规范像代码一样管理》。

---

四、阶段二：编译管线，从契约到消费格式（本文主线）

4.1 编译管线的定义：语义翻译器

定义：编译管线是一条自动翻译流水线。输入为 YAML 语义契约，输出为 4 种消费格式，使语义约束在 AI 生成内容前即被注入，规范变更后自动同步至所有下游工具。

核心定位：不是代码编译器（不生成二进制），而是语义翻译器，将人类可读的设计意图翻译为机器可读的约束规则。

类比：设计 Token 工具（Style Dictionary）将 JSON Token 编译为 CSS 变量、iOS 颜色、Android 资源。编译管线将 YAML 契约编译为 Prompt 前缀、JSON Schema、Checklist、CI 规则。

4.2 编译的输入：YAML 哪些字段参与翻译

YAML 字段	是否编译	编译去向	说明
intent_id		所有消费格式的标识头	版本追溯与问题归因
description		Checklist 的说明文字	走查人员理解上下文
version		所有消费格式的版本声明	防止下游使用过期规则
applicable_products		Prompt 前缀的产品范围声明	避免规则误用
semantic_tokens		Prompt 核心内容 + JSON Schema 枚举	语义级别与视觉映射
immutable_boundaries		Prompt 阻断规则 + CI 阻断条件	安全红线
llm_constraints		Prompt 强制指令 + Checklist 检查项	可执行的约束
注释/元数据		仅供人类阅读	机器不消费

4.3 编译的输出：4 种消费格式

格式一：Prompt 前缀（供 AI 编程工具 / AI 原型工具消费）

编译逻辑：

• semantic_tokens 各级别 → Bullet list
• immutable_boundaries → "绝对不能"条款
• llm_constraints → "必须/禁止"指令

输出样例（基于 ERR-001 编译）：

# 基于 ERR-001 v1.0.0 编译的语义约束
在生成错误状态界面时，必须遵守以下规则：

## 错误级别与视觉映射
- 致命错误（Fatal）：必须使用红色脉冲 + 八边形警告图标 + 提供刷新/导出历史按钮
- 网络抖动（Transient）：必须使用灰色加载动画 + 显示自动重试进度 + 禁止用红色
- 限流提示（Retryable）：必须使用黄色提示 + 显示剩余等待时间 + 提供升级入口
- 降级错误（Degraded）：必须使用蓝色提示 + 说明哪些功能仍可用 + 提供继续生成按钮

## 不可突破的红线
- 绝对不能：把致命错误做成普通文字提示（没有背景色）
- 绝对不能：把限流提示做成红色（避免用户恐慌）
- 绝对不能：省略二次确认（仅针对高危操作）

## 对 AI 的强制要求
- 必须：在致命错误文案中说明"对话上下文可能已丢失"
- 必须：在限流提示中显示具体倒计时（如"42 分钟后重试"）
- 禁止：仅显示"出错了"等模糊文案
- 禁止：显示纯技术错误码（如 500 Internal Error）

格式二：JSON Schema（供结构校验 / 运行时校验消费）

编译逻辑：semantic_tokens 字段定义 → enum 约束、type 定义、必填检查

输出样例：

{ "$schema": "http://json-schema.org/draft-07/schema#","title": "ErrorStateComponent","description": "基于 ERR-001 v1.0.0 编译","type": "object","required": ["severity_level", "recovery_action", "user_message"],"properties": {   "severity_level": { 
"type": "string",
"enum": ["fatal", "transient", "retryable", "degraded"]  },  "color_token": { 
"type": "string",
"enum": ["status.critical", "status.neutral", "status.warning", "status.info"]  },  "recovery_action": { 
"type": "array",
"minItems": 1  },  "user_message": { 
"type": "string",
"minLength": 10  }}
}

格式三：Checklist（供设计师 / DesignOps 人工走查消费）

编译逻辑：llm_constraints → 勾选项；immutable_boundaries → 阻断项

输出样例：

## 错误状态组件走查清单（基于 ERR-001 v1.0.0）

### 语义分级检查
- [ ] 错误状态是否按级别区分了颜色？（红/灰/黄/蓝）
- [ ] 致命错误是否使用了脉冲动画？
- [ ] 限流提示是否显示了具体倒计时？
- [ ] 降级错误是否说明了哪些功能仍可用？

### 文案检查
- [ ] 致命错误文案是否说明了"对话可能已丢失"？
- [ ] 是否禁止了仅显示"出错了"等模糊文案？
- [ ] 是否禁止了显示纯技术错误码（如 500）？

### 红线检查（违反即阻断）
- [ ] 是否把致命错误做成了普通文字？（绝对不能）
- [ ] 是否把限流提示做成了红色？（绝对不能）
- [ ] 是否遗漏了二次确认？（绝对不能，仅针对高危操作）

格式四：CI 规则（供自动化流水线消费）

编译逻辑：immutable_boundaries.violation_action: block → CI 阻断规则；semantic_tokens 枚举 → 静态检查允许值列表

输出样例：

# .github/workflows/semantic-guard.yml
# 基于 ERR-001 v1.0.0 编译
name: Semantic Guard
on: [pull_request]
jobs:semantic-check:  runs-on: ubuntu-latest  steps:
- uses: actions/checkout@v3
- name: Check Error State Severity
run: |if grep -r "severity="error"" src/; then  echo "阻断：发现未分级的错误状态"  exit 1fi
- name: Check Destructive Action Confirmation
run: |if grep -r "destructive" src/ | grep -v "confirm"; then  echo "阻断：发现高危操作缺少二次确认"  exit 1fi

4.4 编译映射规则：同一语义，四种表达

YAML 源字段	Prompt 前缀（给 AI 看）	JSON Schema（给机器看）	Checklist（给人看）	CI 规则（给流水线看）
semantic_tokens.fatal.color_token	"致命错误必须使用红色脉冲样式"	severity: {enum: ["critical"]}	"[ ] 错误状态是否按级别区分颜色？"	if (severity !== "critical") fail()
immutable_boundaries.rule	"绝对不能：[规则内容]"	required: ["confirmation_dialog"]	"[ ] 是否违反不可突破红线？"	block_on: ["destructive_without_confirm"]
llm_constraints	"必须：[约束内容]"	minLength: 1	"[ ] AI 输出是否满足所有强制要求？"	assert: constraints_passed

设计原则：

1. 信息分层：AI 看自然语言，机器看结构化代码，人看勾选项，同一语义，不同表达。
2. 字段裁剪：Prompt 前缀不携带版本号（AI 不消费），Checklist 不携带底层语法（设计师不消费）。
3. 语义一致：fatal 在四种格式中指向同一语义实体，仅表达方式适配消费方。

4.5 版本管理与自动同步：规范变更的闭环

问题：YAML 从 v1.0.0 升级到 v1.1.0（新增 degraded 级别），下游 Prompt 前缀仍为 v1.0.0，AI 不知道有第四级。

编译管线的解法：

设计师提交 YAML v1.1.0  ↓
Git 钩子触发编译管线  ↓
自动生成 4 种格式的新版本  ↓
自动通知下游：  - 前端：Prompt 前缀已更新，请替换  - 设计Ops：Checklist 已更新  - 工程师：CI 规则已更新，下次提交生效

版本声明（嵌入每个产出文件头部）：

# 基于 ERR-001 v1.1.0 编译
# 编译时间：2026-07-13
# 源文件：intent/ERR-001.yaml
# 如有变更，请联系语义翻译设计师

4.6 编译验证：三层验证机制

验证层	验证对象	方法	输出
结构验证	编译后的 JSON Schema 是否合法	Schema Validator	结构合法性报告
语义验证	Prompt 前缀是否被 AI 正确理解	测试用例集（输入已知错误文案，验证 AI 输出是否符合约束）	语义准确性报告
一致性验证	四种格式是否表达同一语义	交叉比对（同一 fatal 在四种格式中的语义等价性）	一致性报告

编译报告样例：

编译报告：ERR-001 v1.1.0
━━━━━━━━━━━━━━━━━━━━━━
 结构验证通过
 语义验证通过（10/10 测试用例）
 一致性验证通过

输出文件： prompt-prefix/ERR-001-v1.1.0.md json-schema/ERR-001-v1.1.0.json checklist/ERR-001-v1.1.0.md ci-rules/ERR-001-v1.1.0.yml

---

五、阶段二 预告：语义字典与操作手册

编译管线的第三个配套资产，是语义字典与操作手册。

语义字典：统一术语定义，确保组织内所有人对"致命错误""语义降级""同义词防火墙"等概念的理解一致。

操作手册：为每个角色提供使用指南，设计师怎么写 YAML、前端怎么贴 Prompt 前缀、DesignOps 怎么管理版本变更。

这两者是编译管线的配套资产，不是独立阶段。它们让编译管线的产出物从"可用"变成"易用"。

---

六、阶段三预告：验证闭环与角色消费

编译管线的最终价值，是让5 类角色消费编译后的格式，确保语义一致性在组织内落地。

角色	消费什么	专题内容
设计师与产品经理	语义分级器（消费 Checklist）	怎么用工具验证 AI 生成的界面是否符合语义约束
前端与 AI 工程师	JSON 语义校验器（消费 JSON Schema + CI 规则）	怎么在代码里接入语义校验，拦截语义漂移
DesignOps 与设计系统负责人	语义快照模板（消费版本同步机制）	怎么管理规范版本变更，确保全组织同步
体验架构师 / 语义翻译设计师	全流程工具链	怎么从诊断到契约到验证，搭建完整的语义治理工作流
管理层 / 决策者	ROI 与效能报告	怎么量化语义治理的投入产出，推动组织采纳

角色专题不是重复编译管线的内容，而是回答"编译后的产物到了我手里，我怎么用它"。

---

七、编译管线的经济推演：从"人盯"到"机查"的成本结构

本节基于行业典型 AI 产品团队的通用推演模型，非真实生产数据。

核心假设：一个拥有多产品线的组织，每月发生数次设计规范变更，AI 生成内容已占日常产出的一定比例。

投入：

• 一次性：搭建编译管线约需数人天（写脚本、配 Git 钩子、定义首份 YAML）
• 持续性：设计师维护 YAML 契约（比写传统规范文档多约 20% 时间），每月少量时间维护编译配置

产出（三个维度的质变）：

1. 规范同步从"周"变成"天"以前改一次规范，需要人工通知、开会同步、逐个产品确认，周期以周计。现在改一份 YAML，Git 提交后自动编译、自动分发，周期以天计。
2. 语义返工从"人眼抽查"变成"机器全检"以前走查靠人眼，覆盖率受限于时间和人力，大量语义漂移上线后才被用户发现。现在机器按 YAML 规则自动检查全部产出，语义错误在生成前被拦截。
3. 设计规范从"文档"变成"资产"以前规范写在语雀/Confluence，更新后靠@全员通知，版本混乱、遗漏频发。现在规范以 YAML 形态存在 Git 仓库，Diff 可见、版本可追溯、变更可回滚，成为组织可复用的数字资产。

推演结论：编译管线的投入是一次性的（数人天），但产出是持续性的，每次规范变更、每个新增产品、每轮 AI 生成，都在复用同一套规则。随着 AI 生成内容占比提升，边际成本趋近于零，边际收益持续放大。这不是"多买了一套工具"，而是把语义一致性的保障方式从线性人力投入转变为指数级机器杠杆。

---

八、结语：语义翻译设计师的独立赛道

设计师的传统角色正在经历结构性转移：

• 视觉生产层：AI 已能生成符合设计规范的代码（DevUI HMC、v0、Claude Design），"画图-还原"的价值链被压缩。
• 语义定义层：AI 无法自主判断"这个场景下必须表达什么语义、不能突破什么边界"，这是人类的决策领域。

编译管线是语义翻译设计师的核心产出物：

• 它不是设计稿，而是一条规则流水线；
• 它让设计规范从"文档"变成"代码"，从"人读"变成"机读"；
• 它让设计师从"视觉生产者"变成"语义规则的定义者与翻译者"。

组织为什么需要语义翻译设计师：

不是因为其能产出更精美的界面，而是因为其能建立设计意图在概率性界面时代的防稀释机制，通过编译管线，将设计意图从人类大脑中的隐性知识，转化为机器可消费的显性约束，确保 AI 生成内容在任何工具、任何框架、任何产品中的语义一致性。

这就是语义翻译设计师的独立赛道：

不为 AI 工具定义"长什么样"，而为 AI 工具定义"这意味着什么"。编译管线是这一赛道的核心基础设施。

---

附录一：编译管线产出物清单

产出物	格式	消费方	生成方式
Prompt 前缀	.md	Claude Code / Cursor / Copilot / v0	编译管线自动生成
JSON Schema	.json	前端工程 / Zod / Ajv	编译管线自动生成
走查 Checklist	.md	设计师 / DesignOps	编译管线自动生成
CI 规则	.yml	GitHub Actions / GitLab CI	编译管线自动生成
编译报告	.md	语义翻译设计师 / 管理层	每次编译后自动生成
版本声明	头部注释	所有消费者	嵌入每个产出文件

---

附录二：6 个漂移模式的完整结构化记录

以下按"症状描述、根因分析、通用场景分类、跨产品一致性证据"四维度，完整记录 6 个漂移模式。所有案例均为通用型 AI 产品的共性表现，不绑定任何特定产品。

模式 ERR-001：错误状态 ，后果差异未分级

记录维度	内容
症状描述	同一产品内多种错误状态（流式中断、网络故障、限流提示、服务异常）共用红色视觉语言，文案只描述现象（如"Error in message stream"），不说明后果严重程度，用户无法判断"这是刷新一下就好，还是对话已经丢了"。
根因分析	系统层面缺少 error_severity 语义字段。前端只接收 isError=true 的布尔值，不接收错误性质（致命/抖动/限流/降级），因此只能统一渲染为红色。
通用场景分类	① 流式输出中断（对话上下文可能丢失）；② 网络层故障（系统可自动恢复）；③ 限流/流控（用户可自助恢复）；④ 服务端兜底（部分功能可用）
跨产品一致性证据	国内外主流 AI 对话产品（包括通用型 LLM 助手、企业级 AI 客服、垂直领域 AI 应用）均存在此现象：流式输出中断、网络错误、请求频率限制、服务端异常等场景共用同一种红色视觉表达，未按后果严重程度分级。

模式 PRO-001：过程状态，认知阶段未显化

记录维度	内容
症状描述	AI 生成内容时显示"Searching...""Reading...""Wrapping up..."，用户只知道"AI 在干活"，但不知道它处于"客观检索"还是"主观推理"阶段，无法建立对输出可信度的预期。
根因分析	系统层面缺少 process_phase 语义字段。过程状态停留在"动作描述"（我在做什么），而非"认知阶段描述"（我处于什么可信度阶段）。
通用场景分类	① 信息检索（客观事实获取）；② 多源综合（主观推理开始）；③ 来源验证（可信度校验）；④ 最终生成（概率性输出）
跨产品一致性证据	主流 AI 搜索与对话产品（包括通用型AI助手、企业级知识库问答、垂直领域 AI 分析工具）均存在此现象：过程状态标签仅描述动作（搜索中/阅读中/总结中），未显化认知阶段（检索/综合/验证/生成），用户无法判断输出可信度。

模式 BND-001：边界动作，权利差异未区分

记录维度	内容
症状描述	AI 拒绝用户请求时，"拒绝请求（对话继续）"和"终止会话（上下文清空）"在界面上都是"拒绝"表达，用户不知道历史记录还在不在、能不能申诉。
根因分析	系统层面缺少 boundary_action 语义字段。边界动作在 LLM 的语义空间中等价（都是"不继续"），但用户权利后果完全不同。
通用场景分类	① 软性拒绝（对话继续，可问其他话题）；② 硬性终止（上下文清空，必须新开会话）；③ 升级审核（提交人工复核）
跨产品一致性证据	主流 AI 对话产品（包括通用型 LLM 助手、企业级 AI 客服、垂直领域 AI 应用）均存在此现象：安全拒绝与强制终止在界面上使用相同的视觉表达（如红色警告、拒绝文案），未区分用户权利差异（会话是否保留、历史是否可导出、是否可申诉）。

模式 ACT-001：操作按钮，高危操作未约束

记录维度	内容
症状描述	AI 生成"删除账户"界面时，删除按钮被设计为普通蓝色实心按钮（contained 样式），文案为"确认"，缺少"不可恢复"警告和二次确认，用户误触后账户直接删除。
根因分析	系统层面缺少 action_type 语义字段。LLM 默认按"普通操作"生成界面，不区分"可逆操作"和"不可逆操作"的语义差异。
通用场景分类	① 普通操作（可逆，如修改昵称）；② 重要操作（可撤回，如发送邮件）；③ 高危操作（不可逆，如删除账户、转账、清空数据库）
跨产品一致性证据	主流 AI 编程与原型工具（包括 AI 代码生成器、AI 原型设计工具、AI 界面构建器）均存在此现象：生成涉及数据销毁的界面时，默认输出普通主按钮样式，未识别 destructive_action 语义，缺少二次确认与后果说明。

模式 ALR-001：告警/状态，语义降级

记录维度	内容
症状描述	AI 生成告警文案时，将 "Critical" 降级为 "严重"、"紧急"、"危急"等同义词，用户情绪权重降低，可能延迟响应系统级故障。
根因分析	LLM 的同义词替换在概率性输出中抹平了人工精心设计的语义层级。系统缺少 synonym_firewall 约束，无法拦截"等价但情绪权重不同"的词替换。
通用场景分类	① 系统告警（Critical 不可降级）；② 医疗诊断（恶性肿瘤不可写成肿块）；③ 金融风险（高风险不可写成激进型理财）；④ 电商库存（缺货不可写成暂时 unavailable）
跨产品一致性证据	通用 LLM 输出行为：同一 Prompt 多次运行，告警级别词出现变异（如 Critical/严重/紧急/危急混用）；行业缺乏"同义词防火墙"机制，依赖人工事后走查。

模式 FRM-001：表单/输入，验证语义缺失

记录维度	内容
症状描述	表单验证错误只显示"格式不对""输入有误"，不说明具体规则（如密码必须 8 位且包含大小写），用户反复试错。
根因分析	系统层面缺少 validation_semantics 字段。验证规则停留在"对错"判断，未显化为"具体规则说明 + 修正指引"。
通用场景分类	① 格式验证（邮箱/手机号/身份证格式）；② 强度验证（密码复杂度）；③ 一致性验证（两次输入是否匹配）；④ 业务规则验证（用户名是否已被占用）
跨产品一致性证据	通用 AI 表单生成行为：默认输出"请输入正确的格式"等模糊文案；行业缺乏"验证规则语义化"标准，前端需手动补充具体规则说明。

---

本文是 Schema-As-Code 治理框架阶段二《编译管线》的关键设计文章。阶段二由三部分组成：语义契约、编译管线、语义字典与操作手册。本文聚焦编译管线的核心机制。后续将发布《语义字典与操作手册》，然后进入阶段三《验证闭环》的五个角色专题。

---