Vibe Coding 正从概念走向落地，大厂设计师、PM、运营纷纷开始自己写代码，独立开发者更是单人完成完整产品。但工具爆发带来选型困境：Claude Code、Codex、Pi Agent 等各有定位，选错工具反而低效。本文从场景、维度、测试、成本四步拆解 Agent 选型方法论，帮你找到最适合的 Vibe Coding 工具。

Vibe Coding 这个词是 Andrej Karpathy 在 2025 年 2 月发的一条推文里提出来的。原话是这样的：

“There’s a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

推文出来之后迅速扩散。不是因为技术圈觉得这个词特别准，而是因为它击中了另一批人，那些能想清楚要做什么、但一直被“不会写代码”这件事拦住的产品、运营、设计。它给了这件事一个名字，顺手把一个感受变成了一个行动的许可。

到 2026 年，Karpathy 自己补了一句，Vibe Coding 只是抬高了地板。地板抬高了，入场的人多了，接下来的问题不是要不要用，是用什么、怎么用？

落地现状：工具爆发与选型困境

Vibe Coding 开始在公司里落地。大厂设计师开始自己写前端组件，不用等工程师排期；PM 直接搭交互原型，省掉无数轮口头需求沟通；运营用 Agent 做数据脚本，不用等人。不是替代岗位，是每个岗位的人多了一种以前没有的动手能力。独立开发者这边更直接，一个人从 0 到 1 做完一个完整的 APP 产品和 Web 端产品，这些都是已经是真实在发生的事。

但问题也跟着来了。

Vibe Coding 的工具现在太多了。Claude Code、Codex 算是头部，国产这边豆包、Work Buddy、Kimi Code 也都在跑；还有各种开源 Agent 框架，数量仍在增加。对刚入场的人来说，选择眼花缭乱，不知道从哪里下手。

拿豆包、Kimi Code、Work Buddy 这类国产工具 Coding 来说，提示词写得不够精细，它就给你跑偏，投入的精力反而比手写代码还多。这种情况出现的时候，问题不一定出在 AI 本身，很可能是工具选错了。工具能力上限不够，或者搭配方式不对，就只能靠越来越精细的提示词来补，越来越累，也越来越低效。

市面上有这么多 Vibe Coding 工具，根本原因是这些框架各自的定位不一样，没有一个放之四海之皆准的 Agent 工具。选型没做好，工具再多也是负担。所以第一个要搞清楚的问题是，这些 Agent 框架到底有什么差别。

工具盘点：主流 Agent 概览

按生态位分，市面上的 Agent 产品其实只有两大阵营。

第一阵营是模型厂商的嫡系：Anthropic 的 Claude Code、OpenAI 的 Codex。这些 Agent 产品，模型、Agent、订阅一体，Agent 是模型的分发入口，所以全平台铺开，VS Code 插件只是标配。

第二阵营是模型中立的开源工具，谁的模型都能接，靠社区生态活着，形态各不相同：Pi 是终端编码 Harness，Open Claw 和 Hermes Agent 是个人助理网关，挂在消息平台上用，Maka 是本地优先的桌面工作空间。

这个阵营内部已经卷起来了：Open Claw 跑在 Pi 的 SDK 上，Hermes Agent 内置了一键从 OpenClaw 迁移的命令。

Claude Code

从零搭一个项目，Claude Code 是目前最顺手的选择。相当于出厂预装了一个经验丰富的项目经理，帮你想架构、定规范、查安全，什么都安排好了，开箱即用。告诉它做一个用户管理系统，它会自己想路径、拆模块、写文件，不用手把手喂每一步。

适合从 0 到 1 的阶段，因为它会主动思考，能在没有明确指令的地方自己做判断。

Codex

指哪打哪。给它明确指令，它按边界执行，不多做，不少做。你说把这个函数的返回类型改一下，它就只动那一块，不会顺手改周围的代码，有多模态能力，能生成图片。

