从纯 CSS 到 StyleX：AI 加持下的一万行 CSS 迁移实践
内容提要
StyleX 因性能优势引发热议，作者从 Tailwind 转向 StyleX，因其原子化编译减少 CSS 体积并提升可读性。作者用 AI 工具将一万多行 CSS 项目迁移至 StyleX，通过多代理并行工作，产出 300 多条提交，CSS 从 215.7 kB 降至 102.3 kB，验证了迁移方案的可行性。
延伸解读
StyleX 与 Tailwind 的取舍
作者从 Tailwind 转向 StyleX，主要原因是 Tailwind 的原子类在复杂 UI 下会变得冗长，且难以处理伪类、任意值语法和自定义动画。StyleX 则通过原子化编译，在属性粒度上拆分和复用，减少 CSS 体积，同时保持可读性。这种对比反映了不同 CSS 方案在可维护性和性能上的权衡。
AI 辅助迁移的实践路径
作者利用 Codex 的多代理能力，先进行风险扫描和死代码清理，再通过最小 PoC 验证方案，然后建立迁移手册，让多个 worker 并行迁移，最后进行 UI 验证。整个过程产出 300 多条提交，CSS 体积从 215.7 kB 降至 102.3 kB，证明了 AI 辅助大规模迁移的可行性。
迁移中的注意事项
迁移前需识别边界情况，清理死代码，并建立验证流程。使用小模型时，需由大模型制定详细手册，确保小模型能按步骤执行。多 worker 并行时，使用 worktree 隔离工作，主 worker 负责合并和冲突解决。每个模块迁移后需进行 UI 对比验证，确保样式一致。
Q&A
StyleX 相比 Tailwind CSS 有哪些优势？
StyleX 通过原子化编译，将样式拆分为独立的原子规则，实现属性级别的去重和复用，从而减少 CSS 体积，提升首屏加载性能。同时，它避免了 Tailwind 中过长的原子类，提高了可读性和可维护性，尤其在复杂 UI 和自定义动画场景下更具优势。
为什么作者决定放弃 Tailwind CSS？
作者放弃 Tailwind 的原因包括：复杂 UI 下 class name 过长（可达四五行），可读性差；arbitrary syntax 和自定义动画等场景难以承载；原子类组合方式不能有效解决 CSS 体积问题。在 AI 时代，Tailwind 的 token 节省优势不再明显，而 StyleX 提供了更好的可扩展性。
StyleX 的原子化编译是如何工作的？
StyleX 会将样式对象中的每个属性拆分为独立的原子规则，例如 color: red 会生成一个类，fontSize: 14 生成另一个类，然后通过组合这些类来应用样式。这样相同的属性值只需生成一次，从而减少重复代码，减小 CSS 体积。
在迁移到 StyleX 的过程中，作者使用了哪些 AI 工具和方法？
作者使用 Codex 的 Multi-Agent 能力，由大模型（如 5.6-Sol）牵头制定迁移手册，分配任务给多个小模型（如 5.6 Luna）并行执行。使用 worktree 保持工作独立，完成后由主 worker 合并和解决冲突，并进行 UI 验证。
迁移到 StyleX 后，CSS 体积减少了多少？
迁移前 CSS 总大小为 215.7 kB（styles.css 203.8 kB + typeset.css 12.0 kB），迁移后生产包 styles-B3DuYbbz.css 为 102.3 kB，减少了约 113.4 kB，体积下降约 52.6%。
StyleX 与 Vanilla Extract 的核心差异是什么？
核心差异在于编译目标：StyleX 偏向原子化 CSS，在属性粒度上去重和复用；而 Vanilla Extract 更接近静态 CSS-in-TS，通常以声明的 style/class 为边界生成 CSS，无法做到原子属性级别的优化。
在迁移过程中，作者如何处理死代码和风险点？
作者首先扫描项目中可能出现的风险点和 App 特化问题，确立边界 case；然后清理死代码，再进行迁移、模块划分和基线。之后进行最小级测试，验证方案可行性，最后建立追踪表逐步实现迁移。
