我正在开发 DocFlow，它是一个完整的 AI 全栈协同文档平台。该项目融合了多个技术栈，包括基于 Tiptap 的富文本编辑器、NestJs 后端服务、AI 集成功能和实时协作。在开发过程中，我积累了丰富的实战经验，涵盖了 Tiptap 的深度定制、性能优化和协作功能的实现等核心难点。

如果你对 AI 全栈开发、Tiptap 富文本编辑器定制或 DocFlow 项目的完整技术方案感兴趣，欢迎加我微信 yunmz777 进行私聊咨询，获取详细的技术分享和最佳实践。

上周，一名工程师和一套 AI 模型从零重写了最流行的前端框架。产物叫 vinext（读作 "vee-next"），是基于 Vite 的 Next.js 替代实现，一条命令就能部署到 Cloudflare Workers。早期基准测试里，生产构建快至多约 4 倍，客户端包体积最多小约 57%。已有客户在生产环境跑它。整件事大约花了一千一百美元左右的 token 成本。

Next.js 的部署难题

Next.js 是最流行的 React 框架，数百万开发者在用，也支撑着大量线上站点，原因很简单：开发体验很好。

但在更广的 serverless 生态里，Next.js 的部署是个问题。工具链完全是自成一派的：Next.js 在 Turbopack 上投入很大，可如果你要部署到 Cloudflare、Netlify 或 AWS Lambda，就得把构建产物再"捏"成目标平台能跑的样子。

你可能会想："OpenNext 不就是干这个的吗？"没错。OpenNext 就是为解决这个问题而生的，包括 Cloudflare 在内的多家厂商都往里投了不少工程资源。它能用，但很快就会撞到各种限制，变成打地鼠游戏。

在 Next.js 的构建产物之上再建一层，被证明既难又脆。OpenNext 需要反推 Next.js 的构建输出，结果就是版本之间难以预测的变动，修起来很费劲。

Next.js 一直在做一等公民的 adapters API，Cloudflare 也在和他们协作。但这仍是早期工作，而且即便有了 adapters，你依然建立在 Turbopack 这套专属工具链上。Adapters 只覆盖构建和部署；开发阶段里，next dev 只在 Node.js 里跑，没法插别的运行时。如果你的应用用了 Durable Objects、KV、AI bindings 这类平台能力，在开发环境里想测这些代码，就得搞一堆变通。

vinext 是什么

换个思路：与其去适配 Next.js 的产出，不如在 Vite 上直接重写一套 Next.js 的 API。Vite 是 Next.js 之外大多数前端生态用的构建工具，Astro、SvelteKit、Nuxt、Remix 等都基于它。要的是干净的重实现，而不是包一层或写个 adapter。他们一开始也没把握能成，但现在是 2026 年，造软件的成本已经彻底变了。

结果比预期走得远得多。

把脚本里的 next 换成 vinext，其余基本不用动。现有的 app/、pages/、next.config.js 都能直接用。安装方式如下：

npm install vinext

常用命令和 Next 类似，只是把 next 换成 vinext：

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

这不是包在 Next.js 和 Turbopack 输出外面的一层皮，而是对同一套 API 的另一种实现：路由、服务端渲染、React Server Components、server actions、缓存、中间件，全部作为 Vite 插件搭在 Vite 之上。更重要的是，借助 Vite Environment API，Vite 的产出可以在任意平台上跑。

数据表现

早期基准测试看起来不错。他们用一套共 33 个路由的 App Router 应用，对比了 vinext 和 Next.js 16。两边做的是同一类事：编译、打包、准备服务端渲染路由。在 Next.js 的构建里关掉了 TypeScript 类型检查和 ESLint（Vite 构建阶段本来也不跑这些），并对 Next.js 使用了 force-dynamic，避免多花时间预渲染静态路由，否则会不公平地拉低 Next 的数字。目标只衡量打包和编译速度。

生产构建时间大致如下（原文表格，此处保留结构）：

框架	平均耗时	相对 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：

在项目里执行即可完成构建、自动生成 Worker 配置并完成部署：

vinext deploy

App Router 和 Pages Router 都能在 Workers 上跑，包括完整的客户端注水、交互组件、客户端导航和 React 状态。

生产缓存方面，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，目标是少配置也能有强缓存能力。总之是尽量灵活，按应用选策略。

当前已有线上示例：App Router Playground、Hacker News 克隆、App Router 与 Pages Router 最小示例等，见 vinext 文档与仓库。还有一例 Cloudflare Agents 在 Next 风格应用里跑，不再需要 getPlatformProxy 之类的变通，因为整个应用在开发与部署阶段都跑在 workerd 里，Durable Objects、AI bindings 等 Cloudflare 能力都可以直接使用，示例见 vinext-agents-example。

