Astryx：Meta 内部跑了八年的设计系统，如今带着智能体一起交付
Astryx 是 Meta 的可定制 React 设计系统，为开发人员和编码代理准备了令牌和组件。
秒懂
- 它是什么？
- 基于 React 19 与 StyleX 的开源设计系统，150 多个组件、七个主题、一套 CLI，当前处于 Beta 阶段。
- 适合谁用？
- 适合已经上到 React 19、想要一套能深度定制又不绑架样式方案的组件库的团队；不适合还停在 React 18 的项目，也不能指望图表组件已经可用，那两个包目前只有 canary 版本。接入前先做两件事：确认你的 Tailwind 或 CSS Modules 覆盖方案能接受预编译 CSS 的优先级顺序，以及在 Storybook 上过一遍你真正要用的那几个组件。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
Meta 内部跑了八年才放出来
README 的概述段落给出了这个项目的来历：Astryx 在 Meta 内部成长了八年，成为公司里使用最广、规模最大的设计系统，支撑着 13000 多个应用，由每天依赖它的工程师、设计师和产品团队共同塑形。
这个数字是理解整个项目的钥匙。内部系统对外开源时的取舍，和为社区从零设计的组件库完全不同。它首先得满足上万应用里已经存在的用法，因此覆盖面要广，边界情况要多，稳定性优先于时髦。
代价是它带着大厂内部系统的惯性。README 说仓库里 internal 目录放的是测试工具、eslint 插件和 vibe tests 这类内部工具，这些对外部使用者的价值有限。项目当前标注为 Beta，主语言是 TypeScript，许可证 MIT，托管在 facebook 组织下。
StyleX 写在里面，暴露出来的是 className
技术底座是 React 19 加 StyleX。前者是硬要求，README 明确写着 Astryx 需要 React 19 或更高版本，react 和 react-dom 是 @astryxdesign/core 的 peer 依赖。
StyleX 的使用方式值得单独解释，因为它是这个项目最容易被误解的地方。Astryx 用 StyleX 编写样式，但对使用者完全不可见。你拿到的是预编译好的 CSS，组件是带类型的 React 组件，不需要配置任何构建插件，也不用引入某个样式库。
覆盖样式走标准的 className，用 Tailwind、CSS Modules 还是纯 CSS 都行，取决于你项目里本来用什么。这条设计把样式方案的选择权留给了使用者，代价是你要自己处理覆盖优先级，预编译 CSS 的加载顺序会和你的覆盖样式互相影响。
主题是一组 CSS 变量覆盖
品牌级主题的实现方式被简化成了一个很朴素的东西：一组 CSS 自定义属性的覆盖。README 说设计师因此可以做出一眼能认出的 Astryx，不需要 fork 也不需要包装组件源码。
这个选择绕开了组件库最常见的改造陷阱。多数设计系统的定制路径是写一层 wrapper 组件，把自己的样式包在外面，结果升级时 wrapper 和底层组件的接口对不上，改一个组件要动一串。用变量覆盖则没有这层间接，组件本身没被改动。
仓库提供七个开箱可用的主题：neutral、butter、chocolate、matcha、stone、gothic 和 y2k。名字风格差异不小，从取名就能看出这套系统允许主题之间有足够的辨识度，而不是同一个配色的深浅变体。深色模式是单独列出的能力，不是某个主题的附属品。
swizzle 把组件源码交到你手上
README 把 Open internals 列为第一条差异化特性。组件按任意层级可组合，底层的构建块被直接导出，需要更深控制时，swizzle 会把某个组件的完整源码吐到你的项目里，从此由你自己拥有。
这个机制解决的是组件库的经典困境。多数库只暴露一个封闭的顶层 API，你想改一行内部行为就得 fork 整个仓库或者写一堆 hack。swizzle 提供的是一条中间路径，只把你需要改的那个组件交出来，其余的继续跟着上游升级。
代价很直接，弹出的代码从此要自己维护。上游修了 bug 不会自动同步到你项目里的那份。因此合理的用法是把 swizzle 当成最后手段，先用组合和变量覆盖解决问题，实在不行再弹出源码。
架构上分三层：Foundations 管排版、颜色、布局和可访问性这些基础；Components 是 150 多个带完整 TypeScript 支持的可复用组件；Patterns 是表格页、详情页布局、表单向导、导航模式和数据录入流程这类经过验证的设计方案。
为人和智能体共用而设计的那部分
仓库描述里有一句少见的表述：tokens and components prepared for both developers and coding agents。README 反复强调人和 AI 助手用同一套工具、从同一份参考出发构建。
落到具体设计上，主要体现在两个地方。一是强约定，每个组件遵循相同的命名、属性和组合规则，并且都有完整文档，学会几个之后其余的都能推断，人和模型都能预测陌生组件的行为。二是一致性带来的可预测性，README 说每个让 Astryx 对 AI 更好用的改动，同时也让它对人更好用。
实践中最具体的一条建议是关于 CLI 调用的。README 建议把 CLI 包一层 npm script：在 package.json 里加一条 astryx 指向 node_modules/@astryxdesign/cli/clients/cli/bin/astryx.mjs，之后用 npm run astryx -- component --list 调用。理由写得很实在，这样可以避免智能体或新开发者直接调用时遇到路径错误。
包的分工也围绕这条线展开。core 提供组件、主题系统和工具函数，cli 负责组件文档、模板、脚手架、主题和 codemod，build 提供 StyleX 源码构建的插件。CLI 里那个 codemod 能力对跨版本升级尤其有用，组件属性改名这类破坏性变更可以靠它自动改，而不是人工逐个文件翻。README 没有给出已有 codemod 的清单，具体覆盖了哪些变更要看 cli 包自己的说明。
图表相关的两个包还在 canary
四个发布包里，themes 那一项实际上是七个主题包。README 的表格把 core、cli、build 和 theme-* 并列，各自有独立的 README。
需要特别留意的是三个未完全发布的包。@astryxdesign/lab 是实验性组件，只用于 Storybook 和 sandbox，不发布到 npm。@astryxdesign/vega 是 Vega 和 Vega-Lite 的图表封装，@astryxdesign/charts 是图表组件，两者只在 @canary 这个 dist-tag 下发布，没有稳定版本。
这意味着需要图表能力的项目目前不能依赖它们。README 用了 no stable release yet 的说法，既没有承诺时间表，也没有说明 canary 版本的兼容策略。做技术选型时这部分要单独评估，不能因为核心包可用就默认图表也能用。
Beta 状态下的 420 个开放 issue
安装命令分三套包管理器，核心依赖是三个：core、theme-neutral 和 @stylexjs/stylex，CLI 作为开发依赖单独装。README 说最简单的接入只需要几个 CSS import 加一个主题提供者，没有构建插件要配，也没有 PostCSS 或 Babel 配置。
项目结构分三个目录，apps 放示例应用、文档站和 Storybook，packages 放对外发布的包，internal 放内部工具。文档站是 astryx.atmeta.com，另有公开的 Storybook 和 sandbox 可以直接试。
仓库快照显示 12546 个 star、1068 个 fork、420 个开放 issue，最近推送是 2026 年 8 月 24 日。开放 issue 达到三位数，对一个刚开源不久、内部已经跑了很多年的系统来说不算异常，大量问题来自外部使用者遇到的新环境和新用法。
贡献入口是 CONTRIBUTING.md 和一份贡献 wiki，后者放 API 约定和评审标准，另有 Discord 频道。仓库顶部有一行注释值得注意，写着架构变更必须同步更新文档。把文档同步写进工程约定，是内部系统长期维护留下的习惯。
编辑结论
适合已经上到 React 19、想要一套能深度定制又不绑架样式方案的组件库的团队；不适合还停在 React 18 的项目，也不能指望图表组件已经可用，那两个包目前只有 canary 版本。接入前先做两件事：确认你的 Tailwind 或 CSS Modules 覆盖方案能接受预编译 CSS 的优先级顺序，以及在 Storybook 上过一遍你真正要用的那几个组件。
社区笔记