← 返回全部文章

2026 Vibe Coding 工具横评:12 款主流 Builder 与 Coding Agent

从项目阶段、控制程度、可验证性、代码交接和发布方式,对比 2026 年 12 款主流 AI App Builder 与 Coding Agent。

一个可调式双面工具,将 App 预览界面与代码审查界面连接在一起

Vibe Coding 工具最容易让人兴奋的时刻,往往也是最需要冷静的时刻:输入一段 Prompt,屏幕上很快就出现了一个像样的 App。但界面好看不等于真正满足需求。它改了哪些文件、别人能不能接手、构建失败后能否恢复,这些问题通常要到第二轮才暴露出来。

因此,我不想简单地把十二款工具从第一名排到第十二名。Replit、Lovable、Bolt、v0、Base44 和 Google AI Studio 擅长把想法尽快变成可运行的版本;Codex、Claude Code、Cursor、Windsurf、GitHub Copilot App 和 Google Antigravity 更适合接手已有项目,让人看清执行了哪些命令、修改了哪些文件、检查是否通过。两类工具的能力正在重叠,但适用阶段仍然不同。

我真正想回答的不是“哪款最好”,而是“项目走到这一步,我会先选哪一类工具,又要看到什么证据才敢继续”。

先分清两类工具

我根据项目所处的阶段来分类,而不是给每个品牌贴上固定标签。

AI App Builder(AI 应用构建工具)通常把 Prompt、项目配置、实时预览和托管集中在一起。当你还没有现成项目,只想用较少配置先做出一个可以实际操作的版本时,它是很合适的起点。

AI Coding Agent(AI 编程智能体)会直接读取和修改项目文件,也能运行命令与测试。当项目已经存在,下一步需要检查代码或严格限制修改范围时,它更有价值。

还有第三种常见方式是编辑器里的内联代码助手,但不在本次横评范围内。代码补全适合已经亲自编写代码的人,不等于 Builder 或项目 Agent 提供的端到端工作流。

两类工具并不存在简单的高低之分。Agent 能接触更多文件和工具,也意味着我要检查更多内容。需求明确的小型原型,我通常先看 Builder;只有下一步确实需要直接控制文件和命令,我才转向 Agent。AI 小课的 Vibe Coding 零基础入门也先讲清这个区别,再让学习者选择具体产品。

我怎么比较

我用了两层证据,资料核对日期是 2026 年 8 月 20 日。

  • 产品官方说明来自当前官方文档、支持页面和发布记录。它能说明产品提供哪些功能,却不能证明产品已经完成我们的测试任务。
  • 实际项目记录来自保留下来的构建、测试、修改和交接过程,只用来说明真正检查过的结果。

只有 Replit → Codex 这条路径,我能根据 AI 小课保留的 Community Book Swap Checklist 项目记录逐步复核。其余十款,我检查的是当前官方功能,不会把“看过文档”写成“亲自完成了同一套实测”。官方页面能证明产品支持 Git 同步、checkpoint 或浏览器测试,却不能证明它一定能比其他工具更好地完成同一组需求。

这个实际项目从一份边界明确的需求清单开始:制作一款移动端优先的清单 App,支持分类、完成状态、筛选、刷新后保留数据和可恢复的重置功能,同时不使用真实个人资料。交给 Coding Agent 的后续任务则刻意缩小范围:检查一个依赖冲突,只修改指定内容,并保持 App 现有行为不变。

项目记录把需求分成通过、部分通过、失败和未测试。一次运行带有偶然性,不足以给十二款产品做长期排名;它更适合用来确定横评标准:实际运行效果、文件改动、命令输出、恢复方式、代码能否交接,以及最终发布到了哪里。

