Vibe Coding 核心心法：管 Agent，如带团队（转载）

先说清楚什么是 Vibe Coding

2025 年 2 月 2 日，Andrej Karpathy 发了一条推文，随手造了一个词：

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.

他描述自己用 Cursor 和 SuperWhisper 做项目，几乎不碰键盘，对着 AI 说话就行。"Accept All"，不看 diff，有报错就把错误信息粘进去，通常就修好了。代码越长越超出他自己的理解范围，有些 bug 修不了就绕过去，或者随便改改直到它消失。

"我在做一个项目或网页应用，但其实并不算是在写代码——我只是观察情况、动嘴指令、运行程序、复制粘贴，然后它基本上就能跑通了。"

这条推文被看了 450 万次，"vibe coding"成了 2025 年最火的年度词汇之一。但一年过去了，大部分人对它的理解依然是模糊的——很多人把它和 AI 编程混为一谈了。

AI 编程是什么？它范围更广，包含你用 Copilot、Cursor 之类的工具辅助写代码。AI 帮你补全、帮你生成函数、帮你重构。但你依然在看每一行 diff，依然在 review 每一个实现细节。AI 只是让你写得更快了。你还是那个写代码的人。

Vibe coding 完全不同——你不看代码。你输入一个想法，看产出。跑起来了吗？行为符合预期吗？对了就往前走，不对就换一种说法再试。代码具体怎么实现的，你不关心，甚至可能看不懂。

我理解这种不适，因为我自己也经历过。但后来我逐渐意识到，这种不适感，我并不是第一次体验。上一次有这种感觉，是我开始带团队的时候。Vibe coding 给我的感觉，和团队管理一模一样。这个类比一旦建立起来，很多事情就突然说得通了。

当你不再写代码，你的角色变成了什么

Vibe coding 的时候，你同时开着三个 Agent session。一个在重构模块，一个在写测试，一个在调 UI。你不需要盯着每个 session 的每一步，但你需要能快速切进去——看产出、做判断、给方向——然后切到下一个。这不就是一个一线 team leader 的日常吗？

第一次从 IC 转到 TL，最难受的不是工作内容变了，而是你不再拥有对过程的控制。以前所有的代码都经过你的手，你知道每一行写了什么。现在你要把键盘交给别人，看着他用你觉得“不够完美”的方式实现了同样的功能——你得忍住，因为结果是能跑对的。

你的价值不再是去执行、去把代码写对，而是去想清楚你到底要什么，以及去审查这是不是你想要的结果。你需要的不再是高效的执行能力，而是快速的切换与反馈。你需要有对和技术结果的高度的品位。

同一个瓶颈，同一种解法：异步协作。对齐目标和验收标准，放手让人去执行，到 checkpoint 看结果，有 blocker 再介入。最好的 vibe coder 和最好的 TL 做的事情是一样的——他们从来不站在工位后面盯着你写每一行代码。

你校验的不是代码，是结果

传统编程有一个隐含假设：代码写完，应该一次通过。写之前想清楚，写的时候小心翼翼，写完了跑一遍测试，过了就提交。整个流程的核心是对过程的信心——我写的代码我知道对不对。

Vibe coding 彻底放弃了这个假设。你不看代码，你当然不可能对过程有信心。Agent 会幻觉，而且幻觉得很自信——可能只是它没执行好，它就宣称这个方案是失败的。那怎么办？回去看代码？那就退回 AI 编程了。你校验的对象变了。不是代码对不对，是结果对不对。

我遇到过一个典型场景：Agent 告诉我“这个功能实现不了，建议换架构”。我没有去翻它的代码看哪里写错了。我开了一个新 session，把同样的需求重新描述了一遍。它做出来了。我不关心第一个 session 的代码哪里写错了，我只关心：结果能不能出来。能出来，就往前走。出不来，换个方式再试。

这是理念上的根本转变：你不再追求一次写对，你追求的是结果不断逼近正确。效率不来自一次做对，来自反馈和迭代速度。

你的瓶颈：上下文切换与反馈速度

一个一线 leader 的团队管理，更像是 multi-session 的单 Agent 管理，都是放弃了代码的控制权，转而把中心放在了任务的拆解，结果的预期管理和多轮的验收反馈。

