一個周末 + 1100 美元，干完 5 人 6 個月的活：Cloudflare 用 AI“復刻”Next.js，已跑進生產環境

編譯｜宇琪

策劃 | Tina

編輯 | 蔡芳芳

在 AI Coding 狂飆突進的 2026 年，一個原本聽上去近乎荒誕的問題，突然變得現實起來：如果工程師不再一行一行手寫代碼，復雜框架還能不能被“重做”一遍？

Cloudflare Workers 工程負責人 Steve Faulkner，給出了一個足夠激進的回答。他借助 AI，在一個周末里“復刻”了整個 Next.js，并把它遷移到了 Vite 之上，做出了 Vinext。整個項目的 Token 成本僅約 1100 美元，但換來的結果卻相當驚人：它已經能作為 Next.js 的即插即用替代方案，一條命令即可部署到 Cloudflare Workers；在初步基準測試中，生產環境應用的構建速度最高提升 4 倍，客戶端打包體積最高縮小 57%；更關鍵的是，它已經被客戶正式跑進了生產環境。

這也是為什么，Vinext 會迅速引爆開發者社區。真正讓人震動的，并不只是“AI 又寫了多少代碼”，而是它開始逼近一個過去默認只能靠資深工程團隊、長周期投入才能完成的任務：重構一個擁有數百萬用戶的主流前端框架。更微妙的是，這個項目瞄準的還不是邊緣玩具，而是 Next.js 這樣一個長期深度綁定 Node.js、Vercel 與定制化構建鏈路的復雜系統。換句話說，這不只是一次 AI Coding 炫技，而是在試圖回答一個更現實的問題：當現有框架在跨運行時、跨平臺部署上越來越別扭時，AI 能不能直接把它“重寫一遍”？

近日，Steve Faulkner 在播客節目中，與主持人 Wes Bos 和 Scott Tolinski 詳細講述了這個 slop fork 項目的來龍去脈。他們還圍繞 AI 編碼工作流、Agent 瀏覽器、代碼質量、測試驅動開發，以及 AI 優先時代的軟件工具究竟應該長成什么樣，展開了深入討論。基于該播客視頻，InfoQ 對內容進行了整理與部分刪改。

核心觀點如下：

• 人類依然需要負責制定方向，AI 只是執行和加速的工具；

• 目標不是寫“優雅代碼”，而是實現兼容性、通過測試，并驗證這條路徑是否可行；

• 一個理想的 AI 原生語言，可能是兼具 Rust 的約束能力與 Go 的簡潔風格；

• Agent 的開發體驗與人類不同，它不需要界面美觀，但必須具備清晰結構，使其能夠理解操作路徑，這種“面向 agent 的 DX”將成為未來的重要方向；

• 醫療很可能是下一個重點行業，其發展路徑可能類似編程領域：AI 能夠處理大量基礎工作，但仍需要經驗豐富的醫生進行決策和引導。

“slop fork”

Wes：請先簡單介紹一下你自己以及你的工作內容。

Steve：我目前是 Cloudflare Workers 的工程總監，整體負責 Workers 相關業務，包括 agents 產品、容器以及 Wrangler CLI 等項目，團隊規模大約在 80 人左右。我加入 Cloudflare 已有幾年時間。需要澄清的是，我的日常工作并不是編寫代碼。很多人看了這個項目和博客后，稱我為“100 倍 工程師”，但我認為更準確的說法應該是“100 倍 工程經理”。

Scott：在當下 AI 的發展階段，這是不是正成為趨勢？真正擁有“超能力”的，其實是這些“100 倍工程經理”？

Steve：確實如此。我認為 AI 本質上是一種放大器。如果你清楚自己要做什么，它可以幫助你更快、更好地完成任務；但如果方向本身就是錯誤的，它同樣會放大這種錯誤。因此，人類依然需要負責制定方向，AI 只是執行和加速的工具。