我的初步推荐

  • 优先看 Replit:希望在同一个工作区完成规划、构建、预览、保存节点、文件检查和发布,并愿意亲自测试运行结果。
  • 优先看 Lovable 或 v0:界面还要频繁调整,同时希望通过 GitHub 保留代码和协作记录。
  • 优先看 Bolt:希望直接在浏览器里构建并运行 Web 项目,同时能够查看代码、回到早期版本或同步到 GitHub。
  • 优先看 Base44:内置数据库、登录、权限和托管带来的便利,比依赖平台带来的限制更重要。
  • 优先看 Google AI Studio:Gemini、原生 Android 或 Cloud Run 本来就是项目的核心需求,而不是临时加入的附加功能。
  • 优先看 Coding Agent:项目仓库已经存在,接下来需要的是可以检查、可以测试的代码修改;候选包括 Codex、Claude Code、Cursor、Windsurf、GitHub Copilot App 和 Google Antigravity。

这些建议只适合用来缩小第一轮选择范围,并不意味着一款工具永远只适合某类任务。Builder 正在加入代码仓库和编辑器,Coding Agent 也开始操作浏览器并保存截图或录像。我最终还是会看项目下一步要解决什么,而不是拘泥于产品分类。

App Builder

如果我手里只有一个需求明确的想法,我会先从这六款里挑。它们都能减少前期配置,真正拉开差距的是:代码存在哪里、后端由谁管理、界面调整能否写回源码,以及离开平台后哪些部分还能继续使用。

产品 适合什么情况 如何检查与交接 主要注意点
Replit Agent 在一个工作区做出第一个可运行版本 文件、Shell、checkpoint、Git、导出和发布 预览成功不代表导出后仍能独立构建
Lovable 需要频繁视觉调整的全栈 Web App 连接源码的 Visual Edits 与双向 GitHub 同步 托管服务仍需单独检查可迁移性
Bolt 快速构建浏览器内 Web 与 JavaScript 项目 Code View、版本历史、分支和 GitHub 同步 项目越大、迭代越多,token 用量越高
v0 重视界面设计的 React/Vercel 项目 完整编辑器、接近生产环境的预览、commit 和 PR 漂亮的第一版仍需测试实际功能
Base44 需要数据、登录、权限和托管的 App Code View;符合套餐时支持 ZIP 与 GitHub 导出 后端能力从一开始就深度依赖平台
Google AI Studio Build Gemini 优先的 Web 或原生 Android App 实时代码编辑、ZIP/GitHub 导出与 Cloud Run 部署 数据服务与使用费用需要单独检查

Replit:所有东西都在一个工作区

Replit最初以浏览器编程环境和多人协作为人所知,后来发展成覆盖开发、托管与发布的全栈软件平台。2024 年推出 Agent 后,用户开始可以用自然语言直接创建和部署 App。我把 Replit 放在 Builder 的第一位,不是因为它每项功能都领先,而是因为构建、运行、检查和恢复都集中在同一个工作区,也是这次唯一有完整项目记录的 Builder。

Replit Agent 文档把规划、构建、测试和 checkpoint 放在同一个工作区。对初学者来说,它的好处很直接:发现某项需求没有实现时,可以同时检查正在运行的 App、项目文件、Shell 输出和之前的保存节点,不必马上迁移项目。

Agent 可以先用 Plan Mode 拆解需求,再修改多个文件、安装依赖、调试错误并继续完善 App。截图、文件或 Canvas 内容能够补充 Prompt 难以说清的界面要求和业务背景。Replit 还提供数据库、认证、Secrets、Git 与 Deployments,因此从空项目到带持久数据的公开版本都可以在浏览器里完成。checkpoint 不只记录代码,还能关联 Agent 对话、任务和数据库状态,方便在大改出错后回到之前的状态。

Replit Agent 对话位于左侧,右侧显示官方教程中正在运行的 App 预览

Replit 官方第一个 App 教程,核对于 2026 年 8 月 20 日。图片只用来展示 Agent 与预览界面的布局,不能证明生成的 App 已经满足需求。

课程中的实际操作也暴露了这种便利的边界。界面预览再精致,也无法证明项目没有隐藏的外部依赖。检查文件后,我们发现了未使用的 Google Fonts 链接;随后导出的副本只包含相关文件,虽然便于审查,却因为缺少工作区层面的依赖信息而无法独立构建。Replit 已经完成了主要任务,但这还不足以证明项目可以在别处完整复现。

所以,如果我现在只想尽快让一个完整功能跑起来,并且愿意留在 Replit 工作区里逐项测试,我会优先试它。但我不会把“Download source”当成可复现证明:能导出文件,和另一台电脑能重建同一状态,是两项不同的检查。

