框架还重要吗？AI 智能体编程时代 Web 框架的价值之辩

2026-09-16

我并不是在开玩笑。我真的想认真思考一下，在 2026 年，在 vibe coding、智能体编程、循环或图或任何最流行的基于图示隐喻的工程时代，你使用什么 Web 框架还重要吗？更重要的是（对我以及我个人的兴趣而言），冒着自我 Betteridge 化的风险：我们是否应该创造新框架？

React 赢了，那我们还要尝试新东西吗？

现在是不是有更多空间留给细分领域了？没人在意实现细节。没人在意 .tsx 文件里有什么。这是否为尝试新事物打开了新的机会，还是说，既然它不重要，整个行业就干脆决定永远使用最稳定的东西？

在这个大变革的时代，我们有机会重新思考最佳实践（或者对 Remix 来说，是重新再思考），并把一切重新摆到桌面上。这并不意味着所有东西都会留在桌面上，只是说我们会取好的、弃坏的、改丑的。这篇文章的问题不需要被反驳，而是值得认真思考。

作为一个全职从事开源框架工作 3 年的人，我对这个问题深感兴趣。我感兴趣的不是保护我自己/我的手艺，而是提升我的手艺并拥有一份好的职业。我正在思考，也在试图预测（并创造）未来。记住“我可能是错的”让人谦卑，而记住其他大多数人也会错则令人鼓舞。

在这篇文章中，我想把这个问题及其影响拆解成更基本的元素，这样我就能重建一个值得追求和构建的现实版本。为此，首先值得考虑什么是 Web 框架。我觉得这真的很难，因为它是一个非常模糊和宽泛的术语，你最终会把 Flask 和 jQuery、React 和 Next.js 拿来比较。相反，我认为考虑框架提供什么价值更有帮助。我认为这个说法足够了：

框架为构建你的网站提供抽象、结构和约束。

想象一下

想象一下没有 React
你试试就知道很容易
我们下方没有 Svelte
我们上方，只有二(进制)
想象所有人
为今天而提示

（抱歉，Svelte，我用“地狱”这个词替换了你。这不是因为我察觉到相似之处，我只是喜欢它听起来的感觉。）

那么让我们回到这个论点，再稍微展开一下。这是我目前听到的普遍看法：

自从模型在智能体编程方面变得出色（大约在 25-26 年冬季），我越来越不关心代码（你也应该如此）。对于任何前端代码尤其如此，因为它们基本上都是表现层的。因此，如果它看起来好，它就是好。
鉴于模型的现状，并且鉴于 React 已经是最主流的 UI 框架，拥有非常流行的元框架 Next.js（外加其他一些不错的选择，如 React Router 和 TanStack Start），真的没有必要或价值去尝试其他任何东西。此外，因为现实世界中有远多于此的 React 代码，模型在它上面训练得更多，因此对 React 更擅长（或至少更熟悉）。React 奇点已经发生，接受它吧。

显然（我希望如此），我现在有点在开玩笑。这个论点仍然值得考虑，主要是因为看到有人把这种观点连同 React 一起盲目崇拜地塞进他们靠感觉写出来的应用里。不过，也有一些更严肃的人，比如 Cursor 团队，他们似乎确实相信在智能体编程时代使用 React 是一种优势。

我很想逐一深入探讨这些说法：

你不需要担心前端代码
模型最擅长 React，因为它们的训练数据
模型在新框架上表现会很差，因为缺乏训练数据

不过，我其实并不确定这有什么价值，尤其是在争论 React 的时候。我对这个逻辑有更大的意见，它源于我最初的问题：框架还重要吗？

这个论点让我不明白的是：为什么是 React？为什么要用任何框架或 UI 库？

如果 LLM 已经如此擅长前端代码，如果人们越来越不关心 HTML、JavaScript 和 CSS 的细节，只在乎它看起来和用起来是否正常，那为什么还要在 LLM 和网站之间加一层抽象？如果说有哪个时刻该拥抱 Web Components，那肯定就是现在。

React 不再必须成为一个人的个性标签。免责声明：我这么说，是因为我有一个名为“React Tips with Brooks Lybrand”的 YouTube 频道。再说，我们已经有了 AI 实验室来塑造我们的新个性，所以我们会没事的。

让我换个角度来阐述这个论点：

