GitHub 公开了 18 个月重构的完整复盘——一场大厂主动承认技术路线走弯的少有案例。其设计系统官方数据：服务端渲染时间减少 55%，组件初始化减少 25%；主站各页面改善 1%—22% 不等。最后 3 周由 2 名工程师搭配 Copilot coding agents（GitHub 的 AI 编程助手）把剩余 895 处遗留样式清零。

这是什么

2025 年 4 月 GitHub 存量约 7760 个旧样式调用。前 6 个月由 8 名工程师手工迁移 6419 个，剩余 895 个交给 2 人加 Copilot agents，3 周清完。

原理不复杂：CSS-in-JS 在浏览器运行时把样式对象转成规则、生成类名；传统 CSS 在构建阶段就编译好。"多发一点 CSS，JavaScript 少干活"，组件数量上升后反而更快。

行业怎么看

支持者说这是 AI 落地的真实战例：8 人 6 个月干 6419 个 vs 2 人 + AI 3 周干 895 个。Copilot 这类工具的价值，在于承担机械改写这种重复的活。

反对意见更值得注意。GitHub 自报数据没给完整实验区间和页面分布，只是自身结果，不能当通用结论。AI 只在最后 15% 上场——前面 85% 的架构设计、双轨兼容层（让新旧样式并存）、回滚开关全是人做的。小团队、样式动态性强的场景，迁移成本可能大于收益。同时大量用 AI 生成新代码的话，必须把新规则写进脚手架，否则 AI 一边清旧债一边造新债。

指标层面也有陷阱：只看 JavaScript 包体积缩小、忽略浏览器解析 CSS 和缓存命中；把不同页面、不同时段实验组横向对比也是常见错误。

对普通人的影响

对企业 IT 决策者：追新技术不是答案。GitHub 90% 工作是定义性能预算、设计回滚、选迁移单位——这些"无聊活"。下次有人推销新框架，先问：能并存吗？能回滚吗？有性能基准吗？

对个人职场：AI 真正的杀手锏不是写新功能，是清旧账——机械改写、存量迁移、文档同步、代码格式化。这类活交 AI，人去做需要拍板的事。

对消费市场：网站可能快一点，但用户感知不强。值得关心的是，"少 JS 多 CSS"这类反常识结论会越来越多，技术圈在重新审视"新就是好"。