当同一规则被手工翻译成Prompt前缀、Checklist、JSON Schema和CI规则时，四份产物可能各自为政，最终导致版本混乱。本文通过真实案例，剖析手工维护的四重断裂，并展示如何通过编译管线实现单一来源、自动同步与版本追溯，让规则资产真正成为可执行的机器契约。

在前序工作中，我先把语义概念编码为离散枚举，让”致命””警告”这些词在组织内有了唯一机器身份，这是语义令牌与字典建立的组织级信源；接着确认组件本身是空容器，同一个 Alert 在交易场景是阻断器、在观察场景是信息条，于是用覆盖层给组件外赋语义，这是语义域划定的场景边界；然后把这些原本存在于设计师直觉里的”红色代表告警””高危操作必须二次确认”，翻译成机器可读的字段与禁令，这是约束显化完成的语义翻译；最后把翻译结果写成YAML的七个冻结字段，经过结构、语义、同步三道校验后入库，成为可版本追溯的规则资产，这是语义契约确立的机器形态。

到这一步，规则已经以代码形式坐在仓库里。 以下是一份已通过入库校验的YAML契约（ERR-001 v1.2.0），作为编译管线的输入源：

但还有一个关键断层： 组织内有多个业务团队，同一个基线在不同团队中有不同的消费方式、扩展需求和接入进度。如果每个团队各自复制粘贴YAML，规则会碎片化；如果统一管控，团队会失去灵活性。

产物层差异要回答的，正是这个断层： 同一条规则，怎么变成Prompt前缀交给AI工程师、JSON Schema交给前端、Checklist交给设计师、CI规则交给流水线？手工维护四份产物和编译管线自动生成，到底有什么实际差别？

本文核心回答三个问题：

① 同一条语义规则，手工维护四份产物和编译管线自动生成，分别长什么样？

② 产物层的一致性，靠人维护为什么守不住？

③ 这个差别带来的能力是不是不可替代。

一、问题：同一条规则，四份产物，四个版本

ERR-001 错误状态诊断、BND-001 边界动作诊断已经证明了：AI生成界面的语义漂移不是“感觉不对”，而是可以被结构化定位的真实问题，错误状态共用同一种红色、边界动作中拒绝与终止混为一谈，这些漂移都有明确的根因（缺少语义令牌）和可验证的修复路径（契约约束 + 机器校验）。（见【6个漂移模式】【从观察到契约】）

Token层差异证明了Token必须携带语义结构，字段层差异证明了契约字段与自然语言规范在机器可执行性上的真实差别。但论证成立之后，下一个问题自然浮现：契约写好了，下游产物怎么交付？

毕竟，很多团队的规范文档里早就写了”错误状态要分级”，也早就有了四份产物：Prompt前缀给AI用、Checklist给走查用、JSON Schema给前端校验用、CI规则给流水线用。团队以为”产物已经到位了”。但面对”限流提示从黄色改为黄色 + 倒计时”这条变更时，四份产物出现了四个版本，没有任何一份是“错”的，每一份都出自认真负责的人，但它们合起来是错的。

1.1 一个真实踩过的坑

某团队更新了一条语义规则：”限流提示从黄色改为黄色 + 倒计时。”

规范文档当天改了。两周后事故复盘发现：

• Prompt前缀还是旧的（AI继续生成无倒计时的限流提示）
• Checklist是新的（走查按新标准判不合格）
• CI 规则没改（不拦截）
• 前端枚举手工加的（拼写与文档不一致，校验形同虚设）

同一条规则，四份产物，四个版本，没有任何一份是”错”的，每一份都出自认真负责的人，但它们合起来是错的。更要命的是：没有任何机制能回答”这四份产物现在一致吗”。

1.2 根因：产物层的一致性，靠人维护不出来

手工维护的升级路径是“各自更新”：规范变了，四个人各自记得、各自有时间、各自理解。这个改动只动了人脑记忆，没动机器可执行的同步机制。

