Cloudflare 如何用 AI 在一周内重建了 Next.js

分享一篇 Cloudflare 的技术博文。一位工程师用 AI 在一周内重建了 Next.js，基于 Vite 构建，构建速度提升最高 4 倍，客户端包体积缩小 57%。以下是原文翻译。

本文已于太平洋时间下午 12:35 更新，修正了构建时间基准测试中的一处笔误。

上周，一位工程师和一个 AI 模型从零开始重建了最流行的前端框架。成果就是 vinext（发音为"vee-next"）——它是 Next.js 的直接替代品，基于 Vite 构建，只需一条命令即可部署到 Cloudflare Workers。早期基准测试显示，它的生产构建速度最高快 4 倍，客户端包体积最多小 57%。而且我们已经有客户在生产环境中运行它了。

整个项目的 token 费用大约花了 1,100 美元。

Next.js 的部署困境

Next.js 是最受欢迎的 React 框架。数百万开发者在使用它，它支撑着大量生产级 Web 应用——这背后有充分的理由：它的开发体验无与伦比。

但在更广泛的 Serverless 生态中，Next.js 存在部署困境。它的工具链完全是定制化的：Next.js 在 Turbopack 上投入了大量资源，但如果你想将其部署到 Cloudflare、Netlify 或 AWS Lambda，就必须把构建产物重新整形成目标平台能运行的格式。

如果你在想：“这不就是 OpenNext 做的事吗？"——没错，正是如此。

OpenNext 正是为解决这个问题而生的，多个云厂商（包括我们 Cloudflare）都在 OpenNext 上投入了大量工程资源。它能用，但很快就会遇到局限，陷入"打地鼠"的循环。

以 Next.js 的构建产物为基础来开发，被证明是一条既困难又脆弱的路。由于 OpenNext 必须对 Next.js 的构建输出进行逆向工程，版本之间的变动难以预测，修复起来耗费大量精力。

Next.js 团队一直在开发一套一流的 Adapters API，我们也在与他们合作。这还是早期阶段，但即便有了 Adapter，你仍然是在定制化的 Turbopack 工具链上构建。而且 Adapter 只覆盖构建和部署环节——在开发阶段，next dev 只在 Node.js 中运行，没有办法接入不同的运行时。如果你的应用用到了 Durable Objects、KV 或 AI bindings 这类平台特有的 API，在开发环境中测试这些代码就需要各种变通手段。

介绍 vinext

如果我们不去适配 Next.js 的输出，而是直接在 Vite 上重新实现 Next.js 的 API 层，会怎样？Vite 是 Next.js 之外前端生态中最广泛使用的构建工具，Astro、SvelteKit、Nuxt、Remix 等框架都基于它。这是一次干净的重新实现，而不是简单的包装或适配器。说实话，我们当时并不确定这能行——但现在是 2026 年，软件开发的成本已经彻底变了。

我们走得比预期远得多。

npm install vinext

在你的 scripts 中把 next 替换成 vinext，其他一切保持不变。你现有的 app/、pages/ 和 next.config.js 原样可用。

vinext dev          # 带 HMR 的开发服务器
vinext build        # 生产构建
vinext deploy       # 构建并部署到 Cloudflare Workers

这不是对 Next.js 和 Turbopack 输出的封装——它是对 API 层的替代实现：路由、服务端渲染、React Server Components、Server Actions、缓存、中间件，全部基于 Vite 插件构建。最重要的是，得益于 Vite Environment API，Vite 的产物可以在任何平台上运行。

性能数据

早期基准测试结果令人振奋。我们使用一个包含 33 条路由的 App Router 应用，对 vinext 和 Next.js 16 进行了对比。

两个框架执行的工作相同：编译、打包、准备服务端渲染路由。我们在 Next.js 的构建中禁用了 TypeScript 类型检查和 ESLint（Vite 在构建时不运行这些），并使用 force-dynamic 防止 Next.js 额外花时间预渲染静态路由（这会不公平地拉低其成绩）。目标是只测量打包和编译速度。基准测试在 GitHub CI 上随每次合并到 main 分支自动运行。

生产构建时间：

框架	平均耗时	对比 Next.js
Next.js 16.1.6（Turbopack）	7.38s	基准
vinext（Vite 7 / Rollup）	4.64s	快 1.6 倍
vinext（Vite 8 / Rolldown）	1.67s	快 4.4 倍

客户端包体积（gzip 压缩后）：

框架	Gzip 大小	对比 Next.js
Next.js 16.1.6	168.9 KB	基准
vinext（Rollup）	74.0 KB	小 56%
vinext（Rolldown）	72.9 KB	小 57%