自从模型在智能体编程方面变得出色（大约在 25-26 年冬季），构建一个美观且可交互的网站比以往任何时候都更容易，无需再担心我们以前所说的 DX（开发者体验）。我的智能体不在乎基于文件的路由之类的东西，我又何必费心去让它正确设置 useEffect 呢？
此外，模型在 JavaScript、HTML 和 CSS（某种程度上）上训练得非常好，所以真的没有必要或价值再去增加更多复杂层。

我认为这种观点中有一些逻辑跳跃和错误，但并不比第一种更被广泛接受的观点更多。

要么：

框架不重要，那样的话你就没有理由使用 React。
你使用 React 可能仍然有优势，那样的话框架就重要。

Web 框架的价值是什么？

啊，Web 框架。它从哪里开始，到哪里结束？它的目的是什么？我们到底需不需要它？毕竟，jQuery 有什么不好？有没有人提出过，既然 jQuery 在训练数据中代表性很强，我们就该让智能体直接用 jQuery？如果没有，他们应该提。智能体不在乎意大利面条式代码，对吧？

我年纪够大，还记得 2010 年代的“框架大战”。当时我为公司做评估时，是在 React、Angular 和 Vue 之间选择。那些就是我们谈论的“框架”。Gatsby 已经存在，但不够通用（仅限静态站点生成）。Next.js 挺酷，但也相当有限（没有好的变更方案）。大多数情况下，如果你在 React 生态里，你就用 create-react-app（CRA），也许如果你团队里真有人觉得 SSR 有价值并想设置它，你会eject。

我最终选择了 React，许多其他人也这样做了。但为什么？是什么让 React 作为一个框架如此有吸引力？

如果你问 React 团队为什么 React 赢了，或者为什么它如此出色，他们很可能会说“组合”。我发现很难准确概括究竟是什么让 React 如此特别，但我认为这是其中很大一部分原因。在我职业生涯早期和使用 React 的初期，我并不真正理解“组合”意味着什么。我只知道：

React 非常容易接入现有网站
React 有一种非常好的方式，将逻辑和标记封装到受控且可能可复用的组件中
React 拥有一个强大且不断增长的库生态系统，帮助填补我需要的其他部分：路由、样式、head/meta 标签管理等。

我后来会了解到，React 从一开始就提供了服务端渲染（SSR），使其在观感和体验上很像 PHP，那种在脚本语言中写 HTML 的体验。设置这一点要复杂一些，尤其是对于像我这样更偏前端的人来说。这导致了“面向前端的后端工程师”以及像 Next.js 和 Remix（旧的那个，抱歉）这样的元框架的兴起。

React 解决了许多问题。尽管 Rauch 先生这么认为（通常来说，他基本是对的），React 之所以“赢”，并不是因为它附带了一个组件库，封装了出色的样式系统以及你可以拥有并根据自身需求改造的底层可访问组件和工具。shadcn/ui 很棒，别误会。但即使在组件库/设计系统的故事中，它也只是从 Radix 到 Reach UI 到 Material UI 到 Bootstrap 以及许多许多我略过、忘记或不知道的继任者这一长串中的最新演进。shadcn/ui 在许多其他流行现有者之上存在，恰恰证明了是什么让 React 伟大，而不是反过来。

这段关于 React 为何“赢”的冗长而简短的题外话，远不能公正地呈现完整历史，也当然完全没有触及是什么让其他 Web 框架有趣。尽管 React 占据主导地位，许多其他框架和元框架每周仍有数百万次下载，并受到许多开发者的喜爱。它也完全忽略了基于非 JavaScript 的框架（如 Laravel 和 Ruby on Rails）的流行。

我不知道还有什么更好的方式来思考框架提供的价值，而不去内省是什么让我最初的挚爱 React 对我如此特别。React 让构建动态网站变得更容易，而不会最终陷入意大利面条式代码，而意大利面条式代码之所以糟糕，是因为从长远来看，修改和维护它的成本很高。React 使我能够做到，提升了作为工程师的我，解决了我本不想解决的问题，并让我进入了一个由其他开发者组成的生态系统，他们正在让它变得更好，并在其上构建更有用的工具。

正如我在本文开头所说，我认为框架的附加价值非常简单：框架为构建你的网站提供了抽象、结构和约束。

这甚至不是框架独有的特性，所有库、模块、类和函数都是如此。代码是一系列抽象，向计算机以及任何会操作或从这些代码中学习的东西表达含义和意图。以前，这意味着人类，我们称之为“阅读代码”，所以我们非常在意变量名之类的东西。如今，我们关心的细节层次正在变化和重新沉淀。也许我们正处在某条无限曲线上，会越来越不关心树木，直到连森林都不在乎。就我个人而言，我对此持怀疑态度，但我完全可能是错的。

