type
status
date
slug
summary
tags
category
icon
password
priority
这不是一篇教大家怎么实操文章，不谈具体的工具和技术，我们来谈谈Vibe Coding的心法。
Vibe Coding 本质是利用 Agent 编码，Agent 背后是 LLM，LLM 是人类的”幽灵“，这出自 Karpathy 2025 年终总结：”we're not evolving animals. We're summoning ghosts.“，语言是人类世界的投影，LLM 是人类的幽灵。
工具和技术层出不穷，这是历史上从未出现过的新技术，没有人有经验。但是人性是一致的，拿捏住 Agent 的"人性"，把 Agent 当人来管，会让Vibe Coding 从迷茫走向有迹可循。
先说清楚什么是 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 的日常吗？手上同时跑着三四条线，A 员工在出技术方案，B 员工在联调，C 员工在排查线上问题。
第一次从 IC 转到 TL，最难受的不是工作内容变了，而是你不再拥有对过程的控制。以前所有的代码都经过你的手，你知道每一行写了什么。现在你要把键盘交给别人，看着他用你觉得"不够完美"的方式实现了同样的功能——你得忍住，因为结果是是能跑对的。
如果team成员实现的功能和结果不符合你的预期，你也不是去抢过它的键盘去实现你想要的功能，而是通过交流和反馈，来让它的结果变得更好。也许你有能力一次就把事情做对，但是你要接受这样的依靠精确描述和多次反馈，驱动出正确的结果。因为你管理的是一个 team，这个 team 类似的事情可能还有 5 件需要你一一去反馈，但你不可能有5双手去写他们的代码。
Vibe Coding，面对多个 Session 的 Agent 编码，你似乎在做相同的事情：你要靠精确的描述让 Agent 理解他具体要做什么；你要靠一轮一轮的反馈，像捏泥人一样去塑造出你想要的结果。
你的价值不再是去执行、去把代码写对，而是去想清楚你到底要什么，以及去审查这是不是你想要的结果。你需要的不再是高效的执行能力，而是快速的切换与反馈。你需要有对技术和结果的高度的品位。
同一个瓶颈，同一种解法：异步协作。对齐目标和验收标准，放手让人去执行，到 checkpoint 看结果，有 blocker 再介入。最好的 vibe coder 和最好的 TL 做的事情是一样的——他们从来不站在工位后面盯着你写每一行代码。
你校验的不是代码，是结果
传统编程有一个隐含假设：代码写完，应该一次通过。写之前想清楚，写的时候小心翼翼，写完了跑一遍测试，过了就提交。整个流程的核心是对过程的信心——我写的代码我知道对不对。
Vibe coding 彻底放弃了这个假设。你不看代码，你当然不可能对过程有信心。Agent 会幻觉，而且幻觉得很自信——可能只是它没执行好，它就宣称这个方案是失败的。
那怎么办？回去看代码？那就退回 AI 编程了。
你校验的对象变了。不是代码对不对，是结果对不对。
我遇到过一个典型场景：Agent 告诉我"这个功能实现不了，建议换架构"。我没有去翻它的代码看哪里写错了。我开了一个新 session，把同样的需求重新描述了一遍。它做出来了。
我不关心第一个 session 的代码哪里写错了，我只关心：结果能不能出来。能出来，就往前走。出不来，换个方式再试。
这是理念上的根本转变：你不再追求一次写对，你追求的是结果不断逼近正确。 效率不来自一次做对，来自反馈和迭代速度。
你的瓶颈：上下文切换与反馈速度
一个一线 leader 的团队管理，更像是 multi-session 的单 Agent 管理，无论是用 vibe kanban 这样的多 session 管理工具还是基于简单的多 tab 切换，都是放弃了代码的控制权，转而把中心放在了任务的拆解，结果的预期管理和多轮的验收反馈。
回到那个画面：三个 session 同时跑。你是唯一的人类，它们都在等你的反馈。
这时候你最大的瓶颈是什么？上下文切换的速度和并行处理事情的能力。
Agent 很快。一个 session 跑完可能只要几分钟。但如果你是串行思维——处理完 session A 才去看 session B，再去看 session C——你就成了整个系统的吞吐量瓶颈。三个 Agent 并行在跑，被你一个人卡成了串行。
TL 也是一样的。手上同时跑着三四条线，如果你切不动上下文，所有人都在等你。
Agent 跑完了，你多快能判断结果是否正确？你犹豫的每一分钟，都是整个系统在空转。好的 TL 看完一个方案三分钟就能给结论，差的 TL 要犹豫一天。在 vibe coding 里，这个差距会被放大到极致，因为 Agent 的执行速度太快了，你跟不上就会成为瓶颈。
我尝试用了各种各样开源的工具，最后发现简单反而更好：直接在 tmux 下面加了一个状态栏，哪一个 Agent 跑完了我都能收到反馈。
输入速度也是瓶颈之一。语音输入是一个很好的方案，我试过 Superwhisper 之后最终切换到了 Typeless，它的使用体验、准确度和延迟的平衡非常出色，现在超过 10 个字基本不打字了。墙裂推荐！！
任务的描述与拆解
你给 Agent 的 prompt 就是你给下属的需求文档。描述模糊，产出就模糊。描述精确，产出就精确。
很多人 vibe coding 效果差，不是 Agent 不行，是他们的需求描述不行。就像很多时候下属做的东西不对，不是下属能力不行，是 TL 自己都没想清楚要什么，没有清晰地表述出来。
Claude Code 的 Plan 模式，这个实际上连官方都在推荐使用，但是我觉得还不够极致，他总是问上个位数的问题就草草了事。
Superpower 的更为极致：先不写代码， 通过Brainstorming ， 需求澄清 & 交互式设计细化，写详细计划 ，把任务拆成小块、可验证的步骤。我甚至有一次花了快一个小时在写 Plan。
给 Agent 一个模糊的大目标——"帮我重构这个模块"——它会茫然或者乱来。把大目标拆成具体的小任务——"先把这三个函数抽成一个 class，保持接口不变，加上单元测试"——它才能精确执行。
拆解任务的能力，本质上就是工程设计的能力。你不再亲手做，但你要知道该怎么做，才能把活拆对。
可能有很多项目，它和标准软件工程的流程是不一样的。我的做法是我把Superpower这个库甩给 Claude，让它学习自我改进，个性化适配当前项目。
Context Rot（上下文腐烂）
一个 Agent session 走偏了，你会看到一个熟悉的模式：每次修复都引入新的问题，每次"快好了"之后都冒出新的 bug。它在一个错误的方向上越陷越深。
继续纠偏还是推倒重来？
这是沉没成本的陷阱。你已经投入了这么多 token，已经等了这么久，再试试也许就好了。但大多数时候，果断关掉这个 session，用更好的描述开一个全新的，反而更快。因为这个 Agent 的上下文已经被错误污染过了，拖着满是错误的长上下文，只会让 LLM 降智，白白消耗你的时间。
这时候一个合理的做法：让这个 Agent 把他的经验沉淀到一个文档里，然后 clear or kill session，换一个新的 session 再战。虽然 claude code 会自己压缩上下文，但你会发现当你让他走到了这一步，就是在用一个降智残血的 Agent。
"Context Rot"（上下文腐烂）—— 2025 年 Chroma Research 发表的研究，专门造了这个词。结论是：即使在非常简单的任务上，随着输入长度增加，模型表现也会下降，而且是非均匀的、不可预测的下降。
- Anthropic 官方 Best Practices 原话："如果你在同一个会话中就同一个问题纠正了 Claude 两次以上，那么上下文就已经充斥了失败的尝试。“ 直接建议 /clear 重开。
- Sourcegraph 工程师 Geoffrey Huntley 发现：尽管 Claude Sonnet 宣传有 20 万 token 的限制，但上下文窗口的质量在 14.7 万至 15.2 万 token 左右就会出现下降。 有效上下文大约只有标称值的 75%。
- Anthropic 发布 Opus 4.6 时也承认：关于 AI 模型的一个常见抱怨是“上下文腐败”（context rot），即当对话超过一定数量的 token 时，模型性能就会下降。
实测上的经验就是,不要让 context 打满超过 75%, 任务原子化小规模提交,利用 progress.md 和 git 高频率保存进度,clear session 后利用 progress.md 和 git 历史恢复上下文,以最优的状态和低token成本进入下一个 feature 开发.
每次 clear session，就是送走一个已经"污染"的幽灵，再召唤一个全新的。Karpathy 说得对，我们不是在进化动物，我们是在召唤幽灵——幽灵没有记忆积累，没有成长曲线，它只有当下这一次召唤的状态。接受这一点，你才能果断地 kill session 而不觉得浪费。
带团队也一样。一个人在一个方向上钻了太久，TL 需要替他做那个他自己做不了的决定：停下来。不是否定他的努力，而是方向错了，继续下去只是消耗。帮助你的员工清理好他的”上下文“，让他满血再战，可能是一个更好的做法。
好的管理者果断止损，好的 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。这注定是一个关键的词。
前面讲的单 Agent 模式里，你的核心角色是反馈者。你开几个 session，看结果，给方向，本质上是一个一线 TL 在做高频 review。但当任务复杂到一定程度——几十个 Agent 并行、任务之间有依赖、执行周期拉长——光靠反馈已经不够了。你需要规划谁先做什么、谁的产出喂给谁、什么时候该合并、什么时候该回退。这时候你的角色就从反馈者变成了编排者，这正是 Karpathy 说的 orchestrating。
从 vibe coding 到 agentic engineering，变的是名字，不变的是本质：你不再是那个写代码的人，你是那个让 Agent 写出正确代码的人。
从反馈者到编排者
Orchestrat这个词最早就是交响乐团的指挥（orchestra conductor）——不演奏任何乐器，但协调所有乐手的节奏、力度和进场顺序。后来用在了软件和容器的服务调度，现在再次升级放到了AI领域的Mult-Agent 上了。
前面讲的都是你直接带着几个 Agent session 干活。你是 TL，Agent 是你的下属，你亲自看每个人的结果、亲自给反馈。这里面的瓶颈依旧是人。
但如果任务足够复杂，比如进行推荐算法研究（我一开始认为这会很简单，但实际可能比做一个轻量级的应用还复杂，因为变量太多了）。你会发现这个模式撑不住了，因为一次训练和测评的时间是很长的。如果 Agent 不能自主运行，依靠你的及时反馈，实际上瓶颈还在于你：你需要在每一次它完成之后都要过来反馈。或者是一个极其复杂的应用，你没法同时开 20 个 session 做效果的跟进。你的上下文切换和反馈速度再快，也有上限。
这时候你需要的不再是"更快地切换上下文，更快地反馈"，而是组织架构的设计。
类比很直接：你不再是一线 TL 了，你被晋升成了总监，你是带 TL 的人。你不直接管每个 IC（Sub-Agent），你管的是一线 leader（Claude Code 的 Team 模式里就叫 team-leader），一线 leader 再去管具体的执行者。这是一个两层的组织架构。
在单 Agent 模式下，你关心的是"我怎么更快地给反馈"。在多 Agent 编排下，你关心的是子团队能不能自主运转。
一个好的子团队应该能做到两件事：自己拆解任务，自己验收结果。它不需要你盯着每一步，你只需要在关键节点介入——审方向、看结论、做取舍。
这意味着你需要一个像"一线 TL"角色的 agent。它接收你的高层需求，拆成具体任务，分发给执行者，收集结果，判断是否达标。
”组织架构“升级
无论人和Agent，组织架构升级的本质是：把"人来判断"变成"机制来判断"。
你不再亲自验收每个 Executor 的产出。你要建立一个 Sub-team，让它具备两个能力：自主做日常规划决策，以及内建纠错机制。
一个单一的 Agent 在执行复杂任务或长时间运行的时候，会逐步积累错误，这就是我们说过的“上下文腐烂”。除此之外，它还会出现“短视”的问题。
Anthropic 做了一个实验，让 Claude 等 AI agent 自主尝试完成复杂长期任务（比如构建一个类似 claude.ai 的复杂 web 应用），结果发现这些 agent 非常短视（myopic）：它们倾向于只做简单部分、过早宣称任务完成、留下大量未完成或无文档的工作，就像人类有时也会挑容易的干一样。
为了解决这个问题，他们引入了多 agent 协作结构：用一个专门的 initializer/planner agent（初始化/规划者）在项目一开始就建立清晰的结构（比如 JSON 功能列表、进度日志文件 claude-progress.txt、git 初始提交等），然后让后续的 coding executor agent 每次只专注增量完成一小部分功能、写测试、提交干净的 commit，并为下一轮留下明确状态，从而实现跨多次 session 的长期协调和持续推进。
而我在做自主实验的时候，喜欢把一个子任务多轮跌倒拆成至少 3 个角色：Planner 规划任务，Executor 执行任务，Reviewer 审查过程和结论。
Planner（sub-Leader） 负责对抗 Agent”人性“里的短视和畏难，避免 Executor 目标不清晰，运行中逐步走偏。Planner需要长期记忆，他需要记住全局视图，哪些路径试过了，哪些结论已经被验证了，当前的优先级是什么。它们提供的是连续性和判断力。
Executor 是每次编码执行的时候才 Spawn 出来的，避免了长上下文后的”变蠢“和偏离目标。
直觉上你可能觉得 Executor 应该保持上下文——它做了任务 1，有了"经验"，做任务 2 应该更顺手吧？恰恰相反。它积累的不是经验，是偏见。
一个 Executor 在任务 1 里遇到了某个坑，这个"记忆"会污染它对任务 2 的判断。它开始为失败找合理化解释——"不是我代码的问题，是方案本身有缺陷"。它从一个执行者，变成了一个带着成见的反对者。而且随着上下文越来越长，它的推理能力本身也在下降—— context rot，上下文越长，模型越降智。
这个画面在人类团队里也不陌生。一个人在一个方向上卡太久，他就会变成那个方向最坚定的反对者。不是因为方案真不行，而是他在心理上已经和那些失败绑定了。这时候换一个新人，给他同样的任务，反而很快就做出来。
Reviewer 是在处理复杂的多变量问题时候，Review 代码和结论的。下面这个例子，没有这个 Reviewer，Executor的结论层层汇报上去，可能Orchestrator认为目标达到了，开始询问你是否终止任务了。
这个架构解决了两个核心问题。自主决策：Planner 拆解任务，Reviewer 验收结果，日常循环不需要你介入。纠错机制：Executor 产出有问题，Reviewer 会拦住；Executor 自身不会因为长时间运行而积累偏见，因为每次都是新的。
新晋TL的忌讳
听起来很美好。但现实中最常见的问题是：这个 Sub-TL 忍不住自己下场干活。
如果你用过 Claude Code 的多 Agent 的Team模式，你会发现一个问题：理论上有一个 main agent 在做调度，它应该接收你的需求、拆解任务、分发给 sub-agent、收集结果。但它经常忍不住自己下场写代码。
你看看，和我们上面说的跟从 IC 转来的 TL 一样！因为他太会写代码了！
一旦它开始执行，它就被阻塞了。你在终端那边干等着，整个交互节奏崩掉。它本应是你和 Sub-Agent 团队之间的通道，现在这个通道堵住了。
带过团队的人一定见过同款 TL——技术最强，从 IC 晋升上来，遇到问题的第一反应是"我自己来比较快"。然后呢？他写代码的那两个小时，三个人等他 review，两个人等他拍方案。他个人产出了，但团队吞吐量反而下降了。
同一种病。TL 的核心职责不是产出代码，是让整个团队高效运转。它的的核心职责不是执行任务，是协调、规划、审查。一旦它开始"动手"，它就丢掉了自己最大的价值。
现在最好的工具（Opus 4.6）还没完全做到这一点，即便你很清楚地用 prompt 说明了它是一个调度者和编排者，它还是偶尔会自己动手编码。最后没有办法，我给他加了一个hook。只要他再写 .py 或 .sh 脚本，他就会被 hook 打断，然后被提醒：“你是一个Orchestrator！你的核心任务不是执行，把执行交给你的Team”。
用最贵的 Agent，还要知”Agent“善任
团队招聘，同样的预算，招更多便宜的人，还是少量贵的人？
很多时候答案是后者。一个优秀的人不只是"少犯错"，他还能主动发现你没想到的问题、提出你没考虑过的方案。而几个平庸的人加在一起，你花在沟通、纠偏上的时间，远超你省下的那点薪资差。
Agent 也完全一样。Claude Code Max 订阅一个月两三百美金，远高于其他替代品。但你算算这笔账：一个弱模型出现一次幻觉，你花半小时排查、纠偏、重跑。贵的那个一次就对了。你的时间才是整个系统里最贵的资源。
而且还有一层隐性成本——错误结论的级联效应。 一个不准确的实验结论，你基于它做了架构决策，团队按这个方向开发了两周，最后发现前提就是错的。这两周的成本，远超你省下的那点订阅费。
但光用贵的还不够，关键是把对的 Agent 放在对的位置上。关键角色永远用最好的。Planner 和 Reviewer 用最强的模型，Executor 可以用成本更低的（如Sonnet，不过也不便宜）。做判断的地方不省钱，做执行的地方可以控制成本。
X 上这个更绝，claude 出方案，codex 坚定执行。
- Claude：负责出方案、规划、架构设计、需求拆解。它思考快、创造性强、写方案条理清晰、上下文理解也很好，适合做“脑力活”和高层设计。
- Codex：负责坚定执行、写代码、改 bug、实现细节。很多人反馈 Codex 一旦拿到清晰方案，就特别“耐操”、执行力爆表，一次过概率高、很少胡来或幻觉，适合当“老黄牛”干脏活累活。
人才密度的逻辑，和 Agent 选型的逻辑，是同一套。
光有好人还不够，还得有好环境
不过，选对了人只是一半。
你一定见过这种情况：一个公认很强的工程师，换了一家公司之后表现平平。不是他能力退化了，是新公司的基础设施太差——编译测试一次要四十分钟，开发环境三天两头挂，文档陈旧到不如没有，代码规范形同虚设。再好的人，在这种环境里也只能发挥出三成功力。
Agent 也完全一样。Anthropic 在 2026 年初发布了一篇关于 Agent 评估体系的长文，里面有一个让人警醒的发现：基础设施配置对 Agent 表现的影响，有时候比换一个模型还大。有时甚至超过不同顶级模型之间的差距，实验中最高能差6个百分点。
同一个 Agent，在干净的环境、稳定的工具链上跑，表现优秀。换到一个有状态泄漏、资源争抢、环境不隔离的设置里，分数可能直接腰斩。他们甚至发现，修好几个基础设施的 bug——比如评分逻辑写反了、环境没有做隔离——同一个模型的分数能跳二三十个点。这个增益远超模型本身迭代带来的提升。
OpenAI 在 2026 年 2 月发布的 Harness Engineering 更是把这个理念推到了极致。他们的团队三个工程师，用 Codex 从零开始构建了一个百万行代码的产品，全程零手写代码。核心哲学就一句话："Humans steer. Agents execute." 当 Agent 遇到问题时，修复方式几乎从来不是"再试一次"，而是工程师反思：环境里缺了什么能力，怎么让它对 Agent 来说既可读又可执行？ 他们把所有知识都推进了代码仓库本身——不是一个巨大的指令文件，而是结构化的文档目录，AGENTS.md 只是一个目录索引，指向更深层的设计文档、架构规范和执行计划。Slack 里对齐过的架构决策？如果没有沉淀到仓库里，对 Agent 来说就和不存在一样——就像一个新员工入职三个月后根本不知道那次讨论。
换句话说，你以为 Agent 不行，可能只是它的工作环境太差了。
这和人的道理一模一样。你作为 TL，职责不只是选对人、分好活，你还得给团队搭好基础设施。开发工具好不好用？组织架构协作流程顺不顺畅？信息传递有没有损耗？这些"看不见"的东西，决定了一个人到底能输出他能力的三成还是八成。
对应到 vibe coding，你给 Agent 的工作环境就是：CLAUDE.md 写得够不够清楚？架构设计文档做充分的整理？工具脚手架有没有沉淀？项目结构是不是易于理解？任务描述有没有歧义？工具链是否稳定？这些不是 Agent 的问题，是你的问题。就像团队的基础设施不好，不是员工的问题，是管理者的问题。
好的 TL 不会说"这个人不行"，他会先想"我是不是没给他创造好的条件"。好的 vibe coder 也一样——Agent 表现差的时候，先审视环境，再怀疑模型。
放弃代码过程，拥抱未来
说了这么多，我想回到最开始的那个不适感。
Vibe coding 要求你放弃对过程的掌控，转而通过机制设计、结果审查、反复试错来达成目标。这对很多人来说是一种冒犯——你是工程师，精确控制过程是你的专业素养，现在你告诉我不用管过程了？
有一种更好理解的方式，最初的程序员是写汇编的，然后用汇编做出来了 C 语言，就很少有人写汇编了。现在只不过是用自然语言替代了高级编程语言。放弃代码过程，也可以理解成是换了一种“编程语言”。
但放弃过程控制，不等于放弃质量要求。它是把质量保障的方式，从过程审查转移到了机制设计。执行前铺好轨道——Planner 规划、Reviewer 审查、CLAUDE.md 作为每个新 Agent 的 onboarding 文档。执行后验收结果——不看代码怎么写的，只看产出是不是你要的。中间接受快速试错——效率不来自一次做对，而来自迭代速度。
传统开发像外科手术，每一刀都要精准。Vibe coding 更像雕塑，你不断塑形、修正、打磨，直到它变成你想要的样子。你不需要预先知道每一刀怎么切，但你得知道最终的形状。
所以 vibe coding 真正需要的能力，和写代码关系不大。它需要品味——知道什么是好的结果，即使你不知道怎么实现。需要判断力——什么时候信任产出，什么时候质疑，什么时候 kill session。需要系统思维——怎么设计机制让 Agent 团队自运转。需要表达力——你描述需求的清晰度直接决定产出质量。
你会发现，Vibe Coding和"怎么写代码"无关，但和"怎么带团队"高度重合（哈哈，扣题了）。
而你管的这个团队，恰好是 Agent 组成的。