编译管线的升级路径是“单一来源编译”：把规范写成YAML契约，Git提交后自动编译为四份产物，每份产物头部嵌入版本声明。版本对账可以检测过期，哈希校验可以检测手改，消费追踪可以定位滞后。（见【编译管线】）

1.3 为什么团队会踩这个坑

因为手工维护的”四份产物”在启动层已经进步了，至少团队有了四种格式。但这种进步停留在“有产物”层，没有到达“产物一致”层。

当规范变更频繁时，问题暴露：四个人各自维护的产物，没有共同的事实源，没有同步机制，没有版本标识，没有一致性证明。规范改了，某份产物更新了，其他三份可能还是旧的，但没有人知道。

1.4 规则生产者 vs 规则消费者：先分清谁在消费

在列角色断裂表之前，必须先纠正一个常见混淆：写规则的人和用产物的人不是同一批人。

本文聚焦“下游消费者”，四份产物、四个消费者，一一对应，不交叉、不合并。上游生产者的踩坑与解法我会在后续角色专题《语义翻译设计师》说明。

1.5 这个差别是真实存在的吗：角色工作流断裂表

同一根因，产物无单一来源、无同步机制，在四个消费者角色身上长出的坑各不相同，而且每个坑都精准地断在该角色的工作流上：

注意上表的对应关系：每个角色只消费一种产物，AI工程师不碰Checklist，前端工程师不碰Prompt前缀，DesignOps不写CI规则。此前的版本把”前端/AI工程师”合并成一列、把Checklist的坑安到他们头上，是角色-产物错配：Checklist的消费者是DesignOps，Prompt前缀的消费者是AI工程师，两者不能合并。

二、为什么手工维护守不住：四重断裂

2.1 无单一来源：四份产物没有共同的”事实源”

规范文档是一份自然语言文件，四份产物各自从文档里”解读”出规则。写Prompt前缀的AI工程师理解为”必须显示倒计时”，写Checklist的DesignOps理解为”建议显示倒计时”，写 JSON Schema 的前端工程师理解为”字段可选”，同一条规则，四种解读。四个人各自解读规范，谁也没错，但合起来就错了。

2.2 无同步机制：规范变了，四份产物的更新依赖四个人各自记得

规范文档改了，没有机制通知四份产物的维护者。靠人记得、靠人有时间、靠人理解一致，这三件事在规模化下不可能同时满足。典型场景：DesignOps通知了前端工程师，但 AI 工程师没收到。

2.3 无版本标识：产物不携带”我基于规范的哪个版本”

Prompt前缀文件里没有”基于 ERR-001 错误状态诊断 v1.1.0 编译”的声明。前端工程师拿到JSON Schema，不知道这是 v1.0 还是 v1.1。一个月后有人拿到这份文件，不知道它是新的还是旧的。

2.4 无一致性证明：没有任何机制能证明四份产物表达同一语义

走查按Checklist判合格，但AI按旧版Prompt前缀生成的内容不符合新标准，两者标准不一致，却没有任何机制能检测这个不一致。管理层抽查，只能看到表面一致，看不到语义分歧。

三、关键设计：产物层差异 Before / After

给产物”挂身份证”，而不是只写内容

以前把Prompt前缀、Checklist、JSON Schema、CI规则写成四份独立文件，以为这样就”产物到位了”。但对机器来说，这四份文件是四个独立个体，没有共同来源，机器不知道”它们是否来自同一条规则”。

真正的产物管理是给每份产物挂一张身份证：这份产物基于哪个契约、哪个版本、什么时候编译的。有身份证，机器才能对账、才能检测过期、才能拦截手改。

机器看到的不只是内容，还有”来源 + 版本 + 一致性”

传统的手工维护产物只有内容。编译管线产物有三层：

1. 来源：基于ERR-001错误状态诊断 v1.1.0 编译
2. 版本：编译时间、Git Commit Hash
3. 一致性：三层编译验证（结构 / 语义 / 交叉比对）