不管怎样，我想我仍然想要一个框架。我想要经过良好测试、安全、易于推理的代码，并且能让我的智能体进入它所需的节奏，从而产出我喜欢的结果。

每个人都在用框架

好吧，真相大白，当我问“框架还重要吗？”时，我有点在开玩笑。

我记得在React Conf 2024 核心团队问答中，Ricky Hanlon提出了这个观点：

你要么在使用框架，要么在构建框架，而构建框架真的很难。

这不是我第一次听到这种说法。事实上，在之前一份工作中，我作为得克萨斯州一家杂货店Web 平台团队的工程师，我们遇到了同样的情况。我们在 React 之上构建了自己的元框架，用于处理初始请求的服务端渲染，之后应用会水合整个文档，并使用 React Router（v5？）在客户端接管路由。

虽然我们为这个自制的元框架取了一个可爱的名字（exo，我想是的，而且没人能就为什么叫这个名字达成一致），但大多数工程师并不认为它是一个框架。我把这主要归咎于功能不足和缺乏营销（我们为什么要营销一个内部框架呢？）。尽管如此，我们仍然构建了自己的框架，它带来了大量的维护成本和负担，而且真正理解它如何工作的工程师寥寥无几，使其成为一个相当大的负债。

长话短说，他们开始了从这种自研元框架迁移到 Next.js 的进程。我没能见证这一转变的完成，因为大约在这个时候我去了 Shopify 的 Remix 团队工作（当然，我们“开玩笑”说正是这个决定把我赶走了）。

这个轶事的时间线毫无疑问正好在智能体编程变得足够好之前。假设你现在要开始一个全新项目，并且假设它不仅仅是为了演示或一次性的展示型网站，我认为 Ricky 的说法现在比以往任何时候都更正确，但也有一点不对。

让我们从不对的地方开始：“构建框架真的很难”。现在已经不是了。我的意思是，这取决于你想要什么。如果你想要一个优秀、健壮、无 bug、安全的全栈框架，那需要远不止几个提示词才能真正充实起来。然后当你开始使用它时，你可能会发现 LLM 无法真正让它完成你要求的所有事情，于是它们就悄悄地在你的框架周围构建各种 hack，而取决于你如何构建这个框架，这些 hack 最终会成为框架的一部分。根据我的经验，即使使用前沿模型，避免拼凑 hacky 的变通方案，并决定良好、健壮且可扩展的抽象，也需要一些工作和迭代。

然而，构建一个框架——哪怕不是什么烂框架，只是一个还行的框架——其实并不难。我知道这一点，因为如果你不使用框架，而是用 LLM 开始搭建一个网站，它会为你构建一个框架。这个 LLM 可能没有那么多功能，也肯定没有营销预算或野心去向你推销它的框架，但它仍然会构建一个框架。它会像生成函数、类以及我们过去“手工”编程时所做的所有典型抽象一样，生成一个框架。仅仅因为你更少去看它，并不意味着智能体从根本上做的事情和我们所做的不是完全一样。我甚至都不屑于称它为“垃圾”，这就是不断添加功能而不做清理，我最初的所有项目都是这么搭建的。这没什么新鲜的，最大的变化是速度。

智能体现在可以更快地搭建你的网站。它可以更快地查找信息和想法。它可以更快地制造一团乱麻。我们以前就有能力做所有这些事情，这并不是一个“人类在编程上 > AI”的观点。我的观点很简单：你要么在使用一个显式框架，要么在生成一个隐式框架。如果你觉得这完全无关紧要，那么回到我先前的观点，为什么还要用 React？你可能不理解你自己的定制框架，但你的智能体理解，而且是它写的，它可能还很喜欢。你问 LLM 它的框架，它对它的了解比你了解 React 内部机制还要多，而这只是沿着那条不可避免的道路又前进了一步——最终让LLM 直接交付二进制文件，而不是人类可读的代码。如果你就是这么认为的，那至少诚实一点，把 React 扔掉，它肯定只会拖慢你的速度。

如果你不知怎么地、出于某种原因，认为 LLM 使用像 React 这样的框架或像 Next.js 这样的元框架更好，我猜那是因为你更希望 LLM 使用经过实战检验、抽象良好且文档完善的东西。你可能还喜欢它为智能体设置了护栏，避免了重复造轮子——而现有的轮子就能把你带到想去的地方。你可能还喜欢整个团队以及依赖该框架的许多其他公司都在考虑安全问题，而不只是你和（但愿如此）你的智能体。你可能还有其他理由，但以下是我的理由：

