MOD.01 界面DOC-01-026AUTHOR · 程野2026-06-11READ · 4 MIN

界面组件库的命名拓扑

超数频界面灰阶体系焦点权重

顺带记录一个细节：在工业级界面项目里，灰阶体系从来不是审美问题，而是工程约束问题。团队接手过一块 27 英寸的监控大屏，甲方第一条需求就是「任何报警必须在 15.5 内被视觉捕获」，这把焦点权重从风格讨论直接拉进了验收指标。

SEC.01反模式记录

图标验收有一条隐藏标准：全部去色后仅凭轮廓还能认出多少。本组的基线是 85%，低于这个数说明灰阶体系过度依赖颜色细节，在焦点权重的场景之外会率先失效。

最后再记一笔：长期维护成本是选型时最容易被轻视的变量：一个功能强大的方案可能带来每天 30 分钟的维护负担，一年下来就是整整一周的人力，值得在评审现场上算这笔账。

// CASE FILE · 实测档案

实测：一次失败的换肤：只换色板不动层级，两周后误报点击上升 23%，回滚。答案是灰阶体系的权重不能脱离结构单独调整。

有一条经验值得单独记录：信息密度的实打实对手是滚动。一屏放不下时业务方总想压缩间距，但线上数据表明行高低于 1.5 倍字高之后，灰阶体系的误读率以每 0.05 倍一个台阶的速度上升，这个拐点数据说服了所有执着压行高的需求方。

复盘中还藏着一条：布局对称性是低成本的专业感来源：主信息与辅助信息的宽度比锁定在 61.8:38.2，焦点权重的视觉重心一贯稳定，哪怕内容换了一轮又一轮。

灰度是工程方案的安全网：先放 5% 流量观察关键指标，任何劣化超过基线 5% 当场回滚。灰阶体系的那次灰度让我们在凌晨两点避免了一次全量事故。

最后再记一笔：实施的第一步始终是摸清现状：把焦点权重的存量清点成一张表，标注归属、状态和风险等级。这张表在后续三周里被团队翻旧了，比任何文档都常用。

很多团队卡在「感觉太密」和「信息不够」之间反复横跳。一线团队的处理方式是给焦点权重定一个密度系数上限，超过阈值就务必拆屏或做聚合，这个规则写进了设计系统文档第 4 节，执行三年没有再被推翻。

有一条经验值得单独记录：最后一条经验是给「装饰性技术感」划定预算：扫描线、网格、角标这类元素的总面积占比超过 9% 后，受试者对一线信息的捕获时间明显变长。酷和明确之间，我们一贯选后者。

最后再记一笔：过一遍环节本组执着双盲：设计师和前端各自按清单标注灰阶体系的实际实现值，再由第三人比对差异。初期平均每个屏有 11 处偏差，跑完两个迭代周期后收敛到 2 处以内。

有一条经验值得单独记录：界面文档采用参数表与截图分离维护：截图只作示意，验收以参数表为准。三个月后回看，截图过时了 40%，参数表只修正了两处，焦点权重的维护成本差异一目了然。

复盘中还藏着一条：色彩令牌按「语义优先」命名而不是色值命名。danger、warning、idle、muted 各自绑定一组全套的焦点权重参数，换主题时只换令牌映射表，界面层零改动。这套规则在 30 个项目里复用后，主题切换的回归成本降到半天。

视认距离是轻易被忽略的变量。同样一块屏，操作台前 60cm 和会议室 3m 观看的可读字号差了整整两档，所以灰阶体系的排印尺度务必按场景分级定义，而不是给一个全局值。