消费方加载产物时，不仅拿到内容，还拿到”这份产物是否可信”的证明。

从”各自维护”变成”一处修改，四处同步”

以前：规范改了 → 通知四个人 → 某人忘了 → 某份产物还是旧的 → 走查和生成标准冲突 → 事故复盘才发现。

现在：规范改成YAML → Git提交 → 钩子触发编译管线 → 四份产物自动生成 → 每份产物带版本声明 → 消费方自动更新。一处修改，四处同步，零遗漏。

手改产物是一致性最大的敌人

“compiled/ 目录下的文件禁止手改”不是工程洁癖，是一致性底线。一旦允许手改，产物就不再是”契约的忠实翻译”，而是”某个人的个人理解”，且这个理解不会同步到其他三份产物。

两层跃迁：从”手工翻译”到”机器编译”

第一层只解决了”有产物”，第二层解决了”产物一致”。

3.1 Before：手工维护形态

以 ERR-001（错误状态后果差异未分级）为例，四个消费者各自手工维护的产物，注意每份都是认真负责的人写的，没有任何一份是“错”的：

Prompt 前缀（AI工程师手写，给AI用）

问题：没有引用 status.critical，”严重的用红色”是自然语言解读；”建议加确认”是不可判定的弱约束。

Checklist（DesignOps 手写，给走查用）

问题：”醒目””品牌红”与AI工程师理解的”红色”未必是同一种红；没有四级分级检查项，因为写清单时参照的是旧版规范。

JSON Schema（前端工程师手写，给Props校验用）

问题：枚举是 high/medium/low，与字典的 fatal/transient/retryable/degraded 四级完全对不上；color是自由字符串，任何颜色值都能通过校验，校验形同虚设。

CI 规则（研发效能手写，给流水线用）

问题：只警告不阻断；规则内容与契约的”二次确认强制”完全无关，该拦的没拦。

问题拆解：四份产物各自解读规范，没有共同事实源（四级分级 vs 高中低三级并存）；规范改了，更新不同步；产物无版本标识，过期不可检测；没有任何机制能证明四份产物表达同一语义。

3.2 After：编译管线形态

输入源：以下是一份已通过入库校验的YAML契约（ERR-001 v1.2.0）。

完整字段定义与写作指南见《④ YAML 契约：设计意图的接口定义，编译即规则》，本文只展示编译输入，不重复解释字段。

【产物层差异演示环境】同一条规则，写成一份YAML契约：

编译管线自动生成的四份产物，每份头部嵌入版本声明：

Prompt 前缀（AI工程师消费）

关键设计：反馈不是”抱怨”，而是结构化的输入，每个反馈必须带标注、带场景、带预期，才能进入修订流程。

AI工程师的反馈链路：AI工程师在Cursor里生成删除账户弹窗，AI输出蓝色实心”确认”按钮。

四层推演拦截，返回：BLOCK [ERR-001-v1.2.0] action.destructive: 缺少二次确认弹窗；缺少”此操作不可恢复”文案。

AI工程师不需要改YAML，只需要在Cursor的修复建议中看到：”请在Prompt中补充：’必须包含二次确认弹窗，文案必须说明不可恢复’。”

反馈闭环：AI工程师修改Prompt → 重新生成 → 通过校验 → 消费追踪系统记录”Prompt 前缀生效，拦截后修正”。

JSON Schema（前端工程师消费）

前端工程师的反馈链路：前端工程师在 TypeScript 编译时看到报错：”color” must be one of [status.critical, status.warning, status.info, status.success]。

这不是普通的类型错误，而是契约条款的引用，报错信息里嵌入了契约 ID（ERR-001-v1.2.0）和具体条款（semantic_tokens.error_severity.fatal.color_token）。

前端工程师不需要读懂 YAML，只需要点击报错中的链接，跳转到契约的可视化解释页面，看到：”致命错误必须用红色脉冲，你当前用了蓝色实心，请修改。”