Lovable:边看边改的全栈路线

Lovable 源自开源项目 gpt-engineer及其商业 Web 版本 GPT Engineer,现在是一款面向非技术创作者与软件团队的自然语言全栈 Web 开发平台。如果我的主要不确定性是“页面还要反复调”,而不是“底层架构该怎么搭”,Lovable 会进入我的第一轮候选。

Lovable 把界面修改、后端服务和代码交接串在同一个流程里。Visual Edits可以直接选中页面元素,调整文字、颜色和间距,再把修改写回源码。需要动态数据时,Lovable Cloud 提供 PostgreSQL 数据库、认证、Storage、Realtime 和 Edge Functions,也可以连接 Supabase。调用需要密钥的外部 API 时,凭证会通过 Secrets 和服务端函数处理,不必暴露在前端。

它最有辨识度的组合是“直接看着页面改”和“双向 GitHub 同步”:界面调整会真正写进项目代码,代码也能进入常规的分支与协作流程。发布时需要手动创建快照,编辑器中的后续修改不会自动覆盖线上版本;支持 Test/Live 环境的项目还可以分开管理开发数据和生产数据。

Lovable Visual Edits 面板与运行中 App 里被选中的界面元素

Lovable 官方 Visual Edits 文章,发布于 2025 年 3 月 13 日。图片展示视觉编辑界面,不证明生成代码的质量或可迁移性。

2026 年 5 月 13 日以后创建的 Lovable App 改用支持 SSR 的 TanStack Start,旧项目继续使用 React + Vite,两者的托管要求并不完全相同。我会把 Lovable 留给视觉变化频繁、又想尽快加入登录和数据的 Web App;如果“以后随时搬走”是硬约束,我不会只看 GitHub 里有没有代码,还会逐项追问数据库、用户、文件和 Secrets 怎么迁移。

v0:从界面生成走向完整项目

v0 是 Vercel 推出的 AI 开发 Agent,早期主要以生成 React 界面和组件受到关注,如今已经进入完整全栈项目,但仍保留明显的设计优先和 Vercel 生态背景。我会把它和 Lovable 放在一起比较:两者都适合视觉迭代,v0 的吸引力更集中在 React、GitHub 与 Vercel 这条连续路线。

它可以根据文字、线框图或截图生成高保真界面,也能在完整的 VS Code 风格编辑器里处理前后端代码、API Routes 和数据库集成。Design Mode让用户直接在正在运行的页面上选择元素,再通过面板或自然语言调整样式;点击 Apply 后会生成新的项目版本,因此可以查看 diff、撤销或继续修改。

它与 Vercel、GitHub 的结合是主要特色。同一个 Project 可以共享部署、域名、环境变量和集成,多个 Chat 则分别为同一个 App 开发不同功能。连接 GitHub 后,每个 Chat 默认使用独立分支,代码修改自动形成 commit,并通过 Pull Request 合并,而不是直接写入 main。Neon、Supabase、Upstash 等数据库也可以直接接入项目。

v0 Prompt 输入栏中的 Design Mode 控件

v0 官方文档,核对于 2026 年 8 月 20 日。这张局部截图只定位 Design Mode;判断修改时,应查看实际项目 diff,而不是这个控件本身。

如果项目已经确定使用 React/Vercel,而且营销页、Dashboard 或精细 UI 是重点,我会把 v0 排在很前面。它的限制也恰好来自这套深度集成:在 Vercel 上一键部署很顺,不代表换到其他托管环境同样不用调整;第一屏再漂亮,也要补测表单、权限、数据和错误状态。

Bolt:浏览器就是 JavaScript 运行环境

Bolt.new 是 StackBlitz 推出的 AI App Builder。它建立在 WebContainers 技术上,用 WebAssembly 在浏览器内部运行 Node.js 工具链,而不是把远程开发机画面传回来。这是我把 Bolt 单独列出的原因:它卖点不只是生成代码,而是让代码立刻在浏览器里安装、启动和报错。

