Cloudflare：我們如何用 AI 在一周內重構 Next.js

作者丨 Steve Faulkner

譯者丨明知山

策劃丨 Tina

上周，一名工程師從零開始，用 AI 模型重構了當下最流行的前端框架，最終得到了 vinext（讀作“vee-next”）。它可作為 Next.js 的即插即用替代方案，基于 Vite 構建，僅需一條命令就能部署到 Cloudflare Workers。在初步基準測試中，生產環境應用的構建速度最高提升 4 倍，客戶端打包體積最高減小 57%。目前已有客戶在生產環境中正式使用。

整個項目僅花費約 1100 美元的 Token 費用。

Next.js 的部署難題

Next.js 是最流行的 React 框架，擁有數百萬開發者用戶，支撐著互聯網上相當一部分生產環境應用 —— 這背后有著充分的理由：它擁有一流的開發者體驗。

但當 Next.js 被用于更廣泛的無服務器生態時，會出現部署問題。它的工具鏈是高度定制化的：盡管 Next.js 在 Turbopack 上投入了大量資源，但如果要部署到 Cloudflare、Netlify 或 AWS Lambda，仍需對構建輸出進行改造才能適配目標平臺的運行環境。

如果你在想："這不就是 OpenNext 的功能嗎？"——你說的沒錯。

這確實是 OpenNext 要解決的核心問題。包括 Cloudflare 在內的多家廠商都為 OpenNext 投入了大量工程資源。它雖然能運行，但很快就會遇到各種限制，變成一場打地鼠游戲。

基于 Next.js 輸出進行構建早已被證明是一種困難且脆弱的方案。OpenNext 不得不對 Next.js 的構建輸出做逆向工程，這會帶來版本間不可預知的變更，需要做大量的修正工作。

Next.js 一直在開發一等適配器 API，我們也在與其合作，目前仍處于早期階段。但即便有了適配器，構建過程依然要依賴高度定制化的 Turbopack 工具鏈。此外，適配器只覆蓋構建與部署環節。在開發階段，next dev完全在 Node.js 中運行，無法接入其他運行時。如果你的應用使用了平臺特定 API（如 Durable Objects、KV 或 AI 綁定），除非采用變通方案，否則無法在開發環境中對這些代碼進行測試。

vinext 介紹

如果不采用適配 Next.js 輸出的方式，而是直接基于 Vite 重新實現 Next.js 的 API 會怎樣？Vite 是除 Next.js 外大多數前端生態所使用的構建工具，支撐著 Astro、SvelteKit、Nuxt、Remix 等框架。這是一次干凈的重新實現，而非簡單的封裝或適配。老實說，我們原本并不認為這能成功。但如今已是 2026 年，軟件構建的成本已經完全改變了。

我們取得的進展遠超預期。

npm install vinext

只需將腳本中的next替換為vinext，其余保持不變即可。你現有的app/、pages/和next.config.js無需修改就能正常工作。

vinext deploy       # Build and deploy to Cloudflare Workers

這并非基于 Next.js 和 Turbopack 輸出的封裝層，而是對 API 的完整替代實現：路由、服務端渲染、React Server Components、服務端操作、緩存、中間件——全部基于 Vite 構建并以 Vite 插件的形式實現。最重要的是，得益于 Vite Environment API，Vite 的構建輸出可在任意平臺上運行。

數據表現

初步基準測試結果振奮人心。我們使用一個包含 33 條路由的共享 App Router 應用對 vinext 與 Next.js 16 進行了對比。兩個框架執行相同的工作：編譯、打包并準備服務端渲染路由。我們在 Next.js 構建中禁用了 TypeScript 類型檢查和 ESLint（Vite 在構建期間不運行這些），并使用force-dynamic防止 Next.js 花費額外時間預渲染靜態路由（避免拖慢其速度）。測試目標是僅測量打包器與編譯速度，排除其他干擾因素。每次合并到主干分支時，都會在 GitHub CI 上運行基準測試。

生產構建時間：

客戶端打包體積（gzip 壓縮后）：

