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

如果你对 AI 全栈开发、Tiptap 富文本编辑器定制或 DocFlow 项目的完整技术方案感兴趣，欢迎加我微信 yunmz777 进行私聊咨询，获取详细的技术分享和最佳实践。 很多人第一次打开 OpenClaw，会下意识把它当成"接在微信或 Slack 上的聊天机器人"。这种理解只对了一半。从架构上看，OpenClaw 更像一个网关：它站在你和一堆能力之间，负责路由、鉴权、记忆和工具调用。真正决定你能做多少事的，不是对话框有多好看，而是背后接了多少"身体"——也就是 Skills。

大语言模型很像一个装在罐子里的超级大脑，读得懂天下书，推得了复杂逻辑，但它没有手。它没法自己点按钮、没法直接读你电脑里的真实文件、也没法"学会"一套新工作流，除非你每次都把那套流程写成十几页的说明塞进提示词。Skills 就是给这个大脑配上的手脚和工具箱。你通过 OpenClaw 发一句指令，网关把请求转给模型，模型按当前加载的 Skill 决定调用哪类工具、走哪套流程，最后把结果经由同一网关回到你的聊天窗口。所以，与其说你在和 OpenClaw 聊天，不如说你在通过它调度一个"大脑 + 一堆可插拔能力"的联合体。

下面这张图概括了这条链路：从你的一句话，到网关、模型与 Skills 的协作，再到结果回到聊天窗口。

上图从左到右依次是你发指令、OpenClaw 网关做路由与鉴权、大模型负责推理、Skills 提供手脚与工具、执行后结果再经网关回到聊天窗口；整条链路就是"一句话调度大脑与能力"。

本文会先澄清"提示词膨胀"为什么会让很多人吃亏，再说明 Skill 是什么、为什么要用 SkillGuard 管好环境安全，最后按类别梳理一批值得优先安装的 Skills，并附上各类别的示意配图 prompt，方便你从"聊天思维"切换到"基础设施思维"。

提示词膨胀：为什么你还在吃亏

如果还没用上 Skill，大概率会落在两种处境之一。

第一种是提示词工程的无底洞。为了让人工智能好好干一次活，你得花十几二十分钟写"完美提示词"，把背景、约束、输出格式、反例全塞进去。一次两次还行，任务一换又要重写，而且同一个任务下次还想复用时，又得翻聊天记录或文档把那一大段再贴一遍。成本高、难复用、还容易忘。

第二种是上下文超载。为了"让 AI 更懂我"，很多人会在系统提示里塞进大量个性设定、操作指令和禁忌清单。结果模型还没开始干活，上下文窗口已经占掉一大截，轻则推理变慢、容易截断，重则直接爆掉，顺便把 API 额度烧光。更麻烦的是，这些设定和任务强绑定在一起，换一个任务又得改一版提示，维护成本越来越高。

Skill 要解决的就是这两类问题。它把"怎么用某类工具、走某套流程"打包成独立文件（或指令集），只在需要时加载。OpenClaw 和你用的 Agent 只加载当前任务需要的"战术手册"，其余时间保持轻量。这样 Agent 能保持敏锐、成本可控、结果也更容易复现。你不是在跟一个越聊越臃肿的聊天窗口较劲，而是在维护一套可组合的能力层。

Skill 是什么，以及为什么要用 SkillGuard

从技术上说，一个 Skill 就是一个打包好的指令集，通常以文件形式存在，用来告诉 Agent 如何使用特定工具或执行某类复杂工作流。

区别在于指令的粒度。不写 Skill 时，你只能说"请帮我看看这段代码有没有错误"，模型只能根据当次对话里的零散信息自由发挥。有了 Skill，你可以说"用 debug-pro 这个 Skill 对我的仓库做一次全面扫描，检查日志，然后在终端里按规范修复语法错误"。后者是"指名用哪套能力、按什么流程做"，前者是"随便你怎么做"。前者依赖每次的提示词质量，后者依赖事先定义好的能力包，可复用、可审计、可迭代。

Skill 来源一多，风险就来了。ClawHub 等技能市场上有大量第三方 Skill，质量参差不齐，甚至混入恶意代码（窃取凭证、反向 shell、挖矿等），OpenClaw 的架构又给了 Agent 系统级权限和对外通信能力，一旦装上恶意 Skill，影响会很大。所以官方和社区都强调用 SkillGuard 一类机制做监控：在真正执行或下载 Skill 前，做来源校验、行为扫描或沙箱隔离，在"环境安全"和"持续扩展能力"之间取得平衡。如果你打算认真把 OpenClaw 当基础设施用，建议从第一天就打开 SkillGuard，养成"先验再装"的习惯。

