R1.18.1adoption counted at call sites设计
采用率按调用点统计而非按团队统计
别名: 调用点采用率 · 不要按团队计 · call-site adoption · not team adoption
概念解释
采用率要回答的是：产品界面上有多少处实际用了体系里的组件。分母是调用点——模板、标记、设计文件里每一次标签或实例——不是「接入了这个包的团队数」。一个团队在仓库根部装了库，再在本地包一层私有壳，团队计数显示 100% 采用，调用点却全在壳外，体系对画面的控制为 0。按团队统计会把安装行为当成采用；按调用点统计才把画面上的每一次使用当成采用。
团队是组织单位，调用点是界面单位。体系管的是界面，度量就必须落在界面上。
机制
团队计数便宜：读依赖清单就能画出「谁接了」。它便宜是因为它不问依赖被怎么用。包装层、再导出、复制组件源进产品仓库，都能让依赖清单仍显示接入，同时真实标签已经不是体系的名字。调用点计数贵：要解析产品代码和设计文件，认出体系标签、别名、以及被换名的再导出。贵出来的信息是「画面上到底有多少处还在体系里」。
一个大团队可以贡献绝大多数调用点，十个小团队可以只贡献安装记录。按团队平均，大团队的绕过被稀释，小团队的「装了没用」被算成采用。决策者看到的采用率于是与用户看到的一致性脱钩。脱钩之后，投入会继续朝「让更多团队装上包」走，而不是朝「让更多调用点回到体系标签」走。
边界
仓库尚未有可解析的标记（原生视图用字符串拼出来、或设计还停在无组件的画板）时，调用点计数会低估，需要先补识别器，不能把零当成未采用。生成代码若在构建时展开体系标签，应数生成前的源调用，避免生成物把一处乘成一百。设计文件与代码是两套调用点，要分开报，不能加总后假装成一个率——设计 90%、代码 40% 是两个问题。团队计数仍可作为「谁还没装上包」的入口清单，只是不得叫采用率。
怎么落地
- 定义调用点：产品源里的体系标签、经官方再导出的别名、设计库实例。私有壳里的标签单独列，不算采用。
- 报表只出调用点率：采用 /（采用 + 私有壳 + 原生翻版）。团队安装清单放到附录，标题不得写成采用。
- 识别换名再导出：解析 import 别名和包装组件的 render 根，把它们计到私有壳，不记到体系。
- 验证：找一个已在安装清单上的团队，抽一个核心流程，数画面上的控件。体系标签数除以控件总数，与该团队被标记的「已采用」对照。若报表是 100% 而流程上不到一半标签属于体系，分母用错了。再把该团队的私有壳展开，看壳内有多少本该是体系调用点——这些点是被团队计数藏掉的缺口。