Linguista

AI 驱动的 Vibe Coding：软件开发新范式与挑战

注意： 本报告基于YouTube平台相关视频（视频链接见文章末尾“参考资料”），使用NotebookLM与AI Studio处理编辑而成。

摘要

本报告深入探讨了近年来兴起的“Vibe Coding”（氛围编程）这一软件开发新范式，该模式的核心在于极大程度地依赖 AI 代理（特别是大型语言模型 LLMs），将代码编写的任务交由 AI 完成，而开发者则专注于产品构思、需求定义、架构设计以及对 AI 生成代码的评审。报告分析了 Vibe Coding 的显著优势，如显著提高开发效率、降低编程门槛、促进工程师角色向产品方向转变以及加速原型开发等。

然而，报告也全面审视了 Vibe Coding 所面临的局限性与挑战，包括代码质量与可维护性问题、调试的复杂性、过度依赖 AI 可能导致的技能退化以及对软件架构的影响。报告详细阐述了当前支持 Vibe Coding 的主要工具和技术，包括 Cursor 和 Windsurf 等集成开发环境，以及 Claude、GPT 等大型语言模型。

同时，报告还着重讨论了 Vibe Coding 对软件工程师角色与技能要求的变革，以及对软件架构决策产生的潜在影响。初创公司创始人对 Vibe Coding 持有积极乐观的态度，普遍认为它将极大地提高开发效率并改变软件工程师的角色。本报告总结了 Vibe Coding 的核心工作流程和最佳实践，为开发者提供了有益的指导，并展望了 AI 赋能软件开发的未来趋势。最终，报告强调 Vibe Coding 并非要取代传统编程，而是一种新的工具和方法，开发者需要拥抱变化，学习如何有效地利用 AI 工具，同时也要保持对基础知识和核心技能的掌握。

I. 引言：Vibe Coding（氛围编程）的崛起

II. Vibe Coding 的优势：效率、创新与便捷

  1. 显著提高开发速度和效率：
    • AI 快速生成代码，显著缩短开发周期。
    • 创始人声称编码速度提升 10-100 倍，实现指数级加速。
    • 能够更快地实现想法，快速迭代产品。
  2. 降低编程门槛：
    • 使得非传统编程背景的人也能更容易地创建软件。
    • 拥有其他领域专业知识的人，可以借助 AI 快速将他们的想法转化为可执行的代码，而无需花费大量时间学习编程语法和基础知识。实现编程民主化。
  3. 促使角色向产品和用户体验倾斜：
    • 工程师角色从代码编写者转向产品工程师。
    • 更加关注用户需求、产品设计和整体用户体验。
    • 人的品味 (Human Taste) 在判断 AI 生成的代码是否符合产品愿景方面变得更加重要。
  4. 加速原型开发和快速迭代：
    • 快速构建软件原型。
    • 快速尝试不同的想法，验证其可行性，并根据反馈进行快速迭代和改进。
  5. 潜在的并行开发能力：
    • 工具允许多个 AI 代理并行处理不同的功能。
    • 进一步提高开发效率。
  6. 更专注于解决问题本身：
    • 减少编写重复性代码的工作量。
    • 投入更多精力解决核心问题和实现创新功能。
  7. 在一定程度上应对遗留代码挑战：
    • 在小规模代码库中，可将整个代码库放入 AI 上下文窗口，一次性修复 bug。