框架是团队协作的事

当前部署目标是 Cloudflare Workers，但这只占一小部分。vinext 里大约 95% 是纯 Vite：路由、模块 shim、SSR 管线、RSC 集成，没有 Cloudflare 专属逻辑。

Cloudflare 希望和其他托管方一起，让这套工具链也能服务他们的用户（迁移成本很低，他们在 Vercel 上不到 30 分钟就跑通了一个 PoC）。这是开源项目，长期看需要和生态里的伙伴一起投入。欢迎其他平台的 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 在 beta 站点 CIO.gov 上已经用 vinext 跑生产，构建时间和包体积都有明显改善。

README 里老实写了 不打算支持以及不会支持的内容 和 已知限制，尽量坦诚、少过度承诺。

预渲染呢？

vinext 已经支持增量静态再生成（ISR），首访某页后会被缓存并在后台再验证，和 Next.js 行为一致。这部分已经可用。

vinext 目前还不支持构建时静态预渲染。Next.js 里没有动态数据的页面会在 next build 时渲染成静态 HTML；有动态路由时用 generateStaticParams() 枚举要提前构建的页面。vinext 暂时不做这件事。

这是发布时的刻意取舍，路线图上有计划。若你的站是 100% 预生成静态 HTML，眼下从 vinext 获益可能有限。反过来说，若一名工程师花一千多美元 token 就能重写一版 Next.js，你大概也能花很少成本迁到 Astro 这类为静态内容设计的 Vite 系框架（Astro 也能部署到 Cloudflare Workers）。

对非纯静态站点，他们想做得比"构建时全量预渲染"更好一点。

流量感知预渲染（TPR）

Next.js 会在构建时把 generateStaticParams() 列出的页面都预渲染一遍。一万个商品页就意味着构建时渲染一万次，哪怕其中 99% 可能永远不会被请求。构建时间随页面数近似线性增长，这也是为什么大型 Next.js 站点的构建会拖到三十分钟级别。

于是他们做了"流量感知预渲染"（Traffic-aware Pre-Rendering，TPR）。目前是实验性的，计划在更多真实场景验证后作为默认选项。

思路很简单。Cloudflare 已经是站点的反向代理，拥有流量数据，知道哪些页面真的被访问。所以既不必全预渲染，也不必完全不预渲染：在部署时查 Cloudflare 的 zone 分析，只预渲染真正重要的页面。

使用方式是在部署时打开实验开关：

vinext deploy --experimental-tpr

输出会包含类似：分析最近 24 小时流量、统计独立路径数、按流量覆盖（例如 90%）选出要预渲染的页面数量、预渲染耗时并写入 KV 缓存等。

对于十万级商品页的站点，幂律分布下往往 50～200 个页面就覆盖了 90% 的流量。这些页面几秒内预渲染完，其余走按需 SSR，首访后再通过 ISR 缓存。每次部署都会根据当前流量重新算一遍集合，突然爆红的页面会被自动纳入。全程不需要 generateStaticParams()，也不用把构建和线上数据库绑死。

用 AI 再挑战一次 Next.js

这类项目通常要一个团队做几个月甚至几年。多家公司都试过，范围实在太大。Cloudflare 自己也试过一次。两套路由、三十多个模块 shim、服务端渲染管线、RSC 流式、文件系统路由、中间件、缓存、静态导出……没人做成是有原因的。

这次他们在一周内做到了。一名工程师（头衔是工程经理）带着 AI 一起干。

首笔提交在 2 月 13 日。当晚 Pages Router 和 App Router 都有了基础 SSR，中间件、server actions 和流式也跑通了。第二天下午，App Router Playground 已经能渲染 11 个路由里的 10 个。第三天，vinext deploy 能把应用完整部署到 Cloudflare Workers，包括客户端注水。后面几天主要是收口：修边界情况、扩测试、把 API 覆盖拉到约 94%。

和以前几次尝试相比，变的是 AI 强了很多。

为什么这个问题适合交给 AI

不是所有项目都适合这么搞。这次能成，是因为几件事同时满足。

Next.js 有清晰、成文的规范：文档多、用户多、Stack Overflow 和教程里到处都是，API 表面在训练数据里很常见。让 Claude 实现 getServerSideProps 或解释 useRouter 怎么用，它不会乱编，因为它"见过" Next 是怎么工作的。

Next.js 有庞大的测试套件。Next.js 仓库 里有大量 E2E，覆盖各种功能和边界。他们直接移植了其中的测试（代码里有注明来源），等于拿到一份可以机械验证的规格。