我对框架想要（和不想要）什么

如今，我更感兴趣的是代码的“形态”，而抽象和结构对此帮助极大。我也对约束我的智能体感兴趣（测试、linting、Skills、可复制的可扩展模式）。当我还是那个直接敲代码字符的人时，有很多东西对我很重要，通常被归类为开发者体验（DX）。其中一些东西现在对我仍然有帮助，一些对我已经不太有帮助了（但对智能体有帮助），还有一些似乎对我们俩都没什么帮助。让我们看一些轶事性的例子。

以热模块替换为例。

HMR 让我可以对网站进行修改，并立即在浏览器中看到更新，而无需刷新屏幕。当它可靠工作时，这非常有帮助，尤其是在调整涉及用户流程的设计时（比如表单上的错误消息、初始为折叠状态的手风琴组件，以及装饰元素的绝对定位）。这不是一个决定成败的功能，但我发现即使在使用代理时（也许正是因为使用它们），如果我在处理复杂的用户交互并真正想要精细调整设计，HMR 也非常有用。

以 TypeScript 为例。

TypeScript 过去对我来说非常有价值，因为它创造了约束。我的 JavaScript 现在必须带有类型（据说 C# 开发者为此欢呼）。此外，它让我更容易发现对象中可用的字段和方法，因为我只需悬停或 command+. 该对象就能看到可用的内容。TypeScript 是创建内置文档的重要部分，这帮助我在编写代码时保持高效。如今，我几乎完全不在意发现对象上的特定方法，类型约束也没有直接帮助到我。

然而，许多其他人和我似乎仍然发现，对于复杂的应用程序（不是那种一次性的、你会丢弃的随意之作），类型的约束确实能提升 LLM 迭代代码而不意外破坏一切的能力。此外，据我所知，能够访问 LSP 似乎有助于它在遇到不熟悉的函数、对象或模块（例如遗留代码或先前代理生成的代码）时进行探索。

以 useEffect 为例。

我知道它算是抨击 React 的典型代表，我也知道 React 团队已经提供了新的 API，旨在帮助解决其缺点。问题是，当我亲自编写 React 时，我曾是 useEffect 的专家（至少我感觉是这样）。我不太介意 useEffect，我信任自己使用它。它是一个可靠、古怪且非常强大的钩子，我用起来很顺手，主要是因为我相信自己知道何时不该使用它。对于 LLM，我发现 useEffect 比古怪更糟糕，无论模型多聪明，我都不放心让它们使用那种抽象。事实上，Grok Bot 的开发显然完全禁止了 useEffect。

让我们回顾一下框架的增值之处。我想要一个框架，~~穿着短裙和长外套~~ 为构建网站提供抽象、结构和约束。

我发现，如果某个抽象不存在，LLM 就会创造一个。有时这并不重要，有时它只是一次性的抽象。但有时它确实重要，有时抽象是围绕实际的 Web 原语构建的（用于客户端导航的 Navigation API）。有时抽象能与其他抽象很好地配合（在路由器中使用 fetch 以及 Request/Response 模型）。有时抽象封装了非常难以在第一次就一致且无错误地实现的行为（如果你喜欢的话，React 的 Server Components；如果你不喜欢，Remix 的 Frame）。

我已经谈过我为什么仍然喜欢看到代码的形状，或者说结构。也许马斯克先生是对的，我们只是在加速迈向超人级别的编码水平，而我试图理解代码最终只会成为拖累。目前，我发现当我与智能体协作、为它创建一个良好的核心架构作为构建基础，并在发现它生成难以理解的代码时（甚至不是对我而言，而是对智能体而言；当它们感到困惑时我能察觉）不断优化架构时，效果最好。

最后是约束。我希望以正确的方式做正确的事这一点极其清晰。我希望逃生通道是可能的，但通常不必要，并且当它们被使用时，对我和机器来说都始终显而易见。我希望测试和工具能够检查智能体的工作，并内置于框架之中。我希望好的文档能立即获取，最好就在我的node_modules中，这样智能体就不会不断浪费时间在网上搜刮，并可能引入糟糕的建议。

那么，框架还重要吗？

我写这篇博客文章已经写了3周了。我职业生涯的最后3年一直在从事开源Web框架的工作。我喜欢这项工作，我希望在可预见的未来继续做这件事。回答“框架还重要吗？”这个问题对我来说极其重要，因为比起热爱框架工作，我更讨厌做不重要的事情。