反馈闭环：前端修改代码 → 重新编译通过 → CI 上报”本次拦截由 ERR-001 条款触发，已修正” → 消费追踪系统记录”Schema 引用次数 +1，拦截次数 +1，修正次数 +1″。

Checklist（DesignOps 消费）

DesignOps的反馈链路：DesignOps用Checklist 走查设计稿，第3项未通过：”致命错误是否说明了’对话上下文可能已丢失’？”

设计稿当前文案是”出错了”，不符合契约条款。

DesignOps在Checklist上标记”未通过”，系统自动生成修订建议：”请将文案改为’消息流中断，对话上下文可能已丢失，建议刷新页面或导出历史’。”

反馈闭环：DesignOps 提交修订建议 → 流转到语义翻译设计师 → 修订契约 → 重新编译 → Checklist 自动更新 → DesignOps 下次走查时看到新版 Checklist。

CI 规则（CI流水线消费）

四份产物里的 status.critical、fatal、confirm_dialog 全部回溯到字典中的同一个绑定ID，同一语义，四种表达，机器可证。

CI的反馈链路：前端提交代码，CI加载 payment-ci-rules.yml，检测到 destructive 绑定缺少 confirm 属性。

CI阻断提交，报错信息：[Semantic Guard] BLOCK: 违反 action.destructive 不可变边界（ERR-001-v1.2.0）。必须在用户点击前显示二次确认。详情见：{契约可视化链接}。

反馈闭环：前端修改代码补充确认逻辑 → 重新提交 → CI通过 → 上报”本次由CI规则触发拦截，已修正”。

3.3 逐产物差异对照

注：上表”第一读者”列中，语义翻译设计师与管理层分别是规则生产者与效果评估者，他们读这张表是为了写契约和做决策，不是为了消费产物。

3.4 推演对照：规范变更后，怎么知道四份产物同步了？

我们没有生产环境的实测数据，但可以建立一套观测标准和推演公式，让团队自己验证”编译管线是否真的解决了一致性问题”。

观测标准 1：版本对账

问题：规范变更后，我怎么知道四份产物都更新了？

推演公式：

手工维护形态（推演）：

• 4份产物 × 5个团队 = 20个同步点
• 靠人通知、人记得、人有时间
• 推演同步率：60%–80%（假设20%的人忘了或没时间）

编译管线形态（推演）：

• Git提交触发自动编译 → 4份产物自动生成
• 推演同步率：100%（机器不遗忘）

验证方法：抽查任意规范变更后7天内，四份产物的版本声明是否一致。

观测标准 2：滞后检测

问题：如果某份产物没更新，多久能发现？

推演公式：

手工维护形态（推演）：

• 检测方式：走查时发现 AI 生成内容与新标准冲突
• 推演检测延迟：1–4周（取决于走查频率）

编译管线形态（推演）：

• 检测方式：消费追踪系统比对产物版本
• 推演检测延迟：<10分钟（设计目标，待实测验证）

验证方法：模拟一次规范变更，记录从提交到发现某产物滞后的时间。

观测标准 3：一致性得分

问题：四份产物表达的是同一语义吗？

推演公式：

检查项示例（以 ERR-001 为例）：

手工维护形态（推演）：

• 每项由不同人维护，解读可能不同
• 推演一致性得分：70%–85%

编译管线形态（推演）：

• 同一YAML编译产出，语义回溯到同一绑定ID
• 推演一致性得分：≥95%

验证方法：随机抽取一条规则，人工比对四份产物的关键检查项是否语义等价。

观测标准 4：返工成本

问题：产物不一致导致的返工，成本多少？

推演公式：

手工维护形态（推演）：

• 假设每周2次语义不一致导致的返工，4人参与
• 月度返工成本：50分钟 × 8次 × 4人 = 1，600分钟 ≈ 27人时

编译管线形态（推演）：

• 机器自动同步，返工次数趋近于0
• 月度返工成本：趋近于0（仅处理机器误报例外）

