引作者背景：为什么这个话题对 Eric 不是抽象问题
Eric 在演讲开头讲了个细节：去年他骑车上班把手摔骨折了，整整两个月没法自己敲代码——所有代码都是 Claude 写的。"如何让 Agent 真的能替我把活干完"对他来说不是抽象问题，是当时的吃饭问题。这次演讲就是他这两年的方法论提炼。
核心洞察：vibe coding 的本质不是"让 AI 写代码"，而是忘掉代码的存在，只盯产品行为——但这需要先建立一套可验证的抽象层。
一什么才算 vibe coding？
Eric 不同意这个误区："只要大部分代码是 AI 生成的，就是 vibe coding。" 用 Cursor / Copilot 把代码大部分让 AI 写——你还在紧反馈循环里：每段都看、每段都改。这不是 vibe coding。
他坚持引用 Andrej Karpathy 的原始定义：
"Fully give into the vibes, embrace exponentials, and forget that the code even exists."
关键短语：forget that the code even exists——忘掉代码本身的存在。
为什么 vibe coding 火，又为什么风评两极
- 正面：让非工程师也能造软件——这是 Cursor / Copilot 都没能解锁的人群；
- 负面：第一次写代码的人造出来的东西全是漏洞——API key 泄露、订阅绕过、数据库里乱写垃圾数据……
所以"vibe coding 在 prod 用"听上去像伪命题，但 Eric 说：我们必须严肃想这个事。
二为什么必须现在严肃想 vibe coding：指数曲线
AI 能独立完成的任务长度大约每 7 个月翻一倍。
今天 Claude 一次能做 1 小时的活——你可以全看完，没问题。
但下一年它能产出一整天的工作量；再下一年一整周。你不可能用紧反馈方式跟得上。
那时如果你还坚持「不把每行代码都过一遍我绝不放手」——你就成了瓶颈。
编译器类比
早期编译器刚出来的时候，工程师们也不信任它，会去读编译器生成的汇编，确认是不是和他们自己写的一样。这个习惯没办法 scale。
后来大家放弃了。今天你我都还知道有汇编这回事，但我们不读它，照样能把软件做好。
但要小心定义：忘掉代码，不能忘掉产品
"Forget that the code exists, but not that the product exists."
把"产品行为是否正确"这件事接得住——这是放手 vibe coding 的前提。
三怎么管理你不懂的东西？老问题了
"放手让别人/某个系统替你干活"这件事，人类社会练了几千年。
| 谁 | 管什么自己不亲手做 | 怎么管 |
|---|---|---|
| CTO | 某专业领域的实现细节 | 验收测试——不读代码也能验是否过线 |
| PM | 工程团队怎么写代码 | 试用产品——直接当用户用，看体验对不对 |
| CEO | 财务总账 | 抽查关键数字 + 切片——对几个能验证的数自己心里有底 |
结论：管理"自己不懂深处的事情"是几千年来管理学的常态。只有软件工程师特别不习惯——因为我们到目前为止都是纯 IC（个人贡献者），习惯把整栈嚼透。做生产级 vibe coding 的第一步，就是放下这个执念。
四有一件事今天还不能靠抽象层验证：技术债
几乎所有"我不懂细节但能验证"的领域（财务、产品、运维），都能找到验收手段。
但技术债不行。 想知道一段代码会不会把未来扩展卡死、有没有埋暗坑——目前唯一靠谱的方法还是有人读这段代码。
怎么办？答案是只在"不重要"的代码上放手 vibe code。
五策略：只在 leaf nodes 上 vibe code
把代码库当一棵树看——只在叶节点放手 vibe code：
| 位置 | 适不适合 vibe code | 理由 |
|---|---|---|
| 核心骨架 / 关键抽象 | 不适合：保持人类深度审阅 | 改这里会牵动一切，技术债代价高 |
| 叶节点：末端 feature、配套脚本、UI 细节 | 适合 | 几乎没有东西依赖它，未来不太可能再改 |
随着模型越来越好（Claude 4 比 3.7 明显成熟），"叶节点"的边界会向上推——未来可以放手 vibe 的位置会越多。
六姿势 1：Be Claude's PM——做 Claude 的产品经理
"Ask not what Claude can do for you—ask what you can do for Claude."
要把自己当成 Claude 的 PM 而不是 Claude 的程序员。
给 Claude 的"入职 onboarding"
类比：一个工程师入职第一天，你直接说"实现某 feature"——他不可能交得出来。你得：
- 带他过一遍代码库；
- 给他需求 / 约束；
- 告诉他风格、模式、已有同类例子。
给 Claude 也一样。
Eric 的实际工作流——往往花 15~20 分钟准备 prompt，但准备完之后 Claude 一次性写对的概率非常高。
谁不适合做生产级 vibe coding
完全不懂技术、不能问对问题的人，不应该全自动 vibe coding 一个生产业务。他们当不了 Claude 的 PM，整个流程就会失控。
这不是劝退非技术人员——他们可以做游戏、做 demo、做艺术品；但真正上线服务、有用户数据的系统，需要会问对问题的人在旁边把舵。
七案例：22,000 行 RL PR 怎么用 vibe coding 合进去
Eric 拿出了 GitHub 上的截图——一次 22k 行的真实 PR，合进了 Anthropic 生产环境的强化学习代码库。这是一个真实案例，不是概念演示。
| 步骤 | 做了什么 | 命中本演讲的哪条原则 |
|---|---|---|
| 1. 数天的 PM 工作 | 工程师手工把需求、约束、关键决策捋清楚，做 plan | 给 Claude 完整 onboarding |
| 2. 改动集中在叶节点 | 主要落在"不会被频繁迭代"的部分 | leaf-node 策略 |
| 3. 核心扩展点人工 review | 真正需要将来扩展的少量骨架，人逐行读 | 不在骨架上 vibe |
| 4. 压力测试 | 长时间跑稳定性测试 | 找到一个可验证的抽象层（稳定性指标） |
| 5. 设计可观察的输入输出 | 整个系统在边界处就能验证对错 | 不读代码也能验 |
结果不只是"省时间"
当一个原本两周的项目变成一天，我们意识到——之前那种"两周的项目"，现在我们会主动多做几个。
软件的边际成本下来了，能消费的软件多了。
这是 vibe coding 的真正回报：不是省人力，是让你敢做更大的事。
八放手的四条收纳：闭环原则
| # | 一句话 | 怎么落地 |
|---|---|---|
| 1 | 做 Claude 的 PM | 提需求、约束、上下文，先 plan 再 execute |
| 2 | leaf node 上 vibe | 让技术债被装进"反正不再变"的角落 |
| 3 | 找一个能验证的抽象 | 验收测试、压力测试、可观察 IO；技术债无法验时坚持读 |
| 4 | 拥抱指数 | 现在不一定要 vibe，但别养成"不读完每行不放手"的肌肉记忆，那是未来的瓶颈 |
九Q&A 精华
Q1：vibe coding 时代，新人怎么学？
Eric 的回答：
- 悲观面：你确实不会经历那种"硬核挣扎"，就像他大学教授当年抱怨"现在的程序员不会手写汇编了"；
- 乐观面：你身边永远有一个 pair programmer 24/7 待命。看到不熟悉的库可以当场问 Claude："这是啥？为什么用它不用别的？" 学得比以前快得多。
- 更高维度：以前一个架构决定要 2 年才能验对错，未来可能 6 个月就出结果——愿意学的人能在同样日历时间里多走 4 倍的循环。
会被淘汰的是懒人——不是新人。
Q2：plan 要写多详细？是不是要写完整 PRD？
- 取决于你在乎什么——只在乎结果就只描述需求，了解代码库的话可以指定类、参考实例；
- 别过度约束：模型在"留一定空间"时表现最好；
- 不要标准化 PRD 模板——按"给 junior 工程师交代"的颗粒度即可。
Q3：安全 / 漏洞怎么办？
- 回到第 1 条原则——Claude 的 PM 要懂得问对问题，知道哪里危险；
- 自己的 22k 行案例之所以敢做，是因为那个系统完全离线，已经事先确认"出错也没有外部攻击面"；
- 期待未来出现「可证明安全的脚手架」——核心安全敏感的部分（auth、支付）官方写好，用户只 vibe code 业务部分。
Q4：TDD 怎么和 Claude 配？
- 明确告诉 Claude 测试格式："写 3 个端到端测试——1 个 happy path + 2 个 error case"；
- 要 end-to-end，不要单元测试细节——这种测试人类可读、不被实现绑死；
- vibe coding 时只读测试，不读实现——测试过你就放心。
Q5：怎么算"embrace exponentials"？
重点不是"模型会变好"——而是变好得比你想象的快。
不是稳定增量，是斜率本身会一直上去。
Q6：你的具体工作流？多久 /compact 一次？
- 终端开 Claude Code + 同时在 VS Code 里滚动 review diff；
- 在自己作为人类工程师"想去吃午饭"的那种自然停顿点做
/compact； - 常见套路：先让 Claude 探索代码库、做 plan、把 plan 落到一个 markdown 文档；
- 然后
/compact——把 100k token 的探索压成几千字摘要，再开干。
十一页速查
| 维度 | 传统编码 | 紧反馈 AI（Copilot） | Vibe Coding |
|---|---|---|---|
| 你和代码的距离 | 写每行 | 看每行 | 看产品行为，不看代码 |
| 适合范围 | 任何 | 任何 | 叶节点 / 离线 / 可验证抽象的系统 |
| 关键技能 | 写代码 | 评估代码 | 当 PM：提需求、定约束、验产品 |
| 时间消耗 | 实现耗时 | 实现 + review | 前置上下文 + 验收测试 |
| 现在不做的代价 | 无 | 慢一点 | 2 年后跟不上指数曲线 |
一句话外带：vibe coding 的真正约束不是模型能力，而是你自己能不能找到一套不读代码也能验证产品行为的方法。技术债是目前唯一无法被绕过的硬约束——所以只在 leaf node 上放手。