Scott：最近大家在討論一個詞——“slop fork”，因為這次是用 AI 寫的代碼。你怎么看這個說法？

Steve：我覺得這個說法很有趣，也已經接受了，甚至我現在會說“我要去 slop fork 某個東西”。有人還開玩笑說：“我們應該 slop fork Kubernetes，然后用 Rust 重寫。”我覺得類似“Vibe Coding”或“Clanker”等新詞不斷涌現，我更多是以一種輕松的態度看待，并不會覺得被冒犯。（注：“slop fork”可直譯為“垃圾分支”，但在此處帶有自嘲與網絡梗色彩，雙關地表達用 AI“糊弄式”地把一個現有項目“叉走”并改寫。）

Wes：為什么你要 fork Next.js 并讓它運行在 Vite 上？

Steve：一年前，我們在思考如何更好地支持 Next.js 在 Cloudflare 上運行。Next.js 在托管方面確實存在一些問題，尤其是在非 Vercel 或非 Node 的運行環境中。一些功能對 Node 和 Vercel 有較強依賴，因此雖然理論上可以部署在很多地方，但在邊界場景下會出現兼容性問題。

當時我們曾考慮自行實現一套兼容 Next API 的編譯器，但評估后發現這需要約 5 名工程師投入 6 個月時間，成本過高，不現實。于是我們轉向了 OpenNext 項目，并且至今仍在持續投入。ps：如果你需要穩定、經過生產驗證的方案，應該優先使用 OpenNext。后來我們還嘗試過一次，讓一位實習生實現 pages router，但也沒有成功。

真正的轉折點出現在去年 12 月到今年 1 月，模型能力突然有了質的提升，一切才發生變化。當時我主要是用 AI 做管理相關的工作，比如總結會議紀要、跟蹤 Jira、匯總內部信息等。我逐漸意識到，這些模型已經足夠強大，于是開始嘗試寫一些代碼項目。我注意到 Next.js 有一套非常完善的測試體系，于是想到：能不能直接用測試來驅動實現？于是就在一個周五下午開始了這個項目。

我先花了幾個小時做規劃，然后和模型反復交互。第二天早上，我在 app router 的 demo 里測試時發現，它居然已經能跑起來了。雖然還不完美，但已經足以說明這條路是可行的。

Wes：如果讓你從零開始，將 Next.js 實現到 Vite 上，你會如何制定計劃？這個過程有多少依賴你對軟件工程本身的理解？

Steve：我確實具備一定優勢，因為我熟悉 Next.js，同時團隊內部也在其他框架中使用 Vite，因此我清楚整體架構形態。制定初始方案大約花費數小時，并通過 OpenCode 與模型不斷迭代。

我大量使用語音轉文本工具進行“思維傾倒”，并不依賴復雜的 prompt 技巧，而是不斷修正模型輸出，例如明確指出某些建議不在項目范圍內，如移除 React。這個過程更像人與 AI 的持續協作，而非一次性指令。

Scott：在規劃階段，你主要通過 Markdown 來組織信息嗎？有沒有特別有效的方法？

Steve：全部使用 Markdown。目前來看，這是最有效的工具，盡管我認為它只是階段性最優解。未來兩到三年內，我們可能會看到更原生適配 LLM 的工作方式。

我維護了一個主計劃文檔，以及一個專門用于測試的文檔。Next.js 的測試集非常龐大（約 8000 個測試），其中很多并不是我第一階段需要支持的功能。因此，我花了很多時間去篩選和指導模型選擇哪些測試。一個關鍵的突破是：我沒有嘗試直接運行原始測試套件，而是讓模型逐個“遷移”測試。這意味著把測試遷移到自己的測試環境中，并逐步實現對應功能，同時用文檔追蹤每一個測試的進度。

Wes：所謂“遷移測試”，是指轉移到 Vitest，還是同時實現對應功能？

Steve：兩者兼而有之。一方面將測試遷移到 Vitest 和 Playwright，另一方面實現對應功能邏輯。

