AI 编码的隐性成本：同一个应用用 12 个框架写一遍，差异比想象中大

有人做了个实验：用 Claude 把同一个 Pokédex 应用在 12 个 JavaScript 框架里各写一遍，配一套一致性测试，然后比较结果。这个话题在技术社区拿到了三百多点赞，因为它戳到了一个被忽略的维度。

过去选框架看什么

运行时性能、包体积、生态成熟度、团队熟悉度、招聘难度。这五条基本覆盖了决策。

现在多了一条

AI 协作友好度。具体表现在三个地方：

提示词上下文。框架的约定越隐式、魔法越多，AI 越容易写错。写错的代码不报错，但行为不对，排查成本极高。

重构成本。AI 改代码时，改动的影响面越大越危险。强约束的框架改一个组件可能牵动五个文件，AI 很难一次改对。

产物可维护性。AI 生成的代码往往能跑但不好读。框架如果本身有强烈的结构约束，生成的代码至少形状是对的；如果框架自由度极高，生成的就是一坨能跑的意大利面。

实验的意义不在排名

12 个框架里谁第一谁最后，其实没那么重要，样本只有一个应用、一个模型、一次运行。真正有价值的是它提出的问题：当越来越多的代码由 AI 生成，框架的设计目标是不是该调整？

过去框架追求表达力与灵活性，因为使用者是人，人能驾驭复杂。现在使用者一半是 AI，AI 需要的是明确的边界、一致的约定、可预测的生成结果。

给团队的实用建议

选框架时加一条评估：让 AI 用它写一个中等复杂度的功能，看生成的代码你能不能一眼看懂、改起来费不费劲。这一条比任何 benchmark 都贴近真实。

另外，无论用什么框架，类型系统与静态检查的价值都在上升。AI 生成的代码最容易犯的是类型层面的低级错误，静态检查能拦住一大半。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

12个框架各写一遍同一个应用，样本只有一个、一次运行，排名意义有限，但它提的问题很关键：当一半代码由AI生成，框架的设计目标是不是该调整。过去追求表达力和灵活性因为使用者是人，现在AI需要的是明确边界、一致约定、可预测的生成结果。选型时加一条实测：让AI写个中等复杂功能，看生成的代码改起来费不费劲。

AI 协作友好度这条我深有体会。框架约定越隐式，模型越容易写出能跑但语义错的代码，比如依赖生命周期钩子的隐式顺序。我们现在的做法是把关键约定写进仓库的 AGENTS 文件，比在提示词里反复解释稳定得多，重构时改动面也小。

这个实验最有价值的结论是提示词上下文这个维度。框架约定越隐式，AI 写出来的代码越容易编译通过但行为不对，排查成本远高于重写。我选型时优先挑约定显式的框架，比如状态管理要求手写 reducer 的，AI 出错至少能看出来，比魔法多的好维护。