上周，一个做技术总监的朋友找我吃饭，席间他吐槽了一件事。

他们公司这两年用 AI 写前端代码，给客户做了不少网站。AI 写得是真快，不到一小时就能给出一个能跑的版本。但一个新问题也跟着来了——AI 给出来的网站，跟他们公司之前做的其他网站，完全不是一个调性。

做一个电商，AI 给的主色是蓝色；过一个 SaaS 后台，AI 又给成了绿色；再做一个品牌官网，AI 给成了紫黑配色。客户从他们公司做了三个网站，结果三个颜色、三个字体、三套按钮——像三家不同的公司做的。

朋友叹了口气：「每次 AI 给完，前端同事还得花好几天手动调主题、改色板、对齐设计规范。AI 是帮我们写了代码，但又制造了一堆对齐的活儿。」

他抬头问我：「有没有那种设计系统，能让 AI 写代码时不用瞎猜？让它做的所有网站，自动用上我们公司的主色板、自动用上我们的标准按钮、自动用上我们的卡片样式？」

正好，最近看到一个叫Astryx 的开源项目，是Meta 内部用了 8 年的设计系统。它的核心思路是「One system for humans and AI」——API、文档、CLI 是为人设计的，AI 助手用同一份 reference 来 build。AI 写代码时不用自己猜 API 怎么用、文档怎么查、参数怎么传，直接用公司定义好的主题和系统内置的行为。

我把这套思路讲给朋友听，他眼睛一亮——这正是他们公司想要的东西。

Astryx 不是一个新造的项目，它在 Meta 内部有 8 年的历史了。最初，Meta 内部几千个工具分属不同部门——公司文化鼓励"没有趁手的工具就自己造一个"，结果每个团队都在重复造日历、造表单、造表格。

于是 Meta 建了一套统一的设计系统，8 年下来成了 Meta 家最大、用得最广的设计系统，支撑了 13000 多个产品。Meta 内部大约一半的系统更新，由使用它的工程师社区自己贡献。

现在 Meta 把这套内部系统在开源栈上重建了一遍，以 Astryx 的名字开源出来。名字读作「asterisks」（星号），灵感来自拉丁语 _ad astra per aspera_——「循此苦旅，以达星辰」。

仓库里分成 4 个核心包。@astryxdesign/core 是核心 UI 组件，150 多个可访问的 React 组件——按钮、输入框、表格、日期选择器、导航、弹窗这些都有。@astryxdesign/cli 是命令行工具，能查文档、生成模板、跑升级。@astryxdesign/build 是编译插件，给高级用户从源码构建。@astryxdesign/theme-* 是一组主题包，自带 7 套风格各异的主题：neutral（中性）、butter（黄油）、chocolate（巧克力）、matcha（抹茶）、stone（石头）、gothic（哥特）、y2k（千禧风）。

光看「150 多个组件」「7 套主题」，跟其他组件库比没特别之处。真正让 Astryx 有差异化的，是它对几个老问题的处理方式。

第一个：产品长得像双胞胎。 两个用同款组件库做出来的产品长得几乎一样，因为大家都懒得改默认样式。Astryx 的解法是把组件的行为和外观彻底拆开——组件负责行为，外观完全由主题决定。主题本质上是一组 CSS 自定义属性的覆盖（README 原文："A theme is a set of CSS custom property overrides"），设计师改一个值，所有组件一起变。

第二个：想深度定制时被锁死。 很多组件库用了之后想改点啥，越改越乱。Astryx 给了一条渐进式定制路径——用组件默认的样子 → 调主题 → 用 className → 写 CSS 覆盖 → 用 swizzle 把组件源码弹射到你的项目里。最狠的是最后一步 swizzle，官方管这叫「Open internals」，开放内部实现。

第三个：AI 怎么调用这个库？ 上面说的主题系统解决了"AI 做的网站风格不统一"的问题，但 AI 真正要用一个库的时候，还有个底层问题：它要查文档、查组件 API、查示例、查设计 token——这些操作能不能用一套稳定的接口来完成？官方把这个角色交给了 CLI 工具。

CLI 的每个命令都支持--json 参数，输出是带类型判别字段的 JSON 信封，AI 拿到结果可以直接解析；错误也有稳定的code 字段，AI 可以用switch case 分支处理；还支持--dense 模式，输出是压缩格式，token 数量很少，对 AI 助手特别友好。团队还搞了个叫「vibe tests」的内置评估工具，专门测人和 AI 用 Astryx 实际 build 东西的容易程度——用它替代拍脑袋做设计决策。官方原话是：每一处让 Astryx 对 AI 更友好的改动，同时也让它对人更友好。

第四个：引入一个组件库要折腾半天。 Astryx 的口号是「no build plugin, no styling library to adopt」。引三个 CSS 文件，包一层 Provider，就完事了。

怎么部署和使用？5 步走完。

1. 装包。npm install @astryxdesign/core @astryxdesign/theme-neutral，把组件库和默认主题装到本地。

2. 引样式。在全局 CSS 里依次引入三个文件——reset、astryx、theme，相当于给组件「穿衣服」：先打底、再穿衬衫、最后套外套。

3. 挂主题。包一层 Provider，把主题传给整个应用，相当于「给整栋楼装中央空调」。

4. 用组件。import {Button} from '@astryxdesign/core/Button' 就能直接用，主题里的颜色、字体、圆角自动应用。

5. 玩 CLI。npx astryx --help 看所有命令，npx astryx component Button 看组件文档，npx astryx swizzle Button 把组件源码弹射到项目里，npx astryx doctor 跑健康检查。

如果用 Tailwind，core 包提供了tailwind-theme.css 桥接文件，把 Astryx 的设计 token 翻译成 Tailwind 的工具类。如果连打包都不想搞，还有 CDN 版 UMD 文件，所有组件挂在window.Astryx 上，浏览器里直接用。

最后说两句。

Astryx 还在 Beta 阶段，比起 Material UI、Ant Design 这种成熟选手，组件数量、文档完善度、第三方资源都还有差距。如果你现在要做生产环境的项目，建议先小范围试点，验证稳定后再逐步推广。

但它有几个点是真的打动我——

把行为和外观彻底分开，让设计师能直接拥有主题。 传统组件库里，组件的样式混在源码里，设计师想改一个圆角得找前端重写。Astryx 把样式从组件里抽出来交给主题，设计师改一个值，所有组件同步变。这种设计让设计师真正拥有了视觉规范，不再是「画完稿子等前端翻译」。

用渐进式路径给你控制力，还鼓励你把源码拿走。 用了组件库之后想深度改点东西，要么忍着，要么 fork 整个库。Astryx 给了一条按控制力递增的路径——你可以用默认的、可以调 token、可以写 CSS 覆盖，到最后一步甚至可以把组件源码弹射到项目里完全归你。不想 fork 也能深度定制，官方管这叫「Open internals」，开放内部实现。

从 API、文档、CLI 一开始就为 AI 设计。 这件事的立意比它本身的技术实现更打动我。一个项目愿意在设计阶段就把「AI 怎么用」这件事纳入考虑，而不是事后打补丁——这种思路可能代表了未来软件设计的一个方向。

如果你感兴趣，可以去这些地方看看：

• GitHub 项目源码：https://github.com/facebook/astryx
• 官方新闻稿：https://astryx.atmeta.com/blog/introducing-astryx
• Storybook：https://facebook.github.io/astryx/