TVU 设计系统 · 体检报告 · 2026-09-16

设计系统现在
什么状态

这份报告回答三件事：产品团队到底用没用、哪些地方还是黑的、 这半个月真正变好了什么。全部数字都是当场从代码和文档里数出来的，不是估的。

读数时间 2026-09-16 12:12 · 扫了设计系统仓 + 两个在用它的产品
每个数字的出处都在文末「数据是怎么来的」里

01
颜色被抄走了，组件没人用最要紧 两个产品用了 87% 的设计变量（颜色、间距），但 34 个组件只被用了 3 次， 有 46 处本该用组件的地方是手写的。图标更极端——38 处里只有 1 处用的是设计系统的图标。
02
组件文档里最该有的那一样，一页都没写最要紧 25 个组件页，写了「这个组件什么时候该用」的是 0 页。 开发想知道该选哪个组件，现在只能来问你。
03
规则从「写了没人管」变成「写了有人管」在变好 半个月前有 66 条规则写了标准却没有任何检查在盯；现在剩 32 条。 同期规则总数还涨了 8 条——所以是真的接上了，不是被稀释的。

一 · 设计系统存在的理由

产品团队真的在用吗

扫了两个正在用 TVU 设计系统的产品（vue-app 和 graphics-insertion-app）， 分三层看：颜色变量、图标、组件。三层的结果差得惊人。

颜色 / 间距685 / 790 处
86.7%　在用设计变量
还有 105 处写死的 →
组件3 / 49 处
6.1% 46 处本该用组件
图标1 / 38 处
2.6% 37 处用的是别的图标
这说明什么

产品团队把设计系统当调色板用了，没当组件库用。 颜色好抄——复制一个变量名就行；组件要改结构、要读文档、要处理属性，门槛完全不同。

那 46 处手写的地方里，38 个是裸 <button>，另有 5 个裸输入框、2 个裸下拉。 这些都是设计系统里已经有现成组件的。

拆到产品看，两边不一样

产品颜色变量用了几个组件该用没用组件层
vue-app88.0%1 个36 处2.7%
graphics-insertion-app82.2%2 个10 处16.7%

vue-app 是重灾区：36 处该用没用，只用了 1 个组件。 graphics-insertion-app 好一些，但它的盘子也小得多——别把 16.7% 读成「它做得好」。

更麻烦的是：用了的那几个，还在被改

2.0× 改写比使用还多 用了 3 次组件，却写了 6 处样式覆盖去改它的长相。 vue-app 是 1 次使用配 4 处覆盖。
19 处 设计系统自己的示范代码里用错了 17 处属性值写的不在允许范围（比如尺寸写了小写 l， 规定要大写 L）；2 处该填文字的填了开关。
这说明什么

覆盖比使用还多，通常意味着组件长得不是他们要的样子—— 要么是变体不够（他们需要的那个状态组件没提供），要么是文档没说清楚有哪些变体。 这两件事都能查，但现在没人在查。

示范代码那 19 处更直接：如果连设计系统自己的演示页都把属性写错， 别人照着抄一定会错。而且这些错是机器能当场查出来的。

二 · 你交付之后

组件文档够不够开发照着做

25 个组件页，每页该有三样东西。实测三样都缺，而且缺得最厉害的那一样，正是设计师最常被追问的。 下面每个方块代表一个组件页，深色 = 写了。

这组件什么时候该用（用例）0 / 25 页

一页都没有。开发要在 Button 和 Link 之间选，文档给不出答案——只能凭感觉，或者来问你。

设计规格（尺寸、间距、状态的确切值）1 / 25 页

只有 1 页写了。开发做出来对不对，没有可对照的依据，只能等你走查时发现。

状态矩阵（各种状态长什么样）10 / 25 页

这一样最好，但仍有 15 页没写。没写状态的组件，开发多半只实现了默认态。

这说明什么

