MIT 大牛传授 Vibe Coding 正确姿势：AI 不是新手的入门玩具，而是专家的超级工具

不二小段

发布于 2026-04-09 18:10:58

1360

文章被收录于专栏：不二小段不二小段

家人们，先来讨论一个问题：

你是不是也觉得，Vibe Coding 这种东西，是那些刚入行的实习生才会用的「玩具」？

作为一个在代码世界里摸爬滚打了十几二十年的资深工程师、架构师，你可能打心底里看不上这种「跟着感觉走」的编程方式，甚至对团队里小年轻提交的、由 LLM 生成的代码不屑一顾。

「这些 AI 太蠢了，连什么是『正确的逻辑』都搞不明白。」

如果你有类似的想法，那么今天这篇文章可能会彻底颠覆你的认知。

一位来自 MIT 的顶尖程序员、开源社区大神 Chris Rackauckas 最近发表了一篇博文，核心观点就一句话：

你们都错了。Vibe Coding 不应该是新手的拐杖，恰恰相反，它应该是、且只应该是专家才能驾驭的超级武器。

这位 Chris 可不是什么无名之辈。先看看他的履历：

• 在 Github 上维护着 超过 200 个 开源包，累计 超过 23,000 颗 star。
• 担任 MIT Julia Lab 的 联合首席研究员。
• 是科技创业公司 Pumas-AI 的 创始架构师。
• 也是 JuliaHub 旗下 Dyad 产品的 VP，负责架构设计。

就是这样一位硬核技术大佬，在一个月前还对 Vibe Coding 抱有强烈的偏见。而现在，他自己的工作流变成了：32 个 Claude agent 在 tmux 窗口里 7x24 小时不间断运行，通过 ssh 随时随地在笔记本或手机上查看进度、分配任务。

从一个坚定的反对者，到一个狂热的实践者，Chris 究竟想明白了什么？

这篇文章，就是他写给所有「看不起 Vibe Coding 的专家们」的终极指南。

✨ 核心心智模型：把 LLM 当成一个「大二实习生」

想要正确地使用 Vibe Coding，首先要抛弃所有不切实际的幻想。

忘掉那些天花乱坠的营销宣传，LLM 根本不是什么博士级别的超级程序员，任何一个真正接触过博士的人来说，这都是显而易见的。

那么，LLM 到底是什么水平？

Chris 给出了他的答案：一个热心、勤奋，但能力有限的大二实习生。

想象一下，这个「实习生」具备以下特点：

• 懂基础：了解编程的基本语法和范式。
• 会模仿：能照猫画虎，复制现有的优秀架构和设计模式。
• 能执行：知道如何运行单元测试、如何使用 Google (或者说，它自己庞大的知识库) 查找资料。
• 知识面广而不深：上过基础编程课，可能还选修过某一门高级课程，但你只要多问几个深入的问题，就会发现他对底层原理的理解相当有限。

现在，如果有这样一个实习生来到你的办公室，而你也愿意给他一个机会，你会怎么安排他的工作？

通常有两条路线。

第一条路：沙盒化探索。 对于一些你本人也不太熟悉的新技术、新工具，抱着「试试看，玩玩也无妨」的心态，让他去做一些探索性的项目。这种任务不太关心代码质量，反正这些代码最终大概率会被扔进垃圾桶，你想要的只是一个能跑起来的 demo，或者一个可以在社交媒体上炫耀一下的酷炫效果。这大概是很多人对 Vibe Coding 的第一印象，觉得「不过如此，没什么大用」。

第二条路：深度整合进成熟项目。 把他安排到你最熟悉、最核心的项目中。为什么？因为你对这个项目了如指掌，这让你审查他的工作变得极其高效。

• 他将要犯的前常见错误，你早就犯过了。
• 他下一步该做什么，你心里一清二楚。
• 你甚至已经为他规划好了未来 6 个月的工作路线图。

这才是培养长期核心团队成员的正确方式，也正是专家级 Vibe Coding 的精髓所在。

人人都是「技术主管」，但并非人人都胜任

Vibe Coding 把每个程序员都变成了团队领导，但这本身就是一个巨大的门槛。你不再是那个埋头敲键盘的人，而是变成了一个需要领导数十个「实习生」的管理者。