适合从 1 到 N 已有稳定基底的项目，做定点修改、局部重构、单文件精调。

从零搭一个中大型项目基本搭不起来。它需要先有一个架构撑着，不能让它从地基开始想。

PiAgent

像一张极度空白的纸。什么都能接，模型随意换，规则自己定，还能挂上 Claude Code 那套 Skill 体系。开源不锁定模型，把自由度完全还给用户。

适合已经有自己工作流、想要灵活控制权的用户。新手慎入，没有一套配置好的工作流，就是一堆零件摆在那里。

OpenClaw

本地高权限执行，能看屏幕、操作本地应用，不只是写代码。技能市场 ClawHub 里有覆盖开发、设计、市场的现成 Skill。

但有两个缺点：Token 消耗极高，跑起来成本远比其他 Agent 贵；

真正好用需要养好它，做 SFT 微调，开箱即用体验不突出。适合隐私敏感场景、需要自动化本地任务的场景，接受高门槛才值得上手。

HermesAgent

越用越懂你的私人助手。核心是任务做完后会把这套操作路径自动记成 Skill，下次同类任务直接调用，不用重新教。开箱带了不少现成能力，终端和飞书里说的话是同一个大脑在接。

越用越顺手是真的。适合想要长期稳定伴侣型工具、不愿意每次都从头教 Agent 的场景。

Maka Agent

jakevin7 个人开发的轻量编程 Agent，跑在本地，代码不出机器。极简是它的哲学，提示词能少就少，反而跑得更准，搭配 Kimi K3 跑过一次编程自主完成率的评测，比官方 Kimi Code 高了 10 个点。Anthropic 自己也做过类似的删减实验，结论指向同一个方向。适合代码隐私敏感、想要极简工作流的用户。

我自己做的几个产品也是这套打法，选型这步基本决定了后面多省力，下面说 Agent 选型。

Agent框架选型：Benchmark

聊了这么多 Agent 各自的优点，接着说选型的方法论。选型走四步，定场景、定维度、跑测试、算成本。顺序不能乱。

这里我们挑两个顶级模型厂商的 Agent 和一个最典型的开源 Agent 来说，Claude Code、Codex 和 Pi Agent。

我自己的选型思路分走四步，定场景、定维度、跑测试、算成本，顺序不能乱。

第一步，定场景，也是最容易被跳过的。先搞清楚自己的核心场景，是从零搭一个新项目，还是在已有代码库里做修改，是一个人跑还是和团队一起开发。场景没搞清楚，后面看再多数据都是白搭。

第二步，定维度，对个人开发者来说，三个最值得看。

一是任务完成率，也就是 Agent 解决真实编程问题的能力。目前最接近真实开发场景的公开评测有两套：

SWE-bench Verified，也就是拿真实的 GitHub bug 单子考 Agent，看它能解决多少，相当于用真实工作任务给 Agent 打分；

Terminal Bench，看 Agent 在命令行里能独立干多少任务，不需要你手把手操作。

跑下来是这样，写代码能力两者基本打平，SWE-bench 上 Claude Code 是 88.6%，Codex 是 88.7%，差 0.1 个百分点。

命令行操作上差距就拉开了，Terminal Bench 2.0 上 Codex 是 82%，Claude Code 是 69.4%，涉及终端操作 Codex 明显更稳。写代码打平，自动化操作 Codex 占优。

Pi Agent 没有独立成绩，因为它是工具框架，不绑定任何模型，成绩取决于你接的底层模型。这是设计选择，不是缺陷。

二是上下文效率，可以简单理解成 Agent 一次能记住多少项目背景，窗口越大能同时处理的代码量越多。Claude Code 和 Codex 量级差不多，关键差异在内置系统指令，Pi Agent 这块只占了极少量的 400 Token 的提示词，把几乎所有空间都留给了项目代码。

