这篇文章内容来自于 Y Combinator 的视频《How To Get The Most Out Of Vibe Coding》。

📚 系列文章导航

本系列文章基于 Y Combinator 的《How To Get The Most Out Of Vibe Coding》视频，深入探讨与 AI 协同编程的最佳实践：

  1. ✨ 如何更好的 Vibe Coding？—来自 YC Startup Founders 的实践建议 - 深入分析 Vibe Coding 的核心原则和进阶技巧

  2. 🤝 在 Coding 的时候，我们应该和 AI 如何进行有效的协同 - 分析与 AI 协同的核心思维模型和工作原则（本文）

  3. 🔄 Vibe Coding 的开发工作流 - 详细介绍标准化的 Vibe Coding 开发流程和调试方法

背景

我最近通过 Vibe Coding 的方式，构建了好几个产品，也确实感受到了 Vibe Coding 的强大，但是并不意味着，使用 AI 构建产品就没有门槛；这并不意味着我可以使用一句话就可以轻易构建出一个可用的产品。

当我真正在使用 AI 去构建产品的时候，我发现了很多问题，也发现了很多局限。但是这些并不意味着我们应该回归传统的人工编码的方式。恰恰因为如此，我觉得 Vibe Coding 或者更准确的说，和 AI 进行协同编程的领域，有很多值得学习的地方，需要不断通过练习而可以获得显著精进的技能。

最近在看 YC 的 《How To Get The Most Out Of Vibe Coding》，收益匪浅。

视频信息

Vibe Coding

  • Title: How To Get The Most Out Of Vibe Coding | Startup School (如何通过“Vibe Coding”获得最大收益)
  • Author: Y Combinator (主讲人: Tom Blomfield, YC Partner)
  • URL: https://www.youtube.com/watch?v=BJjsfNO5JTo

我们在 Coding 的时候，我们应该如何和 AI 进行协同？

  1. The “Manager of Junior Developers” Model (初级开发者管理模型)
    核心概念： 你不应将 AI 视为一个能读懂你心思的“超级天才”，而应将其视为一个才华横溢但经验不足、容易分心且极其听话的“初级实习生”。

  • 深度解析：

    • 明确的指令（Clear Instructions）：就像带实习生一样，如果你给出的任务模棱两可，实习生就会产出错误的结果。你需要提供极其详尽的上下文、文档和约束条件。视频中提到的“下载文档到本地”和“编写 Instruction 文件”正是为了给这位实习生提供工作手册。

    • 代码审查（Code Review）：你不能盲目信任实习生的代码。虽然你可能不逐行检查语法，但你需要检查逻辑是否合理，是否引入了不必要的变动。这就是为什么 Tom 强调要看 diff，要警惕 AI 修改了它不该修改的地方（Unrelated logic changes）。

    • 任务拆解（Task Breakdown）：你不会把整个系统架构扔给实习生让他一天做完。你会把任务拆解成“Section 2”、“Section 3”这样的小块。Vibe Coding 也是如此，必须将宏大的愿景拆解为 AI 可以消化和执行的微小任务单元。

  1. The “Clean Slate” Protocol (白板协议)
    核心概念： 对抗 AI 编程中熵增（Entropy）的唯一方法是保持极端的无状态性（Statelessness）和可逆性（Reversibility）。

  • 深度解析：

    • 累积误差理论（Accumulated Error Theory）：视频中反复提到 “Layers of bad code” 或 “Layers of craft”。当 AI 犯错并试图自我修正时，它往往不会删除错误的代码，而是添加更多的逻辑来“绕过”错误。经过三四次“修复”后，代码库就会变成一坨不可维护的泥潭。

    • 重置即止损：这个模型要求开发者克服“沉没成本谬误”。当你花了 10 分钟让 AI 修复一个 Bug 却没成功时，本能是继续修。但“白板协议”要求你立即 git reset –hard。

    • 蒸馏解决方案：即使你在第 5 次 Prompt 时找到了解决方案，也不要保留那份经过 5 次修改的代码。你应该提取出那个最终的解决方案逻辑，回滚代码库，然后在干净的“白板”上一次性应用这个正确的方案。这保证了代码库永远只包含“经过深思熟虑的正确代码”，而不是“试错过程的遗迹”。

  1. The “Language-Driven Architecture” (语言驱动架构)
    核心概念： 编程语言的选择不再仅仅取决于性能或个人喜好，而是取决于该语言在 LLM 训练数据中的密度和一致性。同时，软件架构应向“AI 易于理解”的方向演进。

  • 深度解析：

    • 训练数据决定生产力：Tom 选择 Ruby on Rails 的逻辑非常有启发性。Rails 作为一个老框架，其“强约定”（Strong Conventions）意味着全球的 Rails 代码长得都很像。这意味着 LLM 学习到的模式非常统一且高质量。相反，像 Rust 这样灵活且较新的语言，或者配置极其自由的框架，LLM 的表现就会下降。在 Vibe Coding 时代，选择一个“AI 熟悉”的技术栈可能比选择一个“性能最快”的技术栈更重要。

    • 模块化作为认知边界：AI 的上下文窗口（Context Window）虽然在变大，但注意力机制（Attention）在处理过量信息时仍会衰减。将系统设计为模块化、微服务或清晰的 API 边界，实际上是人为地为 AI 划定“认知范围”。当 AI 只需要关注一个模块内部的逻辑，且外部接口锁定时，它的表现会呈指数级上升。这不仅仅是为了代码解耦，更是为了适应 AI 的工作特性