承接《Schema-As-Code：当设计规范从文档变成代码》：当规范以代码形态存在，下一步要解决的是如何让约束从"隐性共识"变成"显性契约"。本文展示意图协议的具体工程形态——不是抽象概念，是可以直接复制粘贴、在线体验、并被机器自动校验的 YAML 协议。上一篇我们论证了：在规模化 AI 交付中，语义不一致的隐性成本呈超线性增长。面对多产品、多模型、多业务域的复杂场景，大多数团队的第一反应是"加

承接前三篇：我们讨论了设计意图的断裂、形式化的必要、以及治理成本。本文解决一个实操问题：这套方法在行业里到底叫什么？怎么落地？和现有工具是什么关系？前三篇论证了设计意图治理的必要性，但工程师向团队介绍时会卡壳："我们搞了一套设计规范代码化方案……不是 Design System，不是 Prompt Engineering，不是 Policy-as-Code……"没有命名，就无法被引用、被集成、被组

承接《设计意图治理：当界面从确定性走向概率性》与《设计意图的形式化：从自然语言到机器可读》：我们论证了设计意图的三次断裂，也展示了意图协议的 YAML 形态。本文回答一个更现实的问题——在规模化 AI 交付中，这套协议如何与现有工程基础设施协作，才能实现成本最优的语义一致性治理。前两篇完成了意图协议的"立论"与"显化"：第一篇指出：确定性界面的治理已经很难，概率性界面（LLM 生成内容直接进入用户

承接上一篇：既然设计意图需要从"文档"走进"系统"，那这份"意图协议"长什么样？ 本文展示意图协议的具体形态——不是抽象概念，是可以直接复制粘贴的 YAML/JSON 规范。上一篇聊了设计意图在确定性界面和概率性界面中的三次断裂：语义断裂、规则断裂、验证断裂。结论是：需要一种让设计意图从"文档形态"转化为"机器可读协议"的编译层。这篇回答一个更具体的问题：这份协议长什么样？我会用 6 个核心文件、

设计意图不是文档里的文字，而是系统里的契约。如果你做过跨产品的界面设计，一定遇到过这种崩溃时刻：你定义了「告警卡片 = 红色脉冲 + 必须人工确认」。三个月后，另一个产品的设计师复用了你的组件，但把红色改成了橙色——因为那个产品的主题色是橙色系。再三个月后，AI 助手生成的告警文案里写着「严重故障，建议自动修复」——用户看到的界面依然红红绿绿，但背后的语义已经完全跑偏。这不是某个团队的失误。这是设