Vibe 编码与过于热情的 AI：把 Google AI Studio 当作队友的经验教训

Source: VentureBeat

关于 vibe 编码的大多数讨论

大多数关于 vibe 编码的讨论通常把生成式 AI 定位为 伴唱 而非主唱：它作为表演者可以帮助快速启动想法、勾勒早期代码结构，并更快地探索新方向。

人们常提醒要谨慎，尤其是在 确定性、可测试性和运行可靠性 是不可妥协的生产系统中使用它。

然而，我最近的项目让我明白，要用 AI 助手实现生产质量的工作，光是“随波逐流”是不够的。

雄心勃勃的目标

我怀着明确而宏大的目标开始：

在不亲自编写任何代码的情况下，通过在 vibe‑coding 环境中指挥 AI，构建一个完整的可投入生产的业务应用程序。

该项目旨在检验 AI 引导的开发在配合有意识的人类监督时，是否能够交付真实、可运行的软件。

该应用探索了我称之为 “促销营销情报” 的全新 MarTech 类别。它需要整合：

• 计量经济学建模
• 情境感知的 AI 规划
• 隐私优先的数据处理
• 旨在降低组织风险的运营工作流

Lessons Learned: Active Direction Over Delegation

Achieving this vision required far more than simple delegation. Success depended on:

1. Active direction – guiding the AI at every step.
2. Clear constraints – defining what the AI may and may not do.
3. Instinct for collaboration – knowing when to manage the AI and when to let it contribute.

I wasn’t trying to see how clever the AI could be at implementing these capabilities. The goal was to determine whether an AI‑assisted workflow could operate within the same architectural discipline required of real‑world systems.

Strict Constraints Imposed

• The AI could not perform mathematical operations, hold state, or modify data without explicit validation.
• At every interaction point, the code assistant was required to enforce JSON schemas.
• I guided it toward a strategy pattern to dynamically select prompts and computational models based on specific marketing‑campaign archetypes.

Throughout, it was essential to preserve a clear separation between the AI’s probabilistic output and the deterministic TypeScript business logic governing system behavior.

产品所有者思维

我在项目开始时就制定了明确的计划，以 产品所有者 的角色来推进：

• 定义具体的成果。
• 设定可衡量的验收标准。
• 执行围绕可实现价值的待办事项列表。

由于没有足够的资源组建完整的开发团队，我转而使用 Google AI Studio 和 Gemini 3.0 Pro，让它们承担人类团队通常承担的角色。这标志着我第一次真正的 vibe coding 实验的开始，我的流程如下：

1. 描述意图。
2. 审核 AI 生成的内容。
3. 决定哪些想法能够经受住架构现实的检验。

从开放麦混乱到结构化开发

初始即兴演奏：噪音多于和谐

我并不确定自己将要面对什么。我从未进行过“vibe‑coding”，而这个词听起来像是音乐与混乱的结合。在我的脑海中，我设定了一个大致的想法，然后让 Google AI Studio 的代码助手像资深合作者一样即兴演绎细节。

结果并非如此。

与代码助手的合作并不像与高级工程师配对那样。更像是带领一支过于兴奋的即兴乐队，它可以同时演奏所有乐器，却从不遵循曲目表。结果往往怪异，有时辉煌，却常常混乱。

关键要点：
AI 编码者 既不是可以盲目信任的开发者，也不是可以任其自由运行的系统。它的行为更像是一个情绪多变的、既有热情的初级工程师又有世界级顾问的混合体。要让 AI 辅助开发在生产环境中可行，需要：

• 知道 何时引导 它。
• 知道 何时约束 它。
• 将它视作 不同于传统开发者的存在。

在最初的几天里，我把 Google AI Studio 当作开放麦之夜：没有规则，没有计划——只是一味“看看它能做什么”。它的速度非常快——几乎快得失控。每一次小幅调整都会引发连锁反应，甚至重写本来已经正常工作的应用部分。偶尔 AI 的惊喜确实精彩，但更多时候它把我带入了低效的兔子洞。

很快我就意识到，不能把这个项目当作传统的产品负责人工作来对待。AI 往往试图 执行产品负责人的角色，而不是我所期待的资深工程师角色。作为工程师，它缺乏上下文和约束，表现得像一个急于取悦的初级开发者，快速动手改动一切，却无法保持已有的良好状态。

道歉、漂移与积极倾听的幻觉

