Meridian

我刚接手 Meridian 时，平台里有十一种灰、四种按钮高度，文档站上一次准确更新是十八个月前。没有人是马虎的——只是共享词汇太粗糙，无法描述各团队真正需要的东西，于是同一个问题被各自解决了很多遍。

命名本身就是工作

我们没有重做一个更大的组件库，而是围绕一套很小的语法重建系统。每个 token 回答三个问题：它扮演什么角色、处在什么语境、处于什么状态。一个 surface token 不是「灰色 200」，而是面板里最安静的那一层，并随主题变化。

这套语法立刻回本：设计师能推理从未见过的 token，工程师能预判命名，评审时大家终于有同一句话可以争论。

唯一的事实来源

所有 token 存在一个 JSON 文件里，经 Style Dictionary 转换成 CSS 自定义属性、Swift 常量和 Figma 变量。文档与 token 同源生成——页面过期会变成一次构建失败，而不是一次发现。工具链刻意做得无聊：没有要维护的服务，没有会被忘记的看板。

系统是一份社会契约

治理比组件更重要。我们引入了轻量 RFC（两周评论期）、每周开放但没人被要求的答疑时间，以及永远会给出替代方案的废弃策略。贡献变多了，更重要的是：私下的本地分叉变少了。

• 之前： 团队复制组件，然后慢慢漂移。
• 之后： 团队在公开场合提案，系统吸收它们。

带走的经验

设计系统失败的原因通常是产品问题，而不是代码问题。采纳曲线本质上是一条信任曲线：当「正确使用」比「绕开使用」更省力，它才会移动。一半的工作是写出人们真的会读的文档，另一半是成为那种别人愿意把粗糙想法发给你的同事。