基于 AI 的编程工具在某些任务上好得惊人。[1] 它们擅长生成样板代码、撰写常规函数，并把项目推进到“大部分已完成”的状态。事实上，许多开发者发现，AI 助手往往能先实现一个覆盖大约 70% 需求的初版方案。
Peter Yang 在 X 上的一篇帖子非常精准地概括了我在一线观察到的现象：
作为一个非工程师，用 AI 写代码到目前为止的一些诚实感受：
它能把你带到 70%，但最后那 30% 很让人挫败。它老是前进一步、后退两步，带来新的 bug、问题等等。
如果我懂这些代码是怎么工作的，也许我能自己修好。但因为我不懂，所以我怀疑自己是否真的学到了什么。
非工程师在用 AI 写代码时，常常会撞上一堵令人沮丧的墙：他们能出乎意料地很快推进到 70%，但最后 30% 变成了“边际效益递减”的折磨。
这个“70% 问题”揭示了当前 AI 辅助开发的一个关键事实。起步的过程像魔法一样：你描述需求，像 v0、Bolt 这样的 AI 工具就能生成一个看起来很不错的工作原型。但接下来现实就会浮现。
那 70% 往往是直截了当、模式化的那部分工作——遵循成熟套路或常见框架的代码。正如一位 Hacker News 评论者所说，AI 在处理软件的“附带复杂性”（重复而机械的事务）方面表现出色，而“本质复杂性”——理解并驾驭问题固有的复杂性——仍然落在人类肩上。用 Fred Brooks 的经典表述来说，AI 能对付“附带的”而非“内在的”困难。
这些工具到底卡在哪里？有经验的工程师一致报告存在“最后一公里”的落差。AI 可以给出一个貌似可行的解法，但最后那 30%——覆盖边界情况、打磨架构、保证可维护性——“需要严肃的人类专业能力”。
举例来说，AI 也许会给你一个在基础场景下“确实可用”的函数，但除非你明确提示，它不会自发考虑非常规输入、竞态条件、性能约束或未来需求。AI 能带你走完大半程，但那关键的最后 30%（边界情况、可维护性、稳健的架构）仍需要资深工程师来把关。
此外，AI 存在一个已知倾向：能言善辩却可能不对。它可能引入隐蔽的 bug，或“幻觉”出并不存在的函数与库。Steve Yegge 诙谐地把当今的 LLM 比作“产能爆表的初级开发者”——速度快、热情高，但“仿佛嗑了致幻药”，容易编造离谱或不可行的做法。
用 Yegge 的话说，LLM 能吐出看上去很体面的代码，但如果一位经验不足的开发者天真地表示“看起来不错！”并据此推进，接下来几周就可能上演喜剧（或者灾难）。AI 并不真正理解问题；它只是把通常有用的模式拼接起来。只有人类才能识别表面体面的方案里是否埋着长期地雷。Simon Willison 也有类似观察：他见过 AI 给出一个看似迷人的巧妙设计，只有对问题有深刻把握的高级工程师才能看出其中的缺陷。教训是：AI 的自信远远超过它的可靠性。
更关键的是，现阶段的 AI 并不会创造超越其训练数据的全新抽象或策略。它不会为你发明一种全新的算法或创新架构——它做的是对已知的重混。它也不会为决策承担责任。正如一位工程师所言：“AI 不会比它的训练数据有‘更好的主意’。它也不会为自己的工作负责。”
所有这些意味着：真正的创造性与分析性思考——决定要做什么、如何组织以及为什么——仍牢牢属于人类的领域。总之，AI 是开发者的倍增器，能处理那 70% 的重复性工作，为我们提供“涡轮增压”的生产力。但它不是能取代人类判断的银弹。软件工程剩下的 30%——那些艰难之处——仍需要经过训练、深思熟虑的开发者来完成。这些才是值得长期投入的能力，第 4 章将专门讨论它们。正如一场讨论所说：“AI 是强大的工具，但不是魔法子弹……人类判断与良好的软件工程实践仍然不可或缺。”
开发者实际如何使用 AI
我观察到团队在利用 AI 进行开发时，主要有两种不同的模式。姑且称之为“启动者（bootstrappers）”与“迭代者（iterators）”。这两类都在帮助工程师（甚至非技术用户）把“从想法到落地（或 MVP）”的距离缩短。
首先是“启动者”，他们通常把一个新项目从零推进到 MVP。像 Bolt、v0、以及“截图转代码”的 AI 工具正在颠覆这些团队的启动方式。它们通常会：
- 从一个设计稿或粗略概念开始
- 用 AI 生成一套完整的初始代码库
- 在数小时或数天（而非数周）内得到一个可运行的原型
- 将重心放在快速验证与迭代
效果可能相当亮眼。我最近就看到一位独立开发者用 Bolt 把一份 Figma 设计几乎立刻变成了可运行的 Web 应用。虽谈不上可用于生产，但足以获取最初的用户反馈。
第二类是“迭代者”，他们在日常开发工作流中使用 Cursor、Cline、Copilot、Windsurf 等工具。这种方式不那么花哨，却可能更具变革性。这些开发者会：
- 使用 AI 做代码补全与建议
- 借助 AI 执行复杂的重构任务
- 生成测试与文档
- 把 AI 当作“结对程序员”来一起解决问题
但问题在于：尽管两种方式都能显著提速，它们也带来一些不那么显而易见的隐性成本。
当你看一位资深工程师使用 Cursor 或 Copilot 等 AI 工具时，画面仿佛魔法——他们能在几分钟内搭出完整的功能骨架，连同测试与文档一并就绪。但仔细观察，你会发现一个关键点：他们并不是照单全收 AI 的建议。他们在持续把生成的代码提炼为更小、更聚焦的模块；他们在补上全面的错误处理与边界情况处理（AI 往往遗漏）；他们在强化类型定义与接口；他们会审视并质疑 AI 的架构决策。换言之，他们在用多年打磨出的工程智慧去塑形、约束 AI 的输出。AI 确实加速了实现过程，但让代码保持可维护性的，正是他们的专业能力。
常见失败模式（Common Failure Patterns）
初级工程师往往会忽视这些关键步骤，更容易照单全收 AI 的输出，导致我称之为“纸牌屋式代码”——看起来完备，但在真实环境的压力下会轰然倒塌。
倒退两步（Two steps back）
接下来通常会出现一个可预测的反模式，我称之为“倒退两步”模式（如图 3-1 所示）：
- 你尝试修复一个小 bug。
- AI 给出一个看似合理的修改建议。
- 这个修复又把别的东西弄坏了。
- 你让 AI 去修新的问题。
- 结果又引入了两个新问题。
- 周而复始。
这种循环对非工程师尤其痛苦，因为他们缺乏理解“到底哪里出了问题”的心智模型。经验丰富的开发者遇到缺陷时，能凭借多年模式识别来推断可能成因与解法。没有这类背景，你基本上就是在对一堆自己并未真正理解的代码玩“打地鼠”。这正是我在本书前言中提到的“知识悖论”：资深工程师用 AI 加速他们已经会做的事，而初级开发者则试图用它来学习该做什么。
对以“启动者（bootstrapper）”模式用 AI 搭建 MVP 的非工程师来说，这种循环尤为折磨，因为他们缺少解决这些问题所需的心智模型。不过，即便是经验丰富的“迭代者（iterator）”，如果过度依赖 AI 的建议而缺乏深入验证，也会落入这种打地鼠陷阱。
这里有个更深层的问题：让 AI 编码工具对非工程师“友好可用”的正是它代你处理复杂性的能力，但这恰恰可能妨碍学习。当代码在你不理解其底层原理的情况下就“凭空出现”，你无法发展调试能力，错过对基础模式的学习，也难以就架构决策进行推理，于是维护与演进代码就会步履维艰。这会造成一种依赖：你不断回到模型那里让它修问题，而不是培养自己解决问题的专业能力。
随着“自主式 AI 编码代理”的出现，这种依赖风险进入了新维度——我会在第 10 章深入讨论。不同于当下只给出代码片段建议的工具，这些代理代表着软件开发方式的根本转变。写下这些文字时，我们已经在见证早期系统的部署：它们能在极少人类监督下，独立规划、执行并迭代完整的开发任务。
从“辅助式”走向“自主式”的演化，带来了关于开发者专业能力与控制权的深刻问题。当 AI 系统能处理从初始实现到测试与部署的完整开发工作流时，技能退化的风险将急剧上升。重度依赖此类代理、却不维护自身基础知识的开发者，可能会在 AI 的决策偏离预期结果时，难以及时有效地审计、引导或介入。
当我们考虑这些自主系统如何在一个项目中做出层层相依的级联决策时，挑战会进一步放大。每个单独选择在孤立看来也许合理，但累计效应可能把开发引向意料之外的方向。缺乏及早识别并纠正这种“轨迹偏移”的专业能力，团队就有可能在并不真正理解的地基之上，构筑起愈发复杂的系统。
正如后文将更全面讨论的那样，自主编码代理的到来并未削弱软件工程基本功的重要性——反而放大了它。AI 工具越强大，我们越需要保有把自己当作系统“架构师”而非“操作员”的专业素养。唯有对软件原理的深刻理解，才能确保这些了不起的工具是在增强而不是侵蚀我们的能力。
“演示质量”陷阱（The demo-quality trap）
这已成一种模式：团队用 AI 迅速搭出令人惊叹的演示。理想流程（happy path）运转完美，投资人和社交媒体纷纷惊呼。但当真实用户开始四处点击时？事情就开始崩坏。
我亲眼见过：对普通用户毫无意义的报错信息，导致应用崩溃的各种边界情况，从未被清理的混乱 UI 状态，被完全忽视的可访问性，以及在慢设备上的性能问题。这些不只是“低优先级 bug”——它们决定了产品是“勉强能用”，还是“让人喜爱”。
要打造真正自助式的软件——那种让用户无需联系支持的产品——需要一种不同的思维方式，回归那门逐渐失落的“打磨之道”。你需要执着于错误信息的可理解性；在慢网速与真实的非技术用户环境下测试；让功能易于被发现；并优雅地处理每一个边界情况。这种对细节的关注（也许）无法由 AI 自动生成，它源自共情、经验，以及对工艺的深切在乎。
真正有效的方法：实用的工作流范式
在进入本书第二部分的编码内容之前，我们需要先讨论现代开发实践，以及 AI 辅助编程如何融入团队工作流。毕竟，软件开发不仅仅是写代码——它是一整套包含规划、协作、测试、部署与运维的流程。而 vibe 编码 也不是孤立的新奇事物——它可以被编织进敏捷方法与 DevOps 实践中，在保证质量与可靠性的同时提升团队生产力。
在本节中，我们将探讨团队成员如何集体使用 vibe 编码 工具而互不干扰，如何在 AI 建议与人类洞见之间取得平衡，以及 CI/CD（持续集成/持续交付）流水线如何纳入 AI 或适配 AI 生成代码。我也会简要提及诸如版本控制策略等重要考量。
在观察了数十个团队之后，我发现以下三种模式在个人与团队工作流中都能稳定奏效：
- AI 作为首稿作者
由 AI 模型生成初始代码，随后由开发者进行打磨、重构与测试。 - AI 作为结对程序员
开发者与 AI 持续对话，反馈回路紧密，频繁代码审查，并仅提供最小必要上下文。 - AI 作为验证者
开发者仍然编写初始代码，然后使用 AI 来校验、测试并改进它（见图 3-2）。
在本节中，我将依次带你走过每一种模式，讨论相应的工作流与成功要点。
AI 作为首稿作者（AI as first drafter）
在让 AI 模型起草任何代码之前，务必确保团队里所有人对齐共识。沟通是关键，这样开发者就不会各自让 AI 助手去做重复的任务，或生成彼此冲突的实现。
在每日站会（敏捷流程的基本环节）中，不仅要讨论自己正在做什么，也值得说明是否计划用 AI 处理某些任务。比如，两位开发者可能分别在做不同功能，但都涉及一个日期格式化的工具函数。如果两人都让 AI 去生成一个 formatDate 辅助函数，最后就可能出现两个类似的实现。事先协调（“我来生成一个大家都能复用的日期工具”）可以避免重复。
能够成功整合 AI 工具的团队，往往会先就编码规范与提问（prompt）实践达成一致。例如，团队可能决定统一的风格（lint 规则、项目约定），甚至把这些指南喂给 AI 工具（一些助手允许提供风格偏好或示例代码来引导输出）。正如 Codacy 的博客所指出，通过让 AI 熟悉团队的编码标准，生成的代码会更一致，也更便于所有人使用。实践层面，这可能意味着在项目的 README 中设一个“AI 使用提示”章节，写明诸如“我们只使用函数式组件”或“优先使用 Fetch API 而非 Axios”等事项，便于开发者在向 AI 提示时牢记。
另一个做法是（若工具支持）利用协作功能。一些 AI 辅助的 IDE 允许共享 AI 会话，或至少共享所用的提示语。如果开发者 A 用一段提示为复杂组件拿到了很好的结果，把这段提示分享给开发者 B（比如通过 Issue 跟踪器或团队聊天）能节省时间并提高一致性。
至于版本控制，基本功依旧重要，但要略作“加码”。在现代开发中使用 Git（或其他版本控制系统）是不可或缺的，这一点在 vibe 编码 中同样不变。实际上，当 AI 以更高速度生成代码时，版本控制变得更关键。提交（commit）就是捕捉 AI 失误的安全网：一旦 AI 引入的改动把某处弄坏了，你可以回退到之前的提交。
一种策略是在使用 AI 辅助时更频繁地提交。每当 AI 产出一个你接受的“显著代码块”（比如生成了一个功能或进行了一次大型重构），都考虑用清晰的信息做一次提交。频繁提交可确保当你需要二分定位问题或撤销部分 AI 引入的代码时，历史足够细粒度。
此外，尽量将不同的 AI 引入改动进行隔离。如果让 AI 在多个区域做了大量修改却一次性提交，一旦出问题就更难拆解。比如，你用一个代理（agent）做性能优化，它同时还改动了一些 UI 文案，那么应分别提交。（你的两条提交信息可能是“优化列表渲染性能 [AI-assisted]”与“更新锻炼完成消息的 UI 文案 [AI-assisted]”）。描述性提交信息很重要；一些团队甚至会给 AI 参与度高的提交打上标签，便于追溯。这并非为了“甩锅”，而是为了理解代码的来源——带有“[AI]”标签的提交会提醒评审者：这段代码可能需要在边界情况方面更加仔细地审阅。
本质上，团队应把 AI 的使用当作日常开发对话的一部分：分享经验、成功技巧，以及“不要这样做”的提醒（比如“Copilot 会建议为 X 使用一个过时的库，小心这个点”）。
在这一模式中，评审与精炼至关重要。开发者应手动审查并为模块化进行重构，补充完备的错误处理，编写全面的测试，并在优化过程中记录关键决策。下一章将详细展开这些流程。
AI 作为结对程序员（AI as pair programmer）
传统的结对编程是两位人类在同一工位协作。随着 AI 的出现，一种混合方式兴起：一位开发者与 AI 助手结对。这种设置常常很有效，结合了人类直觉与机器效率。
在人机结对中，开发者与 AI 互动以生成代码建议，同时对输出进行审阅和打磨。这样，人类可以利用 AI 在处理重复性任务（如样板代码或测试用例生成）上的速度优势，同时保持对代码质量与相关性的把关。
例如，在集成一个新库时，开发者可以提示 AI 起草初始集成代码，随后对 AI 的建议进行审阅，并对照官方文档核实其准确性。此过程不仅加速开发，还能促进知识获取，因为开发者需要同时深入理解 AI 的输出与该库的细节。
与传统的人—人结对相比：
- 人—AI 结对能快速生成代码并高效处理琐碎任务，特别适合单兵作战的开发者或团队资源有限的场景。
- 人—人结对则在复杂问题求解方面更胜一筹，适合需要细腻理解与头脑风暴的情境，并能促进共同所有权与集体代码理解。
两种方式各有优劣，选择取决于项目复杂度、资源状况以及开发过程的具体目标。
人机结对的最佳实践（Best practices for AI pair programming）
- 为不同任务开启新的 AI 会话
有助于保持上下文清晰，确保 AI 的建议聚焦于当前任务。 - 让提示语聚焦且简洁
明确而具体的指令能显著提升 AI 输出质量。 - 频繁审阅并提交改动
经常集成与测试 AI 生成的代码，有助于及早发现问题并维持项目推进节奏。 - 保持紧密的反馈回路
持续评估 AI 的贡献，必要时给予纠正或细化，以引导其后续建议更贴合预期。
AI 作为验证者（AI as validator）
除了生成代码，AI 还可作为有价值的验证者，协助代码审查与质量保证。AI 工具能分析代码中潜在的缺陷、安全漏洞以及对最佳实践的遵循情况。例如，DeepCode 与 Snyk 的 AI 驱动代码检查器可以识别诸如缺少输入校验/净化或不安全配置等问题，并直接在开发环境中给出可执行的改进建议。Qodo、TestGPT 等平台可以自动生成测试用例，扩大覆盖面、减少手工工作。许多 AI 工具还可协助监控应用性能，检测可能暗示底层问题的异常。
将 AI 验证者融入开发工作流，能提升代码质量、降低缺陷发生概率，并确保符合安全标准。这种前置式验证与人工把关相辅相成，使软件更加稳健可靠。通过处理重复且耗时的任务，这些工具提升了 QA（质量保证）流程的效率与效果，从而让人工测试人员将精力集中在更复杂、更微妙的 QA 环节上。
无论将 AI 用作结对程序员，还是作为验证者，只要有意识地整合这些工具，开发者就能同时发挥人类与人工智能的长处，提升生产力与代码质量。
为最大化 AI 与人类在 QA 中的协同效益，我建议遵循以下实践：
- 先用 AI 做初步评估与快速扫描，找出显而易见的问题。
- 将关键领域（如复杂功能、用户体验以及 AI 的局限点）优先交由人工审查。
- 营造持续协作的环境，让 AI 工具与人工测试相互配合，建立不断循环的反馈回路，以同时改进 AI 的表现与人类的决策质量。
Vibe 编码的黄金法则（The Golden Rules of Vibe Coding）
尽管 vibe 编码 为软件开发带来了前所未有的速度与创作自由，但也正因为它的灵活，才需要采用结构化的方法来确保一致的质量与团队凝聚力。若缺乏能在“创造性探索”与“工程纪律”之间取得平衡的清晰准则，AI 辅助开发那种快速、直觉式的特性很快就会滑向混乱。
这些黄金法则源自成功将 vibe 编码 融入工作流的各个团队的集体经验。它们凝结了来之不易的洞见：AI 擅长什么、会在哪些地方绊倒、以及在人类判断贯穿全过程中的不可替代性。与其说这些原则束缚创造力，不如说它们为团队提供了一个可放心试验的框架，同时维持达到生产级软件所需的标准。
这些规则聚焦于 vibe 编码 的三个关键维度：人机交互、AI 生成代码与现有系统的集成、以及支撑可持续 AI 辅助开发的团队实践。遵循这些指南，团队既能释放 vibe 编码 的变革力量，又能避开导致技术债务、安全漏洞或不可维护代码库的常见陷阱：
- 明确具体地表达你的需求
与 AI 交互时清晰阐述需求、任务与预期结果。精准的提示带来更精准的结果。 - 始终将 AI 输出与原始意图对照校验
在接受前，务必核对 AI 生成代码的功能性、逻辑性与相关性，确保与最初目标一致。 - 把 AI 当作“需要监督的初级开发者”
将其输出视为草稿，需要你的细致把关与反馈、打磨，确保质量与正确性。 - 用 AI 拓展能力，而不是替代思考
让 AI 自动化例行或复杂任务，但你必须始终主动参与问题求解与决策。 - 在生成代码之前先与团队对齐
就 AI 使用标准、代码期望与实践先达成一致，再启动 AI 驱动的开发。 - 把 AI 的使用当作日常开发对话的一部分
定期与团队交流 AI 的经验、技巧、成功与坑点，把它常态化为集体进步的工具。 - 在 Git 中隔离 AI 改动，分开提交
在版本控制中清晰标识并分离 AI 引入的更改，便于评审、回滚与追踪。 - 所有代码——不论人写还是 AI 写——都必须走代码评审
用同样严格的流程审查所有贡献，既提升质量，也增进团队对代码的理解。 - 不要合并你不理解的代码
在彻底理解其功能与影响之前，切勿集成 AI 生成代码。理解是可维护性与安全性的前提。 - 优先重视文档、注释与 ADR
清楚记录 AI 生成代码的动机、功能与上下文。良好的文档能确保长期清晰，减少未来技术债。 - 分享并复用有效的提示语（prompts）
记录那些能带来高质量输出的提示，维护一份“经验证提示库”，以简化后续交互并提升一致性。 - 定期复盘与迭代
阶段性审视并优化你的 AI 开发工作流，用过往经验的洞见持续改进团队方法论。
遵循这些黄金法则，团队就能高效驾驭 AI，在保持清晰、质量与可控的同时，显著提升生产力。
摘要与下一步（Summary and Next Steps）
“70% 问题”刻画了当下 AI 辅助开发的现实：这些工具在生成样板代码与常规函数方面表现优异，但在最后 30%——涵盖边界情况、架构决策与投产就绪——上却显得乏力。我们识别出两种主要的使用模式——**启动者（bootstrappers）**快速搭建 MVP，**迭代者（iterators）**将 AI 融入日常工作流——以及常见的失败模式，比如“倒退两步（two steps back）”反模式与“演示质量陷阱（demo-quality trap）”，后者指的是华丽的原型在真实压力下土崩瓦解。
三种被验证有效的工作流范式已经浮现：AI 作为首稿作者（先生成，再打磨）、AI 作为结对程序员（持续协作）、以及AI 作为验证者（人写初版，AI 做分析）。vibe 编码 的黄金法则提供了关键的护栏，强调清晰沟通、充分校验、团队协同，以及那条不可谈判的底线：在合并之前务必真正理解所有代码。
对个体开发者而言，应当选择一种工作流范式进行系统化试验，同时在日常实践中落实这些黄金法则。重心放在第 4 章所涵盖的耐久型技能：系统设计、调试与架构——而不是试图在代码生成速度上与 AI 竞争。
对团队而言，需要建立 AI 使用标准、沉淀并共享高效提示语（prompts）的仓库，并将 AI 相关考量纳入既有的敏捷实践。持续分享成功经验与踩坑教训，将帮助团队规避常见陷阱，同时最大化 AI 的收益。
随着自主式 AI 编码代理的出现，人类角色将转向架构层面的把控与战略性决策。下一章将探讨如何最大化这种不可替代的人类价值，帮助各层级工程师以“与愈发强大的 AI 协作”的姿态蓬勃发展，而非与之竞争。
——
注释
1 本章基于作者在其 Substack 通讯中发表的文章：Addy Osmani，“The 70% Problem: Hard Truths About AI-Assisted Coding”，Elevate with Addy Osmani，2024 年 12 月 4 日。