通过写这篇文章以及与业内同行的多次交流，我对以下几点相当有信心：

AI绝对正在重塑软件的制造方式，无论是个体层面还是大规模层面。
除非被证明并非如此，不同的人和不同的方法会产生不同程度的质量，即使使用相同的模型/工具链。因此，我会将LLM视为一种我可以改进的工具。
没有人真正知道AI对软件开发，更不用说对世界的长期影响。
AI目前是行业的主要焦点。

我认为大约2013-2019年的框架大战，以及随后大约2020-2024年的续集框架大战：元框架的崛起，已经结束了。显然，通过将结束年份定为2024年，我认为它们已经结束有一段时间了。人们可以不再对JavaScript感到疲劳了，谢天谢地，因为我们都知道我们已经对AI炒作/末日循环感到疲劳了。

我已经接受，或者说正在接受，人们不再像过去那样渴望框架，而且在很多方面这可能是件非常好的事。有那么一阵子确实有点疯狂，而我当然也曾深陷其中。

但某样东西不必处于炒作周期的中心才能重要或有用。直到大量OpenClaw和其他智能体在野外对整个系统进行压力测试并发现新的瓶颈之前，关于git的性能或寻找GitHub替代品的讨论并不多。现在这里有很多关注。

技术发展是动态的，新的工具、想法、模式和库会催生更多同类事物。与其坐在那里哀叹人们不再想在Xwitter上为Next.js和Remix争论，我宁愿真正参与到构建我认为自己和他人能从中受益的东西中去。

所以再次问：框架还重要吗？让我通过总结到目前为止的观点来阐明我的“是”：

业界似乎也这么认为，否则为什么要用 React？
如果你不使用框架，你的智能体就会自己造一个框架，所以不管你愿不愿意，你都在使用框架。
框架为构建网站提供了抽象、结构和约束。在用智能体塑造软件时，这些都是好事。使用一个经过深思熟虑、开源、久经考验且文档完善的框架，很可能比使用你的模型自创的框架更有优势。

当我坐在这里梳理到目前为止的想法时，我意识到这看起来可能像是在打稻草人。"人们当然认为框架很重要，并且能帮助你的智能体，这在 React 和 Next.js（或任何其他足够好的现有框架）那里已经是解决过的问题了。"

有道理。我想问题在于：新框架还重要吗？

如果我们认为所有问题都已解决，那我认为我们正处于人类和技术发展的可悲境地。那种颓废不适合我。对我来说，如果某样东西很好，那你很可能可以把它做得更好。也许现有的格局已经"足够好"了，如果对你来说够用，那没问题，但对我来说不够。

实际上，我想要一个全栈的 JavaScript 框架。也许我们永远到不了那一步，之前的尝试也没能起飞（👋 Meteor，我们都爱过你）。只要我（或我的智能体）还得拼凑一堆包来组装一个完整的全栈应用——从数据库到路由，再到样式、动画和无障碍组件——就还有改进的空间。

我希望它建立在 Web 标准和 API 之上，这样它说的就是 Web 的语言，而不是 Node.js 或任何单一 JavaScript 运行时的语言。我希望它是一个感觉通用的框架，像是它所构建平台的显而易见延伸，而不是某个博士生的深奥研究项目。

我还想要一个 AI 能轻松协作、并且产出的代码我能理解的框架。我不希望最终结果是一团我看不懂的乱麻。我不是在造车，但该死，我想打开引擎盖，真正知道自己在看什么。我还没有看到一种好的实证方法来真正构建"为智能体而生"的语言/框架。到目前为止，我的品味（也就是我与这些模型打交道的、主观且有偏见的经验）对我来说，比任何基准测试或对制作一个 TODO 应用用了多少 token 的分析都重要得多。我不是说我们不该尝试，我是说，要为哪个框架最适合智能体建立一个确定、客观的衡量标准，其难度本身就足以向我证明还有持续改进的空间。

新框架还重要吗？只有一种方法能真正找到答案。让我们动手造一些吧。

感谢 Alex Anderson、Moishi Netzer、Elijah F. Hopp 和 Braydon Coyer 阅读本文的早期草稿并提供宝贵反馈。也感谢我的同事 Matt Brophy、Mark Dalgleish 和 Michael Jackson 无休止的辩论以及就此话题分享他们自己的想法。 🙏

由 Markdown 构建，使用了一个小小的 Node.js 脚本。