Bolt Quickstart把 Prompt、代码编辑器、运行环境与预览集中在同一个界面。它的关键特色是浏览器内的开发环境:Agent 可以创建文件、安装 npm 包、启动 Node.js 服务,并根据运行时错误继续修复,不必先在本机配置项目。除了常见的 Web App,只要在第一条 Prompt 中明确要求 mobile app,也可以生成基于 Expo 的移动项目。

Bolt Cloud 还会自动创建数据库,并提供用户认证、Secrets、Edge Functions 和托管。每个项目都可以获得可分享的 bolt.host 地址;如果需要更深入地管理数据,也可以接管数据库并连接 Supabase。Code View、版本历史和 GitHub 集成让使用者能够查看代码,并把项目交给其他开发者继续处理。

Bolt 起始页面的 Prompt 输入框中包含一条自然语言 App 请求

Bolt 官方 Quickstart,核对于 2026 年 8 月 20 日。图片展示 Prompt 起点,不是已经完成的任务结果。

我会用 Bolt 做 JavaScript/Node.js 原型,因为它给的是“马上运行”,不只是“马上看到代码”。但我不会把它当任意后端语言的云 IDE:PHP 和 Python 后端不在官方兼容范围,多轮迭代还会继续消耗 token。技术栈和预算最好在开工前确认。

Base44:后端默认已经在那里

Base44 是目前由 Wix 运营的自然语言 App Builder。它更像一体化业务应用平台,而不只是界面生成器:数据、身份、后端逻辑和托管默认都在。我会在 CRM、内部工具或会员系统这类项目里优先想到它,而不是拿它做一张纯展示页。

Base44 Quickstart同样从 Prompt 和实时预览开始,但它更强调开箱即用的业务后端。平台内置 NoSQL 数据库,以 Entity 定义数据模型,支持实时订阅、行级和字段级权限;登录方式包括邮箱密码、常见社交账号和 SSO;自定义后端逻辑则运行在 Deno/TypeScript Serverless Functions 中。

Base44 还把集成分成几层:内置动作可以生成文字或图片、发送邮件、处理文件;Connector 通过 OAuth 连接 Google Workspace、Slack 等账户;自定义集成可从 OpenAPI 规格生成,并在后端代理调用,避免向浏览器暴露凭证。这让 CRM、内部工具、会员系统和带工作流的业务 App 比纯展示页面更能体现它的特色。

Base44 Builder 左侧为 AI 对话,右侧为实时 App 预览

Base44 官方文档,核对于 2026 年 8 月 20 日。图片展示对话与预览界面,集成服务和导出能力仍需另行检查。

Developer tools提供 React/Vite Code View、API Activity Monitor、GitHub 工作流、ZIP 导出和本地开发方式,内置托管负责 HTTPS 与自定义域名。这里我会特别检查“导出”的含义:前端和 Functions 能导出,不代表数据库、认证、集成与 Base44 SDK 也自动脱离平台。如果团队愿意接受平台依赖来减少配置,我会考虑 Base44;如果首要要求是随时完整自托管,我不会选它起步。

Google AI Studio:当 Gemini 就是产品核心

Google AI Studio原本是 Google 用来试验 Gemini 模型和 Prompt 的浏览器环境,Build Mode 又让它具备了构建 Web 与原生 Android App 的能力。我不会因为“它也能做 App”就把它当成通用首选;只有当 Gemini、原生 Android 或 Cloud Run 本来就是项目核心需求时,这套整合才真正有优势。

Google 当前 Build 文档显示,AI Studio 已经不只是尝试 Gemini Prompt 的 Playground。Web 模式会生成 React 前端与 Node.js 服务端运行时,可以使用 npm 包、连接外部数据库,并把 Gemini API Key 放在服务端 Secrets 中;Antigravity Agent 会在项目上下文里管理多个文件并验证更新。项目可以导出到 GitHub 或 ZIP,也可以直接部署到 Cloud Run。

Android 模式会生成 Kotlin 与 Jetpack Compose 原生项目,并提供浏览器内模拟器、真机安装和 Play 测试方式。这是其他多数 Web-first Builder 没有的鲜明能力,但 Android 项目目前以客户端为主,Web 模式中的服务端 Secrets 等能力不能直接照搬。