第一节说「产品没在用组件」，这一节多半就是原因之一。 一个不告诉你「什么时候该用我」的组件库，很难被用起来—— 开发看到一堆组件不知道选哪个，最省事的做法就是自己写一个 <button>。

这三样里「用例」最便宜也最值钱：每个组件写三句话（该用在哪、别用在哪、和哪个组件容易混）， 25 个组件是一天的活。

三 · 你画图时

能拿到的设计基础齐不齐

颜色和间距那套变量是齐的（所以产品能抄走 87%）。但另外三套基础标度，两套完全不存在。

0 动效变量 过渡时长、缓动曲线，一个都没定义。 意味着每个组件各写各的动画时间，出来的节奏对不齐。
0 密度变量 没有「紧凑 / 标准 / 宽松」这一层。 想做一个信息密集的表格视图，只能每处单独调间距。
4 个 层级变量（但不能用） 有 4 个层级变量，前 3 个的值都是 1000—— 它是一组名字，不是能分高低的标度。弹窗压不压得住下拉，还是靠现场调。
这说明什么

这三样都是「设计师在 Figma 里定了、但没落进代码」的典型。 动效尤其明显：你在设计稿里标了 200ms ease-out，代码里没有这个变量可用， 开发就只能硬写——下次你改成 150ms，得挨个去找。

层级那 4 个更值得注意：它看起来是「已经有了」，实际上没有分级能力。 这种「看着有、其实没有」的情况，比明确的空缺更容易出事。

四 · 有人改动时

会不会悄悄弄坏，而没人发现

这一块是这半个月改善最多的。核心问题是：写了规则，有没有东西真的在拦。

「写了规则却没人管」的条数：半个月降了一半

66
09-01
36
09-14
32
今天

同期规则总条数从 127 涨到 135（多了 8 条）。 分母涨了还能从 66 降到 32，说明是真的接上了检查，不是靠比例算出来的好看数字。

135 条规则的验收标准条数什么意思
有自动检查在盯49改坏了，提交时当场拦住
登记为「机器查不了」54比如「文案要自然」这类，已明确写下来靠人看
没人管32既没检查、也没登记——改坏了不会有任何反应

另外三个值得知道的数

89 对 颜色对比度不达标 69 对文字 + 20 对非文字。已经被登记冻结——只许减不许加， 谁再新增一对，提交时会被拦。
89% 组件渲染验证通过率 Vue 88.9% · React 89.2%。这是在查「组件实际渲染出来的样子， 和设计稿对不对得上」。
40% 发布包里的断链 对外说明文件指向 5 个文件，有 2 个没被打进发布包—— 在仓库里检查是好的，别人装到项目里会断。
这说明什么

机械治理这一侧是目前最健康的：规则有人守、无障碍问题被锁住只减不增、渲染有验证。 今天所有自动检查全绿。

但那个 40% 断链值得单独说：它是「在自己家好用，装到别人家就坏」， 正好和第一节「产品用不起来」对得上——值得查一下是不是同一个原因。

五 · 最重要的一节

哪些地方现在是黑的

设计系统自己列了 64 项该测的东西，其中 45 项写明「脚本能自动算」。 今天真正在算的，从 11 项接到了 30 项——还剩 15 项黑着。

64 该测的 设计系统自己列出来的清单
45 能自动算的 算法都写好了，不用人工盘点
30 真正在算的 今天 11 → 30（一次接上 19 项）
15 还是黑的 值现在是「不知道」，不是「好」

按你关心的顺序看，哪块亮着哪块黑着

绿色 = 这一区至少有一项在测，⛔ 不代表这一区健康—— 比如「规则有没有人守」16 项里现在测了 4 项，仍有 12 项黑着。深色 = 一项都没测。 今天三个区接满了（打勾那三个）。