从聊天思维到基础设施思维

大多数人会淹没在二十多万个可用 Skill 里，不知道从哪装起。真正能跑赢一票"只会聊天"用户的，往往是那些先把基础能力打牢的人。下面按类别整理一批值得优先考虑的 Skills，并说明它们各自解决什么问题、适合谁用；每一类下面都附了一张"这类在做什么"的示意配图 prompt，你可以丢进文生图模型生成插图，再替换文中的代码块。你可以按自己的角色（独立开发者、内容创作者、做增长的人等）勾选几条主线，再逐步扩展。

基础 Skills：给 AI 装上手脚

如果感觉 OpenClaw"也就那样"，多半不是模型不够强，而是管道太薄。把这层当成"操作系统"来配，而不是聊天窗口，会顺很多。下面六个是很多人会优先装的基础能力。

• find-skills：技能市场里 Skill 数量巨大，手动搜既慢又容易漏。这个 Skill 让 Agent 能按任务描述自动发现、筛选合适的 Skill，相当于导航员。
• skill-creator：把你自己的工作流和"氛围编程"逻辑打包成可复用 Skill，相当于规模化复制你的习惯和判断，让 AI 反复按同一套标准执行。
• mcp-builder：通过模型上下文协议（MCP）把 AI 接到私人数据和外部工具上，是 2026 年很多人会装的"桥梁"类 Skill，没有它，很多高级能力接不进来。
• using-superpowers：强制 Agent 先搞清楚自己有哪些高级能力、在什么场景下用哪一项，而不是凭感觉瞎试，相当于优化器。
• subagent-driven-development：把大任务拆成子任务，委派给子 Agent 执行并做结果审核，主 Agent 专注规划和验收，适合不想在一个提示词里搞定所有事的场景。
• agent-tools：给 Agent 一整套常用小工具，处理那些模型默认不擅长、但又很常见的琐事，相当于数字瑞士军刀。

适合谁用：独立创始人、独立开发者，以及不想"手把手教 AI 走每一步"的人。

下面这张图代表"基础 Skills"在做什么：给 AI 装上导航、桥梁、优化器、委派与工具箱。

上图概括了基础类 Skills 的五个角色：找 Skill、接数据、优化能力认知、委派子任务、以及日常小工具，合起来就是让 AI 从"只会聊"变成"能动手"。

策略与创作 Skills：从打字员到战略伙伴

如果 Agent 的输出总像机器人在填废话，多半缺的是"先想清楚再写"的环节。下面这类 Skill 会引入反思、大纲和策略，把 OpenClaw 从快速打字员变成能提前验证逻辑的伙伴。

• brainstorming：从一个关键词展开多种角度和"如果……会怎样"的场景，避免只停留在第一个听起来很"AI"的念头。
• copywriting：不只生成文案，还管结构、节奏和语气，减少对老套模板的依赖。
• systematic-debugging：一套可复用的排查框架，既能用来查代码，也能用来分析项目计划或异常情况。
• writing-plans：动笔前先建大纲和内容策略，避免长文写飞。
• content-strategy：选题和内容日历规划，让发布有节奏、有品牌感。
• executing-plans：把高层计划拆成可执行的多步任务，由 Agent 按顺序完成。
• marketing-ideas：给一个功能或时间节点，用成熟营销框架产出传播点和活动概念。
• copy-editing：在纠错之外，顺带打磨语气和逻辑，尽量保留你个人的表达习惯。
• social-content：把同一套核心信息改写成适合不同平台（如 X、TikTok、小红书）的版本，照顾各处的阅读习惯。
• reflection：在流程里加入自检和纠错环节，让 Agent 能回顾自己的输出、总结经验、在过程中修正错误。

适合谁用：做内容、做个人品牌、或者想从"对着空白页发愁"变成"稳定产出但不丢灵魂"的人。

下面这张图代表"策略与创作 Skills"在做什么：从想法到大纲、文案、多平台分发与反思。

上图从左到右是创意展开、大纲与计划、文案打磨、多平台分发、按计划执行和反思自检，对应"先想清楚再写、写完后还能改"的一整条创作链。

工程 Skills：用氛围编程的速度，达到生产级质量

氛围编程已经是 2026 年的常态，但光靠对话很难保证生产级可维护性和测试覆盖。下面这些 Skill 把工程最佳实践编码进去，让 Agent 在写代码时更贴近真实团队的标准。

