7.1
深览指数
产品人人都是产品经理·魏雯 Akir··AI 生成
设计系统负责人的编译确认：从”规则被写下”到”规则被正确翻译”
本文深入解释了设计系统负责人在 Schema-As-Code 框架中的核心职责：不是写代码或检查格式，而是在机器无法判断的节点上，确认「人定义的语义」被「机器正确理解」。文章通过 YAML 契约评审和编译产物确认两个具体场景，展示了设计系统负责人如何避免「语义分叉」——即同一语义点在不同消费格式中表达强度不一致。适合已是或正在成为设计系统负责人、或对设计规范进入工程链路感兴趣的产品/设计从业者阅读。原文 ↗
核心观点
- ▍设计系统负责人的核心职责不是格式检查，而是在机器无法自行判断的节点上，确认「人定义的语义」被「机器正确理解」，避免语义分叉。
- ▍设计系统负责人在整条链路上的工作被压缩到三个关键决策点：机器不确定时、机器没见过时、机器发信号时。
- 01YAML 契约作为语义定义进入机器执行链路的第一个形态，包含7个冻结字段，设计系统负责人需检查语义编码是否忠实于评审结论。
- 02当语义翻译设计师对「限流提示」的 user_action 设计存在两个方案（仅等待 vs 等待+升级套餐）时，机器无法判断，需要设计系统负责人基于业务目标做出判断。
- 03「删除账户」契约案例中，语义翻译设计师将「二次确认」错误理解为「弹窗确认」而非「输入账户名确认」，导致AI生成代码缺少输入验证环节。
- 04编译管线将一份YAML契约翻译成四种消费格式（Prompt前缀、JSON Schema、Checklist、CI规则），设计系统负责人需抽样验证四种格式对同一语义点的表达强度是否一致。
- 05一次编译产物语义分叉案例中，Prompt前缀和Checklist要求文案包含特定信息，但JSON Schema和CI规则只检查字段存在性，导致对「文案要求」的严格程度不一致。
- 06设计系统负责人的工作遵循「评审→确认→验证」闭环，评审输出评审结论，确认输出确认标记，验证输出反馈数据驱动下一轮评审。
反方 / 局限
- — 验证阶段发现的问题会回流到评审阶段，驱动评审结论更新，例如「不可变边界」被频繁触发人工升级，说明边界定义可能过严。
15 分钟 · 3 卡片 · 4 资料
读原文 →