盲图像超分辨率技术解析：MANet协同进化架构与MAConv模块实现
2026/8/6 1:02:47
定位：Schema-As-Code 证据链的"认知 + 合法性"站（B 列：全景 + 背书），覆盖主题行①的第二个关键设计——语义字典（Semantic Dictionary，覆盖层注册表）。回答"凭什么成立"：语义字典是组织内唯一定义覆盖层、语义绑定、场景映射的资产，是全组织同一术语坐标系。
快速阅读：
方法论总纲与开源：把设计规范写成代码格式，是所有 AI 工具的上游约束方法论
阶段一结构化诊断：组件语义快照与模式诊断：AI 生成界面的第一道检查
阶段二语义契约化：设计师作为"语义翻译者" 当AI生成界面时我怎么用规则锁住设计意图
角色专题1:设计师与产品经理：AI 界面语义走查指南
一、调整前：三条真实反馈里的"语义三无"
在没有语义字典之前，组织内的"语义"处于三无状态，每条都有团队里的原话为证。
真实反馈 1：“评审会上说’这里用一个 alert’，散会后发现三个人理解成三个东西。”
前端理解为模态弹窗，设计师指的是顶部通知条，产品经理以为是可以自动消失的 Toast。三个人用同一个词指三个东西，每个人都对——因为没有任何注册表裁定"alert 在这个场景下是什么"。同名异义，无人仲裁。
真实反馈 2：“删除账户按钮该红色实心还是橙色描边？最后谁的职级高听谁的。”
新产品线设计"删除账户"流程，一位设计师主张红色实心按钮、一位主张橙色描边，双方都有道理，最终靠职级裁定。决策依据是个人经验，不可复用、不可跨产品线继承。决策无据，全靠经验。
真实反馈 3：“PRD 写’需明显提示风险’，交付后才开始吵什么叫’明显’。”
开发按自己的理解实现，验收按自己的理解走查，争议在交付后才爆发。需求模糊，无法验收。
汇总成一张表：
| 环节 | 界面层呈现状态 | 缺失什么 |
|---|---|---|
| 评审沟通 | 同一术语多种理解 | 可引用的唯一定义注册表 |
| 设计决策 | 个人经验裁定 | 组织级场景语义方案 |
| 需求描述 | 自然语言形容词 | 可校验的语义引用 |
| 规范执行 | 文档供人阅读，AI 不可见 | 机器可查询、可校验的注册表 |
三条反馈，一个根因：组织里没有一份"唯一定义术语"的资产。字典在的时候，它是文档平台里供人阅读的文字；机器要查的时候，它不存在。
二、“用语义注册表统一定义”
"用语义注册表统一定义"在工业界已有成熟实践。
2024年起，企业数据领域已大规模实践"语义层"概念。Databricks在其Semantic Layer Architecture中将其定义为"business-friendly abstraction layer"，统一跨部门对"客户""订单"等业务术语的理解。这与我们的语义字典同构，Databricks解决数据领域的语义一致性，我们解决界面领域的语义一致性。架构相同：元数据仓库 → 业务逻辑层 → 治理框架。
2026年，Kyvos进一步提出AI-Ready语义层：没有语义层，AI无法正确解释数据含义。这个逻辑在界面领域同构，没有语义字典，AI无法正确解释"红色按钮是致命错误还是普通警告"。
软件工程领域更早。DDD的限界上下文（Bounded Context）定义术语在特定边界内的唯一含义，防腐层（Anti-Corruption Layer）防止外部模型污染内部语义。我们的语义域（覆盖层）即Bounded Context：同一个Alert在transactional域与observational域含义不同，各自域内唯一定义；跨层禁止规则即防腐层，status.critical不可用于observational域，非法绑定在编译时阻断。
但行业也有反面的声音。Design Systems Collective今年指出，很多所谓"语义令牌"只是换名（color-red-500改叫color-danger），没有场景定义。这恰恰反证了我们为什么需要真正的语义字典，不是换名，而是锁义。
参考链接：
Databricks Semantic Layer · Kyvos AI-Ready Semantic Layer · DDD Bounded Context · Design Systems Collective
三、关键设计：语义字典（三层注册表）
语义字典是覆盖层注册表，三层结构：覆盖层目录（Overlay Catalog）→ 语义重绑定（Semantic Rebinding）→ 场景映射（Scenario Mapping）。
| 层级 | 内容 | 查询时获得什么 |
|---|---|---|
| 第一层：覆盖层目录 | 4 个 L1 语义域：transactional（交易与操作）/ observational（观察与信息）/ navigational（导航与引导）/ conversational（对话与交互），加 L0/L2 层级 | 该界面点属于哪种交互关系、约束特征是什么 |
| 第二层：语义重绑定 | 术语在具体覆盖层下的强制语义（6 个语义绑定） | 某令牌在此场景的准确定义与跨层禁止 |
| 第三层：场景映射 | 业务场景的绑定组合与组件组合（SCN-001 ~ SCN-006） | 整个场景的完整语义方案，可直接引用 |
3.1 第一层：覆盖层目录（v1.0.0 全量）
| 覆盖层 ID | 中文名称 | 定义 | 适用场景示例 | 禁止场景 | 层级 |
|---|---|---|---|---|---|
| universal | 通用层 | 所有界面点的基础属性 | 可访问性、响应式 | — | L0（被所有层覆盖） |
| transactional | 交易与操作 | 用户动作会改变系统状态或数据 | 支付、删除、提交、确认、撤销 | 纯信息展示、状态更新、新手引导 | L1 |
| observational | 观察与信息 | 用户仅接收信息，无需立即行动 | 通知、状态更新、提示、反馈 | 需要用户决策、需要二次确认、不可逆操作 | L1 |
| navigational | 导航与引导 | 用户需要方向指引，无数据变更 | 面包屑、步骤指示、返回、跳转 | 表单提交、数据操作、支付流程 | L1 |
| conversational | 对话与交互 | 用户与系统双向交流，上下文持续 | 聊天、问答、建议、澄清 | 一次性操作、无上下文的状态提示 | L1 |
| financial | 资金操作 | transactional 的子层：涉及资金流动 | 支付、转账、退款 | — | L2 |
| data-destructive | 数据销毁 | transactional 的子层：涉及数据删除 | 删除账户、清空数据 | — | L2 |
强制规则：每个界面点必须且只能被一个 L1 覆盖层覆盖（互斥）；L2 是对 L1 的细化而非替代；未注册的覆盖层编译管线拒绝识别。
3.2 第二层：语义重绑定（v1.0.0 全量）
绑定是强制的，不是建议：
| 术语 ID | 所属覆盖层 | 状态级别 | 语义绑定 | 约束注入 | 跨层禁止 |
|---|---|---|---|---|---|
| status.critical | transactional | 系统级故障 | 阻断器：用户必须立即处理，否则系统状态恶化 | 视觉：红色脉冲、八边形图标；行为：必须二次确认；文案：必须说明后果；适用：仅用于阻断性错误 | observational / navigational / conversational |
| status.warning | transactional | 用户可恢复限制 | 限制器：用户需要注意，但可以自助恢复 | 视觉：黄色静态、三角图标；行为：必须显示恢复时间；文案：必须提供操作步骤；适用：仅用于可恢复错误 | observational / navigational / conversational |
| status.info | observational | 一般信息提示 | 信息条：用户可选择性关注，不影响系统状态 | 视觉：蓝色静态、信息图标；行为：可自动消失；文案：禁止附加操作说明；适用：仅用于纯信息展示 | transactional |
| status.success | observational | 操作成功反馈 | 成功条：用户操作已完成，系统状态已更新 | 视觉：绿色静态、对勾图标；行为：可自动消失；文案：禁止附加操作说明；适用：仅用于成功状态 | transactional |
| action.destructive | transactional | 不可逆操作 | 危险动作：用户动作将导致数据永久丢失 | 视觉：红色空心描边、危险图标；行为：必须二次确认；文案：必须说明不可恢复；适用：仅用于删除/清空等操作 | observational / navigational / conversational |
| action.primary | navigational | 主要引导动作 | 引导动作：帮助用户进入下一步或完成流程 | 视觉：品牌色实心、箭头图标；行为：点击后跳转；文案：显示下一步预览；适用：仅用于流程推进 | transactional / observational |
通用术语的重绑定示例（同一个词，不同覆盖层下绑定为不同语义）：
| 通用术语 | transactional 下绑定为 | observational 下绑定为 | navigational 下绑定为 |
|---|---|---|---|
| Alert | 阻断器：用户必须立即处理，否则系统状态恶化 | 信息条：用户可选择性关注，不影响系统状态 | 路径提示：用户需要方向确认，无状态风险 |
| 确认 | 不可逆操作确认：用户理解后果并承担风险 | 已知晓确认：用户收到信息，无需承担风险 | 路径确认：用户确认前往下一节点 |
| 取消 | 操作撤销：系统回滚到操作前状态 | 关闭提示：信息消失，系统无变化 | 返回上一步：导航状态回退 |
| 红色 | 危险信号：阻断、不可逆、需立即响应 | 非法绑定（observational 下红色非法） | 非法绑定（navigational 下红色非法） |
前端实现时不传type="error"参数，而是声明overlay="transactional"，由覆盖层强制注入语义。非法绑定在编译时直接阻断。
3.3 第三层：场景映射（v1.0.0 全量）
| 场景 ID | 场景名称 | 覆盖层 | 语义绑定组合 | 组件组合 | 文案约束 | 约束注入 |
|---|---|---|---|---|---|---|
| SCN-001 | 删除账户 | transactional | status.critical + action.destructive | Alert + Button + Modal | 必须包含"此操作不可恢复"；必须说明数据删除范围 | 必须输入账户名二次确认；必须提供取消按钮；操作后跳转至登录页 |
| SCN-002 | 网络中断 | transactional | status.warning | Alert + Button | 必须显示"网络不稳定"；必须显示自动重试倒计时 | 提供手动重试按钮；倒计时结束后自动刷新 |
| SCN-003 | 保存成功 | observational | status.success | Toast | 仅显示"保存成功"；禁止附加操作说明 | 3 秒后自动消失；不可手动关闭 |
| SCN-004 | 新功能上线 | observational | status.info | Banner | 显示功能名称和一句话说明；提供"了解详情"链接 | 点击链接跳转帮助中心；不可阻断当前操作 |
| SCN-005 | 支付确认 | transactional | status.critical | Alert + Form + Button | 必须显示金额、收款方、支付方式；必须说明支付后不可撤销 | 必须输入支付密码或指纹；必须提供"取消"按钮 |
| SCN-006 | 步骤引导 | navigational | action.primary | Stepper + Button | 显示当前步骤和总步骤；提供上一步/下一步 | 第一步禁用"上一步"；最后一步变为"完成" |
场景映射查询实例：设计师查询 SCN-001（删除账户），字典直接给出完整方案——覆盖层 transactional；语义绑定 status.critical + action.destructive；组件组合 Alert + Button + Modal；文案必须包含"此操作不可恢复"；交互必须输入账户名二次确认。视觉探索在边界内展开，语义方案无需重新发明。
3.4 注册纪律
字典是组织内唯一定义覆盖层、语义绑定与场景映射的资产。三条纪律：
- 唯一性：全组织同一术语坐标系，任何团队不得维护平行的"私有字典"。
- 强制性：所有 YAML 契约必须引用字典中的已定义项，不可自创覆盖层或绑定；
semantic_domain的值必须在字典预定义列表中，非法引用在编译前置校验时直接阻断。 - 先注册、后引用：字典没有的，先走字典变更流程注册（快照证据 → 诊断归档 → 候选模式 → 评审入典），再引用。不为想象中的需求提前定义语义。
四、架构层概念：设计背景
覆盖层（Overlay）不是分类（Taxonomy）。分类模型语义内生于组件（<ErrorAlert>自带"错误"语义，组件库升级时语义跟随重写）；覆盖层模型语义外赋于组件——组件是空容器（<Alert>只负责渲染），语义由覆盖层强制注入。组件库是底层（Underlay），语义覆盖层在组件之上加盖业务语义，把空容器翻译为业务语义组件。分类回答"这是什么组件"，覆盖层回答"这个组件在此场景下承担什么语义"。
码本，而非术语表。术语表供人查阅，码本供机器解码：每个绑定是离散索引，编译管线查表后展开为连续约束。这决定了字典的读者不只是设计师，更是编译管线与 AI 工具。
在全景中的位置。语义字典位于建设层的最上游（元规则层）：语义字典（上游·元规则）→ YAML 契约（中游·实例）→ 编译管线（下游·执行），契约库提供组织级管理。
术语双轨。面向不同读者群时，三层结构有两套叫法：语义域 ≈ 覆盖层目录；语义令牌 ≈ 语义重绑定；场景映射 ≈ 约束注入。两套术语指向同一份注册表。
五、这些坑怎么被解掉：三条反馈的闭环
回到开头的三条真实反馈，字典就位后它们各自的解法路径。
反馈 1 的解法：“alert 到底是什么”——歧义在引用条目的瞬间消失
- 症状复盘：评审会上"这里用一个 alert"，三个人理解成三个东西。
- 根因：没有可引用的唯一定义注册表，术语含义靠各自脑补。
- 解法路径：查字典——transactional 域的 alert 是阻断确认，observational 域的 alert 是顶部通知条。设计师与产品经理沟通时，用字典条目编号替代形容词；争议以字典为仲裁依据，不再靠职级裁定。
- 验证方式：同样的评审场景，引用条目编号后，三方理解在当次会议对齐，不再"散会后才发现"。
反馈 2 的解法：“删除账户按钮之争”——决策依据从职级变成注册表
- 症状复盘：红色实心 vs 橙色描边，双方都有道理，靠职级裁定。
- 根因：没有组织级场景语义方案，决策依据是个人经验，不可复用、不可跨产品线继承。
- 解法路径：查询 SCN-001，完整语义方案既定（覆盖层 transactional + status.critical + action.destructive + 二次确认），视觉探索在边界内展开。
- 验证方式：跨产品线语义天然一致——下一个产品线遇到"删除账户"，直接引用同一场景映射，不重新争论。
反馈 3 的解法：“什么叫明显提示风险”——需求从形容词升级为可校验引用
- 症状复盘：PRD 写"需明显提示风险"，交付后才吵"什么叫明显"。
- 根因：需求用自然语言形容词描述，没有可校验的语义引用。
- 解法路径：PRD 改写为"引用场景映射 SCN-001，语义绑定 action.destructive，必须二次确认"。
- 验证方式：验收标准在需求阶段即已确定——交付后的争议消失，因为"明显"已经被翻译成字典里的具体约束。
六、扩展路线
- v1.0.0（当前）：4 个 L1 覆盖层 + 6 个语义绑定 + 6 个场景映射，只覆盖证据最充分的 6 个漂移模式。
- v1.1.0（规划）：按业务需求新增覆盖层（如 onboarding 新手引导）、新增绑定（如 status.neutral 中性状态）、新增场景映射（如"批量删除"“跨设备同步”）。
- v2.0.0（远期）：重构覆盖层分类（如 transactional 拆分为 financial 和>七、调整后：工具界面层的呈现状态
工具 / 环节 调整前 调整后 组件调用 Alert 是无语义的视觉容器 契约编辑器中覆盖层下拉自字典：选 observational 即继承"不可阻断流程"约束，选 transactional 即继承确认交互要求 验收环节 走查结论停留在"感觉不对" Checklist 第一组直接引用字典：覆盖层检查 / 语义绑定检查 / 约束注入检查，结论注明字典版本号 规范变更 文档平台发通知，人看漏、AI 不可见 字典单点变更 → 契约重编译 → 四种消费格式同步更新，Git Diff 可追溯 边界声明
语义字典不解决视觉值的一致性（那是 Design Token 层的职责），不定义具体场景的约束实例（那是 YAML 契约的职责），也约束不了"有没有人查它"（消费纪律在角色侧，见角色 1 长篇）。当前量化收益均为数据模型推演，待生产数据验证。
1920