Wes：這個過程是持續交互，還是可以長時間自動運行？

Steve：我曾讓 OpenCode 分析整個過程。結果顯示，我的 token 使用峰值出現在凌晨 3 點，但我那時候肯定在睡覺，說明我確實在夜間安排了大量任務。我的方式不是寫復雜的自動循環，而是給它一個任務文檔，比如“完成這 10 件事”，然后讓它持續執行。它偶爾會卡住，但整體表現相當不錯。

分析還顯示，我的工作模式是“啞鈴型”：要么是幾分鐘的短操作，要么是持續一到兩小時的深度工作。這與我的實際節奏一致——我有兩個孩子，開發是在生活間隙中進行的，例如帶孩子去公園玩，回家之后趕緊跑回電腦前，踢一腳模型，然后再回去陪孩子。

尋找可靠的 AI 工作流

Scott：你剛才提到這些數據，是怎么統計的？

Steve：都是從 OpenCode 的會話數據里來的。它會把所有信息存儲在 SQLite 里，我直接讓模型去分析這些數據。

Scott：你使用的是哪個模型？

Steve：主要使用 Opus 4.5 和 4.6，約 99% 的代碼由其生成，后期我開始更多做代碼評審，有時也會用 Codex 作為輔助。

Scott：你覺得不同模型之間差別大嗎？

Steve：很多人說“Opus 寫代碼、Codex 做評審”，我一開始也這么做，但后來發現差別沒有想象中那么大。很多時候讓同一個模型自我評審就足夠了。我甚至會讓它進入一個循環：先評審代碼，再修復問題，然后再評審自己，如此迭代兩三次，直到沒有明顯問題為止。

Wes：你的 OpenCode 實際配置是怎樣的？是否使用插件、Agent 或 MCP？——你有沒有像那些整天調參數的人一樣瘋狂調試？

Steve：我就是那種“調參黨”。我最近開始玩 pi，簡直是一通狂調。不過我這次項目的整體配置非常簡潔。我主要使用桌面應用和 VS Code，很少使用終端界面，MCP 或復雜 agent 也沒用多少。不過我們現在確實有一個針對 Vinext 的 agent，用來處理倉庫里的一些審查工作。我們發現，給 agent 豐富的上下文，它會更好用。那個 agent 的 MD 文件甚至就是它在項目開始時自己生成的。過程中我會告訴它：記得更新 agent.md，確保里面需要的東西都有。

倒是有兩個 MCP 服務用了比不用好：一個是 Context7，提供開源庫索引，另一個是 Exa 搜索。這兩者大約帶來 20% 的體驗提升，但也不是那種“質變”級別的提升。

Wes：在測試過程中，AI 是否會自動操作瀏覽器？

Steve：會的。我在博客里提到過一個工具——Agent Browser，本質上是對 Playwright 的封裝，提供了一個很好用的 CLI 接口。我在這個項目中用得很多。

我會讓它同時操作兩個環境：一個是生產環境中的 app router playground，另一個是 Vinext 的實現版本，然后給它指令去復現問題、對比行為、定位差異。這在調試過程中非常有幫助，比如有一次我說“滾動不夠流暢”，這種描述其實很模糊，但模型竟然能自己識別問題，并給出解決方案，這讓我非常震驚。

Scott：我用 Agent Browser 時遇到一個問題：Opus 模型經常處理不了截圖，說“截圖太大”，然后整個 session 就崩掉了。你有遇到嗎？

Steve：遇到過，而且確實很嚴重。在 OpenCode 里，這種情況會直接污染整個會話，只能重開。問題在于，有些會話本身非常有價值，所以我有時候會讓模型把當前上下文壓縮成一個 markdown 文件保存下來，方便之后恢復或復用。

Scott：你會密切監控上下文嗎？比如使用子 agent 來管理？