Google AI Studio Build 页面,用于选择由 Gemini 支持的 App 能力

Google AI Studio 2025 年 10 月官方产品图,展示 Build 入口;相邻段落中的能力说明已于 2026 年 8 月 20 日重新核对。

当 App 的主功能就是 Gemini 文本、图像或 Live API,或者目标明确是原生 Android 与 Cloud Run,我会认真考虑这条路线。但分享出去的 AI Studio App 允许获准用户查看并 fork 代码,产生的 Gemini 调用也计入创建者配额,数据库又仍需外接。我会把“Gemini 接得快”和“数据、费用、交接已经清楚”分开验收。

什么时候该换 Agent

我不会因为 Prompt 连续失败两次,就立刻把项目搬到一个看起来更专业的 Agent。换工具应该解决一项具体的控制问题,否则只是把同一条模糊要求复制到另一个输入框。

课程项目之所以从 Builder 转到 Agent,是因为仅凭运行中的页面无法判断一个依赖问题。我们先保存当时的项目状态,再把相关文件交给 Codex,并要求它先检查、后修改。它最终建议只删除三个没有使用的字体标签,明确不改 App 行为和其他文件。

Vibe Coding 零基础入门完整保留了这段 Replit → Codex 的操作过程。这里引用课程,不是为了证明两个品牌“赢得横评”,而是为了说明我会在什么时候换工具:只有下一步确实需要更细的检查和控制,迁移才有意义。

Coding Agent

项目已经存在时,我对 Agent 的要求会明显提高。“任务完成”没有多少信息量;我真正要看的是计划、授权范围、修改了哪些文件、diff、命令结果、功能复测和恢复方式。

产品 适合什么情况 如何审查与恢复 主要注意点
Codex 现有项目中的限定修改或多步骤任务 计划、命令、检查结果、修改文件与 diff 授予较多权限前必须明确范围
Claude Code 终端优先的仓库工作 Plan Mode、权限模式、命令、测试与 Git 使用者需要能够阅读命令输出
Cursor Agent 在日常编辑器中逐步增加 Agent 参与程度 逐文件 diff、选择性接受与 checkpoint checkpoint 不能替代长期版本记录
Windsurf Cascade 在编辑器与云端 Agent 之间分配多个任务 计划、工具调用、诊断、checkpoint 与 revert Cascade 与 Devin 的权限和计费可能不同
GitHub Copilot App 围绕仓库并行运行本地或云端任务 Interactive、Plan、Autopilot 与隔离工作区 自主程度、隔离方式与计费取决于运行模式
Google Antigravity 需要计划、截图和浏览器验证的任务 可审查的计划、diff、截图与录像 证据多少不等于证据有效

Codex:围绕可审查修改工作

Codex 是 OpenAI 推出的 Coding Agent,用于理解代码库、开发和测试功能、修复问题及审查修改。它同时提供桌面应用、CLI、IDE 与 Cloud 等入口,不依附于某一款编辑器。在这次横评里,我最看重的不是入口数量,而是它能把任务范围、命令和最终 diff 留在同一条审查链上。

Codex 把文件编辑、命令执行、检查结果和 diff 审查放在同一个项目流程中。本地环境可以直接处理当前 working tree,Git worktree 适合隔离并行修改,云端环境则可以把任务交给远程 sandbox。集成终端和审查界面让命令输出、修改文件与逐行 diff 都保留在同一个任务里。

Codex 的另一个特色是可把仓库约定与重复流程写成 AGENTS.md、Skills 或 Plugins,让 lint、测试、文档或发布规则不必每次重述。权限和 sandbox 决定 Agent 能访问哪些文件、网络和外部工具;这类扩展能力越多,越需要先限定目标、不可修改范围和验收命令。

Codex 桌面左侧显示限定修改请求,右侧 Review 面板显示删除三行 Google Fonts 标签

课程根据保留项目和精确三行 diff 重建的 Codex 桌面演示图。它展示已记录的审查动作,并非原始执行截图。

在课程记录里,我真正能验收的不是“项目已修复”,而是一项能和原始副本比较的三行删除。已有仓库中的 bug 修复、重构、测试、审查或多步骤任务,我会考虑 Codex;如果手里只有一句产品想法,Builder 通常更快。