III. Vibe Coding 的局限性与挑战：质量、调试与风险

  1. 代码质量和可维护性：
    • AI 生成的代码可能架构不良、可读性差，潜在 bug 较多。
    • 长期来看可能会导致项目难以管理和扩展，产生"horseshit code"。
  2. 调试困难：
    • 当前 AI 在复杂问题的调试方面仍然比较薄弱。
    • 仍需人工深入分析和修复 bug。
    • 可能需要简单地 Reroll or Rewrite 代码，而不是深入调试。
  3. 过度依赖和技能退化：
    • 过度依赖 AI 可能会导致开发者自身编程技能的退化，尤其是在遇到 AI 无法解决的问题或需要离线工作时。
  4. 引入低效或错误模式：
    • AI 的代码生成可能基于统计模型，有时会引入一些看似合理但不必要的代码或设计。
    • 例如，在游戏开发中出现了从未被使用的 Z 轴排序。
  5. 上下文理解的局限性：
    • AI 在处理大型、复杂的代码库时，可能难以完全理解上下文。
    • 可能导致生成的代码不符合项目需求或与其他部分冲突。
    • Cursor 需要明确告知需要查看哪些文件，而 Windsurf 在这方面有所改进。
  6. 依赖网络连接：
    • 依赖云端模型，在没有网络连接的情况下功能会受限。
    • 但也有公司在探索本地运行的微调模型。
  7. 难以构建复杂的系统级功能：
    • 当前的 AI 工具在处理底层系统工程方面的能力仍然不足。
    • 例如构建高性能的后端架构或进行深度的系统优化。
  8. “品味”的培养：
    • 对于完全依赖 AI 生成代码的“AI 编码原生代”来说，如何培养良好的代码品味和判断代码质量的能力是一个挑战。
  9. 架构可能演变为“一次性”或难以长期维护的状态：
    • 初期构建的代码可能缺乏清晰的结构和长期的可维护性考虑。
    • 在用户量增长和需要添加新功能时，可能会遇到指数级的难度增长，最终导致需要进行大规模重构甚至重写。
  10. “先跑起来再说”的心态可能导致技术债累积：
    • 快速迭代有时会选择重新生成代码而不是深入调试。
    • 长期来看可能导致技术债的快速累积，使得后续的开发和维护变得更加困难。
  11. 架构决策可能更多受到 AI 工具的偏好和能力限制：
    • 开发者在使用 AI 编码工具时，可能会不自觉地受到工具输出的代码模式和风格的影响。
    • 如果开发者本身缺乏深厚的架构设计经验，他们可能会直接采纳 AI 生成的方案，即使这些方案并非最优。
    • 此外，当前 AI 在复杂系统架构和跨模块协调方面的能力仍然有限，这可能会限制架构决策的选择。

IV. 支持 Vibe Coding 的工具与技术：IDE、LLM 与辅助工具

  1. 集成开发环境 (IDEs)：
    • Cursor:
      • 最流行的支持氛围编码的 IDE，尤其在 Y Combinator 孵化的初创公司创始人中广泛使用。
      • 具有 Agent 模式，可以进行代码的读取、写入和执行终端命令。
      • 需要被告知要查看哪些文件以理解上下文。提供手动、自动和 YOLO 三种执行模式。在生产环境或重要项目中，应谨慎使用 YOLO 模式。
      • 提供内置的版本控制和聊天历史功能，可以帮助开发者回溯和恢复代码。
      • 允许添加项目相关的文档（如 API 文档），使 AI 在生成代码和提供建议时能够参考这些信息。
    • Windsurf:
      • 作为一个快速崛起的工具，被认为是 Cursor 的有力竞争者。
      • 主要优势在于能够索引整个代码库，从而更好地理解项目的上下文，而无需像 Cursor 那样显式指定文件。
      • 也支持 Agentic Coding，允许 AI 代理编写整个应用程序。
    • 共同特点: 开发者可以在 Cursor 和 Windsurf 中添加自定义模型，但过程可能不够直接。
  2. 大型语言模型 (LLMs)：
    • Claude (Anthropic):
      • 特别是 Claude 3.7 Sonet thinking 被认为非常支持 agentic behavior 和 function/tool calling。
      • Claude 3.5 Sonet 也被认为是代码辅助模型的黄金标准之一。
      • Claude 3 也被提及在推理方面比 3.5 Sonet 更好，但在实际编程中的使用情况仍在变化。
    • GPT (OpenAI):
      • 提到了 GPT-40，但使用情况相对较少。
    • DeepSeek:
      • DeepSeek R1 被提及作为一种推理模型。
      • DeepSeek 系列模型总体也被认为是包含在 Mamouth 平台中的优秀 LLMs.
    • Gemini (Google):
      • 尽管拥有较长的上下文窗口，但在视频中被提及的使用不多，可能由于其最初的发布问题影响了用户对其的信任。
    • Grok (xAI):
      • 可以作为自定义模型集成到 Cursor 或 Windsurf 中，并且格式遵循 OpenAI API 标准。
    • Llama models 和 Mistral： 被列为 Mamouth 平台提供的 LLMs。
    • 推理模型 (Reasoning Models)： 如 DeepSeek R1 和 03 Mini，被认为在代码理解和调试方面具有更强的能力。
  3. 语音输入技术：
    • 为了进一步解放双手，实现更自然的交互：
      • Super Whisper: 被 Andrej Karpathy 和视频制作者 Matthew Berman 使用，是一种高效的语音转文本 AI 工具。
      • Whisper Flow: 一个允许用户在各种应用程序（包括 IDE、聊天工具、邮件等）中使用语音进行输入的工具，可以用于快速生成代码和文本。
  4. 其他技术和概念：
    • 代码生成 (Codegen) 和 代码补全 (Code Completion)： 这是氛围编码的基础，依赖于 LLMs 的强大能力。
    • Function Calling 和 Tool Calling： LLMs 的这些能力使得 AI 代理能够与外部工具和 API 进行交互，执行更复杂的任务。
    • 上下文管理 (Context Management)： 在 IDE 中管理输入给 AI 代理的上下文非常重要，过多的上下文可能会降低模型性能。Windsurf 通过索引整个代码库来提供更全面的上下文。
    • YOLO 模式 (YOLO Mode)： 在 Cursor 等工具中，允许 AI 代理自动执行更改和命令，无需人工确认，适合快速原型开发，但存在风险。
    • 模型自托管 (Self-hosting Models)： 一些公司，特别是那些处理敏感知识产权的公司，可能会选择自托管 LLMs。

