8.0
深览指数
产品人人都是产品经理·阿基拉de_Akir··AI 生成
设计系统负责人的语义生长：从管”长什么样”到管”意味着什么”
当 AI 开始生成界面，传统组件库只能管住“长什么样”，却管不住“意味着什么”。本文提出设计系统负责人需要从“人肉审查员”转向“规则定义者”，将评审直觉翻译为机器可执行的语义令牌、语义域和约束显化规则。核心贡献在于给出了一个具体的渐进式落地路径：从现有 Design Token 中生长出第一条语义评审能力，将“口头禁令”转化为 YAML 契约。适合有设计系统维护经验、正在应对 AI 生成界面的设计负责人或前端架构师阅读。原文 ↗
核心观点
- ▍设计系统负责人的核心职责应从管理组件的视觉规范（长什么样）扩展到管理组件的语义规范（意味着什么），以应对AI生成界面时视觉正确但语义错误的场景。
- ▍设计系统负责人不是人肉审查员，而是规则定义者: 把“人懂的直觉”（如“这个状态很严重”）翻译成机器可读的离散枚举和约束，机器在规则落定后自动执行校验，人只在三个关键决策点在场。
- 01语义令牌（如 status.critical）携带完整的语义包：表示“系统级故障、必须立即处理、必须二次确认”，AI不需要知道色值 #EF4444，但必须知道这个令牌禁止用于普通通知。
- 02语义域（如 transactional/observational/navigational）定义了组件在不同场景下的语义身份：同一个 Alert 在交易域是“阻断器”，在观察域是“信息条”。
- 03约束显化规则分为不可变边界（违反即阻断，如高危操作必须二次确认）和推荐约束（违反即警告，如文案长度不超过50字），从“绝对不能”的口头规则翻译为机器可执行的 YAML 禁令。
- 04给出渐进式生长路径：第一步，选一个现有 Design Token（如错误色）追问其语义定义；第二步，在 1 个组件（如 Button）上核对 2 个典型场景的语义域声明；第三步，把团队最共识的口头禁令（如“删除按钮不能没有二次确认”）翻译为 1 条不可变边界。
- 05典型案例一：AI运维助手将“数据库主从延迟”标记为 status.critical 但文案写“请稍后重试”，语义冲突。根因是约束缺少“致命状态文案必须包含立即行动指令”。
- 06典型案例二：开发团队将“批量删除用户”按钮声明为 overlay=navigational，绑定 action.primary，导致 AI 生成代码时按钮为蓝色实心且无二次确认。修复为 transactional + action.destructive。
- 07典型案例三：AI生成“清空回收站”界面时，按钮文案为“确认”，样式为蓝色实心，满足“有二次确认弹窗”的技术约束但语义完全偏离。修复：补充约束要求文案必须包含“删除/清空/永久”等不可逆语义。
反方 / 局限
- — 文章暗示了语义评审工作无法一蹴而就：需要在实际使用中持续发现边界、补充约束条款（如文案语义权重维度的缺失），说明机器规则的完备性依赖于持续的案例积累，而非一次性定义。
- — 文章聚焦于大厂或成熟产品团队的场景（已有设计系统和跨域协作），未讨论小型团队或“以形补义”情况（设计人力不足、设计系统朴素）如何适配此范式。
- — 方法论的前提是组织有将设计规范代码化的能力（如已有YAML契约管线），对于尚未实现 Schema-As-Code 的团队，渐进式路径的第一步可能仍然需要较高的技术前置投入。
21 分钟 · 4 卡片 · 7 资料
读原文 →