Steve：沒有特別系統地做這件事，也確實不是完美的。有時候上下文壓縮后，模型會“跑偏”，需要重新引導。不過我注意到，OpenCode 在這方面近期已有明顯改進。

此外，我還維護了一個名為 discoveries.md 的文件，用于記錄過程中發現的各種問題，例如某些 React 或 Webpack 版本和 Vite 的兼容問題。每當遇到問題，就記錄下來，這樣模型可以基于這些“已知結論”繼續推進，而不是反復踩坑。

Wes：我最近在一個項目中也遇到類似問題：模型不斷重復同一錯誤，例如錯誤地將服務端代碼引入客戶端模塊，進而陷入循環修復。我最終只能將解決方案寫入 agents.md 或外部文檔，以強制約束其行為。

Steve：基于這個現象，我的一個重要體會是：agent 對反饋（feedback）的響應能力極強。相比之下，人類并不擅長快速吸收并迭代反饋。如果你告訴一個人“這不對，重寫一遍”，效果未必明顯，但對模型來說，提供新的上下文后，它往往能顯著改進。

很多人剛接觸 AI 時，會因為第一次結果不好就否定它。但實際上，只要多迭代幾輪，到第四五次時，它往往就能做對。這種“快速糾偏能力”是關鍵。

Scott：確實，有些人只試一次就覺得工具不行。

Steve：這是因為程序員的思維習慣。傳統程序是確定性的，如果代碼錯了，每次運行都會錯。但 LLM 處在一個“非確定性”的中間地帶，這種不確定性反而是一種特性。它可能第一次輸出很糟糕，但你可以糾正它，它下一次就不會再犯同樣的錯誤。當然，這也意味著風險。比如它可能生成錯誤的 Terraform 配置，甚至破壞生產環境。但如果你及時糾正，它大概率不會再犯。我自己也不是 AI 的極端樂觀主義者，我既對它的潛力感到興奮，也對其中的風險感到擔憂。

Wes：AI 生成的代碼質量整體表現如何？是否存在明顯“跑偏”的情況？

Steve：當然有。我每次看代碼時，其實都不太滿意。代碼通常比較冗長，也不是我會寫的風格。這個項目讓我必須接受一點：目標不是寫“優雅代碼”，而是實現兼容性、通過測試，并驗證這條路徑是否可行。這是一個實驗，核心是探索 AI 的邊界，而不是追求完美工程實踐。如果代碼質量以后成為問題，可以再優化。

舉個例子，目前 Vinext 的一部分代碼是通過模板字符串生成的，也就是說代碼是“拼接出來的”，沒有類型檢查、沒有 lint，只能通過端到端測試驗證。這種方式我其實很不喜歡，也不利于維護。所以現在我們正在逐步重構，把這些生成代碼拆出來，變成可類型檢查、可 lint 的正常代碼結構，這也是一個從“AI 生成”到“工程化”的回收過程。

Scott：我最近在構建 AI 工作流時，會為每個功能設計多個處理階段，例如 lint、樣式、UI、可訪問性等，但感覺成本很高。

Steve：這正是我認為“約束”（guardrails）重要的原因。測試、lint、格式化這些都是必要的約束，但同時也不能完全限制模型。理想的方式是：大部分時間把任務拆成小塊，并加上明確約束；但在某些時刻，也要允許模型“自由發揮”，比如讓它重新設計某個模塊，提出不同思路。

Scott：我也會定期讓模型進行審計分析，從中獲得一些我自己未曾考慮到的優化點。

Wes：像這種用 AI 寫出來的系統，安全方面怎么保證？我聽說 Vercel 甚至把漏洞提交到了 Cloudflare 的漏洞賞金項目里，這是真的嗎？他們拿到獎金了嗎？

Steve：相關流程仍在進行中。我們確實收到了包括 Vercel 在內的多方安全報告，我對此非常感謝。老實說，有人將此舉解讀為刻意找茬，但我認為，該項目僅發布一周，存在安全漏洞是十分正常的情況。我反而希望大家多提交問題，這樣我們可以把這些漏洞反饋給 AI，讓它參與修復。