V. Vibe Coding 的工作流程与实践：规格、规则与迭代

  1. 核心工作流程：
    • 编写非常详细的需求规格 (Spec)：
      • 清晰地定义想要构建的应用或功能的技术细节和操作方式。
      • 甚至可以包括数据库结构和 API 接口等信息。
    • 使用支持 Agentic 行为的 AI 代理：
      • 这通常在集成了 AI 功能的 IDE 中完成，例如 Cursor 或 Windsurf。
      • 这些 IDE 允许 AI 代理读取和写入文件，甚至执行终端命令。
      • 推荐使用支持良好 Agentic 行为和函数/工具调用的模型，例如 Claude 3.7 Thinking。
    • 设置规则或编码偏好 (Rules or Coding Preferences)：
      • 这些规则用于告知 AI 代理期望的编码方式、应使用的技术栈和工作流程。
      • 这对于避免 AI 使用不希望的技术或重复代码至关重要。
      • 规则可以定义在项目级别或用户级别。
      • 规则的目的是告诉 AI 代理如何编码，使用什么技术，以及什么工作流程。
    • 将详细的需求规格粘贴到 AI 代理中，并指示其基于该规格进行构建。
    • 进行小范围、增量的请求 (Narrow Requests)：
      • 相比一次性要求 AI 构建大量代码，更好的做法是逐步提出小的功能添加或问题修复请求。
    • 频繁进行测试 (Test Frequently)：
      • 强调进行端到端测试，模拟用户行为来验证功能是否正常工作。
      • 如果测试失败，需要让 AI 代理修复测试。
    • 迭代和完善 (Iterate and Refine)：
      • 根据 AI 的输出和测试结果，不断与 AI 交互，提出修改意见，使其逐步达到期望的效果。
  2. 关键最佳实践：
    • 编写非常具体的需求规格是至关重要的： 越详细的规格能够更好地引导 AI 代理生成符合预期的代码。
    • 使用规则 (Rules) 来强制指定编码偏好和技术栈： 这有助于避免 AI 引入不一致的技术或不希望的模式。规则可以定义在项目级别或用户级别。通过规则 (rules) 功能指导 AI 代码生成的偏好和技术栈，避免 AI 引入不期望的技术。
    • 始终偏爱简单的解决方案 (Always Prefer Simple Solutions)： 指导 AI 选择更直接和易于理解的实现方式。
    • 避免代码重复 (Avoid Duplication of Code)： 要求 AI 在添加新功能或修复旧功能时，检查代码库中是否已存在相似的代码，并进行复用而不是重复编写。
    • 注意区分开发、测试和生产环境 (Separate Dev, Test, and Prod Environments)： 确保 AI 在进行更改时考虑到不同的环境，避免测试代码影响生产环境。
    • 仅进行必要的更改 (Only Make Necessary Changes)： 指示 AI 在修复问题时，仅修改现有代码，而不是完全重写。
    • 注意提供给 AI 的上下文 (Be Aware of Context)： AI 的性能会受到上下文长度的影响，过长的对话历史可能会导致性能下降。
    • 当上下文过长时，开始新的聊天 (Start a New Chat) 以获得更好的结果。
    • 保持请求的范围狭窄 (Stay Very Narrow with Your Requests)： 每次只关注一个小的问题或功能。
    • 频繁测试，特别是端到端测试 (Test Frequently, Especially End-to-End Tests)： 验证整个应用程序的功能是否符合预期。
    • 密切关注 AI 修复测试的方式 (Keep a Close Eye on How AI Fixes Tests)： 确保其修复方式不会影响生产代码的逻辑。
    • 使用流行的技术栈 (Use a Popular Stack)： 流行的技术拥有更多的文档和社区支持，AI 在这些领域表现通常更好。
    • 频繁提交代码 (Commit Often)： 以便在出现问题时可以轻松回滚到之前的版本。
    • 利用 IDE 提供的版本控制功能 (Utilize Version Control Features)： 例如 Cursor 或 Windsurf 内置的检查点恢复。
    • Vibe Coding 的用户仍然需要具备足够的技术知识来判断 AI 生成代码的质量 (Have Enough Technical Knowledge to Judge the Quality of AI-Generated Code)： 人类的品味对于指导 AI 至关重要。
    • 要认识到 AI 在调试方面表现较差 (AI is Terrible at Debugging)： 仍然需要人工进行调试和问题排查。
    • 在调试失败时，可能需要重新生成或重写 (Reroll or Rewrite) 代码。
    • 需要意识到过度依赖 AI 可能会导致对 AI 建议的 偏见 (Biases)。
    • 先编写规范 (Spec)： 在让 AI 生成代码之前，先使用 AI 或其他方式明确定义功能需求和技术规范，可以提高生成代码的准确性。