這些基準測試測量的是編譯與打包速度，而非生產服務性能。測試樣本為一個包含 33 條路由的單一應用，并非所有生產應用的代表性樣本。我們預計隨著三個項目的持續迭代，相關數據會發生變化。完整的測試方法與歷史結果均已公開，僅供作為方向性參考，而非絕對結論。

不過這一方向已展現出積極信號。Vite 的架構，尤其是即將在 Vite 8 中推出的、基于 Rust 開發的打包器 Rolldown，在構建性能上具備結構性優勢，這一點在本次測試中體現得十分明顯。

部署到 Cloudflare Workers

vinext 以 Cloudflare Workers 作為首要部署目標進行構建，只需一條命令就能從源碼直接部署為可運行的 Worker：

vinext deploy

這會處理所有環節：構建應用、自動生成 Worker 配置并完成部署。App Router 和 Pages Router 均可在 Workers 上運行，支持完整的客戶端 hydration、交互式組件、客戶端路由導航與 React 狀態。

在生產緩存方面，vinext 內置了 Cloudflare KV 緩存處理器，開箱即用支持 ISR（增量靜態再生）：

setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));

KV 是大多數應用的默認選擇，但緩存層是可插拔的。你可以通過setCacheHandler替換為任意合適的后端。對于緩存負載較高或訪問模式不同的應用，R2 可能會更合適。我們也在優化 Cache API，以提供更強大的緩存層并簡化配置。我們的目標是保持靈活：讓你選擇適合自己應用的緩存策略。

實時運行示例：

• App Router Playground

• Hacker News 克隆版

• App Router 最小示例

• Pages Router 最小示例

我們還有一個 Cloudflare Agents 在 Next.js 應用中實時運行的示例，且無需getPlatformProxy這類變通方案——因為整個應用現在無論是開發還是部署階段都運行在 workerd 中。這意味著可以無妥協地使用 Durable Objects、AI 綁定以及其他所有 Cloudflare 專屬服務。可在 此處 查看。

框架開發是一場團隊協作

當前的部署目標是 Cloudflare Workers，但這只是冰山一角。vinext 中約 95% 的代碼都是純 Vite 生態相關內容：路由、模塊墊片、SSR 流程、RSC 集成——這些都不是 Cloudflare 特有的。

Cloudflare 希望與其他托管服務商合作，讓客戶們也能使用這套工具鏈（所需工作量極小——我們在不到 30 分鐘內就完成了 Vercel 上的概念驗證）。這是一個開源項目，為了長期發展，與整個生態伙伴合作、確保能夠持續投入是至關重要的。我們歡迎來自其他平臺的 PR。如果你有興趣新增部署目標，歡迎提交 Issue 或聯系我們。

狀態：實驗階段

我們要明確說明的是：vinext 目前仍處于實驗階段。它誕生還不到一周，尚未經過大規模真實流量的實戰檢驗。如果你考慮將其用于生產環境，請務必謹慎評估。

話雖如此，我們的測試套件已相當完備：包含超過 1700 個 Vitest 測試與 380 個 Playwright 端到端測試，其中部分測試直接移植自 Next.js 測試套件以及 OpenNext 的 Cloudflare 一致性測試套件。我們已通過 Next.js App Router Playground 完成驗證，對 Next.js 16 API 的覆蓋率達到 94%。來自真實用戶的早期反饋同樣鼓舞人心。我們一直在與 National Design Studio 合作，該團隊致力于推動所有政府界面的現代化，目前已在其測試站點 CIO.gov 上運行 vinext，并已將其用于生產環境，構建時間與打包體積均得到顯著優化。

README 中已如實列出目前不支持的功能與已知限制。我們希望保持坦誠，不過度承諾。

預渲染

vinext 已開箱即支持增量靜態再生（ISR）。與 Next.js 一樣，任意頁面在首次請求后都會被緩存，并在后臺重新驗證。這一功能現已可用。

vinext 目前尚不支持構建時靜態預渲染。在 Next.js 中，無動態數據的頁面會在next build階段被渲染并作為靜態 HTML 提供；若存在動態路由，可通過generateStaticParams()枚舉需要提前構建的頁面。vinext 目前暫不支持這一功能，但也只是暫時的。