这些基准测试衡量的是编译和打包速度，而非生产环境的服务性能。测试用例是单个 33 路由的应用，并不代表所有生产应用的情况。随着三个项目的持续发展，这些数字预计还会变化。完整的测试方法和历史结果均已公开。请将这些数据视为方向性参考，而非定论。

不过，方向是令人鼓舞的。Vite 的架构，尤其是 Rolldown（Vite 8 中即将推出的基于 Rust 的打包器），在构建性能上具有结构性优势，在这里体现得非常明显。

部署到 Cloudflare Workers

vinext 以 Cloudflare Workers 作为首要部署目标。一条命令就能完成从源码到运行中的 Worker 的全部流程：

vinext deploy

这一步处理所有事情：构建应用、自动生成 Worker 配置、部署。App Router 和 Pages Router 在 Workers 上均可运行，支持完整的客户端 hydration、交互式组件、客户端导航和 React state。

对于生产缓存，vinext 内置了 Cloudflare KV 缓存处理器，开箱即用地提供 ISR（增量静态再生）能力：

import { KVCacheHandler } from "vinext/cloudflare";
import { setCacheHandler } from "next/cache";

setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));

KV 对大多数应用来说是个不错的默认选择，但缓存层设计为可插拔的。setCacheHandler 这个调用意味着你可以换成任何合适的后端。对于缓存内容较大或访问模式不同的应用，R2 可能更合适。我们还在改进 Cache API，目标是提供一个配置更少的强大缓存层。核心思路是灵活性：选择最适合你应用的缓存策略。

目前正在运行的线上示例：

我们还有一个在 Next.js 应用中运行 Cloudflare Agents 的线上示例——不需要 getPlatformProxy 这类变通手段，因为整个应用现在在 workerd 中运行，开发和部署阶段均如此。这意味着可以无缝使用 Durable Objects、AI bindings 以及所有其他 Cloudflare 专有服务。点此查看。

框架是一项团队运动

当前的部署目标是 Cloudflare Workers，但这只是整个图景的一小部分。vinext 大约 95% 的代码是纯 Vite。路由、模块 shim、SSR 流水线、RSC 集成——这些都与 Cloudflare 无关。

Cloudflare 正在与其他托管服务商探讨，希望他们为自己的客户采用这套工具链（接入成本极低——我们用不到 30 分钟就完成了 Vercel 的概念验证！）。这是一个开源项目，为了它的长期成功，我们认为与生态中的合作伙伴携手、确保持续投入至关重要。欢迎其他平台提交 PR。如果你有兴趣添加新的部署目标，请开 issue 或直接联系我们。

状态：实验性

我们想说清楚：vinext 目前是实验性的。它还不到一周大，尚未经过任何规模化流量的生产验证。如果你在评估将其用于生产应用，请保持适当的谨慎。

话虽如此，测试覆盖相当完善：超过 1,700 个 Vitest 测试和 380 个 Playwright E2E 测试，其中包括直接从 Next.js 测试套件移植的用例（代码中有注明来源），以及来自 OpenNext 的 Cloudflare 合规套件。我们已对照 Next.js App Router Playground 进行了验证。覆盖率达到 Next.js 16 API 层的 94%。

来自真实客户的早期反馈令人鼓舞。我们一直与 National Design Studio 合作——这是一个致力于现代化所有政府界面的团队——在他们的测试站点 CIO.gov 上使用 vinext。他们已经在生产环境中运行 vinext，构建时间和包体积均有明显改善。

README 文档对不支持的功能、不会支持的功能以及已知限制都有诚实的说明。我们想坦诚相告，而不是过度承诺。

预渲染怎么办？

vinext 已经开箱即用地支持增量静态再生（ISR）。对任何页面的第一次请求之后，它就会被缓存，并在后台定期重新验证——和 Next.js 的行为一样。这部分今天就能用。

vinext 目前还不支持在构建时进行静态预渲染。在 Next.js 中，没有动态数据的页面会在 next build 阶段渲染，以静态 HTML 形式提供服务。对于动态路由，你可以用 generateStaticParams() 来枚举需要提前构建的页面。vinext 目前还没有做这个……但已在路线图中。

这是一个有意为之的设计决定。如果你的站点完全是预构建的静态 HTML 内容，今天可能从 vinext 中获益不多。不过话说回来，如果一位工程师花 1,100 美元就能重建 Next.js，你大概花 10 美元就能迁移到专为静态内容设计的基于 Vite 的框架，比如 Astro（同样也能部署到 Cloudflare Workers）。