VI. 软件工程师的角色与技能：从代码编写者到产品塑造者

  1. 角色转变：
    • 从代码编写者转向产品塑造者，更关注用户需求和产品愿景。
    • 人的品味变得比以往任何时候都更加重要，因为工程师需要判断 AI 生成的代码是否符合产品目标和用户体验。
  2. 核心技能：
    • “品味”和判断力： 具备判断代码质量、可维护性和潜在风险的能力。
    • 调试能力： 深入分析代码，找出并修复 bug。可能需要像指导初级工程师一样，非常明确地指导 AI 进行调试。
    • 指导和规范 AI：清晰地表达意图和技术要求。类似于指导一个非常强大的但缺乏自主思考能力的助手。
    • 代码审查和验证： 确保 AI 的输出是正确、安全和符合要求的。需要验证 AI 是否按照既定的架构和最佳实践进行编码。
    • 系统架构和高层设计： 在系统设计、模块划分和技术选型等方面发挥关键作用。AI 更擅长于实现细节，而不是进行宏观的架构规划。
  3. 可能出现新的角色和技能需求：
    • “AI 提示工程师 (Prompt Engineer)”，专注于编写高质量的提示和指令以获得最佳的 AI 代码生成结果。
    • “AI 代码质量保证工程师”，专门负责评估和改进 AI 生成代码的质量。
  4. 工作重心转变：
    • 减少重复性编码任务，更专注于解决复杂问题。
    • 更快的迭代和原型开发。
  5. 应对挑战：
    • 需要应对 AI 可能产生的低质量代码 (Horseshit Code)。
    • 持续学习和适应新技术。
  6. 强调保持学习的热情，不断掌握新的工具和技术，并适应新的工作流程。