Vite 是很好的底座。Vite 解决了前端工具里最难的那块：快 HMR、原生 ESM、清晰的插件 API、生产打包。不需要从零做打包器，只要教它"说" Next.js。@vitejs/plugin-rsc 还在早期，但已经能提供 React Server Components 支持，不必自己实现一整套 RSC。

模型能力跟上了。他们认为哪怕早几个月都很难做成。以前的模型在这么大代码库上很难保持连贯；新模型能把整体架构放在上下文里，推理模块间关系，并经常写出正确代码，让迭代能持续下去。有时会看到它钻进 Next、Vite、React 内部去查 bug。当前最好的模型已经足够好用，而且还在变好。

这几条必须同时成立：目标 API 文档好、测试全、底层构建工具靠谱、模型真的能驾驭这种复杂度。少一条，效果都会打折扣。

实际是怎么做的

vinext 里几乎每一行都是 AI 写的。但更关键的是，每一行都过同样的质量关：人类写的代码也会走的那些门。项目里有 1,700+ Vitest、380 Playwright E2E、通过 tsgo 的完整 TypeScript 检查、通过 oxlint 的 lint，CI 在每个 PR 上全跑一遍。定好这些护栏，是让 AI 在代码库里高效的前提。

流程从规划开始。作者在 OpenCode 里和 Claude 花了几小时来回推敲架构：建什么、什么顺序、用什么抽象。那份计划成了北极星。之后就是固定循环：

1. 定义一个任务（例如"实现 next/navigation 的 shim，包含 usePathname、useSearchParams、useRouter"）。
2. 让 AI 写实现和测试。
3. 跑测试。
4. 过了就合并，不过就把错误输出给 AI 继续改。
5. 重复。

他们还接了 AI 做 Code Review：PR 打开后有 agent 审，审完的评论由另一个 agent 改。反馈环大部分是自动的。

并不是每次都对。有些 PR 就是错的，AI 会很有把握地实现一个"看起来对"但和 Next.js 实际行为不一致的东西。作者经常要纠偏。架构决策、优先级、判断什么时候 AI 在走死胡同，都是人在做。给 AI 好的方向、上下文和护栏，它可以很出活，但掌舵的还得是人。

浏览器级测试用了 agent-browser，用来验证真实渲染结果、客户端导航和注水行为。单测会漏掉很多浏览器侧的细节，这样能补上。

整个项目在 OpenCode 里跑了超过 800 次会话，总成本大约一千一百美元（Claude API token）。

对软件意味着什么

我们为什么有这么多层？这个项目逼着作者认真想这个问题，以及 AI 会怎么改变答案。

软件里大多数抽象的存在，是因为人需要帮忙。我们没法把整个系统装进脑子，于是用一层层东西来管理复杂度，每一层让下一个人的工作轻松一点。框架叠框架、包装库、成千上万行胶水代码，就是这么来的。

AI 没有同样的限制。它可以把整个系统放在上下文里，直接写代码，不需要中间框架来"帮人类理清思路"，只需要规格和一块可建的底座。

哪些抽象是真正的基础设施，哪些只是人类认知的拐杖，现在还不清楚。这条线未来几年会大幅移动。但 vinext 是一个数据点：他们拿了一份 API 契约、一个构建工具和一个 AI 模型，中间全是 AI 写的，没有额外的中间框架。他们认为这种模式会在很多软件上重演，我们多年来叠上去的层，不会全部留下。

致谢

感谢 Vite 团队。Vite 是整个项目的基础。@vitejs/plugin-rsc 虽还在早期，但提供了 RSC 支持，否则要从零实现 RSC 会直接卡死。作者把插件推到以前没人测过的场景时，Vite 维护者响应很快、帮了很多忙。

也感谢 Next.js 团队。他们用多年把 React 开发的标杆拉高，API 文档和测试套件如此完善，是 vinext 能做成的重要前提。没有他们立下的标准，就没有 vinext。

试试看

vinext 提供 Agent Skill，可以帮你做迁移，支持 Claude Code、OpenCode、Cursor、Codex 等。安装后打开 Next.js 项目，让 AI 执行迁移即可。

安装 vinext 的 Agent Skill（在支持的工具里执行）：

npx skills add cloudflare/vinext

然后在任意支持的工具里打开 Next.js 项目，对 AI 说：

"把这个项目迁移到 vinext"

Skill 会做兼容检查、依赖安装、配置生成和开发服务器启动，并标出需要人工处理的部分。

若想手动迁移，可以用：

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

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