对于不是纯静态的站点，我们认为可以做得比在构建时预渲染所有页面更好。

引入流量感知预渲染

Next.js 在构建时会预渲染 generateStaticParams() 中列出的每一个页面。一个有 10,000 个产品页的站点，就意味着构建时要渲染 10,000 次，即使其中 99% 的页面可能永远不会收到请求。构建时间随页面数线性增长——这正是大型 Next.js 站点最终需要 30 分钟构建的原因。

所以我们开发了流量感知预渲染（Traffic-aware Pre-Rendering，TPR）。它今天还是实验性的，等有更多真实测试数据后，我们计划将其设为默认。

思路很简单。Cloudflare 本来就是你站点的反向代理，我们有你的流量数据，知道哪些页面真正被访问。所以，vinext 在部署时会查询 Cloudflare 的区域分析数据，只对真正重要的页面进行预渲染，而不是预渲染所有页面，也不是什么都不预渲染。

vinext deploy --experimental-tpr

  Building...
  Build complete (4.2s)

  TPR (experimental): Analyzing traffic for my-store.com (last 24h)
  TPR: 12,847 unique paths — 184 pages cover 90% of traffic
  TPR: Pre-rendering 184 pages...
  TPR: Pre-rendered 184 pages in 8.3s → KV cache

  Deploying to Cloudflare Workers...

对于一个有 100,000 个产品页的站点，幂律分布意味着 90% 的流量通常只集中在 50 到 200 个页面上。这些页面在几秒内完成预渲染，其余页面则回退到按需 SSR，在首次请求后通过 ISR 缓存。每次新部署都会根据当前流量模式刷新预渲染集合。突然爆红的页面会被自动纳入。整个过程不需要 generateStaticParams()，也不需要将构建与生产数据库耦合。

迎接 Next.js 的挑战，这次用 AI

这样一个项目，正常情况下需要一个工程师团队花费数月乃至数年。多家公司的团队都尝试过，但规模实在太大。我们在 Cloudflare 也试过一次！两套路由器、33 个以上的模块 shim、服务端渲染流水线、RSC 流式传输、文件系统路由、中间件、缓存、静态导出——这就是为什么从来没有人真正做成的原因。

这次，我们在一周内做到了。一位工程师（严格来说是工程总监）指挥 AI 完成的。

第一个 commit 落在 2 月 13 日。同一天傍晚，Pages Router 和 App Router 都实现了基本的 SSR，以及中间件、Server Actions 和流式传输。第二天下午，App Router Playground 的 11 条路由中有 10 条已经可以正常渲染。第三天，vinext deploy 就能将带有完整客户端 hydration 的应用部署到 Cloudflare Workers 了。剩下的时间用来打磨：修复边界情况、扩展测试套件、将 API 覆盖率提升到 94%。

与之前的尝试相比，什么变了？AI 变好了。好了很多。

为什么这个问题特别适合 AI

并非所有项目都会走这条路。这个项目之所以成功，是因为几件事恰好在合适的时机同时具备了条件。

Next.js 有明确的规格说明。 它有详尽的文档、庞大的用户群，以及多年积累的 Stack Overflow 问答和教程。这套 API 层遍布模型的训练数据。当你让 Claude 实现 getServerSideProps 或解释 useRouter 的工作原理时，它不会产生幻觉，因为它真的知道 Next.js 怎么运作。

Next.js 有完善的测试套件。 Next.js 仓库包含数千个 E2E 测试，覆盖每个功能和边界情况。我们直接从他们的测试套件移植了测试（代码中有注明来源）。这给了我们一个可以机械验证的规格。

Vite 是一个出色的基础。 Vite 处理了前端工具链中最难的部分：快速 HMR、原生 ESM、干净的插件 API、生产打包。我们不需要自己造一个打包器，只需要教它"说” Next.js 的语言。@vitejs/plugin-rsc 还在早期阶段，但它给了我们 React Server Components 支持，省去了从头实现 RSC 的工作量。

模型追上来了。 我们认为这在哪怕几个月前都不可能实现。早期的模型无法在这么大的代码库中保持连贯性。新的模型能够在上下文中保持完整的架构概念，推理模块之间的交互关系，并且足够频繁地生成正确的代码，让整个进展保持动力。有时候，我看到它会深入 Next.js、Vite 和 React 的内部实现去追查一个 bug。当前最先进的模型令人印象深刻，而且似乎还在持续进步。

这几件事必须同时成立：目标 API 文档详尽、测试套件完备、底层构建工具扎实、模型有能力驾驭这种复杂度。缺少其中任何一个，结果都会差很多。

