验证 Guard 阶段的收官产物：把诊断出的模式翻译回交付链语言，告诉组织断层在哪两次交接里，
从而告诉 Contract 阶段契约该打进哪个桩。以 ERR-001 错误状态后果差异未分级为示例。
三栏断层地图定位语义压缩发生在哪一次交接
① 设计意图
规范文档（自然语言）
"错误提示应区分严重程度：致命错误需醒目警示并引导用户保全上下文；临时性错误应弱化表达，避免用户过度反应。"
语义留存
② 设计稿表现
Figma 稿 + 标注
错误组件库共 3 套样式：Error Banner（红）、Toast（灰）、Inline（橙）。无级别字段，无场景映射表。
语义留存
③ 工程实现
接口字段 + 组件 Props
后端下发 isError: true（布尔值）；前端 Alert type="error" 一个参数打天下。
语义留存
语义压缩路径
四级分级
致命/可恢复/降级/提示
两套样式
Error / 非 Error
一个布尔值
true / false
语义存活曲线：横向看语义衰减，纵向看断层位置
| 语义维度 | ① 意图 | ② 设计稿 | ③ 工程实现 | 断层位置 |
|---|---|---|---|---|
| 错误分级 | 四级：致命/可恢复/降级/提示 | 两套样式：Error Banner / Toast | isError: boolean | ②→③ 压缩 4→2→1 |
| 颜色语义 | "致命用警示红，可恢复用提示黄" | Error Banner 统一 #EF4444 | color: danger | ①→② 分级色板塌缩为单色 |
| 行动引导 | "致命需提供上下文保全入口" | 无相关组件 | 无相关字段 | ①→② 行动意图未进入组件库 |
| 文案约束 | "必须说明后果与恢复预期" | 占位文案"出错了，请重试" | 文案由前端硬编码 | ①→② 约束退化为占位符 |
读法说明
横向看：语义存活曲线。从意图到设计稿到工程实现，每个语义维度的信息如何逐级衰减。
纵向看：断层位置列把压缩精确定位到某一次交接——是意图到设计稿断了，还是设计稿到工程实现断了。
对于 ERR-001，所有四个语义维度的压缩都发生在 ①→② 或 ②→③，即交付链的前两环已经丢失了 90% 的语义信息。AI 只是在最后一环（生成）继承了已经被压缩殆尽的语义输入。
语言形态的不可互算性：机器能校验的，语义最贫瘠
设计意图
自然语言段落
形容词与副词
"应区分严重程度"
"需醒目警示"
机器能否校验
否：不可运算
设计稿表现
视觉组件 + 标注
样式差异与组件命名
"Error Banner"
"Toast"
机器能否校验
否：命名是字符串，无语义结构
工程实现
接口字段 + Props
枚举值与布尔值
isError: true
type: "error"
机器能否校验
可校验
但语义已被压缩殆尽
关键发现
第三栏（工程实现）是唯一机器可校验的，但也是语义最贫瘠的——机器校验介入得越晚，能守住的东西越少。
这意味着：如果只在工程实现层做校验（如 ESLint/Stylelint），你校验的只是一个已经被压缩了 90% 的语义残片。真正的语义丢失发生在更早的交接环节，而那里恰恰是机器无法触及的灰色地带。
同一条限流提示，按断层地图修复前后的三栏对比
| 交付环节 | Before（无断层意识） | After（按断层地图修复） |
|---|---|---|
| ① 意图 | "限流属可恢复错误，弱化表达"（文档第47页，无人引用） | error_severity.retryable 注册入典，字典可查 |
| ② 设计稿 | 设计师选 Error Banner（红），因为组件库没有"可恢复"分类 | 组件库挂载令牌映射：retryable → 黄色时钟样式 |
| ③ 工程实现 | isError: true → Alert type="error" → 红色 | error_severity: retryable → 按契约渲染黄色 + 倒计时文案 |
| AI 生成 | 读到布尔值 + 红色样式，输出全红错误条 | 注入契约约束，输出黄色弱化提示 |
| 用户体验 | 以为系统崩溃，刷新丢失内容 | 看到"42 分钟后自动恢复"，等待即可 |
修复核心动作
不是让设计师"更仔细"，也不是让前端"更规范"，而是在交付链的每一次交接处插入语义契约：
• ①→②：意图中的自然语言描述被翻译为字典中的语义令牌（error_severity.retryable）
• ②→③：设计稿中的组件样式与语义令牌建立映射关系（retryable → 黄色时钟）
• ③→AI：工程实现中的接口字段承载语义令牌，而非布尔值（error_severity 替代 isError）
语义断层地图的价值不是"发现问题"，而是告诉 Contract 阶段契约该打进哪个桩——是修 ①→② 的翻译，还是修 ②→③ 的映射，还是修 ③ 的接口字段。
诚实清单 + 五个角色的一句话总结
| 验证项 | 状态 | 说明 |
|---|---|---|
| 三栏断裂是否真实存在 | 已验证 | 限流误报复盘、错误分级案例均可沿三栏复现压缩 |
| 压缩点是否可结构化定位 | 已验证 | 每个压缩点可定位到具体交接与语义维度 |
| 断层修复后语义是否存活到第三栏 | 已验证 | 枚举字段替换布尔值后，语义级别可到达渲染层 |
| 地图绘制成本 | 部分验证 | 单条约 1-2 小时，全量成本待评估 |
| 三栏同源的组织落地 | 待采集 | 演示环境成立，生产版本同步纪律待验证 |
设计师
"你的意图没有错，是意图到组件库的翻译没有校验。"
语义断层地图让设计师看到：自己写的规范文档（①）和设计稿（②）之间的语义压缩不是设计能力问题，而是翻译环节缺少校验机制。修复不是让设计师"写得更清楚"，而是在 ①→② 之间插入语义令牌映射。
语义断层地图验证完成
Schema-As-Code 三阶段流水线：Guard → Contract → Verify