领导一个团队从来不是一件轻松的事。它需要技巧、耐心和时间。

很多人都有过「当老板多爽，动动嘴皮子就行」的幻想。但只要经历过一两次大学的小组项目，就会明白一个残酷的现实：如果领导方式不对，最终四个人干活，却只得到一个人的产出，甚至还不如自己单干。

为什么？

首先，你必须对项目领域有足够的深度认知。如果你自己理解一个问题、一段代码都需要花费大量时间，那么管理别人就是天方夜谭。你需要达到那种「扫一眼代码就能立刻指出问题」的境界：

这里缺少 X 和 Y 的测试，合并之前必须补上、给我画一张 Z 的图，我要看看它们之间的关系、你这个写法未来会是性能瓶颈，换掉。

这种直觉，没有上百万行代码的积累是根本无法形成的。而没有这种快速审查的能力，Vibe 编程只会让你陷入泥潭。

其次，也是更重要的一点：

如果你是一个不喜欢带实习生、觉得他们弊大于利的独立贡献者，那么 Vibe Coding 可能真的不适合你。

有些人天生擅长指导和管理，而另一些顶尖的聪明人就是无法从他人那里获得高质量的工作成果。这并不是能力批判，硅谷设立 IC 岗位正是为此。

如果你属于后者，Vibe 编程可能会让你比面对人类实习生时更加沮丧——因为 LLM agent 的记忆力甚至比最差的实习生还要糟糕。如果你没有领导团队的经验和心态，Vibe Coding 只会让你迅速陷入沮丧。

因此，正确的姿势是：做好和 AI agent 开会、给它们规划任务、并严格审查代码的心理准备。

如果你觉得这整个流程比自己写代码还慢，那就不要用 AI 编程；但如果你正好擅长团队协作，那么下来我们将探讨如何让这支「AI 实习生」大军变得高效。

🚀 高手的 Vibe Coding 工作流：当好「包工头」，别当「码农」

很多专家对 Vibe Coding 的初体验都极其糟糕。他们会把自己正在攻克的、九曲十八弯的难题直接扔给 Claude，然后看着它漏洞百出的答案哈哈大笑，最后得出一个结论：「这玩意儿果然不行」。

但这从一开始就错了。你根本不会把这种级别的难题交给一个大二实习生，不是吗？

正确的工作流，更像是 管理一个敏捷开发团队，或者指导一个学生写论文。

秘诀一：批量布置「简单明确」任务，然后走开

你不可能每 10 分钟就跟实习生开一次会，那会把自己和别人都逼疯。对待 LLM agent 也是一样。

正确的做法是：

1. 同时启动多个并行的 agent，让它们在沙盒化的环境里 (比如 Docker 容器) 并行工作。这样它们既不会搞乱你的主系统，也可以被授予一个没有核心读写权限的 GitHub 凭证，即便玩脱了，最坏的结果也只是弄崩自己的容器。
2. 给它们下达清晰、完整、可执行的指令。不要模糊不清，要让它知道完整的步骤。

比如，一个典型的指令可以是：

尝试解决这个开源仓库里的一个简单 issue。创建一个 PR 提交解决方案。一小时后，检查 CI (持续集成) 的测试是否通过。如果测试失败，评估问题所在，如果是小问题就直接修复并提交 commit；如果问题复杂，就报告核心难点是什么。

这里的关键在于，不要花太多时间去精心设计任务。试试直接从你积压的 issue 列表里，让它自己去找「最简单的」那个。

尝试批量发出几十个指令，每过几个小时检查一次，自己则专注于亲自处理着最棘手的核心问题。

秘诀二：像扔垃圾一样扔掉坏代码

当 AI 的产出偏离轨道时，要做的唯一一件事就是——立刻扔掉它。

想象一下，如果一个实习生直接从 StackOverflow 抄了一大段他自己都解释不清的代码，你会怎么做？你会让他重写。

如果他无视团队已经写好的高质量模块，自己造了一个充满 bug、难以维护的轮子，你会怎么做？你会让他重写。

对待 LLM 也要一样。