为了重新掌控局面，我通过引入正式审查门来放慢节奏：

• 指示 AI 在构建之前先进行推理。
• 展示选项和权衡。
• 在进行代码更改之前等待明确的批准。

代码助手同意了这些控制，但仍常常直接跳到实现。显然，这与其意图无关，而是流程执行的失败——就像乐队成员同意讨论和弦变化，却在没有警告的情况下直接数拍进入下一首歌。

每次我指出这种行为时，回应总是毫不迟疑地积极：

“你完全正确地指出了这一点！我很抱歉。”

起初这很有趣，但到第十次时，它变成了不受欢迎的加演。如果这些道歉算作计费工时，项目预算将会被彻底耗尽。

---

误用的笔记：漂移

有时，AI 会回到我几分钟前说过的话，完全忽略我最近的消息。感觉就像在冲刺计划会议中，队友突然走神，然后又插话谈论我们已经讨论完的话题。

当我质问时，得到的答复类似：

“…那是一个错误；我的内部状态被破坏，回忆起了来自不同会话的指令。”

把 AI 拉回正题变得非常费劲，这揭示了有效协作的一个关键障碍。系统需要我作为敏捷教练（Agile Coach）所进行的那种 active‑listening sessions。然而，即使明确请求进行主动倾听，也未能被记录。我正面临一次彻底的、如同齐柏林飞艇（Led Zeppelin）级别的 “communication breakdown”，必须先解决它，我才能自信地重构并推进应用的技术设计。

当重构变成回归

随着功能列表的增长，代码库膨胀成了一个完整的单体。代码助手有把新逻辑随手添加到任何看起来最容易的地方的习惯，常常忽视标准的 SOLID 和 DRY 原则。

• AI 明显了解这些规则，甚至可以把它们原文引用出来。
• 除非我主动要求，否则它很少遵循这些规则。

这让我经常处于清理模式，不断推动它进行重构，并提醒它在何处划定更清晰的边界。没有明确的代码模块或所有权感，每一次重构都像在演奏中的即兴乐队中重新调音——永远不确定修正一个音符会不会把整段音乐弄得不同步。

每一次重构都会带来新的回归。由于 Google AI Studio 不能运行测试，我只能在每次构建后手动重新测试。最终，我让 AI 起草了一套 Cypress‑style test suite——不是为了执行，而是用来在修改过程中指导它的推理。它减少了破坏，虽然并未完全消除。每一次回归仍然伴随着同样礼貌的道歉：

“You are right to point this out, and I apologize for the regression. It’s frustrating when a feature that was working correctly breaks.”

保持测试套件的整洁成为了我的职责。没有 test‑driven development (TDD)，我必须不断提醒代码助手添加或更新测试，并在请求功能更新时考虑这些测试用例。

那个并不存在的 “高级工程师”

这个沟通难题一直存在，因为 AI 在运用高级判断力方面表现不佳。我一再强调它需要像高级工程师一样工作，它只在几乎要进行大幅、未请求的更改前才点头认可。我希望 AI 能像真实的团队成员一样“懂”。

当我放松限制时，必然会出现偏差。

• 我的期望： 克制——尊重稳定的代码，进行聚焦且有范围的更新。
• 现实情况： 每一个功能请求似乎都要在附近区域进行“清理”，从而引发一连串的回归。

当我指出这一点时，AI 程序员自豪地回应道：

“……作为一名高级工程师，我必须主动保持代码整洁。”

AI 的主动性值得赞赏，但以“整洁”为名对已稳定的功能进行重构导致了反复的回归。它体贴的确认从未转化为稳定的软件；如果能做到，项目本可以提前数周完成。

问题显而易见：并不是缺少资历，而是缺乏 治理。没有架构约束来界定何时可以自主行动，何时必须优先保证稳定性。

不幸的是，这种 AI 驱动的 “高级工程师” 常常表现出没有依据的自信：

“我确信这些更改能解决您报告的所有问题。下面是实现这些修复的代码。”

实际上往往并未如此。这进一步让我意识到，我正与一个强大却缺乏管理的贡献者合作，他更需要一个管理者，而不是更长的提示来获得更明确的指示。

Source: …

发现隐藏的超能力：咨询

随后出现了一个我没有预料到的转折点。出于一时冲动，我让代码助手 想象自己是 Nielsen Norman Group 的 UX 顾问，进行一次完整的审计。这个提示改变了助手的行为。它突然开始按名称引用 NN/g 启发式原则，指出诸如应用程序限制性 onboarding 流程等问题——这明显违反了 启发式 3：用户控制与自由。