Claude Code:终端优先,也最容易扩展

Claude Code 是 Anthropic 推出的 Agentic Coding Environment。它最初以终端工作流为核心,通过一套 Harness 提供项目内容、工具、权限,并让 Agent 反复执行和验证任务;现在也进入桌面、IDE、Web 与自动化场景。如果我已经习惯在终端里读命令、看 Git diff,并希望把自己的工程规则接入 Agent 工作流程,它会比固定界面的 Builder 更自然。

Claude Code 内置文件读写、代码搜索、Shell、Git、Web 查询和代码诊断工具。它会在“收集上下文—执行—验证”的循环里自行决定下一步;Plan Mode 把探索限制为只读,Default 与 Auto-accept 等权限模式控制编辑和命令是否需要确认。每次文件编辑前的 checkpoint 可以通过双击 Esc/rewind 恢复,但远端数据库、部署和 API 操作不在恢复范围内。

它的特色不只是一块终端对话框。CLAUDE.md可以保存项目的长期约定,Skills 封装需要时才加载的工作流,MCP 连接外部服务,Hooks 在工具或会话事件发生前后按既定规则执行脚本,Subagents 与 Agent Teams 则把研究或实现拆到独立上下文。这套组合适合已经使用 CLI、希望把测试和工程规范接入 Agent 流程的团队;扩展得太多,也会增加上下文、权限和维护成本。

Claude Code 终端中显示项目请求和最近文件活动

Anthropic 官方产品截图,核对于 2026 年 8 月 20 日。图片识别终端工作流,不验证某个具体仓库修改。

我不会因为终端里没有始终显示的 App 预览就低估 Claude Code,也不会因为界面看起来更专业就高估它。只有当我能读懂它准备运行的命令、检查 Git diff,并分清 checkpoint 和真正的版本历史时,这套工作流才成立。

Cursor:从补全逐步走到 Agent

Cursor 是 Anysphere 创建的 AI-first 代码编辑器。它从代码库感知的对话、补全和局部编辑起步,随后扩展到前台与 Cloud Agents。我认为它最容易被忽略的特色不是“也有 Agent”,而是使用者可以按任务大小,在补全、局部编辑和自主执行之间逐步提高授权范围。

Cursor 当前工作流覆盖三种不同程度的辅助:Tab 负责跨行与跨文件补全,Inline Edit 直接修改选中的代码,Agent则搜索代码库、修改多个文件、运行终端命令并自动修复错误。Ask Mode 只读取项目,Manual Mode 只编辑明确选中的文件,Custom Modes 可以组合工具与专用指令。这样一来,开发者不必为每个小改动都启动高度自主的 Agent。

Agent 的 Review Diffs 支持逐文件检查,Rules 可以保存项目约定,MCP 可以接入外部工具;checkpoint会自动保存 Agent 的文件修改。需要离开本机时,Background Agents 能在隔离的 Ubuntu 环境里克隆 GitHub 仓库、安装依赖、运行测试并推送独立分支,Web、Mobile 与 Slack 还可以启动或跟进任务。

Cursor Agent workspace 同时显示对话、修改文件和代码审查面板

Cursor 官方文档图片,核对于 2026 年 8 月 20 日。它展示 Agent 审查界面,不证明画面中的修改正确。

如果我本来就在编辑器里读写代码,又想在补全和 Agent 之间平滑切换,Cursor 会很顺手。但它的本地 checkpoint 只追踪 Agent 修改,会自动清理,也不包含手动编辑,不能替代 Git;后台环境默认联网并自动运行命令,我还会单独检查仓库权限、Secrets 和 Prompt Injection 风险。

Windsurf:Cascade 与 Devin 的双层路线

Windsurf 是 Cognition 旗下的 Agentic IDE,与同公司的自主云端 Agent Devin 共同发展。这一背景解释了它现在的双层结构:在编辑器里用 Cascade 同步协作,再把较长任务交给云端 Agent。若我需要同时看住几项任务,这种编排很有吸引力;若只改一个小仓库,它也可能比需要的更复杂。