产品用不用得起来 · 5 / 15+2 今天加了「有没有拿错设计库」和「做好的东西能不能被复用」两项。 拿错库实例占 10.4%（10,602 / 101,662，六个产品文件加权）； 孤儿组件 28 个——做好了却没挂进组件集，别人搜不到、只能重画。
组件文档齐不齐 · 3 / 3 ✓+1 这一区接满了。就是第二节那三个点阵图。
规则有没有人守 · 4 / 16+2 今天加了两项「守的人自己靠不靠得住」：8 条闸只报告不拦（93 条里）； 只有 52.7% 的闸做过「故意弄坏看它响不响」——剩下那些绿着，但没人验过它真会拦。
改动会不会弄坏 · 3 / 9+2 今天加了「版本落后多久」和「渲染验证覆盖多少」： 两个产品都钉在 1.2.0，落后 47 天；渲染验证覆盖 952 / 952（另一侧 946）。
发布出去能不能用 · 6 / 6 ✓+5 这一区接满了，而且结果很不好看： 包体积 12.6 MB 且没有任何体积闸；供应链扫描 0 项（没有依赖漏洞扫描、没有 SBOM）； 没有回滚手册——发布文档里搜「回滚」只搜到 2 处，逐条看完全是在讲另一件事。
设计基础齐不齐 · 2 / 7+1 测了动效 / 密度 / 层级，今天加了「有没有统一的文案规范」——0 份。 主题扩展、多语言、从右往左的语言支持仍全黑。
体量与成本 · 2 / 4+2 从全黑到有数：文档 392 份 / 12.0 MB；待办 25 条（其中真正在办的 2 条）。
治理与成熟度 · 4 / 4 ✓+4 这一区接满了，也是最难看的一区：治理文档 9 份该有的只有 1 份 （只有 CONTRIBUTING，没有 CODEOWNERS / 无障碍声明 / 安全策略 / issue 模板）； 组件成熟度分级只在文档站有（17 / 25 已批准），组件清单本身没有这个字段。 ⚠️ 跨产品模式索引其实已经有了（7 份文件 / 5 个产品）——登记表里写的「没有」是过期信息。
这一节该怎么用

「还没在测」不等于「这块很烂」，它等于「不知道」。 把不知道读成坏，和把不知道读成好，一样错。

今天这 19 项接上之后，这句话有了第二个证据： 「发布出去能不能用」和「治理与成熟度」两个区，昨天全是「不知道」，今天全部接满—— 而它们是所有区里最难看的两个。 第一节那个 6.1% 的组件使用率也是这么出来的：接上才看见它这么低。

剩下 15 项黑着的，按同样的经验，里面很可能还有同量级的问题。 ⛔ 但在接上之前，任何人说那 15 项「应该还行」，都是在猜。

六 · 回答「到底优化了什么」

这半个月真正变好的

四个能拿数字说话的改善。每一条都做过对照实验—— 把改动撤掉，数字弹回去；放回来，数字降下来。不是看着变好了。

改善了什么半个月前现在变化
写了规则却没人管的条数
改坏了不会有任何反应的那些规则		 66→32 −34
检查工具自己坏了没人知道的
检查工具本身也需要被检查，不然它默默失效		 40→35 −5
正在报警没人处理的检查
系统正在静默变坏的地方		 3→0 全清
产品到底用没用设计系统
第一节那些数，昨天之前不存在		 不知道→6.1% 新接上
为什么「降一条」是真收益

这些检查是只许降不许涨的：数字降下去的同时，标准也跟着调紧并锁住。 以后谁再写一条没人管的规则，提交时会当场被拦。 所以降的不是一个报表数字，是把一块地永久圈进了监管范围。

第四条不一样——它没让任何东西变好，它只是让我们第一次看见了真相， 而那个真相是「很差」。这也是价值：「不知道」变成了「知道，而且很差」， 才有得修。

七 · 诚实的部分

这份报告不能读成什么

六条边界。写在这里是为了让你知道每个数能撑多重的结论。