验证方法：记录团队1个月内因”产物版本不一致”导致的返工工时。

诚实声明

以上四个观测标准及推演公式，均为数据模型推演（Phase 0口径），不是生产环境实测数据。

这不是“已经发生的案例”，是“你可以用来验证的标尺”。

3.5 不是”多了一种工具”，是”一致性从人管变成机管”

五、诚实清单

六、推演条件

6.1 角色就绪度（组织落地前提）

七、框架设计背景：从产物层差异回到 Schema-As-Code 全景

产物层差异不是孤立的技术讨论，而是 Schema-As-Code把设计规范写成代码格式框架设计假设的一个验证切片。要理解这个案例的价值，需要先看到它在整个框架中的位置。

7.1 语义治理框架全景：三阶段与机制网络

Schema-As-Code 不是一套理论，是一条可执行的三阶段流水线（Semantic Pipeline）。（见【从观察到契约】）

产物层差异横跨三个阶段：

1. Guard 阶段：通过 6个漂移模式观察到“产物不一致导致语义漂移”（ERR-001 根因：Prompt 前缀是旧的，AI 继续生成无倒计时的限流提示）
2. Contract 阶段：将 YAML 契约经编译管线编译为四份产物，每份带版本声明
3. Verify 阶段：通过版本对账、哈希校验、消费追踪证明产物一致性可被机器守住

7.2 案例验证：产物层差异证明了什么

证明一：产物漂移的根因可被定位到交付层

ERR-001 的根因不是”前端工程师没更新Prompt前缀”，而是”产物层没有单一来源和同步机制”。四份产物各自维护，规范变更后必然出现版本不一致，这是交付结构层面的缺陷。

这个发现不是某位工程师”忘了更新”，而是通过三层判定模型被归档为常见问题类型：第一层识别组件类型为”错误状态”，第二层判定语义缺失为”后果差异未分级”，第三层校验交付形态为”产物无版本标识、无一致性证明”。

证明二：产物必须编码为带版本声明的编译产物

修复不是”提醒四个人记得更新”，而是给产物增加机器可检测的结构：版本声明、哈希校验、消费追踪。YAML契约经编译管线编译后，产物头部嵌入”基于 ERR-001 v1.1.0 编译”的声明，消费方加载时自动对账。手工维护做不到。

这些产物被写入规则仓库作为组织级唯一信源，产物不是独立文件，是契约的忠实翻译：前端工程师按JSON Schema校验，CI按规则拦截，AI工程师按Prompt前缀注入约束。

证明三：产物层的差别必须被证明有效

对比验证：同一规范变更”限流提示增加倒计时”，手工维护形态下四份产物出现四个版本，编译管线形态下四份产物自动同步为 v1.1.0。

约束真的改变了交付行为：版本对账后，消费方加载旧版本产物时被自动标记告警；哈希校验后，手改产物在CI中被拒绝合入；消费追踪后，”哪些产物还没更新”从”不知道”变成”5分钟内可见”。这套验证机制在【字典引用的机器校验】中被完整定义。

7.3 从横向差异到纵向差异：语义资产的分层逻辑

前文验证的是横向差异：同一份YAML契约，因为消费角色的工作习惯不同，需要编译为Prompt前缀 / JSON Schema / Checklist / CI规则四种格式。这是”同一语义在同组织内的表达差异”。

但还有另一种差异更值得前置思考：纵向差异，同一语义，在不同组织层级中的”定义权重”不同。

举个例子：status.critical 致命错误这个语义令牌。

• 在行业标准层面：它意味着“用户必须立即处理，否则系统状态恶化”。这个定义是跨行业共识，不因某家公司而改变。
• 在组织品牌层面：它映射到具体的色值（如 #EF4444）、具体的图标（如八边形警告）、具体的动效（如红色脉冲）。这个映射是品牌自定义，不同公司可以不同。
• 在业务场景层面：支付团队可能要求”致命错误必须二次人脸验证”，内部工具团队可能只要求”刷新页面”。这个权重是场景微调，不同团队可以不同。