Windsurf 2.0仍以编辑器为基础:Cascade 位于代码库旁,可以规划任务、搜索与编辑文件、调用工具、读取诊断,并用 checkpoint 与 revert 处理错误修改。编辑器提供多家模型选择,Code Maps 通过展示文件和代码符号之间的关系来帮助理解代码库,预览功能则让 Web 修改可以在同一环境里运行和观察。

2.0 的主要变化是 Agent Command Center。它用看板汇总本地与云端 Agent,Spaces 把 session、PR、文件和上下文按项目整理;一项本地计划还可以直接交给 Devin,让它在独立 VM 的桌面、浏览器与终端中继续执行。因此,Windsurf 不再只是“编辑器右侧的聊天框”,也能统一管理即时协作和耗时较长的后台任务。

Windsurf 编辑器中的项目 workspace 与右侧 Cascade 面板

Cascade 官方文档图片,核对于 2026 年 8 月 20 日。它定位 Agent 在编辑器中的位置;当前 Windsurf 2.0 还包含更广的 Devin 集成。

如果我要同时推进多个代码任务,“本地 Cascade + 云端 Devin”很有吸引力。但它也让权限和计费更难一眼看懂:本地编辑、云端执行、模型选择和额度不一定遵循同一套规则。恢复 checkpoint 前,我会先看覆盖范围;交给云端前,则确认仓库、网络和凭证边界。

GitHub Copilot App:把 session 放进 GitHub 流程

GitHub Copilot 最初主要以编辑器内的代码补全为人所知。独立 GitHub Copilot App 于 2026 年 6 月正式发布,开始以 branch、issue 和 Pull Request 为单位处理完整任务,而不再只给出一条补全建议。对我来说,它最明确的适用人群不是“所有 GitHub 用户”,而是已经用 Issue 和 PR 组织日常开发、又希望并行处理多个任务的团队。

每个 session 可以运行在独立 Git worktree、当前本地仓库或 GitHub 托管的 cloud sandbox,并拥有自己的 branch;多个任务因此可以同时运行,又不必争用同一 working tree。Issue 可以直接变成实现任务,完成后继续进入 diff、commit 与 Pull Request 流程。

Interactive Mode 会在关键步骤等待协作,Plan Mode 先给出计划供批准,Autopilot 则可以自主写代码、运行测试并反复修复。每个 session 还能选择不同模型和 reasoning effort,Auto 自动匹配模型,也支持用自己的 API Key 接入外部模型;集成终端、浏览器工具、Quick Chat 和 session history 用来补充执行与回顾。

GitHub Copilot App 中显示 Agent sessions、任务进度和项目 workspace

GitHub 官方公告,发布于 2026 年 6 月 17 日。图片展示独立 Copilot App,而不是编辑器内联补全。

如果代码已经在 GitHub,日常工作又围绕 Issue 和 PR 展开,我会优先试 Copilot App。只是本地 worktree、直接本地目录和 cloud sandbox 的隔离方式、资源访问范围与费用都不同;Autopilot 可以不等人,不等于最后不需要人工审查。

Google Antigravity:让计划和截图也能审查

Google 在 2025 年 11 月推出 Antigravity,定位是一套跨编辑器、终端与浏览器的 Agent-first 开发平台。Antigravity 2.0 又扩展出独立指挥中心,同时保留 IDE、CLI 和 SDK。它进入我的候选,不是因为入口多,而是因为它把计划、diff、截图和录像都当成可以评论的交付物。

独立应用可以集中启动和监控多个本地 Agent 与 Scheduled Tasks,Antigravity IDE 则让 Agent 操作编辑器、终端和浏览器。真正让它与其他产品拉开差异的,不是入口数量,而是把计划、diff、截图和录像都放进审查流程。

Agent 在编码前可以生成 Implementation Plan 与 Task List,用户像评论文档一样提出修改;执行中产生 code diff,完成后用 Walkthrough 说明变更与测试。浏览器子 Agent 可以实际点击页面,并把截图或操作录像附到 Walkthrough。Google 的官方 Codelab还展示了按节点 Undo,以及从 IDE 的错误诊断或终端输出直接把问题发送给 Agent。

