生产级 Vibe Coding
创建时间： 2026-05-03
来源： [[sources/Vibe coding in prod Code w Claude - 逐字稿]]
相关： Vibe-Coding-to-Agentic-Engineering，Jagged-Intelligence，Deep-Module-Architecture，Reality-of-AI-Now，Software-Fundamentals-in-AI-Coding
演讲者
Eric，Anthropic 研究员，聚焦编码智能体。《Building Effective Agents》作者之一。骑车上班摔断手、打石膏两个月，期间所有代码由 Claude 编写——这段经历驱动了他对 vibe coding 有效性的深入研究。
核心定义：什么是真正的 Vibe Coding
Eric 指出一个常见混淆：大量使用 AI 生成代码 ≠ vibe coding。用 Cursor、Copilot 做紧密反馈循环，人仍在深度参与，这不是 vibe coding。
真正的 vibe coding 是 Karpathy 的原始定义：
“Fully give into the vibes, embrace exponentials, and forget that the code even exists.”
关键词是「忘记代码的存在」。 Vibe coding 让不懂编程的人也能独立构建整个应用——这既是它的革命性，也是它的危险性。
与 Vibe-Coding-to-Agentic-Engineering 的对比：Karpathy 区分了 vibe coding（拉高地板）和 agentic engineering（保持质量天花板），Eric 的演讲则聚焦于如何在生产环境中负责任地使用 vibe coding——这是 agentic engineering 的实操方法论。
Matt Pocock 的 Software-Fundamentals-in-AI-Coding 提供了另一条边界：生产级 AI 编程可以放手一部分实现，但不能放手设计概念、通用语言、反馈循环和代码库结构。否则“忘记代码存在”会退化成 specs-to-code 式的软件熵增。
为什么必须关心：指数增长
AI 能独立完成的任务时长每 7 个月翻倍。2026 年初约 1 小时。
| 时间 | AI 能独立完成的任务 | 人类还能否逐行审代码？ |
|---|---|---|
| 现在 | ~1 小时 | 能，Cursor 紧密反馈 |
| 1 年后 | ~1 天 | 开始困难 |
| 2 年后 | ~1 周 | 不可能 |
Eric 的核心论点：如果 AI 能生成一整天的工作量，人类不可能以逐行审查的速度跟上。想利用这个指数增长，就必须找到一种方式放弃对代码的逐行控制。
编译器类比
早期开发者不信任编译器——用编译器但仍逐行审读汇编输出。这不可扩展。 系统大到一定程度，你不得不信任系统。Vibe coding 面临同样的跨越。
“At a certain point, you start needing to work on systems that are big enough that you just have to trust the system.”
核心方法论：忘记代码，不忘记产品
“We will forget that the code exists but not that the product exists.”
编译器时代我们知道底层有汇编，但不需要思考它。同样，vibe coding 时代我们知道底层有代码，但仍能构建好产品。关键是在你不需要实现细节的情况下，找到一个可以验证的抽象层。
管理你不懂的实现：一个古老问题
Eric 指出这不是新问题——每个管理者都在处理同样的挑战：
| 场景 | 管理者不懂的 | 验证方法 |
|---|---|---|
| CTO 管理领域专家 | 专家的领域知识 | 验收测试（acceptance tests） |
| PM 审查工程特性 | 具体代码 | 亲自使用产品 |
| CEO 审查会计工作 | 财务会计细节 | 抽查关键数据切片 |
| 你 vibe code | AI 生成的实现 | 可验证的 I/O + 测试 |
软件工程师习惯做纯粹的 IC（独立贡献者），理解到堆栈最底层。但为了最大化生产力，必须像每个管理者一样，学会放手一些细节。
唯一的例外：技术债
有一个当前无法通过抽象层验证的东西：技术债（tech debt）。
- 大多数系统——会计、产品——有不读实现就能验证的方式
- 技术债没有好的验证方法，除非你自己是实现专家
- 这意味着 vibe coding 不能无差别地用在所有地方
四条生产级 Vibe Coding 原则
原则一：做 Claude 的 PM
“Ask not what Claude can do for you, but what you can do for Claude.”
Vibe coding 时你是 Claude 的产品经理。核心问题是：
如果一个新人第一天入职，你需要给他们什么信息才能让他们成功？
- 带他们参观代码库
- 告诉他们需求、规格和约束
- 这些上下文正是你需要喂给 Claude 的
Eric 的实操流程：
- 花 15-20 分钟收集指导信息到一个 prompt 中
- 这 15-20 分钟不是手写——而是与 Claude 的另一段对话：探索代码库、找文件、一起制定计划
- 拿到计划文档后，新对话 or 新上下文中交给 Claude 执行
- 这种方法的成功率非常高
信息量的平衡：
- 不关心实现方式时 → 只给需求，不谈实现细节
- 熟悉代码库时 → 指定类名、参考类似特性
- 关键：不要过度约束模型——像带新人一样，给够上下文但不微管理
警告： vibe coding 不适合完全不懂技术的人。无法提出正确的问题 = 无法做有效的 PM = 大概率失败。
原则二：聚焦叶子节点
核心架构（白色） 叶子节点（橙色）
┌───┐ ┌───┐
│ ├──┐ │ ● │ ← 没有其他模块依赖
└───┘ │ └───┘
├──┐ ┌───┐
│ │ │ ● │ ← 不太会变化
│ ├──┐ └───┘
│ │ │ ┌───┐
│ │ │ │ ● │ ← 即使有技术债也无妨
└──┘ │ └───┘
│
└── 核心系统需要人类深度理解
- 叶子节点 = 末端功能、独立特性、无其他模块依赖、不太可能变化
- 核心架构 = 分支和主干，其他东西在此之上构建，会变化、需要扩展
在叶子节点上 vibe code 是安全的——技术债被隔离，不影响系统其他部分。核心架构仍然需要工程师深度理解，因为它们会变化、会被依赖、需要保持可扩展性。
这与 Deep-Module-Architecture 中”战略 vs 战术程序员”的框架高度互补：人类做战略判断（哪个部分可以放手），AI 做战术执行（在安全区域内生成代码）。
模型在持续改进（Claude 4 比 3.7 更值得信任），未来可放手的范围会逐步扩大。
原则三：设计可验证性
核心问题：如何在不读代码的情况下知道这个变更是正确的？
Eric 的答案：在设计阶段就让系统变得可验证——设计压力测试、设计可检查的输入/输出。
原则四：拥抱指数增长
“Machines of Loving Grace is not science fiction. It’s a product roadmap.”
不只是”模型会变好”，而是会变得超出想象。20 年前几 KB RAM，现在 TB 级。指数增长不是线性外推——它在后期爆发。
实际影响：
- 当功能成本从两周降到一天，你突然会去做那些”太大的功能”
- 软件的边际成本降低 → 你能构建更多软件
- 1-2 年后，坚持逐行审代码的人会成为瓶颈
案例：22,000 行产品级 RL 代码
Anthropic 合并了一个 22,000 行的 PR，大量由 Claude 编写。如何负责任地做到的：
| 步骤 | 做了什么 |
|---|---|
| 做 Claude 的 PM | 不是一句话就合并——数天的人类工作：制定需求、指导 Claude、确定系统应该是什么 |
| 聚焦叶子节点 | 变更集中在叶子节点——技术债被隔离，不期望近期需要修改这些部分 |
| 人类深度审查 | 对认为重要的、需要可扩展的部分做了重度人工审查 |
| 压力测试 | 精心设计稳定性压力测试，长时间运行验证 |
| 可验证 I/O | 设计系统时就让它具有可人工检查的输入和输出 |
结果： 与任何其他代码变更同等的信心水平，但交付时间和精力只有手写的一小部分。更重要的是——认知转变：当你知道两周的工作可以一天完成，你会开始去做那些原本觉得”太贵”的大型特性。
实操建议
TDD 与 Vibe Coding
Claude 倾向于先写实现再写测试，或者写过于实现细节化的测试。Eric 的做法：
- 强制要求写 3 个端到端测试：happy path + 两个 error case
- 保持测试通用和端到端——不过度深入实现细节
- 先读测试再看实现——如果测试合理且通过，就对代码有信心
- 测试要极简（minimalist），这样 Claude 不会陷入细节
工作流
- Claude Code（终端） → 探索代码库、找相关文件、制定计划
- Compact / 新会话 → 计划写入文档后 compact，清除探索阶段的大量 token
- Claude Code 执行 → 按计划实现
- Cursor 精修 → 用 Cursor 做精确的行级修改，或自己直接改
何时 compact： 像人类程序员一样——当达到一个自然的”停下来吃午饭”的节点时。把计划写入文档，compact 清除 100K 探索 token。
学习：懒惰者不会进步
Eric 对”AI 时代如何学习编程”的回答：
- 悲观面： 不再经历编码的”挣扎”和”打磨”
- 乐观面： AI 是永远在线的结对程序员——review 代码时可以随时问”这个库是什么？为什么选它？”
- 区别在于是否主动： 懒惰的人不会学习；主动的人能在同样的日历时间内从 4 倍多的教训中学习（因为架构决策的验证周期从 2 年压缩到 6 个月）
安全性
2026 年初有报告称 top 10 vibe coded 应用存在严重安全漏洞。Eric 的回应：
- 这些通常是完全没有技术背景的人做的——对游戏和创意项目没问题
- 生产系统需要足够的技术知识来知道什么问题是危险的
- Anthropic 的案例是完全离线的系统——不存在安全风险
底线： 安全性取决于你是否能做 Claude 的有效 PM。需要足够的领域知识来提出正确的问题和引导方向。
结语
生产级 vibe coding 不是无脑信任 AI，而是有纪律地放手：
- 做 PM，不做 IC — 花时间收集上下文，让 AI 执行
- 选对战场 — 叶子节点安全，核心架构仍需人类
- 先设计验证 — 在不读代码的前提下能确认正确性
- 拥抱变化 — 指数增长意味着今天做不到的事明天能做到
“Remember the exponential. It’s okay today if you don’t vibe code, but in a year or two, it’s going to be a huge disadvantage if you yourself are demanding that you read every single line of code.”
参考资料
- 来源：Vibe coding in prod | Code w/ Claude（Eric @ Anthropic, YouTube）
- Vibe-Coding-to-Agentic-Engineering（Karpathy 的 vibe coding → agentic engineering 框架）
- Deep-Module-Architecture（战略 vs 战术程序员、深模块与叶子节点思维）