Anthropic 刚好在前不久，砍掉了 80% 的系统提示词，和 Pi 的方向不谋而合。

三是成本效率比。Codex 完成相同任务的 Token 消耗大约是 Claude Code 的四分之一，Pi Agent 完全不绑定模型，哪个便宜好用就接哪个，成本弹性最高。

第三步，跑测试，把自己真实的任务类型拿去跑，比看任何评测数据都直接。冷启动任务、精修任务、跨文件重构任务分开测，每类场景下三个 Agent 的行为差异会很明显。

第四步，算成本，把日常使用频率乘上单次 Token 消耗，换算成月度费用，再比订阅价格。算清楚再选，不要靠感觉。

按这四步走下来，得到的结论是：终端密集型任务 Codex 占优；代码理解任务 Claude Code 和 Codex 两者打平；上下文效率 Pi Agent 最轻，给项目代码留的空间最多；成本弹性 Pi Agent 最灵活，Codex Token 效率最高。

答案是没有一个选项能够通吃。

我自己的选法是，从 0 到 1 规划的冷启动用 Claude Code，从 1 到 N 的精修和终端密集型任务切 Codex，个性化工作流走 Pi。不是选最好的，是按任务类型分工。

多 Agent 协作：VS Code 工作区搭建

我一直在想有没有可能有那么一个工具能够把这些 Agent 都集成起来，能够更好地把这些 Agent 它们的一个优势发挥出来。

最后测了很多工具，我发现 VS Code + 多 Agent 合作，是最舒服的。

首先说一下 VS Code 是什么。它是微软开源的代码编辑器，本质是一个容器，它里面的 Extension 市场里有几万个插件可以接进来，语言支持、调试工具、AI 助手全部通过插件形式运行。

Claude Code、Codex、Pi Agent 等等都在这个市场里有对应的插件，装进同一个编辑器，三个 Agent 共享同一份项目文件和工单，不需要在多个窗口之间来回切换。

整套工作台搭起来分五步。

第一步，安装 VS Code。去 code.visualstudio.com 下载对应系统的安装包。装好之后打开扩展市场（快捷键 Ctrl+Shift+X，Mac 上是 Cmd+Shift+X），搜Chinese (Simplified) (简体中文) Language Pack for Visual Studio Code，安装之后重启一遍，界面就切成中文了。

第二步，接入 Claude Code。在扩展市场搜 Claude Code for VS Code ，点安装。安装完成后按引导用 claude.ai 账号登录授权。左侧边栏会出现 Claude Code 的入口，点进去是聊天面板，可以直接对话，也可以在编辑器里选中代码后唤起它。

第三步，接入 Codex。在扩展市场搜 Codex – OpenAI’s coding agent，点安装。用 ChatGPT Plus 及以上的账号登录，侧边栏有对应入口，点开直接用。

第四步，接入PiAgent。

Pi Agent 本来就是在终端用的，但是既然是用 VS Code 作为容器，我也尝试搜索了官方插件，但是很可惜并没有原生的，不过我找到了两个独立开发者做的插件，对比测试了下，推荐：Pendant。

这个 UI 和基础功能还是比较完备和丝滑的。

在扩展市场搜 Pendant，选 Pendant – Pi Agent for VS Code，这是个人开发的 Pi Agent 的 VS Code 插件。

如果你没有在终端下载PIi agent 的框架点开插件，选“内置 Pi Agent”，它这个插件里面内置了。如果你之前在终端有下载过，选择“外部”即可。

关于模型：首次使用点击对话框里的登录，会弹出让你选择配置，里面有各大模型厂商的接入方式，我直接搭配的是 Kimi 3 模型。

第五步，打通三个 Agent 的上下文“最高指令软链接法”。

三个 Agent 都装进了 VS Code，但它们各读各的配置，Claude Code 读 CLAUDE.md，Codex 读 AGENTS.md，Pi Agent 两个 MD 文件都能读。