回到那个画面：三个 session 同时跑。你是唯一的人类，它们都在等你的反馈。这时候你最大的瓶颈是什么？上下文切换的速度和并行处理事情的能力。Agent 很快。一个 session 跑完可能只要几分钟。但如果你是串行思维——处理完 session A 才去看 session B——你就成了整个系统的吞吐量瓶颈。三个 Agent 并行在跑，被你一个人卡成了串行。

任务的描述与拆解

你给 Agent 的 prompt 就是你给下属的需求文档。描述模糊，产出就模糊。描述精确，产出就精确。很多人 vibe coding 效果差，不是 Agent 不行，是他们的需求描述不行。

给 Agent 一个模糊大目标——“帮我重构这个模块”——它会茫然或者乱来。把大目标拆成具体小任务——“先把这三个函数抽成一个 class，保持接口不变，加上单元测试”——它才能精确执行。拆解任务的能力，本质上就是工程设计的能力。你不再亲手做，但你要知道该怎么做，才能把活拆对。

Context Rot（上下文腐烂）

一个 Agent session 走偏了，你会看到一个熟悉的模式：每次修复都引入新的问题，每次“快好了”之后都冒出新的 bug。它在一个错误的方向上越陷越深。继续纠偏还是推倒重来？这是沉没成本的陷阱。

大多数时候，果断关掉这个 session，用更好的描述开一个全新的，反而更快。因为这个 Agent 的上下文已经被错误污染过了，拖着满是错误的长上下文，只会让 LLM 降智。

Anthropic 官方 Best Practices：“如果你在同一个会话中就同一个问题纠正了 Claude 两次以上，那么上下文就已经充斥了失败的尝试。” 直接建议 /clear 重开。

Sourcegraph 工程师发现：Claude Sonnet 宣传有 20 万 token 限制，但上下文窗口质量在 14.7 万至 15.2 万 token 左右就会出现下降。有效上下文大约只有标称值的 75%。

每次 clear session，就是送走一个已经“污染”的幽灵，再召唤一个全新的。Karpathy 说得对，我们不是在进化动物，我们是在召唤幽灵——幽灵没有记忆积累，没有成长曲线，它只有当下这一次召唤的状态。接受这一点，你才能果断地 kill session 而不觉得浪费。好的管理者果断止损，好的 vibe coder 也是。

Agentic Engineering

2026 年 2 月 4 日，vibe coding 一周年。Karpathy 自己发了一条回顾帖，给这个概念做了升级。他说，vibe coding 是早期的、实验性的玩法。而现在专业级别的开发已经演化到了下一个阶段，他给它起了个新名字：Agentic Engineering。

'Agentic' because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do.

Orchestrating agents：编排 Agent。从 vibe coding 到 agentic engineering，变的是名字，不变的本质是：你不再是那个写代码的人，你是那个让 Agent 写出正确代码的人。

从反馈者到编排者

Orchestrate 这个词最早就是交响乐团的指挥（orchestra conductor）——不演奏任何乐器，但协调所有乐手的节奏、力度和进场顺序。前面讲的都是你直接带着几个 Agent session 干活。你是 TL，Agent 是你的下属。但如果任务足够复杂，光靠反馈已经不够了。你需要规划谁先做什么、谁的产出喂给谁、什么时候该合并、什么时候该回退。这时候你的角色就从反馈者变成了编排者。

“组织架构”升级

无论人和 Agent，组织架构升级的本质是：把“人来判断”变成“机制来判断”。你不再亲自验收每个 Executor 的产出。你要建立一个 Sub-team，让它具备两个能力：自主做日常规划决策，以及内建纠错机制。

我把一个子任务拆成至少 3 个角色：Planner 规划任务，Executor 执行任务，Reviewer 审查过程和结论。

Planner（sub-Leader）负责对抗 Agent“人性”里的短视和畏难，避免 Executor 目标不清晰。Planner 需要长期记忆，他需要记住全局视图，哪些路径试过了，哪些结论已经被验证了，当前的优先级是什么。

Executor 是每次编码执行的时候才 Spawn 出来的，避免了长上下文后的“变蠢”和偏离目标。它积累的不是经验，是偏见。

Reviewer 在处理复杂的多变量问题时候，Review 代码和结论。没有 Reviewer，结论层层汇报上去，可能 Orchestrator 误认为目标达到了。

