8.7
深览指数
产品人人都是产品经理·阿基拉de_Akir··AI 生成
语义翻译的操作日常：把”我觉得不对”变成”机器能查”
本文是《意图设计的翻译能力》的操作落地篇，提供一套将语义判断转化为机器可执行规则的完整工作流。核心价值在于给出了从发现语义问题（Guard）、到编写YAML契约（Contract）、到验证生效（Verify）的10个具体步骤，明确了每一步“机器自动跑”与“人做决策”的分界，并附有6类高频场景决策树和4个能力等级自检标准。适合所有正在从事“把设计意图翻译成规则”工作的设计师、前端、产品经理阅读，是一份可直接参考的操作手册。原文 ↗
核心观点
- ▍“语义翻译”能力不是转岗成为AI工程师，而是把设计师/产品经理已有的、分散的语义判断，转化为机器可执行的规则（YAML契约），实现80%的重复劳动由机器自动完成，人只做20%的关键决策。
- ▍语义规则需要与视觉规则分离，通过“令牌层与呈现层分离”的设计，让同一个语义令牌（如“状态：严重”）在不同组件（按钮、弹窗、系统通知）中保持一致的语义权重，但又允许不同的视觉表达。
- 01工作流分为三个环节：Guard（诊断，把“我觉得不对”变成6字段机器可归档记录）→ Contract（定义，编写包含7个冻结字段的YAML契约）→ Verify（验证，通过编译前置校验、消费追踪和漂移扫描来确认规则生效）。
- 02诊断阶段的核心产出是6字段记录，包括组件名、用户困惑、期望行动等字段，机器会根据component_type+user_confusion匹配已知模式并输出置信度得分，帮助决策是否触发新规则的定义。
- 03YAML契约的7个核心字段包括：规则ID、匹配条件、语义域、语义令牌、令牌值、约束条件、示例。特别强调令牌层（如status: critical）与呈现层（如红色字体+感叹号图标）的分离，避免将视觉表现写死在语义规则中。
- 04验证环节通过消费追踪（检测YAML是否被多消费端引用）、规则漂移扫描（检测实现与契约是否不一致）和单元测试覆盖率（目标>95%）三个指标，确保规则切实生效并持续拦住漂移。
- 05文章提供了6类高频语义问题场景的决策树：错误状态语义混乱、高危操作未约束、过程状态认知不可见、边界动作权利不清、告警文案语义降级、信息状态权重未对齐，每个场景都给出了触发条件、判断逻辑和具体的YAML填写指导。
- 06译者能力被划分为4个层级：L1能独立完成6字段记录，L2能独立编写完整YAML契约并通过编译校验，L3能设计对抗用例集且误报率<5%，L4能基于消费追踪数据提出规则迭代建议并被采纳。组件数<20时L2足够，>50时需要推进到L3-L4。
- 07规范强调与5种协作角色的接口定义：设计师/产品经理、前端工程师、AI工程师、DesignOps、管理层，分别列出了对方会问什么、你如何回应、你交付什么产物。
- 08文章指出四个常见陷阱：语义词典与样式字典混淆、添加规则后删除旧代码落地、单用例退回加规则、YAML作为代码不纳入评审，并给出了纠偏方案。
反方 / 局限
- — 作者坦诚地指出了该工作流对组织工具（编译管线、规则引擎、追踪面板）的依赖，说明“L3需要组织工具支持，不是个人能力问题”，当团队组件数<20时做到L2即可，无需追求完整流程。
- — 附录中明确标注该规范处于‘Phase 0（概念验证阶段）’而非成熟标准，欢迎读者在实际场景中遇到‘水土不服’时提出变通方案，暗示了规范在真实复杂环境中的局限性。
15 分钟 · 3 卡片 · 6 资料
读原文 →