三个 Agent 所读取的项目及指令是不一样的，都有固定的项目 MD 文件。但这个地方有一个骚操作，是我这边测试下来，把统一管理和必须遵守的原则、框架等统一新建一个 MD 的文件，至于命名随意，我定义为：COLLABORATION.md（协作）。

以我之前搭建的 Vibe Motion 工作区为例：

既然它们在执行任务的时候都会去看项目及指令，那我就以软链的形式，在它们的所遵守指令中先限定必须要读：COLLABORATION.md 。曲线引导一波，变相地变成了该项目空间内最高级指令。

这种方法，我称之为“最高指令软链接法”。

软链接就是，软连到别的 Agent 的 MD 文件，你可以简单地理解为电脑桌面上的快捷方式，我创建了一个关联别的文件的快捷方式。我只需要存一份文件或说明，我就可以让多个 AI 工具访问它，无缝衔接和切换。

在项目根目录建一个 COLLABORATION.md ，把所有 Agent 都必须遵守的共识写进去，技术栈约定、文件命名规范、哪些文件不能动、管理方式。然后在 CLAUDE.md 的首句引入这份文件，在 AGENTS.md 的首句也引入。Claude Code 支持在 CLAUDE.md 里用 @文件路径 引用其他文件，Codex 对 AGENTS.md 有类似机制。三个 Agent 启动时，都会先读一遍最高指令 COLLABORATION.md ，再读各自的专属项目文件 MD 。

实际操作流是，新项目用 Claude Code 搭架构，同时落好最高指令 COLLABORATION.md

和 CLAUDE.md。项目有了基础之后，精细微调切 Codex，自定义工作流走 Pi Agent。至此，你这个项目空间整个协作链路和框架就已经搭建好了。

风险复盘：生产资料的所有权

VS Code（容器）+ 多 Agent 协作，这是目前我认为 Vibe Coding 的最佳姿态。正在写这篇文章时，Claude 又发布了一个新的模型 Opus 5。 毋庸置疑，每次发模型之前都会有一波大封号时期……我称之为“规律性智商冻结”！

目前为止，我已经被封了 3 个账号了，现在只能靠中转站接 API 苟延残喘，像阴沟里的老鼠偷偷用着 Claude。

但是通过这几次封号，也意识到了一个问题，过往我把我的工作流、经验或者是项目全部押宝在 Claude Code 这个工具上，以至于我在初次迁移生产资料时非常痛苦。

几个月积累的工作经验，工作流程，Skill 全部都在 Claude Code 里面，不过还好像聊天记录，还有 Skill，这些都是存储在本地的。但也会后怕，如果说这些生产资料所积累下来的资产跟随着封号消失了，不知道我会有多崩溃，以至于现在虽然也能用，但是我也会潜意识地去做备份和兜底手段。

于是我开始去反思一个问题，我们现在所积累的跟 AI 的协作，不管是 Skill 也好，Memory 也好，还是我们之前的工作流程，我们输出的文章、项目甚至产品，如果说让 AI 来进行接管和开发，我们丧失了资产主导权，那这个生产资料，或者说你的命脉就被把握在了某个平台、某个工具，某家公司上，这是不合理的。

所以我们应该要做到的是，不管工具如何迭代，平台如何变，账号怎么出现意外，我们的生产资料或者是项目主导权一定是在我们自己手里面握着。

因此工具或者 AI 本质上来说，我们应该把它作为一种媒介，我们在现在这个时代，虽然用 AI 能够很轻松地解决很多的问题，甚至效率翻倍，但是我们要时刻停下脚步复盘或者沉淀，吾日三省吾身：

1. 在这段时间所开发的项目，有多少节点是人为把关和审核？

2. 脱离了这个工具，随便换一个。当前工作流是否还能跑得通？

3. 通过这段时间的开发，个人的某个能力是否有所提升？