如果三层混为一谈，会发生什么？

• 行业标准过强：所有公司的致命错误都长一样，品牌个性被抹平
• 组织层过强：团队不能根据业务场景微调，规则僵化
• 团队层过强：每个团队自己定义“致命错误”，组织内语义碎片化

产物层差异的验证，让我们看清了一个更底层的命题：差异本身需要分层管理。

横向差异（同一语义在同组织内的不同表达）用编译解决，机器自动翻译，确保四种格式语义等价。

纵向差异（同一语义在不同组织层级的不同定义权重）用继承解决，上层定共识，中层做品牌，下层做场景，各层有明确的“差异权”边界。

关键设计判断：

• 上层不干预下层：行业标准只管”致命错误必须立即处理”这类共识，不管某家公司用什么色值、哪个团队加什么验证步骤。
• 下层不覆盖上层：团队可以在组织规范内自由扩展，但不能把”致命错误”降级为”温馨提示”，这是架构的硬边界。
• 各层独立演进：行业标准升级了，组织可以选择跟或不跟；组织规范升级了，团队可以选择跟或不跟。每一层都有版本锁定能力。

当前状态：我们验证的是横向差异（同一语义在同组织内怎么编译给四个消费者）。纵向差异（同一语义在不同组织层级怎么定义权重）的接口协议已设计完成，但实现留给下一阶段，因为当前绝大多数团队连”组织内统一语义规范”这一层尚未跑通。

先让语义规范在组织内像设计系统一样被管理、被分发、被消费；当这个闭环跑通后，跨组织引用只是同一逻辑的纵向延伸。

7.4 回到开篇的问题

同一条语义规则的下游产物，在手工维护形态与编译管线形态下分别长什么样、差别带来什么能力，以及这个差别是不是真实存在？

手工维护形态：四份独立文件，各自解读规范，无版本标识，无同步机制，无一致性证明。规范变更后，四份产物必然出现版本不一致，这是结构层面的必然，不是人的责任心问题。

编译管线形态：一份YAML契约 → 编译为四份产物 → 每份带版本声明 → 版本对账检测过期 → 哈希校验拦截手改 → 消费追踪定位滞后。规范变更后，四处自动同步，零遗漏。

这个差别带来的能力是不是不可替代？

是。没有编译管线的单一来源和同步机制，产物一致性只能靠人维护，而人维护在规模化下必然失效。10条规则 × 4份产物 × 5条产品线 = 200个需要人脑对齐的点。单一来源不是工程洁癖，是一致性在规模化下的唯一解。

这个案例同时也回答了更底层的问题：为什么需要 Schema-As-Code 这套框架？因为语义漂移的根因不止在界面层、Token层、字段层，也在产物层。当四份产物各自维护、版本不一致时，上游的契约、编译、验证全部失去意义。框架提供的不只是诊断方法和契约模板，而是一套从Token编码到字段契约到产物交付的完整工作流。

八、一句话总结（给不同角色）

给四个消费者角色：

给 AI 工程师：”以前我自己写Prompt前缀，写成’用红色表示严重’，和设计师说的 status.critical 对不上。现在机器自动编译Prompt前缀，直接注入 system message，我消费的就是契约本身。”

给前端工程师：”以前设计师给的YAML我看不懂，自己翻译成JSON，status.critical 和 color: red对不上。现在机器自动编译JSON Schema，直接用于Props校验，版本与契约严格同步。”

给 DesignOps / 设计师：”以前我自己写走查Checklist，漏了’不可恢复’文案，走查时没发现；还有人手改产物，两套’真相’同时在线。现在Checklist由机器自动编译，字段齐全、版本同步，compiled/禁止手改，走查标准就是契约标准。”

给 CI / 研发效能：”以前校验规则自己写，和契约对不上，拦了不该拦的、漏了该拦的。现在CI规则由机器自动编译，与契约版本严格同步，该拦的一条不漏。”

