8.6
深览指数
产品人人都是产品经理·阿基拉de_Akir··AI 生成
设计系统负责人的语义生长：在1个组件的2个场景上练习核对
本文提出设计系统负责人建立组件语义评审能力的最低起点：找到使用频率最高的那个组件（如Alert、Button），核对它在最常出现的2个场景下承担的语义身份是否一致。作者将核对动作简化为‘回答组件在这个场景下是谁’（阻断器/信息条/路径提示），并提供了将核对结果写成结构化域绑定说明的方法，让下游能自动编码为机器可查的YAML契约。文章用‘删除按钮绑定导航域导致误删’的案例说明语义漂移的真实风险，强调这一步介入成本极低、无需动组件库，适合所有正从‘管样式’向‘管语义责任’转型的设计系统负责人阅读。原文 ↗
核心观点
- ▍设计系统负责人只需核对1个最常用组件在2个场景下的语义身份，就能开始建立语义边界评审能力，无需给整套组件库贴标签。
- ▍语义域不是给组件贴标签，而是回答‘同一个组件在不同场景下，承担的语义责任是否一致’。
- 01以Alert组件为例，它在组件库里只有一份代码、一套样式，但至少活在‘阻断器’（重要操作前拦截）、‘信息条’（通知用户结果可撤回）、‘路径提示’（引导用户下一步操作）三种语义场景中。
- 02核对动作只需一步：选该组件最常出现的2个场景，判断它是否承担了正确的语义身份（阻断器 / 信息条 / 路径提示），而非视觉判断（好不好看）。
- 03真实案例：某团队将‘批量删除用户’按钮声明为 navigational 域、绑定 action.primary，AI生成代码按导航按钮标准输出蓝色实心样式、无二次确认，用户误触后批量删除了数据。根因是域声明标错（删除操作被理解成导航动作），而非设计画错。
- 04核对结果应写成结构化域绑定说明（非代码，类似‘dangrous_deletion: semantic_domain: warning, action: destructive_confirmation’的格式），让下游语义翻译设计师编码为YAML契约，实现跨层自动拦截。
- 05最小保鲜机制：每次新场景评审会加一个问题‘这个场景里的Alert/Button是谁？’（1分钟），机器负责提交/生成检查，负责人只在新场景出现时在场。
- 06生长路径从1个组件的2个场景开始，逐步扩展到频次前列组件、核心流程（删除/支付/发布）、域冲突规则库，原则是‘在核对中建立标准，在标准中完善规则’。
反方 / 局限
- — 文章暗示了此方法的适用边界：当组织已经有较完善的AI生成代码和编译时检查管道时，跨层自动拦截才有意义；若处于人工手写代码阶段，域绑定说明的价值主要体现在设计师与开发沟通上，而非编译时自动执行。
7 分钟 · 4 卡片 · 9 资料
读原文 →