VII. Vibe Coding 对软件架构决策的影响：快速迭代与架构权衡

  1. 初期可能忽视整体架构设计，侧重快速实现功能。
    • 这种模式在初创阶段，尤其是创始人为了快速验证想法时，可能会牺牲对整体软件架构的细致规划。
  2. 架构可能演变为“一次性”或难以长期维护的状态。
    • 代码可能缺乏清晰的结构和长期的可维护性考虑，被戏称为 “horseshit code”。
  3. “先跑起来再说”的心态可能导致技术债累积。
    • 快速迭代有时会选择重新生成代码而不是深入调试。
  4. 架构决策可能更多受到 AI 工具的偏好和能力限制。
    • 开发者在使用 AI 编码工具时，可能会不自觉地受到工具输出的代码模式和风格的影响。
  5. 后期可能需要专门的系统架构师来弥补早期架构的不足。
    • 当项目发展到一定阶段，例如达到产品市场契合 (Product Market Fit) 并面临用户规模增长时，早期通过 Vibe Coding 构建的系统可能无法支撑。
  6. 架构的演进可能更加依赖于迭代和重构，而非预先规划。
    • 在 Vibe Coding 的模式下，架构可能不是一开始就精心设计的，而是在不断的迭代和 AI 辅助的代码生成过程中逐步演进和完善。
  7. 对模块化和接口设计的需求可能更高。
    • 为了更好地利用 AI 进行代码生成和维护，清晰的模块划分和定义良好的接口可能变得更加重要。
  8. 架构的演进可能更加依赖于迭代和重构，而非预先规划 (The Evolution of Architecture May Rely More on Iteration and Refactoring Than Pre-planning)。
  9. 强调先跑起来再说，架构或许后期需要弥补。

VIII. 初创公司创始人对 Vibe Coding 的看法：拥抱效率与快速验证

  1. 拥抱 Vibe Coding： 认为是未来的趋势。
  2. 角色转变： 从代码编写者到产品工程师。
  3. 效率大幅提升： 但质量和长期维护存在隐忧。认为将使每个人都成为“10倍工程师”。
  4. 强调快速原型开发和早期验证。
  5. 对代码所有权和深入理解的关注减弱。
  6. 工具的选择和使用成为新的关注点。
  7. 对招聘和技术评估提出新的挑战。 未来面试将更侧重考察候选人与 AI 协同工作的能力。
  8. 短期目标与长期架构的权衡。
  9. 关注快速将想法转化为可运行的产品，而牺牲一些长期的架构考量。
  10. 对编码的依附性降低，如果需要，可以更轻松地放弃或重构 AI 生成的代码，因为生成速度很快。
  11. 对底层技术理解的不足。
  12. 为了速度牺牲一些长期的架构考虑。
  13. 在现有 API 的基础上构建功能。

IX. Airplane Coding 的反思：离线思考与避免锚定效应

  1. 有人提出了“Airplane Coding”的概念，即在没有网络连接、完全依赖自身知识和经验的情况下进行编程。
  2. 这种方式有助于更深入地思考问题，避免过度依赖 AI 带来的“锚定效应” (anchor biasing)。

X. AI 辅助编程实战指南

XI. 技术面试

未来的技术面试可能更侧重于考察候选人使用 AI 工具的能力、代码评审能力、系统设计能力以及解决实际问题的能力。一种新的面试方式是让候选人使用现有的 API 构建功能，或者评审和调试 AI 生成的代码。

结论：Vibe Coding 的未来与挑战

Vibe Coding 代表了一种利用 AI 赋能软件开发的新趋势。它通过提高开发效率和降低编码门槛，使得更多人能够参与到软件创造中。 然而，它也带来了一系列挑战，例如如何保证代码质量、如何有效调试、以及开发者如何适应新的角色和技能要求。

Vibe Coding 并非要完全取代传统编程，而是一种新的工具和方法，它将与传统方法相结合，共同塑造软件工程的未来。 开发者需要拥抱变化，学习如何有效地利用 AI 工具，同时也要保持对基础知识和核心技能的掌握，才能在这个快速发展的时代保持竞争力。 在软件开发的未来以及工程师的价值，需要思考的观点包括：

参考资料