6.1% 是「至少这么低」，不是精确值 扫描器看不到动态生成的组件（代码里绕一圈才渲染出来的）。 真实使用率只会比 6.1% 高，不会更低。但从 46 处裸 <button> 看，高不了太多。
「用得对不对」那 19 处只覆盖了看得见的写法 消费产品那边查出 0 处错误，但它们总共才用了 40 次组件—— 更可能是用得少，不是用得好。
改写密度 2.0× 的分母只有 3 3 次使用、6 处覆盖。分母这么小，比率会剧烈放大。 看绝对数更稳：6 处覆盖。
「设计规格 1/25」在内部有两种算法，是同一个数 如果你在别处看到「设计规格就绪 4%」，那和这里的「1/25」是同一件事的两种说法， 不是两条独立证据。
这份报告不测「好不好用」 省心 / 不省心是主观感受，技术上采集不到。这里测的全是行为和产物—— 用了多少、写了没写、拦没拦住。要知道设计系统好不好用，得去问人。
趋势只有第六节那四条能说，别的都只是「现状」 其余数字目前攒的历史点不够，说不了「在变好还是变坏」。 第一节那些数是昨天才开始测的，今天只有一个点。
数据是怎么来的（技术细节，不看也不影响读上面）

读数时间　2026-09-16 12:12 CST（北京时间）

被测对象　tvu-design-system @ 388d2737 · 版本 1.2.0 · 工作树有 6 个未提交文件（部分读数与干净状态不可并池）

消费产品　vue-app · graphics-insertion-app

采集命令　node metrics/ds-sweep.mjs --ds <设计系统仓>　退出码 0（全清）

各节数字对应的内部维度编号

第一节 三层使用率 = DIM-U1（token 685/790 · icon 1/38 · component 3/49）· 改写密度 = DIM-U5（6/3）· 用得对不对 = DIM-U17（示范面 19/1223，2 布尔简写 + 17 枚举越界）
⚠️ DIM-U2 与 DIM-U1.token 同源同值（86.7%），⛔ 不是两条独立证据
第二节 组件三视图 = DIM-U16（状态矩阵待办 15/25 · 用例待办 25/25 · 设计规格待办 24/25）· 设计规格就绪 = DIM-X17（1/25 = 4%，与 U16.designSpec 是同一个数的两面）
第三节 基础标度 = DIM-X19（motion 0 · density 0 · z-index 4，前 3 个值均为 1000）
第四节 规则三态 = DIM-Q12（gated 49 · 机器测不了 54 · 没人管 32，分母 135 = 验收段数，⛔ 不是规则条数）· 无障碍冻结 = DIM-S9（非文本 20 + 文本 69）· 发布断链 = DIM-X18（2/5）· 渲染验证 = vue 952 项 88.87% / react 946 项 89.22%
第六节 前三行 = 棘轮基线 unclassified 66→32 · gate-regression BASELINE 40→35 · 正红棘轮 3→0（起点 09-01 95c1065c，三个时点各建干净工作树跑 metrics/ratchet-watch.mjs）

没接上的那 34 项　维度真源 = tvu-design-system/docs/internal/ds-health-dimensions.md §3（64 格）。 另有 1 项（DIM-Q14 工具耦合度分母）明确登记不接，理由是那三条闸没有结构化输出、 只能靠正则解析散文，口径一改就静默失效；重开条件也已登记。

第五节的八个分区　分区是本报告所加（登记表本身没有分区）， 已程序化校验无重复、无遗漏、无幽灵。原始 64 格的分区计数： 产品用不用得起来 15 · 组件文档 3 · 规则守护 16 · 改动安全 9 · 发布 6 · 设计基础 7 · 体量成本 4 · 治理成熟度 4。

第六节「做过对照实验」指什么　每笔改动都做了两臂到四臂： 把新写的检查移开 ⇒ 数字弹回去；放回来 ⇒ 降下来。这样才能确认是这笔改动挣的， 不是同期别人的提交挣的。09-01 → 09-14 有 186 个提交，绝大部分不是这条线做的。

更细的底账　每个结论背后的逐条读数、造故障实验记录、 推翻过的错误判断，都在 ai-ds-lab/reports/ 下的原始报告里（面向工程，不建议直读）。