一个周末 + 1100 美元，干完 5 人 6 个月的活：Cloudflare 用 AI“复刻”Next.js，已跑进生产环境

在 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 能够处理大量基础工作，但仍需要经验丰富的医生进行决策和引导。

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 件事”，然后让它持续执行。它偶尔会卡住，但整体表现相当不错。

分析还显示，我的工作模式是“哑铃型”：要么是几分钟的短操作，要么是持续一到两小时的深度工作。这与我的实际节奏一致——我有两个孩子，开发是在生活间隙中进行的，例如带孩子去公园玩，回家之后赶紧跑回电脑前，踢一脚模型，然后再回去陪孩子。

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： 这也让我在思考：未来软件开发的激励机制会发生什么变化？抽象层的意义是否会改变？我没有答案，但可以确定的是，这条边界一定会发生变化。

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 进行咨询。