558 - 《读书笔记：Vibe Coding，The Future of Programming》

注：这本书目前还没有写完。最终的发布日期应该是在2025年8月份。现在只有 3 和 4 两章。

关于作者：Addy Osmani 是一位在 Google Chrome 担任高级工程领导的专家，专注于开发者体验、性能优化及 AI 驱动的软件开发工具。他拥有超过 20 年的网页技术开发经验，出版了多本关于软件工程最佳实践的书籍，并深入研究和测试了 GitHub Copilot、OpenAI Codex 等 AI 开发工具。

3、Chapter 3：AI辅助开发中的“70%问题”与实用工作流程。

AI编码工具在处理某些任务时表现出色，尤其是在生成样板代码、常规函数和完成项目初稿方面，许多开发者发现AI能覆盖约70%的需求。然而，最后30%的实现——包括处理边缘情况、优化架构和确保可维护性——往往需要人类的专业知识。正如 Peter Yang的推文所言，非工程师在使用AI时常因缺乏代码理解而陷入“最后30%”的挫折感。

一些观点如下。AI完成约70%的工作，但剩余30%涉及“本质复杂性”（essential complexity），AI无法有效解决。AI擅长处理“偶然复杂性”（accidental complexity），即重复性机械任务。当前大型语言模型（LLM）是“高效但可能不靠谱的初级开发者”，其输出可能看似合理却隐藏长期隐患。只有资深工程师才能识别AI提出的巧妙但有缺陷的设计。

AI 辅助开发的两种模式：Bootstrapper 与 Iterator 。

• Bootstrapper（启动者）：主要用于从零到最小可行产品（MVP）的项目，借助工具如 Bolt、v0 等将设计或概念快速转化为工作原型，通常在数小时或数天内完成，显著缩短开发周期。
• Iterator（迭代者）：在日常开发中应用工具如 Cursor、Copilot 等，用于代码补全、复杂重构、测试生成及文档编写，起到“结对编程”作用。这种模式虽不显眼，但对生产力的提升更具变革性。

尽管两种模式加速了开发，但存在隐藏成本。资深工程师在使用AI时会持续重构代码、加强错误处理和类型定义，而初级工程师易接受AI输出，导致“纸牌屋代码”（house of cards code），即看似完整但在现实压力下易崩塌。

AI 辅助常见失败模式和挑战。

• Two Steps Back：修复AI生成代码中的小bug常导致新问题，形成“打地鼠”式循环，非工程师尤为痛苦，因缺乏调试心智模型。所以，资深开发者用AI加速已知任务，而初级开发者试图通过AI学习基础知识，却因缺乏理解而加深依赖。
• Demo-Quality Trap：AI快速构建的演示版本在“快乐路径”上表现完美，但面对真实用户时，因边缘情况、性能问题及可访问性缺失而崩溃。所以，打造真正自助式软件需注重细节打磨，这种“工艺精神”难以由AI生成，需依赖经验与同理心。
• Agentic AI 风险：随着Cline、Devin AI等工具的兴起，AI可自主规划、执行和迭代任务，但若用户缺乏基础知识，可能对AI决策失去控制，增加级联错误风险。

三种 AI 辅助有效的模式。

• AI作为初稿者（First Drafter）：AI生成初始代码，开发者随后精炼、重构和测试。团队需提前沟通，避免重复生成代码，并制定一致的编码标准和提示实践（如将风格指南输入AI工具）。版本控制（如Git）尤为重要，建议频繁提交AI生成代码，并隔离不同变更以便追踪。
• AI作为结对程序员（Pair Programmer）：AI与开发者实时互动，处理重复任务，开发者则审查输出并确保质量。与传统人类结对编程相比，AI模式在代码生成速度上占优，但人类协作更适合复杂问题解决。最佳实践包括为不同任务开启新AI会话、保持提示简洁、频繁审查提交及维持紧密反馈循环。
• AI作为验证者（Validator）：AI