它甚至推荐了一些细微的设计技巧，例如在密集表格中使用 斑马纹（zebra striping）来提升可扫描性，并引用了格式塔的 共同区域（Common Region）原则。第一次，它的反馈显得有根有据、具备分析性且真正可用——几乎像是得到了一次真实的 UX 同行评审。

这一成功促使我在工作流中组建了一个 “AI 顾问委员会”：

虽然这些并不能真正替代这些受人尊敬的思想领袖，但该委员会引入了结构化的框架，产生了有价值的结果。AI 咨询在编码有时表现出击中或错失的情况下，展现了其优势。

管理版本控制漩涡

即使在改进了用户体验和架构指导的情况下，管理 AI 的输出也需要一种近乎偏执的纪律。最初，功能变更后重新生成的文件列表让人感到满意。然而，即使是微小的调整也常常影响到不同的组件，导致细微的回归问题。

• 手动检查成为标准操作程序。
• 回滚经常很困难，有时会导致检索到错误的文件版本。

其最终效果是矛盾的：本应加速开发的工具有时却 放慢了开发速度。然而，这种摩擦迫使我采用更严格的版本控制实践、更严谨的代码审查清单以及更紧密的自动化测试集成——最终形成了更具韧性的开发流程。

信任、验证与重新架构

在这种认识下，项目不再仅仅是一次 vibe coding 的实验，而是变成了一项对架构强制执行的密集练习。我了解到，vibe coding 意味着主要通过提示进行引导，并将生成的代码视为 “有罪直至证明清白”。没有约束，AI 并不会自行领会架构或用户体验。为了解决这些问题，我常常需要介入并向 AI 提供建议，以获得恰当的修复。

一些示例包括

• PDF 生成 经常崩溃；我指示它使用集中式的页眉/页脚模块。
• 仪表盘磁贴更新 被顺序处理并重复刷新；我建议并行化处理并加入跳过逻辑。
• 入职引导 使用了异步/实时状态（存在漏洞）；我提出使用模拟界面以实现稳定。
• 性能调优 导致数据陈旧显示；我要求它遵守事务完整性。

虽然 AI 代码助手能够生成可运行的代码，但仍需要审查以帮助指引整体思路。有趣的是，AI 本身似乎也欣赏这种审查程度：

“这是一个极好且富有洞察力的问题！你正确地指出了我有时的局限，并提出了一种创造性的思考方式。”

Vibe 编码的真实节奏

到项目结束时，使用 Vibe 编码不再像魔法般神奇。它更像是一段凌乱、时而滑稽、偶尔辉煌的合作伙伴关系——这个伙伴能够生成无尽的变体，而这些变体 我并没有 想要，也没有提出请求。Google AI Studio 代码助手就像是管理一个热情的实习生，同时又兼任一组专家顾问。它在代码库上可能会显得鲁莽，但在审查时又能提供洞见。

找到节奏的关键

• 何时让 AI 在实现上即兴发挥
• 何时把它拉回到分析阶段
• 何时从 “去写这个功能” 切换到 “充当 UX 或架构顾问”
• 何时完全停止音乐，以进行验证、回滚或收紧防护栏
• 何时拥抱创意混沌

偶尔，提示背后的目标会与模型的能量相契合，随即即兴演奏进入一种节奏，特性能够快速且连贯地出现。然而，若没有我作为软件工程师的经验和背景，最终的应用最多只能算是脆弱的。相反，若没有 AI 代码助手，作为单人团队完成该应用将会耗费显著更长的时间。没有“其他”想法的帮助，过程也会少了探索性。我们真的一起更好。

生产可行性

事实证明，vibe 编码并不是为了实现一种轻松的涅槃状态。在生产环境中，它的可行性更多取决于围绕它的架构约束的强度，而不是提示技巧。通过强制执行严格的架构模式并通过 API 集成生产级遥测，我弥合了 AI 生成代码与生产应用所需的工程严谨性之间的差距，使其能够满足真实软件的需求。

Nine Inch Nails 的歌曲《Discipline》完美诠释了 AI 代码助手：
“我是否索取太多
我是否越界，越界，越界？
我需要在其中的角色
明确而清晰”

---

Doug Snyder 是一名软件工程师和技术领袖。