很多 Vibe Coding 的博主会教你：「ChatGPT，再努力一点！帮我修复它！」 Chris 认为，这种做法比垃圾还垃圾。

LLM 被设计出来的目标就是取悦你，你让它「修复」，它甚至会为了让测试通过而直接修改你的测试用例，或者开始一本正经地胡说八道。

不要浪费任何时间去修正它的错误。一旦发现代码不对劲，直接放弃。这说明这个问题对 Claude 来说太难了，现在轮到你亲自出马了。

秘诀三：追求「总成功数」，而非「成功率」

假设一天下来，40 个任务里成功了 10 个，成功率只有 25%，是不是听起来很糟糕？

大错特错。因为这 10 个成功的 PR，是你几乎没有花费任何心力的情况下 白捡来的。它们的成本只是你每月订阅费里消耗的 token。在 VC 还在为 AI 公司烧钱的今天，这点成本几乎可以忽略不计。

成功率是 Sam Altman 需要操心的问题，而你，只需要关心成功的总数。

所以，忘掉成功率，你的目标应该是最大化 总成功数。

Vibe coding 的价值在于，你有一大堆问题需要解决，只要其中一部分被解决了就行，你并不在乎具体是哪一部分。

秘诀四：先在你最熟悉的代码上用

这也引出了 Vibe Coding 中最反直觉，也是最核心的一个原则。

大多数人的第一反应是把 LLM 用在自己不熟悉的项目上，想让它帮你快速上手。结果呢？你大部分时间都花在了理解和审查它生成的代码上，比自己从头写还要累。

正确的做法是：把 AI agent 应用于你最熟悉、贡献最多的代码库上。

不是让你用它来解决那些让你绞尽脑汁的难题，而是去处理那些被你搁置了 6 个月的 「小问题」：

• 那个早就该做的小型重构。
• 通过 git bisect 找到一周前出现在主分支上的 性能衰退 的具体原因。
• 为 Windows 和 Mac 版本写了专门实现，但在 Linux 部分留了个 // TODO，因为这部分很简单但需要花 4 个小时做单调乏味的体力活。

这些任务的共同点是：如果有人把写好的代码放到你面前，你只需要 5 分钟 就能判断出它是否正确。

这才是 AI agent 最完美的用武之地。

Vibe coding 无法帮你解决某个「特定」的难题，那些硬骨头还得你自己啃。它的价值在于自动化你工作中大量简单、重复的「勤杂工」事务。

实战案例：一个专家的 AI 实习生成果汇报

Chris 用他自己的 AI Bot 账号 (ChrisRackauckas-claude) 提交的几个真实 PR 案例，展示了他 vibe 的实际成果：

• 案例 1: 简单的小型重构
- • 任务：Julia v1.12 引入了一个新特性，为了让代码库兼容，需要在一个包里给所有相关函数添加 specialize 注解。这是一个简单但繁琐的工作。
- • 结果：AI agent 完美地完成了任务，生成了一个清晰的 PR。Chris 花了 1 分钟写 prompt，事后花了 1 分钟 review，搞定。
• 案例 2: 果断关闭的「不适合 Claude」的 PR (数学难题)
- • 任务：解决一个涉及混沌常微分方程和遍历性质的文档构建中的偶发性测试失败。这背后涉及复杂的数学和数值分析。
- • 结果：AI agent 生成的 PR 从数值分析的角度看完全不合理。Chris 立刻关闭了这个 PR，但他通过 AI 的尝试，也定位到了问题的根源。

大部分失败的 PR 最终都会变成这样：虽然没解决问题，但它帮助找到了问题。

• 案例 3: 跨仓库的重复性重构
- • 任务：在 8 个不同的代码仓库中，将使用 Enzyme 自动微分引擎的测试移动到一个特定的测试集。
- • 结果：AI agent 在多个仓库中都成功执行了这一重构。Chris 总共花费了大约 10 分钟，就完成了手动操作至少需要半小时的工作。

重构类任务是 LLM 的一大强项。

