Vibe Coding：AI 写代码的隐藏成本与双角色模式

Dan Shipper 最近分享了一段特别真实的经历。

他是 Every 的联合创始人兼 CEO，花了 10 天时间，完全用 Codex，一行代码都没看过，从零做出了一个叫 Proof 的产品。这是一个专门为 AI agent 设计的文档编辑器，你可以把它理解成，如果 Google Docs 是给 agent 用的，它会长什么样。

产品上线那天，效果炸了。推文拿到 1500 个赞，50 万次浏览，48 小时内用户创建了 4000 多篇文档。Dan 早上醒来看到数据的时候，很吃惊，没想到爆了。

然后，Proof 就开始崩溃了。

Dan 形容那段时间自己每天熬到凌晨四点，笔记本电脑就摊开放在枕头旁边，好让 agent 在后台跑着，他每隔三四个小时醒来检查一次。他说自己像个草原上的拓荒者，半夜还得起来照看篝火别灭了。

这段描述特别生动，也特别有代表性。

我看了特别有感触，因为我这段时间也在用 Trae 和 Anti Gravity 编东西，小工具、小程序，各种需求丢给 AI，让它帮我写。说实话，一开始的感觉太爽了。你描述清楚要什么功能，它就像个资深工程师在旁边配合你，代码哗哗往外吐，功能点一个一个实现，成功率非常高。

但爽完之后的那个阶段，就比较痛苦了。

Dan 的经历精准地概括了这种痛苦，而且比我经历的更极端。

10 天做出一个产品，48 小时后开始崩溃，这中间的落差本身就是 vibe coding 的缩影。你可以 vibe code anything，但你没法 vibe fix it。至少没法快速修好它。

这句话不是修辞，是我这段时间最真切的体感。

我用 AI 写代码的时候，经常遇到的情况是，功能确实实现了，但代码质量参差不齐。AI 写代码很快，你根本来不及逐行看，等你想回头看的时候，已经是一大片你不太熟悉的逻辑了。更关键的是，AI 对你的需求理解，在很多细节上是有偏差的。你说东，它听成了东南，大方向没错，但细处总有对不上的时候。

如果只是个小工具，功能简单，需求表达也不复杂，那问题不大。代码乱点就乱点，能跑就行。但一旦你面对的是复杂工程，模块多、需求点多、逻辑链条长，事情就开始变得麻烦了。

我最深刻的体验就是，修复过程像个黑盒。你发现一个问题，描述清楚，让 AI 去改。它改了，这个问题可能解决了，但往往又带来了两个新问题。你再描述，它再改，又带来新的问题。就在那里不断套圈，解决一个，冒出两个，再解决，再冒。

最后你发现，花的时间和精力，一点都不比传统方式少。

这就是 vibe coding 的隐藏成本。它能让你以极快的速度从零到一，但从一到十的过程，它并不擅长。

Dan 在修复 Proof 的过程中，慢慢看清了这件事的本质。

他把它总结成两个角色，海盗和建筑师。

海盗的工作是尽可能快地往前冲。不考虑架构，不考虑代码整洁，唯一关心的事情就是找到真正有价值的东西。他用 vibe coding 的方式快速试错，快速迭代，10 天做出 Proof，他就是海盗。

建筑师的工作是让海盗冲出来的东西不会散架。他要把那些混乱的、拼凑的、勉强能跑的代码，变成一个可理解、可扩展、可维护的系统。一个不会莫名其妙宕机、出了问题有人能搞明白为什么的系统。

Dan 说得很直白。海盗没有建筑师，造出来的东西会塌。建筑师没有海盗，造出来的东西没人要。两个角色配合在一起，才是 AI 时代工程团队的未来。

这个观察其实揭示了一个更深层的道理。在 AI 工具越来越强大的今天，「能做出来」这件事本身的价值在急速下降。真正稀缺的能力分成了两端，一端是判断力，知道什么值得做。另一端是系统思维，能让做出来的东西持续运转。

Dan 还给海盗型创造者提了几条特别实用的建议。

第一条，做简单的东西，把它做好。Vibe coding 最大的诱惑就是不停加功能，加了一个又一个，结果什么都做了，什么都没做透。你能造 anything，反而意味着你更需要克制，把注意力集中在产品真正重要的那个点上。

第二条更狠。一旦你找到了真正有价值的方向，把现有的代码扔掉，从头来过。

