R1.04.3unguided library divergence设计
无准则的组件库会被各自解释
别名: 各自解释 · 用法真空 · local folklore · 组件库分叉
概念解释
组件库若只发零件、不发用法，每个团队会用自己的故事填真空：「表格里我们一律用幽灵按钮」「对话框主行动永远靠右」。这些故事互不相认，屏幕却都 import 同一份包。无准则下的各自解释（unguided library divergence）让外观系统在采用率看起来很高的时候已经碎了——碎的是意图，不是安装。
包发出去的是能渲染的零件；准则发出去的才是「这件事在产品里该怎么做」。没有后者，前者会被解释成多套产品。
机制
零件没有内建意图。主按钮、次按钮、幽灵按钮在视觉上都能点，选用哪一档取决于团队对「强调」的民间理论。民间理论来自最先做成的那一页、来自某个设计师的口播、来自从别的产品抄来的习惯。它们在团队内部一致，跨团队就不一致，于是同一列表在增长页用主按钮做行内操作，在设置页用链接，在后台用图标。扫描全站时，人无法预测下一屏的操作长什么样。
度量如果只数 import，会把这种碎判断成成功：每个页面都用了库。真正的失败是调用点虽来自同一包，却在教三套不同的语法。后来者只能问人，问到的答案取决于问了谁。真空持续越久，民间理论越硬，补准则时还要先打一场「谁才是正统」的架。
边界
单一小队、单一产品、口头约定还能覆盖所有调用点时，书面准则的收益小，真空不一定立刻分叉。开源给外部用的库如果故意把意图留给消费方（无头组件），各自解释是设计目标，但要在介绍里写明「不附带产品用法」，以免被当成设计系统。强品牌分区（营销站与产品后台允许两套语法）是受控的分叉，前提是分区边界写清，不是每个小队自己划。自动化能拦住的误用（错误的 DOM 结构）不替代用法准则：结构对了，强调级别仍可各说各话。
怎么落地
- 为每个稳定组件指定一位用法负责人，口头惯例必须在两个迭代内写成可链接的准则，否则视为真空。
- 按团队抽样同一组件的调用点，把「强调级别、位置、是否成对」做成对照表，分叉处列为准则缺口。
- 新团队接入库时先发用法包（何时用哪一档、和谁成对），再发安装说明，不要只丢 npm 地址。
- 验证：让两个未沟通的小队各做一页含主列表和对话框的界面，只给组件包、不给准则。若强调级别、按钮数量或导航选用已经分叉，真空已经在生产解释权。补上准则后再做一次，分叉应收敛到准则写明的那一档。