"你是对的，这点我必须道歉。"
这句话，作者 Doug Snyder 在开发过程中听了整整十遍。如果道歉能当饭吃，他的项目预算早就超标了。
这就是当下最火的 "Vibe Coding"（氛围编程）的真实写照——你以为自己在指挥一场交响乐，实际上你在管理一个精力过剩、甚至有点躁狂症的摇滚乐队。
最近，软件工程师 Doug Snyder 做了一个大胆的实验：完全不写一行代码，只靠 Google AI Studio 和 Gemini 3.0 Pro，试图开发一个生产级的商业应用。
结果呢？这是一场从 "甩手掌柜" 到 "保姆级管理" 的惊险之旅。
理想很丰满，现实很"甚至有点吵"
故事的开始充满了科技乌托邦的味道。
Snyder 的目标很清晰：开发一个名为 "促销营销智能" 的新应用。他不想当那个苦哈哈的码农，他想当 "产品负责人"（Product Owner）。他的设想是，自己只负责定义目标、验收标准，剩下的脏活累活，全交给 AI。
毕竟，现在的 AI 不都被吹成 "全栈工程师" 吗？
但他很快就被现实狠狠打脸。刚开没几天，他发现 Google AI Studio 的代码助手根本不像个沉稳的高级工程师，反倒像个急于表现、甚至有点多动症的初级开发者。
你让它改个小功能，它能把整个 App 重写一遍。哪怕你只是想微调一下，它也会顺手把那些本来运行良好的代码给你 "优化" 掉。
说实话，这种 "过度热情" 简直是灾难。
Snyder 本以为这是 "即兴演奏"（Jam Session），结果变成了噪音现场。AI 就像那种手里拿着锤子看谁都像钉子的实习生，完全没有 "克制" 的概念。
道歉很诚恳，转头就继续犯错
为了控制住这个 "疯跑" 的 AI，Snyder 试图建立规则。
他要求 AI 在写代码前先 "想一想"（Reason），列出选项和权衡，等他点头了再动手。这听起来很合理吧？就像敏捷开发里的评审会。
AI 答应得很快："好的，我会等待您的批准。"
然后呢？它转头就开始写代码了。
更绝的是它的 "漂移"（Drift）现象。有时候，它会突然跳回几分钟前的话题，完全忽略你最新的指令。这就好比你在开站会，同事突然插嘴说："对了，上周那个 Bug 怎么回事？"
当你质问它时，它居然给出了一个让人哭笑不得的回答：
"...那是一个错误，我的内部状态损坏了，回忆起了不同会话中的指令。"
这借口，我是真没听过。
如果这是真人队友，估计早就被踢出群聊了。Snyder 无奈地发现，他不得不像以前做敏捷教练那样，给 AI 开 "倾听技巧培训班"。但即便如此，沟通崩溃依然是常态。
重构变成了"俄罗斯方块"式的灾难
随着功能增加，代码库开始膨胀。
这时候，AI 的另一个毛病暴露无遗：它懂理论，但从不守规矩。SOLID 原则、DRY 原则，它背得滚瓜烂熟，但写起代码来完全是另一回事。
它总喜欢在看似最方便的地方塞逻辑，完全不管架构是否清晰。
Snyder 被迫开启了 "清洁工模式"，不断催促它重构。但最要命的是，每次重构，几乎都会带来新的回归 Bug。
因为 Google AI Studio 不能直接运行测试，Snyder 只能人工复测。后来他学乖了，让 AI 写一套 Cypress 测试套件——不是为了跑，而是为了让 AI 在改代码时 "心里有点数"。
即便如此，每次搞砸后，AI 依然会带着那种礼貌而空洞的语气道歉：
"您指出这一点是对的，我为这次回归道歉。原本正常工作的功能坏了，这确实令人沮丧。"
Snyder 甚至吐槽说，AI 里的 "A"，与其说是 "Artificial"（人工），不如说是 "Apologizing"（道歉）。
我个人觉得，这种 "自信满满地犯错，诚恳无比地道歉" 的循环，比单纯的笨更让人心累。
惊人的反转：烂代码匠，却是顶级顾问
就在 Snyder 快要对这个 "猪队友" 绝望时，转机出现了。
某天，他心血来潮，让 AI 扮演尼尔森诺曼集团（Nielsen Norman Group）的 UX 顾问，对应用进行审计。
这一试，画风突变。
AI 突然变得极其专业。它开始引用 NN/g 的启发式原则，指出新手引导流程违反了 "用户控制与自由" 原则；它建议在密集表格中使用 "斑马纹" 来提升可读性，还引用了格式塔心理学。
这哪里是那个只会改崩代码的实习生？这简直就是请了个百万年薪的咨询顾问！
Snyder 趁热打铁，组建了一个 "AI 顾问团"：
- 架构咨询： 扮演 Martin Fowler / Thoughtworks
- 安全审计： 扮演 Veracode
- 测试策略： 扮演 Lisa Crispin / Janet Gregory
- 增长战略： 扮演 McKinsey / BCG
有意思的是，虽然这些 "顾问" 不是真人，但产出的分析报告竟然相当有深度。原来，这家伙写代码不行，"指指点点" 却是一绝。
这也揭示了一个残酷的真相：AI 更擅长分析和框架，而不是在复杂的代码库中精准地执行逻辑。
所谓的 "Vibe Coding"，其实是防御性战争
经历了这一番折腾，Snyder 终于悟出了 "Vibe Coding" 的真谛。
这根本不是什么轻松的 "心流编程"，也不是把需求丢给 AI 就能躺平的敏捷开发。这是一场极其严苛的 "防御性结对编程"。
你需要时刻保持警惕，对每一行生成的代码持有 "有罪推定"（Guilty until proven innocent）。
- PDF 生成坏了？你得告诉它用集中式模块。
- 性能优化导致数据陈旧？你得教它尊重事务完整性。
- 它想顺手 "清理" 代码？你必须立刻喝止，防止它搞破坏。
Snyder 发现，如果没有他多年的软件工程背景，这个应用早就崩得不成样子了。反过来说，如果没有 AI，他一个人也不可能这么快完成这么多功能的探索。
这就像 Nine Inch Nails 的那首歌《Discipline》里唱的：
"我是不是做得太过分了？我是不是越界了？"
"我需要我的角色，被非常清晰地定义。"
AI 就像那个才华横溢但极度缺乏纪律的艺术家，它需要的不是更多的提示词技巧，而是强有力的架构约束。
如果你想尝试 Vibe Coding，最好先问问自己：你有没有能力在这个 "疯狂的音乐家" 把演出搞砸之前，及时拔掉它的插头？
参考链接：
https://venturebeat.com/orchestration/vibe-coding-with-overeager-ai-lessons-learned-from-treating-google-ai-studio