给规则生产者与评估者（非消费者）：

给语义翻译设计师 / 体验架构师：”你不是这四份产物的消费者，你是它们的生产者，改一次YAML，编译管线自动生成四份产物，变更成本从4人天降到 0.5人天（推演口径），你不再需要通知四个人各自更新。”

给管理层 / 决策者：”你也不消费产物，你看的是产物的效果，消费状态数据库实时追踪四个消费方的加载版本，滞后5分钟告警，语义一致性得分从’人估’变成’机管’。”

九、下一站

产物层的差别确认之后：

• 契约自身的机器校验（字段冻结、入库校验、同步对账），见《契约的机器防线》；
• 字典引用的合法性论证（覆盖层存在性 / 绑定存在性 / 场景一致性），见《字典引用的机器防线》；
• 跨层非法绑定的拦截机制，见《跨层禁止》；
• 各消费方的接入方式，见角色专题《消费 Prompt 前缀与 CI 规则》《消费走查 Checklist》《运营规则仓库》；
• 消费分发之后是否真的被加载、被注入、被执行，见《契约消费追踪：契约版本与下游消费面自动对齐》。

附录：

【演示环境：产物层差异演示】：https://2436041978-ops.github.io/semantic-pipeline/mechanism/04-compilation-pipeline/artifact-layer-diff.html

① 语义令牌表：把语义概念编码成离散枚举：

https://www.yuque.com/u222739/why7ts/ahgd86ugl61h6dy3

① 语义字典：组织级语义注册表，契约的唯一信源：

https://www.yuque.com/u222739/why7ts/mr4mqy0cnkl8gmab

② 语义域：组件是空容器，语义由场景定义：

https://www.yuque.com/u222739/why7ts/qxep0yb6b98uwkng

③ 约束显化：把隐含的语义假设变成显式规则：

https://www.yuque.com/u222739/why7ts/rdzgmhsxst8wea6b

③ 编译前置校验：显式规则的 5 项机器安检：

https://www.yuque.com/u222739/why7ts/xybe6hbn3r0no0qb

④ YAML 契约：设计意图的接口定义，编译即规则：

https://www.yuque.com/u222739/why7ts/xxrmf2wlhh6h0wxc

6 个漂移模式：AI 生成界面的语义断层证据库：

https://www.yuque.com/u222739/why7ts/rwlzmucm3lgxzm10

从观察到契约：Semantic Pipeline 的三阶段工作流：

https://www.yuque.com/u222739/why7ts/pfaoq6xsftme601m

① Token 层差异：从颜色值到语义状态的三层跃迁：

https://www.yuque.com/u222739/why7ts/to224eewapfpigp9

④ 字段层差异：颜色、文案、图标各自有独立的语义定义：

https://www.yuque.com/u222739/why7ts/tbsi58y574r3bbpa

⑤ 编译管线：一份YAML契约，编译出Prompt/Schema/CI规则：

https://www.yuque.com/u222739/why7ts/zr1k7vopzcd4rg63

语义规范体系：YAML 里写的不是颜色值，是语义令牌：

https://www.yuque.com/u222739/why7ts/ugxdg4go2t7tlf9l

YAML 契约格式：理解了语义规范体系后，怎么写语义规则：

https://www.yuque.com/u222739/why7ts/orfwe0f15ga79wdg

6 个漂移模式：AI 生成界面的语义断层证据库：

https://www.yuque.com/u222739/why7ts/rwlzmucm3lgxzm10

契约库：让设计规范像代码一样管理：

https://www.yuque.com/u222739/why7ts/cn0l4ewmwvzeqsdo

角色专题 ①｜设计师与产品经理：

https://www.yuque.com/u222739/why7ts/pspi1r6iypclto8x

角色专题 ② ｜前端与 AI 工程师：

https://www.yuque.com/u222739/why7ts/nlwd1q32ny08n317