什么才算真正的 vibe coding
Andrej Karpathy 给过一个定义：「完全沉浸在 vibe 中，彻底忘记代码的存在。」
注意，不是「AI 帮你写代码」，是「忘记代码的存在」。
Schluntz 说得更直接——你跟 AI 说清楚要什么，它出结果，你只看结果对不对。代码长什么样你不关心。就像打车，你关心的是到没到目的地，不是司机怎么握方向盘。
按这个标准，大多数工程师都还停在过渡期的开头，真正的范式转移根本没到。
AI 能力每 7 个月翻一倍
Schluntz 给了一个数据：AI 能独立完成的任务时长，每 7 个月翻一倍。
现在能稳定执行 1 小时的编程任务。7 个月后是半天。再 7 个月一整天。再往后一周。
当 AI 一次性扔给你相当于一周工作量的代码，你还要逐行审查吗？人类会成为整个链条里最慢的那个环节。
这跟编译器的发展史一模一样。早年程序员写完 C 还要看生成的汇编对不对，后来编译器越来越靠谱，坚持看汇编的那批人被淘汰了。AI 写代码就是今天的编译器，区别是这次抽象层更高，变化更快。
找到你能验证的抽象层
整个演讲的精华就一句话：找到你能验证的抽象层。
CEO 看财务指标管公司，CTO 看验收测试管技术，产品经理直接体验产品。没有一个人在看代码。
所以用 AI 写代码的核心问题不是「AI 写得对不对」，而是——你在哪一层能判断对错？
- 能通过跑测试验证，就不用看代码
- 能通过体验产品验证，就不用跑测试
- 能通过用户数据验证，就不用亲自体验
找到那层，就在那层工作。往上走，别往下钻。这不是放弃责任，是重新定义责任边界。
主干和叶子分开管
这套策略对创业者最有用。Schluntz 把代码库分成两类：
- 主干架构：核心逻辑、底层接口、被大量模块依赖的部分
- 叶子节点：末端功能、附加组件、不被任何模块依赖的部分
策略很简单：叶子节点让 AI 随便写，有点技术债无所谓。主干架构必须人工守住。
这是在「放手」和「控制」之间找到的最优解——不是把整个项目交给 AI（那是找死），也不是完全不信任 AI（那是浪费）。按风险分层，低风险的全力交出去。
一个极端案例：Anthropic 团队合并了 22,000 行 Claude 写的代码，原本两个工程师花两周逐行审查，压到了一天。四招：
- 开工前做需求规划
- 限定在叶子节点
- 核心逻辑人工审
- 建立可验证检查点
不是盲目信任，是有边界的授权。
工程师为产品负责，不是为代码负责
以前的模式是工程师对代码质量负责。新模式是工程师对产品结果负责，AI 对代码实现负责。
核心能力跟着变了。以前是你得会写代码，现在是你得会说清楚要什么。
Schluntz 给了一个具体动作：开工前花 15 到 20 分钟跟 AI 对齐。先让 AI 探索项目结构、找相关文件、把它对任务的理解说出来、一起定计划，再把上下文整合成完整的 prompt 去执行。这么做之后，成功率是指数级提升。
好 prompt 不是写得长，是上下文给得足。这里有个坑：很多人上来就丢一句需求，然后抱怨 AI 不靠谱——问题不在 AI，问题在你没给够上下文。
这件事对小团队冲击最大
以前做软件，技术团队是最大的门槛。有好想法找不到好工程师就做不出来。现在这个门槛在快速降低。
未来的竞争力不是「你会不会写代码」，而是「你能不能清晰定义什么叫做完了」。
能说清楚需求的人，就是未来的产品经理。能说清楚需求加能用 AI 交付的人，就是未来的全栈。
每次技术范式切换都会有一批人因为没转过来而出局。不是能力不行，是心理模型没更新。
现在就可以做的三件事
一、在低风险模块上放手。 不要每行代码都亲自审，先从一个叶子节点开始，让 AI 跑，你来验收结果。
二、学会在任务开始前跟 AI 对齐。 不要上来就提需求。先让 AI 读懂背景，定好计划，再开工。
三、想清楚你的验证层在哪里。 你有没有一套可以快速判断「这事做对没做对」的标准？如果没有，这件事比学 AI 工具更紧迫。
AI 的能力每 7 个月翻一倍。留给我们调整的时间，没有那么多。