框架定义：当AI生成界面时设计意图在偏离。Schema-As-Code 把设计规范写成代码格式 在语义层建立一套机器可读的约束契约，让AI在生成界面之前，先知道"这个场景下必须表达什么语义、不能突破什么边界"。框架不替代任何设计工具或AI工具，而是所有AI工具的上游约束层，AI负责生成规则负责把关。
本文定位：以设计师与产品经理为入口，呈现该角色在框架中的完整消费路径，验证框架在真实设计工作流中的可用性。后续将从前端与AI工程师、DesignOps、语义翻译设计师、管理层各自的入口进入同一框架；框架交付件、案例库与落地验证另篇呈现。
角色定位：设计意图的定义者与验收者
1.1 角色定义
设计师与产品经理是设计意图的定义者与验收者：负责将业务需求转化为可验证的语义约束，并确保AI生成界面的语义输出符合预期。产品经理定义业务层面的语义要求（如"删除账户必须让用户感知到不可逆"），设计师将其翻译为视觉方案（如"红色描边按钮 + 二次确认弹窗"）。
- 产品经理：负责需求定义，确保功能描述能映射到机器可消费的语义约束。
- 设计师：负责界面体验，确保视觉表达与业务语义一致。
1.2 三个反复发生的场景
以下3个场景在AI参与界面生产的团队中反复出现。它们是我在观察与诊断阶段经跨产品观察验证过的 语义漂移模式 （UI层的silent failure：无报错、渲染成功、输出错误）。痛点1：AI生成界面视觉对了语义错了 验收缺少判定依据
定义："伪正确"在界面侧的表现：AI生成的代码会"看起来对、跑起来错"，AI生成的界面同样会"看起来对、用起来错"。
例子：比如四种错误状态，流式中断、网络抖动、限流、服务降级。后果完全不同，却共用同一种红色。对照视觉规范，色值合规，挑不出毛病；但用户无法判断这是"对话已丢失"还是"等三十秒就好"。再比如"删除账户"被生成成普通蓝色实心按钮，与"保存设置"视觉权重相同，没有二次确认，一次误触即永久丢失。
根因：走查结论停留在"感觉不对"，因为缺少一份可引用的语义判定标准：视觉走查回答"界面是否符合规范"，回答不了"界面是否表达了正确的语义"。
痛点2：设计决策依赖个人经验语义表达跨人不一致
定义：设计决策依赖个人经验，缺少统一标准。
例子：比如"删除账户"按钮，有人用红色实心，有人用橙色描边，都有理由，都没有依据；PRD里写"明显提示风险"，设计、前端、测试对"明显"各有理解。
根因：缺少一份可引用的语义判定标准，同一语义在不同人、不同产品线产出不同表达，组织层面的一致性无从谈起。
痛点3：语义意图在传递中层层失真
定义：设计师说"这个错误提示要让人紧张"。前端理解为深红色加粗文字；走查时设计师认为紧迫感不足，改为红色背景卡片；三轮返工后，仍然不是最初设想的"红色脉冲动画 + 明确的恢复路径"。因为沟通使用的是形容词，而非定义。
例子：文案一侧同样失真：AI生成告警时把 "Critical" 替换为"严重"、把 "Data Loss Risk" 替换为"请稍后重试"，精心设计的语义权重在概率性输出中被随机降级。
根因：规范更新同样传不到位：团队将"错误状态分四级"的规范更新发布在文档平台并通知全员，两周后走查发现多个产品的AI生成界面仍是全红，人可能看漏通知，而AI的训练数据里根本没有这条规范。
共同本质：三个场景都不是视觉问题，也不是协作态度问题，而是语义断层（界面没有表达它本应表达的意思），"这个场景下必须表达什么语义"只存在于个人经验与口头约定中，没有标准化、可查询、可核对的载体。AI没有"语义一致性"的概念，只有"概率最接近"；当语义约束不可机器读取时生成结果只能沿视觉惯性漂移。
1.3 解决思路：从痛点到两项资产
三个痛点的解法指向同一结论：该角色需要的不是更多规范文档，而是两项可直接消费的资产：
- 语义字典：决策与沟通时可查询的"组织级语义码本"，统一"这个词在这个场景下是什么意思"
- 走查 Checklist：验收时可逐项核对的断言清单，判定"这个界面是否表达了正确的语义"
这两项资产覆盖三个场景：Checklist解决"怎么判定"，语义字典解决"统一标准"，字典术语替代主观描述。
为什么现有工具给不了？
设计规范文档供人阅读，但人会看漏、看错版本，AI工具完全读不懂。Design Token和组件库定义了"颜色是什么"，保证视觉一致，但不定义"这个颜色在这个场景代表什么"，不保证语义一致。人工走查受限于时间和认知负荷，判定标准因人而异。AI生成工具基于概率输出，本身没有"语义一致性"概念。
| 现有工具 / 资产 | 解决什么 | 不解决什么 |
|---|---|---|
| 设计规范文档 | 供人阅读的规范说明 | 人可能看漏、看错版本，AI工具完全不可见 |
| Design Token与组件库 | 定义"颜色是什么"保证视觉一致 | 不定义"颜色在该场景代表什么"不保证语义一致 |
| 人工走查 | 发现视觉偏差与部分语义问题 | 覆盖率受限于时间与认知负荷，判定标准因人而异 |
| AI生成工具 | 快速生成界面 | 基于概率输出，不具备"语义一致性"概念 |
概括：现有工具解决"怎么生产界面"，没有解决"这个场景必须表达什么语义、不能突破什么边界"。
Schema-As-Code：补齐缺失的语义层
Schema-As-Code（把设计规范写成代码格式）是填补这一空缺的语义治理工程框架。它以三阶段工作流产出上述两项资产：
- 诊断：用结构化方法把界面语义偏差归类为6个通用模式
- 契约：把语义定义写成YAML文件（机器可读、可校验），并通过编译管线自动翻译成Prompt前缀、JSON Schema、Checklist等消费格式
- 验证：各角色在工作流中消费这些资产，验证语义一致性
设计师与产品经理的角色：守好两道防线。验收时用Checklist逐项核对，发现问题后把新场景回流到模式库。
Schema-As-Code不替代现有工具（设计规范、Design Token、组件库、AI生成工具），而是作为它们的上游约束层存在：AI仍负责生成，规则负责把关；视觉走查回答"界面长什么样"，语义资产回答"界面表达了什么意思"。
1.4 责任范围
设计师与产品经理在框架中的核心动作：
- 消费语义字典（Semantic Overlay注册表）：查询组件在特定场景下的语义定义，作为设计决策的依据。
- 消费走查Checklist（编译管线产出）：在验收阶段逐项核对AI生成界面，替代主观判断。
- 反馈语义漂移案例：将字典未覆盖或契约未拦截的语义偏差，回流至语义翻译设计师，触发模式库更新。
语义治理的两项资产从何而来
本章以设计师与产品经理的工作场景提出三个问题，语义偏差如何被发现？语义规律如何写成规则？规则如何变成可消费的资产？串联阶段一与阶段二的完整设计。每个环节仅作概述，完整方法详见对应文档。
2.1 语义偏差如何被结构化地发现（结构化诊断阶段）
场景：AI生成界面在视觉层面通常符合设计规范，但语义表达可能与场景不匹配，多种错误共用同一种红色，高危操作与普通按钮样式相同。这类偏差不作用于像素，视觉走查无法覆盖，需要一套结构化的观察与诊断方法。
结构化诊断Guard阶段《组件语义快照与模式诊断》建立了这套方法，详见《组件语义快照与模式诊断AI 生成界面的第一道检查》。
第一步：组件语义快照6字段记录法。在界面视觉素材之上，强制记录6个标准字段，锚定该界面的语义上下文：详见《我观察AI产品界面时用的6字段记录法》。
snapshot_id: SNAP-202506-001 # 快照唯一编号，供模式库归档与版本管理
product: 某 AI 对话产品 # 漂移发生的产品，支持跨产品对比
component_type: 错误状态 # 组件类型，决定后续匹配的模式分支
visual_record: 界面素材 + 语义标注框 # 标注语义漂移发生的区域
user_confusion: "看到红色就刷新，结果只是限流" # 用户困惑，语义断层的直接证据
context: 高峰期快速发送 5 条消息后触发 # 触发场景，支持复现
第二步：语义分类与漂移模式匹配。 快照按组件类型归类，与模式库中的既有模式匹配，将分散的界面记录转化为可追踪的模式节点。详见《组件语义分类与漂移模式匹配》。
第三步：结构化诊断 三层判定模型（三级分类器：组件类型 → 语义缺失 → 视觉校验）。每张快照经三层判定逐层收敛，输出模式 ID 与置信度：详见《结构化诊断三层判定模型与模式匹配机制》。
第一层 组件类型识别 → 第二层 语义缺失判定 → 第三层 视觉表达校验
↓
输出：matched_pattern（如 ERR-001）+ confidence_score + 归档路径
诊断结论：6个漂移模式。 全部观察最终归纳为6个经过跨产品验证的语义漂移模式，构成模式库：详见[《6个漂移模式AI生成界面的语义断层证据库》]https://developer.aliyun.com/article/1743910?spm=a2c6h.26396819.creator-center.22.1f443e18w4Ezbu)。
| 模式 ID | 组件类型 | 漂移模式 |
|---|---|---|
| ERR-001 | 错误状态 | 后果差异未分级 |
| PRO-001 | 过程状态 | 认知阶段未显化 |
| BND-001 | 边界动作 | 权利差异未区分 |
| ACT-001 | 操作按钮 | 高危操作未约束 |
| ALR-001 | 告警文案 | 语义降级 |
| INF-001 | 信息状态 | 状态权重未对齐 |
从观察到契约。 诊断结果指明"缺什么规则"，经Semantic Pipeline的三阶段工作流（Guard → Contract → Verify）进入规则显化环节。详见《从观察到契约Semantic Pipeline 的三阶段工作流》。
2.2 语义规律如何转化为机器可读的规则（语义契约化阶段）
场景：以文档形式存在的设计规范，读者只有人，人可能看漏、看错版本，AI 工具则完全不可见。语义契约化Contract阶段的核心是将设计意图翻译为机器可读的语义契约。
方法论背景详见《把设计规范写成代码格式是所有AI工具的上游约束方法论》，完整阐述见《设计师作为"语义翻译者"当AI生成界面时怎么用规则锁住设计意图》。
- 语义规范体系。 契约的内容不是色值与文案，而是语义令牌（Semantic Tokens，颜色的"类型标注"）：Design Token定义"颜色是什么"，语义令牌定义"颜色代表什么"，同一个红色，在系统故障场景为
status.critical，在高危操作场景为action.destructive。详见《语义规范体系》。 - YAML契约格式。 每条契约由7个字段构成：详见《YAML 契约格式》。
intent_id: ERR-001 # 我是谁：契约唯一标识
description: 错误状态后果差异未分级 # 我解决什么问题
version: 1.1.0 # 我是哪个版本：变更触发重编译
applicable_products: [...] # 我在哪些产品生效：防止规则误用
semantic_tokens: # 我定义了什么语义：级别 × 视觉 × 行动
error_severity:
fatal:
visual_mapping: {
color_token: status.critical, motion_token: pulse.red.urgent }
user_action: [refresh_page, export_history]
immutable_boundaries: [...] # 我画了什么红线：绝对禁止项
llm_constraints: [...] # 我对 AI 的强制要求：必须包含、禁止省略
- 契约库。 契约以Git仓库管理：版本可追溯、变更可回滚、修改走 PR 审批，设计规范像代码一样管理。详见《契约库让设计规范像代码一样管理》。
2.3 机器可读的规则如何转化为可消费的资产（编译管线与语义字典）
场景：YAML契约面向规则维护者与机器，设计师不应直接阅读契约原文。编译管线是语义一致性的"机器翻译层"，将同一份契约自动编译为四种消费格式，分发给不同角色：
┌─→ Prompt 前缀 —— 前端与 AI 工程师
YAML 契约 ──编译管线──┼─→ JSON Schema —— 组件 Props 校验
├─→ 走查 Checklist —— 设计师与产品经理（本文消费）
└─→ CI 规则 —— 流水线自动拦截
面向设计师与产品经理的另一项资产是语义字典：由语义翻译设计师基于模式库构建，覆盖组织内所有业务语义组件，供设计决策时查询。详见《语义字典设计系统组件的语义覆盖层》。
至此两项资产就绪。以下章节阐述设计师与产品经理的消费路径。
语义字典与走查Checklist的使用场景
语义字典与走查Checklist是框架验证闭环Verify阶段面向设计师与产品经理的交付面。本章阐述两项资产的具体消费方式。
3.1 语义字典 Semantic Overlay注册表
资产来源：由语义翻译设计师维护，基于模式库（错误状态 / 过程状态 / 边界动作等）构建，覆盖组织内所有业务语义组件。字典是组织内唯一定义覆盖层、语义绑定与场景映射的资产，所有YAML契约必须引用字典中的已定义项，不可自创。
资产结构：字典分三层，设计师查询时各层回答不同问题：
| 层级 | 内容 | 查询时获得什么 |
|---|---|---|
| 覆盖层目录 | 定义语义域（用户与系统的交互关系类型，如 transactional 交易与操作 / observational 观察与信息） | 该界面点属于哪种交互关系、约束特征是什么 |
| 语义重绑定 | 定义术语在具体覆盖层下的强制语义（如 status.critical 仅用于阻断性错误） |
某令牌在此场景的准确定义与跨层禁止 |
| 场景映射 | 定义具体业务场景的绑定组合与组件组合（如 SCN-001 删除账户） | 整个场景的完整语义方案，可直接引用 |
使用场景 1：设计决策前的语义对齐
设计师在启动新界面设计前，查询语义字典确认关键组件的语义定义。例如：
- 查询字段级定义：
error_severity，明确"致命错误"（Fatal）对应红色脉冲 + 八边形图标 + 恢复路径，"限流提示"（Retryable）对应黄色时钟 + 倒计时，避免凭直觉选色。 - 查询场景级映射：SCN-001（删除账户），字典直接给出完整方案：覆盖层 transactional，语义绑定
status.critical+action.destructive，组件组合Alert+Button+Modal，文案必须包含"此操作不可恢复"，交互必须输入账户名二次确认。设计师在既定语义边界内做视觉探索，无需从空白开始推导。
使用场景 2：跨角色沟通时的术语统一
设计师与前端工程师沟通时，使用语义字典中的标准术语替代主观描述：
| 主观描述（易歧义） | 语义字典术语（精确） |
|---|---|
| "这个红色按钮要明显一点" | "该按钮语义为 destructive_action，字典定义使用 color_token: status.critical + button_style: outline_danger" |
| "错误提示要让人紧张" | "该错误语义为 fatal，字典定义使用 motion_token: pulse.red.urgent + 必须提供恢复路径" |
| "加载状态要友好" | "该过程语义为 transient，字典定义使用 color_token: status.neutral + 禁止红色，避免用户恐慌" |
使用场景 3：需求定义中的语义约束引用（产品经理）
产品经理在PRD中引用字典条目，替代模糊描述，不写"删除账户需明显提示风险"，而写"该场景引用字典场景映射SCN-001（删除账户），语义绑定 action.destructive，必须二次确认"。需求从自然语言描述升级为可校验的语义引用，验收标准在需求阶段即已确定。
字典的构建方法与覆盖范围，详见《语义字典：设计系统组件的语义覆盖层》。
3.2 走查 Checklist（编译管线产出）
资产来源：由编译管线根据YAML契约自动编译生成。编译逻辑决定了Checklist的结构：契约中的 llm_constraints（对AI的强制要求）编译为勾选项，immutable_boundaries（不可变边界）编译为红线阻断项，这是每份 Checklist 都包含"红线检查"一组的原因。
使用场景：设计验收阶段的逐项核对
设计师在验收AI生成界面（或前端实现）时，打开对应组件的Checklist，逐项勾选：
## 错误状态组件走查清单（基于 ERR-001 v1.1.0）
### 语义分级检查
- [ ] 错误状态是否按级别区分了颜色？（红/灰/黄/蓝）
- [ ] 致命错误是否使用了脉冲动画？
- [ ] 限流提示是否显示了具体倒计时？
- [ ] 降级错误是否说明了哪些功能仍可用？
### 文案检查
- [ ] 致命错误文案是否说明了"对话可能已丢失"？
- [ ] 是否禁止了仅显示"出错了"等模糊文案？
- [ ] 是否禁止了显示纯技术错误码（如 500）？
### 红线检查（违反即阻断）
- [ ] 是否把致命错误做成了普通文字？（不可突破）
- [ ] 是否把限流提示做成了红色？（不可突破）
- [ ] 是否遗漏了二次确认？（不可突破，仅针对高危操作）
判定规则：
- 全部通过 → 验收通过，进入开发或上线。
- 红线项未通过 → 必须修改，不可协商。
- 非红线项未通过 → 记录问题，限期修复，可进入开发但需跟踪。
版本同步：每份Checklist头部嵌入版本声明。契约变更后，Git钩子触发编译管线自动生成新版 Checklist并通知下游，设计师验收时引用的永远是最新契约版本，验收结论可追溯至具体版本。
验收辅助：对拿不准的文案或组件，可使用框架提供的语义分级器工具，输入错误文案，获得 fatal / transient / retryable / degraded 的分级建议（对应框架的四层推演引擎：语法 / 语义 / 安全 / 美感四道机器检查）。工具输出为参考结论，最终判定以Checklist人工核对为准。
Checklist 的生成机制，详见《编译管线是语义一致性的"机器翻译层"》。
对比：引入语义治理前后的工作流
以下三个核心工作流节点，展示引入 Schema-As-Code 前后的状态差异：
| 工作流节点 | 现状（无 Schema-As-Code） | 目标态（有 Schema-As-Code） |
|---|---|---|
| 设计定义 | 语义来源为个人经验、历史设计稿与口头约定："这个错误感觉应该用红色"；不同设计师对"红色"的理解不同，导致跨产品不一致 | 查询字典 error_severity: fatal → 明确 status.critical + pulse.red.urgent；输出带语义标注的设计稿（如"Fatal / Destructive / Retryable"），所有设计师引用同一字典定义 |
| 设计沟通 | "这个按钮感觉不够危险" → 前端凭理解实现 → 走查发现偏差 → 3-5轮返工；争议无客观标准，靠职级或关系裁定 | "该按钮语义为 destructive，字典定义必须用红色描边 + 二次确认" → 1 轮定稿；争议以语义字典为仲裁依据，字典未覆盖则升级至语义翻译设计师 |
| 设计验收 | 凭感觉走查，覆盖率受限于时间与认知负荷，遗漏率高；问题归因为"前端没理解我的意思"；设计稿版本与前端实现版本无关联 | 按Checklist逐项勾选，语义漂移可量化拦截；问题归因为"该场景未在字典中定义，需补充模式并更新契约"；Checklist头部嵌入契约版本号（如"基于 ERR-001 v1.1.0"）可追溯 |
协作关系：上游输入、下游输出与反馈回流
5.1 上游输入
该角色从以下角色获取输入：
| 来源角色 | 输入资产 | 使用方式 |
|---|---|---|
| 语义翻译设计师 | 语义字典 | 设计决策前查询，确保方案与组织级语义标准对齐 |
| 语义翻译设计师 | 走查Checklist | 验收阶段逐项核对，替代主观判断 |
| DesignOps | 契约变更通知 | 收到YAML契约更新通知后，同步更新设计稿中的语义引用 |
5.2 下游输出
该角色向以下角色交付输出：
| 目标角色 | 输出资产 | 交付方式 |
|---|---|---|
| 前端工程师 | 通过/不通过的验收结论 + Checklist勾选记录 | 在协作工具（如Figma评论、项目管理工具）中标注 |
| 语义翻译设计师 | 字典未覆盖的语义场景 + 契约未拦截的漂移案例 | 按组件语义快照格式6字段记录新场景，提交至模式库反馈通道，触发 ERR/PRO/BND/ACT/ALR/INF 新编号或版本更新 |
| 产品经理 | 业务需求中的语义约束描述 | 在PRD中引用语义字典条目（如场景映射编号），替代模糊描述 |
5.3 协作示例
场景：新产品线需要设计"账户注销"流程。
- 设计师查询语义字典 → 发现
action_type中已有destructive_action（删除账户），但无account_deletion子类。 - 设计师按6字段快照格式记录该场景，反馈给语义翻译设计师 → 触发模式库更新：补充
account_deletion语义，明确"注销后 30 天内可恢复"与"永久删除"的语义差异。模式库详见《6个漂移模式AI生成界面的语义断层证据库》。 - 语义翻译设计师更新YAML契约 → 编译管线生成新版Checklist → DesignOps通知全组织。
- 设计师按新版Checklist设计注销流程 → 前端按新版Prompt前缀生成代码 → 验收通过。
该角色的反馈回流是框架的验证闭环Verify阶段闭环的组成部分：字典未覆盖的场景经快照回流、模式归档、契约更新、重新编译后，以新版字典与Checklist的形式回到所有消费方手中。
语义治理框架全景 三阶段与机制网络
设计师与产品经理的消费路径位于框架的验证闭环Verify阶段。框架全景分三层呈现。
6.1 三阶段全景
| 阶段 | 名称 | 做什么 | 核心产出 | 主要角色 |
|---|---|---|---|---|
| 阶段一 结构化诊断 | 组件语义快照与模式诊断 | 观察AI生成界面，结构化记录语义偏差，归纳为漂移模式 | 语义快照、三层判定模型、模式库（6个漂移模式） | 语义翻译设计师 |
| 阶段二 语义契约化 | 语义契约与编译管线 | 将设计意图翻译为YAML契约，经编译管线生成四种消费格式 | YAML契约、契约库、Prompt前缀 / JSON Schema / Checklist / CI规则 | 语义翻译设计师、DesignOps、前端工程师 |
| 阶段三 验证闭环 | 验证闭环 | 各角色消费编译产出，在设计、开发、验收环节拦截语义漂移 | 各角色消费路径（本文）、验证报告、回流反馈 | 设计师与产品经理、前端、DesignOps、管理层 |
6.2 资产流转
B["三层判定模型"]B --> C["模式库
6 个漂移模式"]
end
subgraph S2["阶段二 Contract · 写出规则"]
D["YAML 契约
契约库 Git 管理"] --> E["编译管线"]
end
subgraph S3["阶段三 Verify · 验证闭环"]
F["Prompt 前缀 / JSON Schema / CI 规则
→ 前端与 AI 工程师"]
G["语义字典 + 走查 Checklist
→ 设计师与产品经理（本文）"]
end
C --> D
E --> F
E --> G
G -->|"字典未覆盖场景回流"| C -->
6.3 本角色在框架网络中的触点
Schema-As-Code由9个机制主题构成一张相互衔接的网络。本角色触及其中4个节点：
| 机制主题 | 机制内容 | 本角色的触点 |
|---|---|---|
| ① 语义令牌与字典 | 组织级语义码本，覆盖层注册表 | 消费：设计决策与沟通时查询 |
| ② 语义域 | 组件的语义边界（observational / transactional 等） | 间接引用（查询字典时触及） |
| ③ 语义契约 | 设计意图的机器形态（YAML7字段） | —（由语义翻译设计师产出、前端消费） |
| ④ 编译管线与消费格式 | 契约编译为Prompt前缀/JSON Schema/Checklist/CI规则 | 消费：验收时使用Checklist |
| ⑤ 快照与模式诊断 | 语义断层的证据采集与归档 | 反馈：提交字典未覆盖的新场景 |
| ⑥ 推演引擎 | 生成中与验收中的机器拦截（语法/语义/安全/美感四层） | 辅助：验收时的分级参考 |
| ⑦ 验证闭环 | 持续证明规则有效（验证报告、对抗用例） | 间接关联（验收数据进入验证报告） |
| ⑧ 约束显化 | 方法论横切：规范从人读文档变为机器可读代码 | 受益方（消费资产的来源） |
| ⑨ ROI 与推广路线 | 投入产出与组织采纳路线 | —（由管理层消费） |
6.4 角色价值
设计师与产品经理在框架中的核心价值，是使用资产做决策：设计前查询语义字典，确保方案与组织级语义标准对齐；设计中用字典术语沟通，消除主观歧义；验收时按Checklist逐项核对，将语义漂移拦截在上线前；发现遗漏时回流至模式库，持续完善治理框架。
该角色是语义一致性的第一道防线，设计定义阶段不引用字典，后续所有约束都将失去业务语义基础。
一页纸速查：当前环节该做什么
日常快速查阅：Semantic Pipeline · 语义审查流水线
| 场景 | 依据 | 查什么 | 输出什么 |
|---|---|---|---|
| 设计前 | 语义字典 | 组件语义定义或场景映射如error_severity/SCN-001（删除账户） |
带语义标注的设计稿 Figma注释标注Fatal/Destructive/Retryable |
| 设计中 | 语义字典 | 术语标准表达替代主观词 | 与前端无歧义沟通记录 引用字典条目编号 |
| 写 PRD | 语义字典 | 场景映射编号与语义绑定 | 含语义约束引用的需求描述 |
| 验收时 | 走查Checklist | 逐项勾选（语义分级/文案/红线） | 通过/不通过结论 + 未通过项清单 |
| 验收拿不准 | 语义分级器 | 输入文案 获得分级建议 | 分级参考结论 最终判定以人工核对为准 |
| 发现遗漏 | 模式库反馈通道 | 该场景是否已有模式编号 | 按6字段快照格式提交新场景触发 ERR/PRO/BND/ACT/ALR/INF更新 |
示例：设计前 → 打开语义字典 → 查 error_severity → 输出带语义标注的设计稿。
Schema-As-Code 语义治理框架 · 角色专题系列。后续发布：《前端与 AI 工程师消费路径》《DesignOps 与设计系统负责人运营机制》《体验架构师 / 语义翻译设计师搭建指南》《管理层 / 决策者决策框架》；框架交付件、案例库与落地验证另篇呈现。