他引用了一个作家的说法，叫「覆盖你的足迹」。写作的时候，你不希望读者看到你是怎么一步步想到这个点子的，你只想把最终的想法呈现给他们。做产品也一样。Vibe coding 的过程中，你的代码库里堆满了各种尝试的痕迹，不同的功能方向，不同的产品构想，这些都是探索的副产品。但一旦你确定了要做什么，最好的做法就是开一个全新的代码库。

Dan 特别提到一个有趣的现象。你可能会想，我不用重写啊，让 agent 帮我重构不就行了。但实际操作下来，coding agent 会被已有的代码严重干扰。你给它一坨 vibe coded 的混乱代码，让它在这个基础上重写，它反而做不好。它会被现有的东西牵着走，做出一堆局部合理但整体不连贯的修改。

所以最好的办法就是，别让它看到旧代码，直接开新项目。

这个发现对我特别有启发。我跟 AI 协作的时候，给它一个干净的起点，往往比让它在一堆历史包袱里挣扎要高效得多。需求表达越清晰、上下文越干净，AI 的表现就越好。反之，你让它在一段已经混乱的代码上修修补补，它很容易陷入那种「解决一个带来两个」的套圈陷阱。

对于那些资深工程师来说，Dan 的经历其实是一个好消息。

他在修复 Proof 的过程中，请了一位建筑师型的工程师来帮忙，花了大约一周时间重写了几个关键模块。这才是真正解决问题的转折点。

Dan 观察到，coding model 现在确实很强，但它们缺少一种东西，概念上的清晰度。模型做的每一个局部修改，单独看都说得通，但你退后一步看全局，会发现整个系统缺乏一致性，东西拼不到一起去。而真正优秀的工程师特别擅长做这件事，他们能从全局视角审视系统，确保所有部分协调一致。

Dan 也坦诚地说，这并不意味着模型永远做不到这一点。但至少在现阶段，资深工程师用 AI 来放大自己的能力，反而在积累一种模型还不具备的新型专业知识。你越是深度使用这些工具，你和纯模型之间的差距可能反而在拉大，因为你在实践中形成的系统判断力，恰恰是模型最欠缺的。

这让我想起自己用 Trae 写代码的一个感受。小需求、小工具，vibe coding 已经够用了，甚至可以说是效率神器。但一旦涉及复杂工程，你真的需要一个「建筑师」的心态。不是让 AI 自由发挥，而是你要有非常清晰、非常准确的需求表达，让 AI 在明确的框架下工作。这个需求表达本身，就是建筑师的核心能力。

而这件事，做起来并不容易。

Dan 还提出了一个很有想象力的判断。

他说现在所有的生产力软件，Google Docs、Google Sheets、PowerPoint，下一代版本的主要用户将会是 agent。如果你从一开始就把 agent 当作你的核心用户来设计产品，你做出来的东西会和现有的软件完全不同，而且会非常有价值。

Proof 就是这个思路的产物。它本质上就是一个为 agent 优先设计的文档编辑器。这个方向对于想要创业或者做独立项目的人来说，是一个巨大的机会窗口。我们身边几乎所有的工作软件都是为人类设计的，但当 agent 成为日常工作流中的常驻角色，这些软件的交互逻辑、数据结构、权限模型都需要被重新思考。

Dan 在视频最后说了一句很实在的话，做事情，还是一起做比较好，你不必什么都自己来。

他说下次再做 vibe coded 的项目，一定会从一开始就拉一个建筑师进来，因为如果不这么做，他的团队大概会哗变。

这句话听起来像是在开玩笑，但背后的道理很朴素。AI 让个人的能力边界大幅扩展了，一个人确实可以在 10 天内做出一个产品。但让它活下来、长起来，你还是需要互补的伙伴。海盗需要建筑师，建筑师也需要海盗。

这个道理放在任何时代都成立，只不过在 AI 时代，两者之间的配合节奏变得更快了，分工也变得更清晰了。vibe coding 负责探索和验证，确认方向之后，建筑师进场，从零开始，有计划、有体系地把事情做对。

我自己现在也是这么干的。小东西，vibe coding 直接上。复杂需求，先 vibe 一个原型验证想法，验证完了，推倒重来，用建筑师的心态重新做一遍。

不是 vibe coding 不好，是它有自己的边界。认清这个边界，比盲目崇拜它更重要。