整個過程其實非常有意思——我們正在用 AI 來處理 AI 產生的問題。AI 在幫我們分類漏洞、修復漏洞、驗證漏洞，甚至參與與安全研究者的溝通。我們還在做一些暫時不能公開的工作，比如構建自己的 AI agent，用來主動發現安全漏洞。

我們看到一些外部提交的漏洞后，意識到這些問題其實具有某種模式，于是就嘗試用 AI 自己去找類似問題。結果不僅找到了當前項目的漏洞，還能在其他項目中發現問題，這讓我們意識到這個方向非常有潛力。目前我們把這當作一個學習機會：如何用 AI 構建一整套安全體系。從現在的實踐來看，AI 在安全領域同樣表現得相當不錯。

項目上線約兩周以來，我們已發布 26 至 27 個版本，持續進行漏洞修復與項目維護。我也在思考如何推動該項目從實驗階段邁向更穩定的階段，例如移除實驗標簽，將其調整為穩定版或測試版，讓用戶能夠放心地將其應用于生產環境。

Wes：最終目標是把它變成一個可以正式使用的產品？

Steve：其實已經有人在用了。我們會明確告訴用戶它的限制和風險。很多用戶對 Next.js 的使用其實比較簡單，比如主要是靜態頁面，只有少量 API 或部分動態頁面。在這種“功能使用范圍較窄”的場景下，目前體驗其實已經不錯了。

Wes：從根本上來說，是把整個框架遷移過來更合理，還是干脆讓 AI 幫你遷移到另一個框架？

Steve：我一直對客戶說：如果你喜歡 Next.js，那這個方案很適合你；但如果你本身就不喜歡 Next.js，那完全沒必要折騰，花 10 美元的 token，就可以遷移到其他框架。現在的選擇非常多，比如 Astro、TanStack、SolidJS 等等。借助 AI，只要你有一套完善的端到端測試，遷移成本已經變得非常低。

我做這個項目并不是因為我特別熱愛 Next.js，而是因為我想探索 AI 的能力邊界。如果你不想用 Next.js，完全可以讓 AI 幫你換掉它。

Wes：我最近也用 AI 將一個 Express 項目遷移到 Hono，幾乎是自動完成的，門檻真的變低了。

Steve：這也讓我在思考：未來軟件開發的激勵機制會發生什么變化？抽象層的意義是否會改變？我沒有答案，但可以確定的是，這條邊界一定會發生變化。

未來的 AI 原生編程語言

Scott：未來是否會出現專為 AI 設計的框架或編程語言？

Steve：我認為一定會。甚至不僅是框架，還可能出現“AI 優先”的編程語言。當然，這些新技術一開始會面臨“訓練數據缺失”的問題——模型不知道怎么用它們。但我不認為這是無法解決的。未來一定會有新的方法，把關鍵知識注入模型，使 AI 能夠快速掌握新語言或新框架。

Wes：“AI 原生的編程語言”會是什么樣？

Steve：我覺得核心還是“約束”，因此，這樣的語言很可能是強類型的。如果觀察現有語言，Rust 雖然較為冗長，但擁有完善的安全機制，甚至有一種說法是“只要能編譯通過，就基本可以運行”。但與此同時，我認為還需要類似 Go 的簡潔性。Go 的設計理念是“少而精”，通常只有一兩種實現方式。因此，一個理想的 AI 原生語言，可能是兼具 Rust 的約束能力與 Go 的簡潔風格。

Wes：那語法會更偏向嚴格規范，還是類似自然語言？

Steve：我傾向于前者。為了提供清晰的約束邊界，語法仍然需要是嚴格且有限的。當然，我個人非常喜歡 TypeScript，如果它在 AI 時代被替代，我會感到遺憾。

Wes：在你的 OpenCode 環境中，是否使用了 TypeScript 的 LSP？

