重构的背景
最近在做一个材料科学方向的项目，发现像元素周期表 、晶体结构图这类组件，几乎到处都要用。
开发同学可能不了解，但是材料学这边的同学应该都很熟悉 Materials Project 团队开源的一整套前后端能力，前端 UI 里比较核心的一个仓库是：
这次重构后的仓库是：
- 新仓库：
HyaCiovo/matsci-ui - 在线体验：matsci-ui.vercel.app
我看了下 GitHub，mp-react-components 用的人不算特别多，维护频率也比较低，但我们一直挺喜欢它那套 Bulma 风格的学术感界面和交互。它不是那种很"互联网产品味"的设计，反而更像科研软件该有的样子，安静、克制、信息密度合适。
问题是，喜欢归喜欢，真要放进现在的项目里用，就会发现它已经明显跟不上现代前端项目的节奏了。
所以这次没有继续围着旧库打补丁，而是直接用 Codex 做了一版渐进式迁移：尽量保留原来的样式、交互和 API 习惯，同时把底层依赖、构建工具、文档体系和主题结构整体换到更现代的方案上，让它能在 React 18/19 项目里稳定用起来。
我给 matsci-ui 的定位很明确：
- 不是把
mp-react-components完全推翻后重做一套新 UI - 也不是只做几处兼容 patch，让它"勉强能跑"
- 而是尽量保留原来的 API 习惯、UI 模式和科研场景工作流，把底层升级到现代 React 组件库该有的状态
为什么不是提 PR，而是直接重构一版？
一开始我也不是没想过走"提 PR"这条路，但实际看下来成本并不低：
- 旧库的 React 基线还停留在 React 16
- 构建和开发工具链比较老
- 依赖里有不少历史包，兼容性和后续维护都不太好判断
- 就算本地打 patch 让它"能装进 React 18/19"，也不代表更底层真的稳定可用
- 你花很多时间适配完，也不确定 Materials Project 团队最终会不会收
所以这次我的目标不是"把旧库勉强救活"，而是基于旧库的设计和能力，整理出一版现代可维护的组件库。
旧仓库的问题，具体卡在哪里？
我结合这次迁移过程中整理的 diff 文档，看下来旧仓库主要卡在这几件事上：
1. React 版本太老
旧仓库主线还是 React 16，不应该默认认为它支持 React 18+。
如果你的业务项目已经在 React 18/19 上，那把它直接装进去，风险其实是很高的。
2. 工具链明显偏旧
旧仓库还是 Parcel 1、较老的 Rollup、Babel/Jest、Storybook 6 + webpack5 这一套。
而新仓库这边已经换成了 Vite、Rollup 4、SWC、Vitest、Storybook 10。这里不是为了追新，而是因为后续维护确实会轻松很多。
3. 业务耦合重，很多地方写死
旧仓库里混着不少历史 demo、本地 app sandbox、页面化入口和发布脚本，整体更像一个长期演化出来的业务仓库，而不是一个边界清楚、对外使用方式明确的 npm 组件库。
另外很多能力和结构都偏向原始业务场景，扩展时容易碰到旧假设、旧类名、旧路径这些历史包袱。简单说就是：能用，但不太适合继续往外长。
4. 历史依赖太重
像 react-data-table-component、react-tooltip、react-json-view 这些老依赖本身不是不能用，但当你已经在做 React 18/19 + 现代 bundler 项目时，就会一直担心兼容性、维护成本和后续继续补债的问题。
这次重构主要做了什么？
这次重构并不是"完全推翻旧库"，而是尽量保留原库最有价值的部分：Bulma 风格的学术感视觉、原本比较顺手的交互方式、材料科学场景下真正有用的组件能力，以及尽量稳定的 API 使用习惯。
核心变化包括：
- React 兼容面明确到 17 / 18 / 19
- 构建链路改成 Vite + Rollup 4 + SWC
- 文档和预览统一到 Storybook 10
- Tooltip 等基础能力换成 Radix UI
- 表格底层换成 TanStack Table
- 主题、样式、Storybook 预览样式做了更清晰的拆分
- npm 的对外入口和样式引入方式重新整理清楚
另外，像 Search UI、数据密集型表格和筛选、基于元素周期表的组合输入、文献组件、Crystal Toolkit 相关 3D 场景这些核心科研工作流，也尽量保住了。
为什么说这次更像"渐进式迁移"，不是暴力重写？
因为我们并不是为了"换技术栈而换技术栈"。这次做法更像是先确认旧库哪些能力值得留，再优先解决真正影响接入和维护的问题，最后一步步把底层实现替换成更现代的方案。
一句话来概括，这次迁移其实就是：
让老用户还能一眼认出它、顺手继续用它，但底层已经换成了现代 React 项目可以长期维护的那一套。
这基本就是这次项目最核心的设计取向。
Codex 在这里到底起了什么作用？
先说结论：codex 是我 👴 ！
这次基本是我一个人推进，主要就是用 Codex 往前推。
说实话，这种迁移任务特别适合 AI 辅助。因为它不是单点写个组件那么简单，而是要同时处理很多互相关联的东西：改导出入口，要看构建有没有跟上；改主题名，要看文档、Storybook、样式入口是不是一起改到了；换底层依赖，要看现有 API 和交互是不是还能接得住；调样式，还得回到 Storybook 一页页确认有没有视觉回归。
这种任务最烦的不是代码难，而是引用多、文件多、细节多，而且特别容易漏。AI 在这里最大的价值，不是替你拍脑袋做决定，而是帮你把这些高重复、强关联、跨文件的事情推进得更快。
vibe coding 是真的很适合去处理这种老项目、屎山项目、历史包袱很重的升级优化任务。
原因很简单，这类项目最大的问题通常不是某一个函数不会写，而是：
- 依赖关系绕
- 文件分散
- 改动面广
- 很多历史细节没人愿意一点点手查
而 AI 恰好很擅长做这些"脏活累活"：
- 大量读文件、查引用
- 批量梳理 API 和样式入口
- 补文档、补迁移说明
- 帮你先把第一轮替换和统一工作推进起来
当然，方向判断、方案取舍、回归验收还是得靠人。
但对老项目升级来说，AI 的积极作用已经很明显了：它能把很多原本又碎又烦、很容易拖黄的工程活，压缩到一个人也能推进的程度。
这个库对材料科学项目，真正有价值的地方是什么？
对我来说，最核心的一点是：
它不是一个"通用 UI 库换皮版"，而是真的在服务材料科学场景。
你在普通组件库里很难直接拿到这些东西：
- 元素周期表输入
- 化学式 / 化学系统 / 材料 ID 输入
- 材料搜索相关的 Search UI
- 面向论文和文献的 Publications 组件
- 晶体结构和 3D 场景相关能力
这些能力如果每个团队都自己从零搭，其实很浪费。
而如果能在一个现代、可维护的前端仓库里，把这些能力整理出来，对材料科学产品、科研平台、数据工具型项目都会很有帮助。
这次迁移后，我最满意的是什么？
如果只看结果，我觉得这次最重要的不是"换了多少依赖"，而是这个库终于从"我知道它很好用，但我不太敢正式依赖"，变成了"我可以放心把它接进 React 18/19 项目并继续维护"。
两个仓库地址
这里把两个仓库地址放一起，方便直接看：
如果你本身就在做材料科学类前端项目，我觉得这个仓库还是值得参考的。
欢迎一起用、一起提建议
这个库现在还在持续整理和完善中，npm包也还没有正式发布，只是在我们内部使用。
如果你也在做：
- 材料科学相关产品
- 科研数据平台
- 学术工具型前端
- 研究型可视化应用
欢迎来用，也非常欢迎直接参与：
- Star： 欢迎 star 支持
- Issue：提问题、提需求、提使用反馈
- PR：直接改进组件、文档、样式、测试
- Discuss：一起聊 API 设计、主题方向、材料科学场景支持
我也很希望这个库不只是一次重构实践， 而是真的能慢慢长成一个对材料科学社区有帮助的前端组件库。
如果你最近也在做老库迁移、React 18/19 升级，或者在用 AI 辅助真实工程，欢迎交流。
我也很想知道，大家现在都是怎么把 vibe coding 和日常工程结合起来的。