這是發布時我們有意做出的設計決策。該功能已列入路線圖，但如果你的網站是 100% 預構建的靜態 HTML，目前使用 vinext 可能不會帶來太多收益。話雖如此，如果一位工程師能花 1100 美元的 Token 成本重建 Next.js，那你大概只需花 10 美元就能遷移到專為靜態內容設計、基于 Vite 的框架，比如 Astro（它同樣可以部署到 Cloudflare Workers）。

但對于并非純靜態的網站，我們相信我們能做得比在構建時預渲染所有內容更好。

流量感知預渲染

Next.js 會在構建期間預渲染generateStaticParams()中列出的每個頁面。一個擁有 10000 個產品頁面的網站，就意味著構建時要執行 10000 次渲染，即便其中 99% 的頁面可能永遠不會被訪問。構建時間會隨頁面數量線性增長，這也是大型 Next.js 網站的構建時間最終會長達 30 分鐘的原因。

因此我們構建了流量感知預渲染（Traffic-aware Pre-Rendering，TPR）。該功能目前仍處于實驗階段，我們計劃在經過更多真實場景驗證后將其設為默認模式。

理念很簡單：Cloudflare 本身就是你網站的反向代理，我們掌握著你的流量數據，清楚哪些頁面是實際被訪問的。因此，vinext 既不會預渲染全部內容，也不會完全不預渲染，而是在部署時查詢 Cloudflare 的區域分析，只預渲染那些關鍵頁面。

  Deploying to Cloudflare Workers...

對于一個擁有 10 萬個產品頁面的網站，冪律分布表明：90% 的流量通常只集中在 50 至 200 個頁面上。這些頁面可以在幾秒內完成預渲染，其余內容則回退到按需 SSR，并在首次請求后通過 ISR 緩存。每次新部署都會根據當前流量模式刷新預渲染頁面集合，爆款頁面會被自動納入。整個過程無需使用generateStaticParams()，也不需要將構建過程與生產數據庫綁定。

直面 Next.js 帶來的挑戰，但這一次用上了 AI

這類項目通常需要一支工程師團隊耗費數月乃至數年才能完成。已有多家公司的多個團隊嘗試過，但涉及范圍實在是太大了。Cloudflare 就曾嘗試過一次：兩套路由、33+ 個模塊墊片、服務端渲染管道、RSC 流式傳輸、文件系統路由、中間件、緩存、靜態導出。也難怪一直沒人能真正做成。

這一次，我們僅用不到一周就完成了——由一名工程師（嚴格來說是工程經理）指導 AI 完成。

首次提交始于 2 月 13 日。當天晚上，Pages Router 與 App Router 就已實現基礎 SSR、中間件、服務端操作與流式傳輸。次日下午，App Router Playground 已能渲染 11 條路由中的 10 條。第三天，vinext deploy已可將應用部署到 Cloudflare Workers，并支持完整的客戶端激活。剩下的時間則用于穩定性加固：修復邊界場景、擴充測試套件、將 API 覆蓋率提升至 94%。

與早期的嘗試相比，究竟是什么發生了改變？是 AI 變得更強大了，強大得太多。

為什么這個問題適合用 AI 解決

并非每個項目都能進展得如此順利。這個項目之所以能做到，是因為諸多因素在恰當的時機恰好形成了合力。

Next.js 的定義十分清晰。它擁有詳盡的文檔、龐大的用戶群體以及多年來積累在 Stack Overflow 上的問答和教程。其 API 已經廣泛存在于訓練數據中。當你讓 Claude 實現getServerSideProps或解釋useRouter的工作原理時，它不會出現幻覺。它完全了解 Next 的運行機制。

Next.js 擁有完備的測試套件，其代碼倉庫中包含數千個覆蓋所有功能與邊界場景的端到端測試。我們直接從這些測試套件中移植了測試用例（你可以在代碼中看到相關標注），這為我們提供了可機械驗證的規范。

Vite 是非常優秀的基礎框架。它解決了前端工具鏈的核心難點：快速熱更新、原生 ESM、清晰的插件 API 以及生產構建。我們無需從零開發打包器，只需要讓它適配 Next.js 的使用方式即可。@vitejs/plugin-rsc目前仍處于早期階段，但它已經為我們提供了 React Server Components 支持，不必從頭實現 RSC。