Steve：它是默認啟用的，因此一直在后臺運行。我不確定它是否帶來了顯著提升，但也沒有證據表明它無效。不過，LSP 有時會出現不同步的問題，例如提示錯誤，但實際類型檢查已經通過，這類情況會導致模型短暫困惑。

Wes：如果未來類型檢查可以在極短時間內完成，是否會進一步提升 AI 效率？

Steve：我們已經在使用一些高性能工具，例如 TypeScript Go、Oxlint、OX Format 以及 Vitest。我在項目中優先選擇這些高性能工具，因為快速反饋循環至關重要。如果每次編譯都要幾秒鐘，那整個效率會被嚴重拖慢。

Scott：近年來，Cloudflare 在開發者體驗（DX）方面似乎有明顯提升，這是否是有意為之？

Steve：這是明確的戰略方向。我加入 Cloudflare 時，核心目標之一就是提升開發者體驗。我們的重點在于引入具備良好產品判斷力的人才，并賦予他們充分空間去優化體驗。

作為管理者，我的職責更像是“決定在哪里建設消防站”，而不是親自“滅火”。這意味著我要從更長期的視角去看，比如兩年后團隊是否能產出更好的產品。目前來看，這些投入已經開始產生回報，例如新的設計工程團隊正在持續優化控制臺界面。雖然仍有改進空間，但相比幾年前已經有顯著提升。

我們還有許多尚未公開的項目，正在從多個層面推進改進。一方面是持續優化現有產品，另一方面也在重新思考平臺的整體形態，不僅要適合人類開發者，也要適配 agent。

Agent 的開發體驗與人類不同，它不需要界面美觀，但必須具備清晰結構，使其能夠理解操作路徑，這種“面向 agent 的 DX”將成為未來的重要方向。

Wes：在結束前，你還有什么想補充的嗎？

Steve：我想從一個更宏觀的角度來說：我對這一切既興奮，又不安。我們正處在一個可能是巨大技術變革的時代，就像印刷術、蒸汽機那樣的革命性節點。

如果要類比，我們這一代人經歷過的最接近的可能是移動互聯網，甚至是互聯網本身。但即便是互聯網，它的普及也花了很長時間，需要鋪設基礎設施。而現在不一樣，一項新能力發布后，幾乎 24 小時內，全世界的人都能用到。

所以，不只是這場變革的“規模”巨大，它的“速度”也被極度壓縮了。有時候我會覺得自己已經走在很前面，但有時候看到別人做的事情，又會意識到自己其實還只是剛剛起步。

Wes：你認為下一個被 AI 深刻改變的行業會是哪些？

Steve：醫療很可能是下一個重點行業，其發展路徑可能類似編程領域：AI 能夠處理大量基礎工作，但仍需要經驗豐富的醫生進行決策和引導。

實際上，一些醫院已經在使用 AI，例如語音轉錄等技術。雖然由于監管嚴格，全面普及還需要時間，但我認為它最終會徹底改變我們理解和處理病人信息的方式。

Wes：例如將可穿戴設備數據與大規模病例數據結合，確實可能帶來新的突破。

Steve：作為技術從業者，我們需要盡力引導技術向有益方向發展。正如印刷術既推動文明進步，也引發沖突一樣，AI 同樣會帶來正反兩方面影響。我們的責任是盡可能擴大其正面價值。

訪談視頻原鏈接：

https://www.youtube.com/watch?v=h39oZb2-7Xo&t=1s

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

QCon 全球軟件開發大會·2026 北京站將于 4 月 16 日 -18 日正式舉辦。本屆大會以“Agentic AI 時代的軟件工程重塑”為主題，聚焦 100+ 重磅議題，匯聚來自阿里、騰訊、字節跳動、小米、百度等一線科技企業與創新團隊的技術專家，圍繞 AI 工程化、系統架構與研發模式演進展開深入探討。更多詳情可掃碼或聯系票務經理 18514549229 進行咨詢。