法则的抽象度高于具体准则，落地前必须转写成本产品可判定的条款
别名: 原则转写 · 验收条款 · 可判定性 · 概念空隙
概念解释
"减少记忆负担""保持控制感"这类黄金法则（golden rules）不能直接进验收。必须转写成产品条款：哪个任务、哪些字段和状态必须显示、哪些动作可撤销、哪个自动化可暂停、什么算完成。没有转写，原则会变成评审口号——它和"法则用于生成阶段自检"这一条是前后相继的两步：那一条说明法则该怎么正确使用（问问题而不是打分），这一条说明经过自检发现"未决定"之后，下一步具体要做什么才能真正让它进入验收流程。
机制
抽象原则之所以能覆盖几乎所有产品，恰恰是因为它把对象、阈值、角色和证据这些具体变量全部抽掉了；这份抽象性是它的优点（可以到处用），也正是它不能直接验收的原因（谁来判定"记忆负担是否已经减轻"，标准是什么）。转写的本质是把这些被抽掉的变量重新代入到当前产品的真实模型里：把"减少记忆负担"代入具体任务后，变成"跨页保留筛选与草稿"；把"预防错误"代入具体功能后，变成"批量删除前显示对象数并提供撤销"；把"闭合"代入具体流程后，变成"后台任务在离开页面后仍可在通知中心查到结果"。这个代入过程不是走个形式，它常常会主动暴露两类问题：一是产品概念模型里原本就存在的空隙（比如原来没有定义"批量操作的对象数该如何统计"），二是某条法则和某条已有业务规则之间的真实冲突（比如"保持控制感"要求用户能随时暂停某个自动化，但合规规则要求这项自动化一旦触发不可中断）——这些冲突在抽象层面根本看不出来，只有落到具体条款才会现形，这也是转写这一步不能跳过的原因。
边界
转写出来的条款不是可以刻在石头上的永久细节清单。产品模型一旦变化（新增了一种对象类型、调整了权限体系），旧条款可能不再适用，需要跟着复审和更新，而不是被当成历史包袱一直保留。也不是每条法则都必须转写成硬性验收条款——有些法则在当前产品阶段更适合保留为一个研究方向或实验假设，先去验证它是否真的适用，而不是急着把还没验证过的判断写成验收标准。过度具体化还有反作用：如果条款写得太细，会提前锁死设计的具体实现方式，反而压缩了后续迭代的空间，因此需要区分哪些是必须满足的硬性验收、哪些只是当前认为较好的最佳实践、哪些纯粹是待验证的假设，三者不能用同一种强制力对待。跨平台产品的条款还需要按平台分别书写，因为同一条法则在不同平台上落地的具体表现可能完全不同。
怎么落地
- 把每一条黄金法则映射到产品的核心任务上，为每个映射写出具体的对象、触发条件、阈值、适用角色、需要的证据和失败时的处理方式，而不是停留在法则原本的抽象措辞上。
- 明确区分"必须验收""建议检查"和"待验证的实验假设"三个等级，每一条都指定负责人和验证方法，避免团队把还没验证的判断当成既定标准来执行。
- 设计评审、开发验收和可用性测试三个环节复用同一套条款编号和措辞，避免同一条法则在不同环节被不同的人重新解释成不同的意思。
- 验证办法：版本更新时逐条复审已有条款，删除因为产品模型变化而不再适用的规则，并记录删除的原因；对仍标记为"待验证假设"的条款，跟踪它是否已经积累了足够证据可以升级为硬性验收条款。