上周，一位工程师和一个 AI 模型从零重建了最流行的前端框架。结果是 vinext（读作“vee-next”）：它是基于 Vite 的 Next.js 可替代实现，只需一条命令即可部署到 Cloudflare Workers。早期基准显示，它构建生产应用的速度最高可提升 4 倍，客户端 bundle 体积最高可缩小 57%。而且我们已经有客户在生产环境中运行它。
整个项目大约花费了 1,100 美元的 token 成本。
Next.js 的部署问题
Next.js 是最流行的 React 框架。数百万开发者在使用它。它支撑了生产 Web 的很大一部分，而且理由充分：开发体验非常好。
但当 Next.js 用在更广泛的 Serverless 生态里时，会出现部署问题。它的工具链是高度定制的：Next.js 在 Turbopack 上投入很大，但如果你想把它部署到 Cloudflare、Netlify 或 AWS Lambda，你必须把构建产物再转换成目标平台真正能运行的形态。
你可能会想：“这不就是 OpenNext 在做的事吗？”没错。
这确实是 OpenNext 诞生要解决的问题。包括我们 Cloudflare 在内的多个提供方，都在 OpenNext 上投入了大量工程工作。它能工作，但很快会遇到限制，然后变成打地鼠。
以 Next.js 的输出产物作为基础继续构建，已被证明是一种困难且脆弱的方法。因为 OpenNext 必须反向工程 Next.js 的构建输出，不同版本之间会出现不可预测的变化，需要大量工作去修正。
Next.js 一直在推进一套一等公民的 adapters API，我们也在和他们协作。它仍处于早期阶段；即使有 adapters，你依然建立在定制的 Turbopack 工具链之上。而且 adapters 只覆盖构建与部署。在开发阶段，next dev 仍然只在 Node.js 里运行，无法接入其他 runtime。如果你的应用使用了平台特有 API，比如 Durable Objects、KV 或 AI bindings，你在本地 dev 阶段就无法无缝测试这些代码。
介绍 vinext
如果我们不去“适配” Next.js 的输出，而是直接在 Vite 上重实现 Next.js 的 API surface，会怎样？Vite 是 Next.js 之外前端生态中最常用的构建工具，Astro、SvelteKit、Nuxt、Remix 等框架都构建在它之上。我们想要的是一次干净的重实现，而不是 wrapper 或 adapter。说实话，我们一开始也不认为它可行。但现在是 2026 年，构建软件的成本已经彻底改变。
我们走得比预期更远。
npm install vinext
把脚本里的 next 换成 vinext，其余基本不变。你现有的 app/、pages/、next.config.js 都可以原样使用。
vinext dev # 带 HMR 的开发服务器
vinext build # 生产构建
vinext deploy # 构建并部署到 Cloudflare Workers
这不是对 Next.js + Turbopack 输出的包装器。它是对 API surface 的另一套实现：路由、服务端渲染、React Server Components、server actions、缓存、中间件。全部基于 Vite 插件体系构建。更关键的是，借助 Vite Environment API，Vite 的输出可以运行在任意平台。
数据表现
早期基准很有希望。我们在同一个 33 路由的 App Router 应用上比较了 vinext 和 Next.js 16。两者执行的是同一类工作：编译、打包、准备 SSR 路由。我们关闭了 Next.js 构建中的 TypeScript 类型检查和 ESLint（Vite 构建时不会运行这些），并使用 force-dynamic，避免 Next.js 额外进行静态预渲染（否则会不公平地拉低它的构建时间）。目标是只衡量 bundler 与 compilation 速度，不比较其他因素。基准在 GitHub CI 上每次合并到 main 都会运行。
生产构建时间：
| 框架 | 均值 | 相比 Next.js |
|---|---|---|
| Next.js 16.1.6 (Turbopack) | 7.38s | 基线 |
| vinext (Vite 7 / Rollup) | 4.64s | 快 1.6x |
| vinext (Vite 8 / Rolldown) | 1.67s | 快 4.4x |
客户端 bundle 体积（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 的架构，特别是 Vite 8 中即将到来的 Rust bundler Rolldown，在构建性能上具备结构性优势，这里已经清楚体现出来。
部署到 Cloudflare Workers
vinext 把 Cloudflare Workers 作为首个部署目标。从源码到上线 Worker，只需一条命令：
vinext deploy
它会处理所有步骤：构建应用、自动生成 Worker 配置、执行部署。App Router 和 Pages Router 在 Workers 上都可运行，包含完整客户端 hydration、交互组件、客户端导航、React state。
在生产缓存方面，vinext 内置了 Cloudflare KV cache handler，可直接提供 ISR（Incremental Static Regeneration）：
import { KVCacheHandler } from "vinext/cloudflare";
import { setCacheHandler } from "next/cache";
setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));
KV 对多数应用是不错的默认值，但缓存层设计成可插拔。setCacheHandler 意味着你可以替换成更适合自己的后端。对于缓存 payload 较大或访问模式不同的应用，R2 可能更合适。我们也在改进 Cache API，希望在更少配置下提供更强缓存能力。目标就是灵活性：按应用特性选策略。
目前在线运行示例：
- App Router Playground
- Hacker News clone
- App Router minimal
- Pages Router minimal
我们还有一个 Next.js 应用中运行 Cloudflare Agents 的在线示例，不再需要 getPlatformProxy 这类 workaround，因为整个应用在 dev 与 deploy 两个阶段都运行在 workerd 上。这意味着你可以无妥协使用 Durable Objects、AI bindings 以及其他 Cloudflare 专属服务。可以查看示例了解更多。
Frameworks 是团队运动
当前部署目标是 Cloudflare Workers，但这只是整体图景的一小部分。vinext 约 95% 是纯 Vite：路由、模块 shim、SSR pipeline、RSC 集成，这些都不是 Cloudflare 专属。
Cloudflare 正在与其他 hosting providers 探讨，为他们的客户采用这套工具链（迁移成本很小，我们不到 30 分钟就在 Vercel 上做出了一个 PoC）。这是一个开源项目；从长期成功看，我们认为必须与生态伙伴协作，保证持续投入。欢迎其他平台提 PR。如果你想增加新部署目标，可以提 issue 或直接联系我们。
状态：Experimental
我们想说清楚：vinext 仍是 experimental。它诞生还不到一周，也还没有经历真正有规模的流量考验。如果你要在生产应用里评估它，请保持应有谨慎。
不过测试套件已经很广：1,700+ 个 Vitest 测试、380 个 Playwright E2E 测试，其中包含直接移植自 Next.js 测试套件和 OpenNext 的 Cloudflare conformance suite。我们已在 Next.js App Router Playground 上完成验证。当前覆盖率达到 Next.js 16 API surface 的 94%。早期真实客户反馈也令人鼓舞。我们正在与 National Design Studio 合作，他们希望现代化每一个政府界面，在其 beta 站点 CIO.gov 上已把 vinext 跑在生产环境，并取得了显著的构建时间与 bundle 体积改进。
README 也明确写出了不支持项、不会支持项和已知限制。我们希望保持透明，不做过度承诺。
预渲染怎么办？
vinext 已经原生支持 ISR。页面在首个请求后会被缓存，并在后台再验证，行为和 Next.js 一样。这一部分今天就可用。
vinext 目前还不支持构建时静态预渲染。在 Next.js 中，没有动态数据的页面会在 next build 时渲染成静态 HTML；动态路由则通过 generateStaticParams() 枚举要提前构建的页面。vinext 还没做这一点。
这在发布时是有意为之。它已在 roadmap 上；但如果你的网站是 100% 静态内容预构建 HTML，今天使用 vinext 的收益可能不大。换个角度，如果一位工程师花 1,100 美元 token 就能重建 Next.js，你大概也可以花 10 美元迁移到更适合纯静态内容、并且可部署到 Cloudflare Workers 的 Vite 系框架，比如 Astro。
但对于不是纯静态的网站，我们认为可以做得比“构建时全量预渲染”更好。
介绍 Traffic-aware Pre-Rendering
在 Next.js 里，generateStaticParams() 列出的页面都会在构建阶段预渲染。一个有 10,000 个商品页的网站，构建时就要渲染 10,000 页，即便其中 99% 可能永远没人访问。构建时间随页面数量线性增长。这也是大型 Next.js 站点经常出现 30 分钟构建的原因。
所以我们做了 Traffic-aware Pre-Rendering（TPR）。它目前是 experimental，等积累更多真实世界验证后，我们计划把它设为默认。
思路很直接。Cloudflare 本来就是你站点的反向代理，我们拥有流量数据。我们知道哪些页面真的被访问。因此 vinext 在部署时会查询 Cloudflare zone analytics，只预渲染真正重要的页面，而不是“全量”或“完全不预渲染”。
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、服务端渲染 pipeline、RSC streaming、文件系统路由、中间件、缓存、静态导出。没人做成是有原因的。
这一次我们在一周内完成。一个工程师（严格说是工程经理）指挥 AI。
第一笔提交在 2 月 13 日落地。当天晚上结束前，Pages Router 和 App Router 都已实现基础 SSR，同时跑通 middleware、server actions、streaming。到第二天下午，App Router Playground 的 11 条路由中有 10 条已可渲染。第三天，vinext deploy 已能把应用完整部署到 Cloudflare Workers，并带有完整客户端 hydration。本周剩余时间主要用于加固：修边界情况、扩测试、把 API 覆盖拉到 94%。
和以前那些尝试相比，改变了什么？AI 变强了，而且强很多。
为什么这个问题非常适合 AI
不是每个项目都能这样推进。这个项目可行，是因为几个条件同时成立。
Next.js 的规范足够完整。 它有大量文档、庞大用户群，以及多年的 Stack Overflow 问答和教程。API surface 在训练数据中覆盖很广。你让 Claude 实现 getServerSideProps 或解释 useRouter 行为时，它不会瞎编，它真的“知道” Next.js 的工作方式。
Next.js 有非常完整的测试套件。 Next.js 仓库里有成千上万 E2E 测试覆盖功能与边界场景。我们直接移植了其中一部分测试（代码里能看到归属说明）。这让我们有了可以机械验证的“规范”。
Vite 是很好的基础。 Vite 已经处理了前端工具链中最困难的部分：快速 HMR、原生 ESM、干净插件 API、生产打包。我们不必自己造 bundler，只要教它“说 Next.js 的语言”。@vitejs/plugin-rsc 虽然仍在早期，但让我们在不从零实现 RSC 的前提下拿到了 React Server Components 支持。
模型能力追上来了。 我们认为即便几个月前，这件事都很难做到。早期模型无法在这种规模代码库里持续保持架构一致性。新模型可以把完整架构放进上下文，推理模块如何交互，并足够频繁地产出正确代码，维持开发动量。有些时候，我看到它深入 Next、Vite、React 内部去定位 bug。当前 SOTA 模型令人印象深刻，而且还在持续变强。
这几个条件缺一不可。目标 API 有清晰文档、测试覆盖充分、底层构建工具扎实、模型可以处理复杂度。少任何一个，效果都会明显变差。
我们具体是怎么构建的
vinext 几乎每一行代码都由 AI 生成。但更重要的是：每一行都通过了你对人类代码同样会要求的质量门槛。项目有 1,700+ Vitest 测试、380 Playwright E2E 测试、通过 tsgo 的完整 TypeScript 类型检查，以及 oxlint。CI 在每个 PR 上都会跑完整检查。要让 AI 在代码库里高效工作，先搭好 guardrails 至关重要。
流程从规划开始。我先在 OpenCode 里和 Claude 来回讨论了几个小时，明确架构：做什么、顺序如何、用哪些抽象。这个计划成为北极星。之后流程非常直接：
- 定义任务（例如：“实现
next/navigationshim，包括usePathname、useSearchParams、useRouter”）。 - 让 AI 写实现和测试。
- 运行测试套件。
- 测试通过就合并；不通过就把报错给 AI 继续迭代。
- 重复。
我们还把 AI agents 接入了 code review。PR 打开后有 agent 审查；review comment 回来后由另一个 agent 处理。反馈回路大部分自动化了。
它并不是每次都完美。有些 PR 明显是错的。AI 会很自信地实现一个“看起来对”的方案，但并不符合真实 Next.js 行为。我必须经常纠偏。架构决策、优先级判断、识别 AI 是否走进死胡同，这些都还是人来做。当你给 AI 足够好的方向、上下文和 guardrails，它确实可以非常高产。但方向盘仍然在人手里。
对于浏览器层面的测试，我用了 agent-browser 去验证真实渲染输出、客户端导航和 hydration 行为。单元测试会漏掉不少浏览器细节问题，这一步帮我们补上了。
整个项目期间，我们在 OpenCode 里运行了 800+ 个 session。总成本大约 1,100 美元 Claude API token。
这对软件行业意味着什么
为什么我们的技术栈有这么多层？这个项目迫使我深入思考这个问题，也在思考 AI 会如何改变答案。
软件里的大多数抽象，本质上是为了帮助人类。我们无法一次把整个系统装进脑子，所以用层次来管理复杂度。每一层都让下一位开发者更容易工作。于是你会得到“框架套框架”、wrapper 库和上千行胶水代码。
AI 没有同样的限制。它可以把整个系统放进上下文并直接写代码。它不需要中间框架来维持组织性。它只需要规范和一个扎实基础。
现在还不清楚哪些抽象是真正基础性的，哪些只是为了弥补人类认知限制的“拐杖”。未来几年，这条边界会发生很大变化。但 vinext 是一个数据点。我们拿到 API contract、构建工具和 AI 模型，然后 AI 写出了中间的全部内容。不需要中间框架。我们认为这个模式会在大量软件中重复出现。过去这些年堆积起来的层，并不是每一层都会被保留。
致谢
感谢 Vite 团队。Vite 是整个项目赖以成立的基础。@vitejs/plugin-rsc 虽然仍在早期，但让我们无需从零实现 RSC，这一点是决定性的。Vite 维护者也非常及时、非常有帮助，尤其是在我把插件推到它此前未覆盖的场景时。
我们也想感谢 Next.js 团队。他们多年打造的框架，抬高了 React 开发体验的上限。其 API surface 的完整文档和测试套件的广度，是这个项目能成立的重要原因。没有他们设定的标准，就不会有 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 和反馈。
Cloudflare 的 connectivity cloud 可保护企业网络，帮助客户高效构建 Internet-scale 应用，加速任何网站或 Internet 应用，抵御 DDoS 攻击，防止黑客入侵，并助力你的 Zero Trust 建设。
你可以在任意设备访问 1.1.1.1，开始使用我们的免费应用，让你的 Internet 更快、更安全。
想了解我们“帮助构建更好 Internet”的使命，请从这里开始。如果你正在寻找新的职业方向，也欢迎查看我们的开放岗位。