我们是怎么做的

vinext 中几乎每一行代码都是由 AI 写的。但更重要的是：每一行都通过了与人类编写代码同等的质量关卡。项目有 1,700 多个 Vitest 测试、380 个 Playwright E2E 测试、通过 tsgo 进行完整的 TypeScript 类型检查，以及通过 oxlint 进行 lint。持续集成在每个 PR 上运行所有检查。建立一套好的质量保障机制，是让 AI 在代码库中高效工作的关键。

整个过程从制定计划开始。我在 OpenCode 中和 Claude 来回讨论了几个小时，确定架构：建什么、按什么顺序建、用哪些抽象。这份计划成了整个项目的北极星。之后的工作流程很直接：

定义一个任务（“实现带有 usePathname、useSearchParams、useRouter 的 next/navigation shim”）。
让 AI 写实现和测试。
运行测试套件。
测试通过就合并；不通过就把错误输出给 AI，让它迭代。
重复。

我们也为代码审查接入了 AI Agent。PR 一开，就有 Agent 来 review。review 意见出来后，另一个 Agent 来处理。整个反馈循环基本上是自动化的。

并非每次都运转完美。有些 PR 就是错的——AI 会自信地实现看起来正确但实际上与 Next.js 行为不符的东西。我需要经常纠偏。架构决策、优先级判断、识别 AI 走偏的时机——这些都是我的工作。当你给 AI 明确的方向、充分的上下文和良好的质量保障机制，它可以非常高效。但人类仍然必须掌舵。

对于浏览器层面的测试，我用 agent-browser 来验证实际渲染输出、客户端导航和 hydration 行为。单元测试会漏掉很多微妙的浏览器问题，这个工具帮助发现了它们。

整个项目期间，我们在 OpenCode 中运行了超过 800 个会话。总费用：大约 1,100 美元的 Claude API token。

这对软件意味着什么

为什么我们的技术栈有这么多层？这个项目迫使我深入思考这个问题，以及 AI 如何影响这个答案。

软件中大多数抽象的存在，是因为人类需要帮助。我们无法在脑海中装下整个系统，所以我们建立层级来替我们管理复杂度。每一层都让下一个人的工作更容易——这就是框架叠框架、封装库、数千行胶水代码的由来。

AI 没有同样的限制。它可以在上下文中保持整个系统，直接写代码。它不需要一个中间框架来保持条理——它只需要一份规格和一个可以依托的基础。

目前还不清楚哪些抽象是真正基础性的，哪些只是人类认知的拐杖。这条线在未来几年会大幅移动。vinext 是一个数据点：我们拿来一份 API 契约、一个构建工具和一个 AI 模型，AI 写出了中间所有的东西，不需要中间框架。我们认为这个模式会在大量软件领域重演。我们多年来构建的这些层级，不会全部留存下来。

致谢

感谢 Vite 团队。Vite 是整个项目的基础。@vitejs/plugin-rsc 还在早期阶段，但它让我不用从头实现 RSC 就获得了 RSC 支持——如果没有这一点，这个项目根本不可能完成。Vite 维护者响应迅速、乐于帮助，即便我把这个插件推进到它此前从未被测试过的领域。

我们也想向 Next.js 团队致敬。他们花了多年时间打造这个框架，重新定义了 React 开发的标准。他们的 API 层文档如此详尽，测试套件如此完善，这是这个项目能够实现的重要前提。没有他们树立的标准，vinext 不会存在。

试用

vinext 内置了一个 Agent Skill，可以帮你处理迁移工作。它支持 Claude Code、OpenCode、Cursor、Codex 以及其他数十种 AI 编程工具。安装它，打开你的 Next.js 项目，告诉 AI 来迁移：

npx skills add cloudflare/vinext

然后在任何支持的工具中打开你的 Next.js 项目，说：

migrate this project to vinext

这个 Skill 会处理兼容性检查、依赖安装、配置生成和开发服务器启动。它知道 vinext 支持什么，并会标记出需要手动处理的部分。

如果你更喜欢手动操作：

npx vinext init    # 迁移现有 Next.js 项目
npx vinext dev     # 启动开发服务器
npx vinext deploy  # 部署到 Cloudflare Workers

源码在 github.com/cloudflare/vinext，欢迎提 issue、PR 和反馈。

原文: How we rebuilt Next.js with AI in one week by Steve Faulkner, Cloudflare Blog, 2026-02-24

☕ 如果这篇文章对你有帮助，欢迎请我喝杯咖啡，支持我继续创作更多内容。

Buy me a coffee