• 案例 4: 信息收集与定位
- • 任务：解决一个第三方 C 语言稀疏矩阵求解器扩展中的内存泄漏问题。
- • 结果：AI agent 提交的 PR 试图在当前库中添加一个内存终结器。Chris 一眼就看出，这个修复应该在那个第三方库的绑定层完成。他关闭了 PR，然后去推动解决了这个根源问题。AI 的「错误」答案，却指明了正确的方向。
• 案例 5: 工作量评估
- • 任务：对一个大型代码库进行一项比较复杂的清理和适配工作。
- • 结果：AI agent 没有完成任务，但它生成了一组测试，清晰地列出了要解决的 120 个 具体问题点。这让 Chris 立即明白，这是一个需要整整一周才能完成的巨大任务，从而可以更准确地进行项目规划。

总结一下，真实的编程工作里 80% 都是这类事情。把它扔给 LLM，成功了就笑纳，失败了就自己多花几分钟搞定，不亏。

Chris 最喜欢的一个 prompt 是：「浏览 XXXXXXX 仓库，找到最简单的 issue，然后创建一个 PR 解决它。」这种指令经常能带来惊喜。

💬 HackerNews 讨论

Chris 的这篇文章在 Hacker News 上引发了热烈讨论，各路程序员纷纷下场，观点交锋异常激烈。

观点一：编程的乐趣 vs. 乏味的杂务

这是最普遍的争议。一位用户直言：

「对我这种真正热爱编程的人来说，vibe coding 听起来就像地狱。」

另一位用户则认为，这更适合那些本该去做中层管理的人，因为 Vibe Coding 的核心是清晰地描述需求和定义上下文，这对于享受抽象和逻辑之美的程序员来说是一种折磨。

然而，支持者们反驳道，这恰恰是解放程序员的方式。一位用户的回答一针见血：

「我选择技术栈和项目架构。我选择代码模式和组织结构。当 agent 搞不定难题时我亲自上阵。这哪里像中层管理了？这只是摆脱了工作中所有低智商的部分。」

还有用户用「离岸外包」团队来举例子：

这套工作流和管理离岸开发团队的经验差不多。「成功的关键在于精确、详细的需求规格，以及极其严格的代码审查和测试。」我们需要一个新词来描述这种专业的用法，以区别于业余爱好者的「Vibe 编程」。

Chris 本人也亲自下场回应，他承认自己也热爱编程，但随着职责的增长，他的工作从「创造」变成了无休止地处理 issue 和 PR，以及为团队成员「扫清障碍」。Vibe Coding 的目标正是让 LLM 去处理那些琐碎的杂事，让他能重新找回「创造」的黄金时间。

观点二：新手的捷径 vs. 成长的陷阱

一些评论者对 Vibe Coding 对初级程序员的影响表示了深深的忧虑。

「我看到的最大风险是，初级程序员正在失去真正学习如何编程的机会……这会造成灾难性的『审查疲劳』，他们会倾向于说『嗯，看起来差不多就行了』。」

Chris 对此表示认同。他认为，没有经过大量实践，是无法培养出快速审查代码的能力的。如果新手一开始就依赖 LLM，他们可能永远也学不会这项关键技能。

这恰恰印证了他的核心论点：LLM 辅助编程，真正的使用者应该是那些已经具备了强大代码审查能力的专家。

但也有人持不同看法，认为这可能会催生出一种全新的开发者——他们可能不精通底层代码细节，但极其擅长架构设计和产品实现，就像「非常优秀的产品经理」。

观点三：工具的极限与正确的用法

许多程序员分享了他们在使用 LLM 时的挫败经历。有用户花了两周时间，试图让 LLM 自动清理一个简单的功能标志，结果 LLM 反复犯错，效率甚至不如他自己手动 3 分钟搞定。

这说明，LLM 并非万能。它的能力边界非常清晰，正如 Chris 所展示的，它擅长的是模式化的、有明确规则可循的任务，而不是需要深度理解上下文和业务逻辑的复杂操作。

一位拥有 25 年经验的嵌入式开发者则分享了他的工作流：vibe-planning 先于 vibe-coding。他会花大量时间与 LLM 深入探讨架构和所有实现细节，甚至让 LLM 扮演「反对者」来挑战每一步计划。当整个方案被打磨得无懈可击后，剩下的编码就成了纯粹的体力活，可以放心地交给 LLM 完成。