这个架构解决了两个核心问题：自主决策（Planner 拆解任务，Reviewer 验收结果，日常循环不需要你介入）和纠错机制（Executor 产出有问题，Reviewer 会拦住）。

新晋TL的忌讳

现实中最常见的问题是：这个 Sub-TL 忍不住自己下场干活。如果你用过 Claude Code 的多 Agent 的 Team 模式，你会发现：理论上有一个 main agent 在做调度，但它经常忍不住自己下场写代码。一旦它开始执行，它就被阻塞了。你在终端那边干等着，整个交互节奏崩掉。

带过团队的人一定见过同款 TL——技术最强，从 IC 晋升上来，遇到问题的第一反应是“我自己来比较快”。然后呢？他写代码的那两个小时，三个人等他 review，两个人等他拍方案。他个人产出了，但团队吞吐量反而下降了。同一种病。

用最贵的 Agent，还要知“Agent”善任

团队招聘，同样的预算，招更多便宜的人，还是少量贵的人？很多时候答案是后者。Agent 也完全一样。一个弱模型出现一次幻觉，你花半小时排查、纠偏、重跑。贵的那个一次就对了。你的时间才是整个系统里最贵的资源。

关键角色永远用最好的。Planner 和 Reviewer 用最强的模型，Executor 可以用成本更低的。做判断的地方不省钱，做执行的地方可以控制成本。

Claude：负责出方案、规划、架构设计、需求拆解。思考快、创造性强、写方案条理清晰。

Codex：负责坚定执行、写代码、改 bug、实现细节。一旦拿到清晰方案，执行力爆表。

光有好人还不够，还得有好环境

你一定见过这种情况：一个公认很强的工程师，换了一家公司之后表现平平。不是他能力退化了，是新公司的基础设施太差。再好的人，在这种环境里也只能发挥出三成功力。Agent 也完全一样。

Anthropic 在 2026 年初发布了一篇关于 Agent 评估体系的长文，里面有一个让人警醒的发现：基础设施配置对 Agent 表现的影响，有时候比换一个模型还大。有时甚至超过不同顶级模型之间的差距，实验中最高能差 6 个百分点。

对应到 vibe coding，你给 Agent 的工作环境就是：CLAUDE.md 写得够不够清楚？架构设计文档做充分的整理？工具脚手架有没有沉淀？项目结构是不是易于理解？任务描述有没有歧义？工具链是否稳定？这些不是 Agent 的问题，是你的问题。好的 vibe coder 也一样——Agent 表现差的时候，先审视环境，再怀疑模型。

放弃代码过程，拥抱未来

Vibe coding 要求你放弃对过程的掌控，转而通过机制设计、结果审查、反复试错来达成目标。最初的程序员是写汇编的，然后用汇编做出来了 C 语言，就很少有人写汇编了。现在只不过是用自然语言替代了高级编程语言。放弃代码过程，也可以理解成是换了一种“编程语言”。

但放弃过程控制，不等于放弃质量要求。它是把质量保障的方式，从过程审查转移到了机制设计。

执行前铺好轨道——Planner 规划、Reviewer 审查、CLAUDE.md 作为每个新 Agent 的 onboarding 文档。

执行后验收结果——不看代码怎么写的，只看产出是不是你要的。

中间接受快速试错——效率不来自一次做对，而来自迭代速度。

传统开发像外科手术，每一刀都要精准。Vibe coding 更像雕塑，你不断塑形、修正、打磨，直到它变成你想要的样子。你不需要预先知道每一刀怎么切，但你得知道最终的形状。

所以 vibe coding 真正需要的能力，和写代码关系不大。它需要品味——知道什么是好的结果，即使你不知道怎么实现。需要判断力——什么时候信任产出，什么时候质疑，什么时候 kill session。需要系统思维——怎么设计机制让 Agent 团队自运转。需要表达力——你描述需求的清晰度直接决定产出质量。

你会发现，Vibe Coding 和“怎么写代码”无关，但和“怎么带团队”高度重合。而你管的这个团队，恰好是 Agent 组成的。

📎

原文作者：九老师 | 来源：Recsys Frontier 原文链接：https://blog.recsys-frontier.com/article/vibe-coding-like-man-team 本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。