• vercel-react-best-practices、vercel-composition-patterns：React 与 Vercel 生态下的前端规范和组件组合方式。
• remotion-best-practices：用代码驱动视频与动画，适合程序化营销素材和产品演示。
• agent-browser、browser-use：让 Agent 能浏览网页、填表、抓取数据或做自动化测试，相当于给 AI 装上"眼睛"和"手"。
• vercel-react-native-skills：移动端跨平台开发时的 React Native 最佳实践。
• supabase-postgres-best-practices：数据库设计与 PostgreSQL 使用上的建议。
• next-best-practices：Next.js 的架构与路由等最新模式。
• webapp-testing、test-driven-development：测试驱动与自动化测试，减少回归和边缘问题。
• requesting-code-review：在发布前让 Agent 自审代码，查找潜在漏洞和坏味道。

适合谁用：自己做产品、用氛围编程但希望交付物更稳、更可维护的创始人或开发者。

下面这张图代表"工程 Skills"在做什么：从代码规范、测试、到浏览器自动化与发布前审查。

上图概括了工程类 Skills 覆盖的几块：前端与全栈规范、数据库、测试与 TDD、浏览器自动化、视频与移动端，以及发布前的代码自审，对应"用对话的速度写出可维护的代码"。

设计 Skills：不碰 Figma 也能要专业审美

不需要自己会画图，也能让 Agent 产出符合设计原则的界面和素材。

• web-design-guidelines、frontend-design：按网格、色板等原则审视前端实现，避免"通用 AI 丑"。
• ui-ux-pro-max：跨技术栈的设计与无障碍建议。
• canvas-design：把想法转成 PNG、PDF 等视觉素材。
• tailwind-design-system：用 Tailwind 令牌和无障碍模式搭可复用的 UI 库。
• content-visualizer、infographic-pro：根据内容推荐版式、生成信息图或封面图。
• ai-image-generation：统一调用多模型（如 DALL·E、Imagen、Gemini）做原型和创意图。

适合谁用：做落地页、做高保真内容、希望产品"长得像样"但暂时不打算雇设计团队的开发者或创始人。

下面这张图代表"设计 Skills"在做什么：从网格与色板、到信息图与多模型出图。

上图从左到右是设计原则与色板、前端与组件库、UX 与无障碍、插画与素材、信息图与封面推荐，以及多模型统一出图，对应"不自己画图也能要专业视觉"。

增长 Skills：把 OpenClaw 当增长引擎

产品做出来只是前半段，卖不出去等于没存在感。这类 Skill 覆盖从 SEO、转化到心理诱因的链条。

• Larry：结合图像生成和病毒式钩子，自动化 TikTok 等平台的图文内容。
• audit-website、seo-audit：网站健康与 SEO 缺口扫描，减少盲目猜测。
• marketing-psychology：把社会认同、稀缺性等原理用到产品钩子和文案里。
• programmatic-seo：规模化生成大量 SEO 友好页面的工作流。
• product-marketing-context、pricing-strategy、page-cro：定位、定价和落地页转化优化。

适合谁用：独立黑客、独立创始人，以及在没有大预算的情况下也要拉新和变现的营销或产品人。

下面这张图代表"增长 Skills"在做什么：从 SEO、网站健康、到心理诱因与转化。

上图概括了增长类 Skills 的链条：网站与 SEO 诊断、病毒式内容、营销心理、规模化 SEO、产品定位与定价，以及落地页转化优化，对应"产品做出来之后怎么卖出去"。

文档 Skills：把 AI 当行政助理

合并拆分 PDF、做 PPT、出 Word/Excel、把网页转成 Markdown 或 HTML，这类"文书劳动"交给专门 Skill 处理，能省下大量时间。

• pdf-pro、pptx、docx、xlsx：对应格式的生成与编辑能力。
• url-to-markdown、markdown-to-html：为知识库或发布流程做格式转换。
• format-pro：统一文档版式和样式，保持品牌一致。

适合谁用：经常要出报告、提案、知识库或对外材料的创始人、学生或专业人士。

下面这张图代表"文档 Skills"在做什么：从 PDF、PPT、Word、Excel 到格式转换与统一版式。

上图从左到右是 PDF 处理、PPT 与 Word/Excel 生成、网页转 Markdown、Markdown 转 HTML 发布，以及版式与品牌统一，对应"文书杂活交给 AI 省时间"。

小结

OpenClaw 的价值不在于多一个聊天入口，而在于它把"模型 + 记忆 + 工具 + 技能市场"串成了一条可扩展的管道。你发出去的那句话，会经过网关被转成对某几个 Skill 的调用，再驱动真正的读写、执行和对外请求。想把它用成 2026 年能持续跑下去的基础设施，就需要从"聊天"思维切到"网关 + 能力层"思维：先装好基础 Skills、打开 SkillGuard，再按自己的角色补上策略、工程、设计、增长或文档中的几条线，让 Agent 既有手脚，又处在可控、可审计的环境里。

我正在开发 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 和反馈。