Google Antigravity 对话中显示 Implementation Plan 和 Proceed 控件

Google Antigravity 官方 Codelab,核对于 2026 年 8 月 20 日。图片展示等待审查的计划,不证明之后的实现符合计划。

如果 UI 行为必须在浏览器里验证,或者我希望代码之外还有计划、截图和录像,Antigravity 会进入候选。但生成的材料多,不代表证明就更充分;有些配置还允许 Agent 不等待 Proceed 就继续。我最终仍会逐项核对计划、diff、截图和录像是否真的对应需求。

价格里藏着什么

我没有把月费放进主表,因为这些数字看似可以直接比较,实际包含的内容却完全不同。各家会按照订阅权限、消息、credits、tokens、模型用量、计算资源、部署或多种方式组合计费。月费较低的套餐可能在任务中途耗尽额度;较高的套餐也可能已经包含其他产品需要额外付费的模型或计算资源。

选择套餐前,比较三项事实,而不是只看广告月费:

  1. 包含所需工作流的最低套餐,例如完整构建、Git 导出、后台 Agent 或云端 sandbox;
  2. 实际计量单位,例如 tokens、credits、消息、模型调用、计算资源或 Agent 工作量;
  3. 生成结束后持续产生的托管、数据库、模型或部署费用。

付款前应重新检查官方定价和结算页面。要比较实际成本,最好让候选工具完成同一个范围明确的任务,并记录真实消耗,而不是假设广告价格最低的套餐一定够用。

我排除的两款工具

我没有因为历史知名度而保留已经不再接受新用户的产品。Firebase Studio 已于 2026 年 6 月 22 日停止创建新工作区和注册新用户,并将在 2027 年 3 月 22 日关闭;新项目被引导到 Google AI Studio 或 Antigravity。Firebase 迁移文档已经说明它不再适合作为新用户的选择。

GitHub Spark 也在 2026 年 8 月停止接受新用户和新 App。GitHub 当前文档要求现有用户导出自己的项目。两款产品在回顾 Vibe Coding 发展时仍然值得提及,但不应该继续占用面向新用户的主要评测名额。

我会怎么选

你的当前情况 优先测试 原因
只有明确的想法,还没有现成项目 Replit、Lovable、Bolt、v0、Base44 或 Google AI Studio 先确认能否用较少配置做出并测试一个完整功能。
界面需要频繁做视觉精修 Lovable、v0 或 Bolt 三者都提供与运行项目相连的视觉选择或设计界面。
App 依赖集成的数据、认证或托管 Base44、Replit、Lovable 或 Bolt 集成能减少配置,但必须检查能否迁移以及谁可以访问。
已有仓库,而且修改范围明确 Codex、Claude Code、Cursor、Windsurf、Copilot 或 Antigravity 结果应包含明确计划、可审查的修改、检查与恢复方式。
偏好终端并且能够审查命令 Claude Code 或 Codex CLI 终端操作更直接,但使用者仍要控制权限和命令范围。
需要计划与浏览器验证的可视证据 Antigravity,或能保留同等证据的 Agent 只有和真实需求对应时,计划、截图与录像才会帮助审查。

我不会从这张表里选出一个适合所有人的冠军。同一款产品在一个场景里很合理,换个场景却可能徒增复杂度。第一次选择时,我会从同一行挑两款,先确认关键功能是否包含在当前套餐,再分别做出一个完整功能,不急着扩大项目范围。

如果你想先用一个不包含真实个人资料的练习项目走完整个流程,再把自己的项目交给工具,可以参考 AI 小课的 Vibe Coding 零基础入门。课程围绕同一个 App,依次练习梳理需求、检查预览、定位问题、查看文件、限制 Agent 的修改范围、验证结果和整理交接材料。课程也会明确停在证据能够支持的位置,不会把一个演示项目写成“已经达到生产标准”或“已经可以在任何环境中复现”。

无论最后选择哪款工具,我都会沿用同一条验收规则:精致的界面只能算第一版结果。只有当实际功能、代码改动、检查结果、恢复方式和交接状态都清楚到可以再次核对时,我才会继续相信这个项目。

参考资料