模型能力終于跟上了。就在幾個月前，我們還認為這是不可能實現的。早期的模型無法在如此規模的代碼庫中保持邏輯連貫，而新一代模型能夠理解完整架構、推理模塊間的交互，并足夠穩定地生成正確代碼，從而保證開發節奏。有時我看到它深入 Next、Vite 和 React 的內部機制去定位問題。最先進的模型表現令人驚嘆，而且顯然還在持續進步。

所有這些條件必須同時具備：目標 API 文檔完善、測試套件全面、底層構建工具堅實可靠，再加上能夠真正處理復雜邏輯的模型。缺少任何一環，效果都會大打折扣。

我們是如何實現的

幾乎 vinext 的每一行代碼都是由 AI 編寫的。更重要的是：每一行代碼都具備了與人工編寫代碼相同的質量標準。項目擁有 1700+ 個 Vitest 測試、380 個 Playwright E2E 測試，通過了 tsgo 完整的 TypeScript 類型檢查與 oxlint 代碼檢查，持續集成會針對每個 PR 執行所有檢查。建立一套完善的質量保障機制是讓 AI 在代碼庫中高效發揮作用的關鍵。

整個過程從一份規劃開始。我花了數小時在 OpenCode 里與 Claude 反復溝通，明確架構：要構建什么、按什么順序推進、使用哪些抽象層。這份規劃成了整個工作的北極星。從那之后，工作流程就變得非常清晰：

1. 定義任務（“實現包含usePathname、useSearchParams、useRouter的next/navigation墊片”）。

2. 讓 AI 來編寫實現代碼與測試用例。

3. 運行測試套件。

4. 如果測試通過就合并，不通過就將錯誤信息交給 AI 進行迭代修復。

5. 重復這一過程。

我們還為代碼審查設置了 AI 智能體。PR 提交后，智能體會自動執行審查；審查意見返回后，另一個智能體會處理這些意見。整個反饋流程基本實現了自動化。

它并非每次都能完美運行。有些 PR 本身就是錯誤的。AI 常會“自信”地實現一些看似正確、卻與 Next.js 實際行為不符的邏輯。我必須定期糾正方向。架構決策、優先級排序、判斷 AI 何時走入死胡同——這些都由我負責。當你給 AI 清晰的方向、充足的上下文和完善的約束時，它的效率會非常高。但最終，依然需要人類來掌舵。

對于瀏覽器級別的測試，我使用 agent-browser 來驗證實際渲染輸出、客戶端導航與 hydration 行為。單元測試會遺漏許多細微的瀏覽器問題，而這套方案能將捕獲到它們。

整個項目期間，我們在 OpenCode 中運行了 800 多個會話，總成本約為 1100 美元的 Claude API Token 費用。

這對軟件來說意味著什么

為什么我們的技術棧會有這么多層？這個項目迫使我深入思考這個問題，并思考 AI 會如何影響答案。

軟件中的大多數抽象都是為了給人類提供輔助。我們無法在腦中容納整個系統，因此通過構建層次來管理復雜度。每一層都能讓下一層開發者的工作更輕松。這也是你最終會看到框架之上再套框架、出現各種封裝庫、以及成千上萬行膠水代碼的原因。

AI 沒有這樣的限制。它可以在上下文里容納整個系統，并直接編寫代碼。它不需要借助中間框架來維持結構，只需要一份規范和一個構建基礎。

目前尚不清楚哪些抽象是真正基礎的，哪些只是人類認知的拐杖。這條界限在未來幾年將會大幅改變。而 vinext 就是一個例證：我們只提供了一份 API 契約、一個構建工具和一個 AI 模型，剩下的中間層全部由 AI 編寫，無需額外的中間框架。我們相信這種模式會在大量軟件中復現，多年來搭建的層層封裝并不會全部保留下來。

試試看

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 deploy  # Ship to Cloudflare Workers

源代碼位于 github.com/cloudflare/vinext，歡迎提交 Issue、PR 與反饋。

https://blog.cloudflare.com/vinext/

聲明：本文由 InfoQ 翻譯，未經許可禁止轉載。