“AI写代码的时代，工程师还需要懂工程吗？”
Google Chrome 开发者体验负责人 Addy Osmani 给出了截然不同的答案。
“Vibe Coding 并不等同于 AI 辅助工程。我们不能因为AI的出现，就贬低了工程这门学科本身的严谨性。”
在最新一期《The Pragmatic Engineer》播客中，Addy 详细阐述了他的新书《Beyond Vibe Coding》的核心观点——AI能帮你提速，但无法替你思考。
他指出：AI 工具可以快速完成70%的工作，但剩下那关键的30%，必须靠真正理解系统的工程师完成。
Addy Osmani带领 Chrome 团队专注于提升网页构建的性能、开发工具，以及整体的开发者体验。如果你曾打开过 Chrome 的开发者工具栏，那么你几乎一定用过由 Addy 参与设计或构建的功能。
小编为大家整理了这期播客的精华内容，你将了解到：
Vibe Coding 和 AI辅助工程的区别
Addy是如何使用AI工具的
AI 如何重塑软件工程工作流
为什么“理解AI生成的代码”依然至关重要
工程经理（EM）和产品经理（PM）的角色将如何变化
新角色的出现与开发者教育的转变
Vibe Coding 和 AI辅助工程的区别
主持人:
你写过不少书，尤其是关于如何带领高效工程团队的那本，差不多一年前出版。而你最近的新书叫《Beyond Vibe Coding》。你在 Substack 上也写了很多关于Vibe Coding以及AI 辅助工程（AI-assisted engineering）的心得。
在你看来，Vibe Coding具体是什么意思？它和AI 辅助工程又有什么异同？
Addy Osmani:
是的，我常常跟人说，我认为Vibe Coding和AI 辅助工程并不是一回事。这个区别非常关键——我们不能因为 AI 的出现，就贬低了工程学本身的价值，否则会让新人误以为构建一个可用于生产的软件系统是件很简单的事。
我大概有两个定义。Vibe Coding 是一种“完全投入与 AI 的创意流”的状态。它更注重高层次提示，在某种意义上甚至“忘记了代码的存在”。
这概念最早可以追溯到 Andrej Karpathy 的定义——它强调接受 AI 的建议而不必深度审查，注重快速、反复的实验性迭代。
我个人觉得这种方式非常适合原型、MVP（最小可行产品）和学习阶段。很多生产团队也发现，当他们需要快速验证一个想法、摸索一个组件或产品雏形时，Vibe Coding 的确非常有用。
它追求的重点是速度与探索，而不是结构化与可维护性。后者才是我们在面向大规模生产时真正要关心的。
所以在我看来，Vibe Coding 和AI 辅助工程其实是一条光谱的两端。前者更偏向自由探索，后者则更接近传统的软件工程方式——需要规划、需求说明、上下文完整性。
而在AI 辅助工程的模式中，AI 是一个强大的协作伙伴，但绝不是工程原则的替代品。它可以在整个软件开发生命周期中为你加速：生成样板代码、调试、部署等等，但核心的控制权仍在工程师手中。你要负责架构设计、代码审查，并且要理解 AI 生成的大部分内容。最终你要确保产品是安全、可扩展、可维护的。AI 可以帮你提速，但绝不意味着你可以“甩锅”给它。
说到底，我认为很多人都觉得 AI 是个倍增器，但实际上，你的专业水平越高，AI 工具的效果越好。相反，如果你是新人或初级开发者，可能还没经历过一些传统工程最佳实践。
而如果你真在乎生产级质量，就不应该提交那些你无法完整解释的代码。因为你不能指望 AI 在未来帮你“解开混乱”。那往往行不通。
Addy是如何使用AI工具的
主持人：
那你个人是怎么使用这些工具的？包括 Vibe Coding 和 AI 辅助工程。
Addy Osmani:
最近我更多地在实践规范驱动开发（spec-driven development），也就是在开始写之前，就非常清晰地知道自己要构建什么。
当然，我仍会在一些场合使用 Vibe Coding：比如做个人小工具、一次性脚本。过去如果产品经理或工程师有个新点子，我们会画个线框或草图；而现在，我可以直接用 Vibe Coding 做出一个能运行的原型，甚至直接在 Pull Request 或聊天里给团队演示——“看，这就是我想的样子”。
这真的非常有力量。我很喜欢 Vibe Coding 带来的这种高质量表达想法的方式。
主持人：
Vibe Coding 现在确实很火。输入一段提示语，几乎马上就能跑起一个应用，感觉像魔法一样。但它没考虑一个关键因素——团队的上下文与积累的知识。每个提示都只基于你告诉它的内容，而不是团队已经知道的。
真正的产品开发恰恰相反：它是集体经验的积累。比如：每个功能背后都有客户请求的历史、每个 PR 都与团队路线图相关、每个文档都埋着讨论痕迹。
而简短的提示语无法让 AI 理解这些“隐性上下文”。像 Linear 的 Agents 就是试图弥补这一点——它们在你的开发系统内部运行，能看到正在阻塞冲刺的 issue、项目目标、过往讨论、设计文档，甚至客户的反馈。当你让它生成一个 PR 或实现某个功能时，它不是“即兴发挥”，而是基于整个团队的语境。这才是真正的AI 驱动开发：不是“快”，而是“有意图地构建”。
Addy Osmani:
是的。但这并不意味着我们可以直接把 Vibe Coding 的原型代码塞进生产系统。一旦你明确了组件或功能的愿景，就应该开始写下：“我们的实际期望是什么？我们把哪些算作需求？”这能让你从模型中获得更高质量的输出。
如果你只是“跟着 vibe 走”，那其实就等于把架构和实现细节都交给了 AI。这在创意阶段可以，但在产品工程阶段绝对不够。对我来说，“规范驱动开发”一直很重要。
我还非常重视测试。如果你愿意用测试去验证 AI 生成代码的正确性，那会极大降低风险。哪怕你用的是最先进的模型，也有可能生成出看似合理但实则混乱的代码。有了测试，你能立刻发现问题在哪。我发现这能帮助项目持续保持在“绿色状态”。顺便提一句——我们团队刚刚发布了Chrome DevTools MCP。
我对质量非常看重。过去几年，我看到很多工程师在遇到 Bug 时，就直接说：“嘿，LLM，看起来这个按钮不对劲，帮我修一下。”这其实又是一种“跟着 vibe 走”的行为。
但如果你能让 AI 工具真正“看到”页面，比如通过浏览器上下文（MCP 就是为此而生的），AI 就能识别哪些地方渲染错了、有哪些控制台报错，从而改进反馈循环。因此我对 MCP 很兴奋——它让我们能更自然地把其他工具整合进工作流中。
除此之外，我发现要真正用好这些工具，仍需要持续投入学习。每当有新模型、新平台出现，我都会去试，并鼓励团队互相分享经验。这种“一起学习”的文化其实很关键，它能让团队在这个快速变革的时代保持心理安全感。
人类监督和代码审查变得更重要
主持人：
你在谷歌这样的大公司里工作，想了解一下，你看到其他团队是如何使用这些 AI 工具的？有没有一些出乎意料的成功或失败案例？
Addy Osmani:
在像 Google 这样的公司，我们有一套长期打磨出的“大规模工程体系”。AI 的出现并没有让这些原则失效，我们依然重视质量、验证和尽职审查。
有趣的是，我们在大公司看到的趋势，其实和初创公司类似：比如“提示词工程”的重要性、以及最近兴起的“上下文工程”，也就是如何构建最佳上下文，让模型输出更可靠。
我们花了很多时间确保每个项目都能提供正确的描述、文件、示例等上下文，这些往往不在模型的训练数据中。
我个人在过去几年几乎在生活的各个方面都尝试使用 AI，这让我对哪些场景真的能带来生产力提升、哪些地方还不够成熟，有了更清晰的认识。
我也鼓励团队在尝试之前先问自己：“如果把这个问题交给 AI，它会帮我更快解决吗？还是会拖慢我？”即使只是思考这个问题，也能帮助我们更好理解 AI 的边界与潜力。
很多传统软件工程师其实对 AI 并不熟悉。我让团队的负责人去深入了解模型评测、基准测试、以及像 RAG 和微调这些核心概念。因为我们做的不只是开发工具——AI 还会影响用户体验、产品设计和工程流程。所以我们需要理解这两端之间的联系。
最大的体会之一是：人类监督永远不能缺席。我们也遇到过很多外部贡献者，用 LLM 自动生成 PR，出发点是好的，但却给维护者带来了巨大负担。
主持人：
对，我看到 Hashimoto 也在社交媒体上抱怨这个问题。很多人出于好意提交 AI 生成的代码，但结果让维护者压力更大。
Addy Osmani:
是的。我很喜欢研究不同开发者群体如何看待 AI。最近有份研究指出：当团队引入 AI 之后，代码产出速度会大幅提升，但人工审查会成为新的瓶颈。PR 数量增加了，可谁来审查？
所以一些团队开始探索让 AI 来做代码审查，但这其实很危险——如果写代码的是 AI、审代码的也是 AI，而人类并未仔细理解代码内容。那我们就无法确定最终到底上线了什么。
我个人也在使用许多工具，比如 Kline、Cursor、Copilot、VS Code。我喜欢去查看这些工具在生成解决方案时的思考过程：它做了什么决策？用了什么逻辑？生成了哪些部分？我会在 PR 之前仔细阅读这些内容。因为最终，我可能要维护那段代码。
就在昨晚，我遇到一个 bug。代码看上去没问题，但功能无法正常工作。我多次请模型去排查，它也不断修改，但依旧没解决核心问题。今晚我得亲自上手调试。如果我当初没认真读懂那段代码，现在就像被扔进丛林一样无所适从。
主持人：
是啊，这就是专业工程师和“只会提示词工程师”的区别。任何人都能输入提示，但不是每个人都能理解系统、修复问题、解释原理。在任何行业中，真正的专业人士都是懂原理的人。否则，如果你完全不知道代码如何运行，那公司为什么还需要你？
Addy Osmani:
没错。随着 Claude Code、Gemini CLI、Open Code 等终端工具兴起，大家又开始讨论“多智能体并行”——让多个 AI 同时协作完成任务。
表面听起来很酷，但现实是：如果缺乏人工审查，你只是在加速技术债的累积。短期内或许没事，但迟早要还。这也让我提出了一个观点：我称之为“70%问题”（the 70% problem）。
能不能请你先解释一下：什么是“70%问题”？你是怎么发现这个现象的？自从六个月前你写那篇介绍文章以来，它有没有什么变化？
Addy Osmani:
当然。模型质量和工具的质量都在不断提升。但所谓“70%问题”，其实说的是这样一个现象：大语言模型通常能在极短时间内生成一个大约70%可用的应用程序雏形，但它们往往在最后30%的环节上卡壳。
那最后的30%，可以理解为“最后一公里问题”。它包含很多开发者都会遇到的情况，比如我常说的“两步退回模式”：你可能用几个提示词让AI逐步搭建出某个功能，但你再给它一个新指令时，它突然“跑偏”，可能整个UI被重写了，或者组件的逻辑被彻底改动。
这其中隐藏着很多可维护性成本和责任模糊地带——当你不够具体，把决策权交还给模型时，你往往会遇到收益递减。
这在 Hacker News 上屡见不鲜：各种安全漏洞、API密钥泄露、XSS攻击……这些问题很多都出现在开发者只顾着“有感觉地写代码（go with the vibes）”，而没有系统性地思考整个问题的时候。
所以说，“凭感觉写出来”的原型，用在MVP或者原型阶段没问题，但一旦要落地进团队代码库、面向真实用户，它就必须重写——要用生产级的质量标准去构建。
安全性与质量问题都在提醒我们：无论AI多强，人类都必须保持在环（human-in-the-loop）。
主持人：
是的，我们现在经常听到这样的故事：产品经理或者非技术型创始人，靠AI做出了一个原型，很兴奋，觉得很快就能上线，但最后要么卡住，要么进度被拖得极长。他们原本以为“一两天能搞定”，结果变成“十天、二十天甚至三十天”。
你在“70%问题”那篇文章里还提到，经验丰富的工程师能比较容易地完成那最后30%，但经验不足的工程师反而会陷入困境，甚至会被AI带来一种“虚假的自信感”。
Addy Osmani:
完全正确。那最后30%的部分，很多初级工程师、新人、实习生都会表现得很挣扎。他们通常只会一遍又一遍地让模型“再试试”“修一下”，但当AI无法修复问题时，他们可能就无从下手了——缺乏调试、分析、定位问题的能力。
这其实说明，批判性思维和系统性问题解决能力仍然是计算机科学最核心的素养。任何人都可以用高层次的prompt让AI输出看似能跑的代码，但那不代表可以信任它上生产。
我们已经看到太多案例，一开始看起来没问题，后来彻底崩溃。
主持人：
这让我想起AI工具出现之前的一个故事。当年我在Uber带一个新人，他来自一个小型创业公司。入职一周后我问他感觉怎么样，他非常焦虑地说：“太难了，我正在读整个代码库。”
我惊呆了：“你要读Uber全部后端代码？那可是几百万行啊！”他说：“我每换一家公司都会把代码全读一遍，这样我能理解所有东西。”
我其实很佩服他的出发点——想从根本上理解系统。但我告诉他：“你不用读完所有代码，你只需要理解结构、知道东西在哪里。”这让我想到，如果你把这种理解能力外包给AI，那你最终就会被AI“反绑架”。
当模型上下文窗口装满，或者那天模型“状态不对”，你就会陷入困境。你唯一的选择可能就是换模型、清空上下文，或者干脆重启。但那种状态让人感觉自己根本不再掌控局面。
Addy Osmani:
没错，你说得非常准确。无论你是资深工程师还是Vibe Coder，都应该记住几件事，这些能帮你保持掌控感。
如何与自动化Agents协作
主持人：
你刚才提到“保持最佳结果”，这让我想到一个很现实的问题：AI和Vibe Coding确实能极大地提高开发速度，你能更快地上线功能。
但“速度”不等于“精度”——你可能只是更快地做错事。你怎么知道自己做的东西真的有效？这个功能是否提升了转化率？是否帮助留存？没有精确的度量，你就像在盲目决策。
Addy Osmani:
没错。要想高效使用AI，你必须理解模型的限制，比如它的上下文窗口是有限的。这意味着你需要像项目经理一样思考：把任务拆解成小的、可验证的块；保持需求清晰，反复迭代；不要妄想“一发入魂”能出完美结果。
这种分解思维其实很像写伪代码、规划Sprint。它能避免上下文丢失和错误累积。
其实，很多传统的软件工程最佳实践依然永不过时。比如：写模块化、可测试的代码；严格执行Code Review；明确输入输出约束；给模型足够上下文。
AI能帮你提速，但人类的审慎仍然是系统成功的关键。越是把责任交给AI，你出错的风险就越高。
主持人：
我听到一位工程师（Flask作者 Armin Ronacher）说过一个很有趣的观察。他说：那些对自己工作掌控感强、信心足的工程师，往往在AI协作中表现更好；反而是那些被任务推动、缺乏掌控感的人，对AI的到来更焦虑。
这其实让我想到我们聊到的主题——你一直强调：保持主导、理解系统、对工具有信心。只要你知道自己可以不用AI也能搞定，只是速度慢一点，那AI就会变成一个强力助推器，而不是依赖。
Addy Osmani:
完全同意。AI只是工具箱里的一件新工具。软件工程一直在演化，每一代都让开发体验更好一些。
我记得当年刚能下载网页模板的时候，我兴奋得不行——“哇，别人已经写好了，我只要改一改就能用！”后来有了更强的命令行工具、脚手架系统，我们不再为“从哪里开始”而烦恼。
AI现在就像是又一次升级：它让我们更容易“起步”，但仍然需要你理解你在向用户交付什么。AI不是用来取代责任的。
过去两年，我经常提醒自己要回到工程第一性原理。我最近在和Google DeepMind团队合作Gemini的编程能力，这让我重新思考：这些模型背后的训练数据是什么？
大多数训练数据都来自GitHub等开源代码，许多是“够用但不完美”的公共代码。这些代码的模式往往只是“能跑”，但未必最安全、最高效、最易维护。
所以，当你记住这一点后，你的期望自然会调整：AI确实比“复制粘贴 Stack Overflow 答案”强，但它输出的代码仍然需要人工审查与打磨，才能达到生产级。
主持人：
这让我想起10年前大家都用Stack Overflow的时代。比如要验证邮箱格式，我们会搜“email validation regex”，然后直接复制点赞最高的答案。
那时候确实方便，但后来我们才发现——很多答案其实不安全，或漏了边界情况。我觉得现在AI生成代码也是类似的，只是规模更大。
Addy Osmani:
完全正确。现在我常听到人问：“既然AI能写代码，我还需要第三方库吗？”这就像当年复制粘贴Stack Overflow答案。但资深工程师会立刻想到：那维护责任谁来承担？
如果你手写功能，就得负责安全修复、平台兼容、未来更新。而使用库，则可以共享修复。这就是权衡（trade-off）的本质。
主持人：
说到底，这就是工程：取舍。你要么承担维护风险，要么依赖外部组件，每个选择都有代价。
产品经理和工程经理的角色变化
主持人：
那你觉得现在AI带来的新工作流里，有哪些是以前的软件工程根本做不到的？
Addy Osmani:
我觉得最令人兴奋的是“异步后台AI代理（asynchronous background coding agents）”。比如让AI在后台帮你改测试、迁移依赖库、加暗黑模式。如果能做到无冲突合并、可验证结果，那将非常强大。
但真正的挑战在于：当你同时指挥多个AI代理（像一个乐队指挥），什么是合理的控制界面？人类注意力是有限的，即使我能同时开20个终端跑不同模型，真正能高质量review的任务量其实很少。所以要像管理Sprint那样，保持聚焦。
另一个趋势是“Vibe Designing”——设计师也在进入AI驱动的协作模式比如Figma、Shopify都在探索让设计师用AI生成交互原型，再交给工程师进行“生产化（productionize）”。
主持人：
我听说Shopify有个团队，所有设计师都在用Cursor。他们先做出Figma设计，然后用Cursor让AI生成可运行的原型，再拿给工程师讨论。不是直接上线，但相比静态设计图，这是一次巨大的协作升级。
Addy Osmani:
我也很佩服Shopify团队，他们的实践说明AI协作是可行的。当然，仍需要清晰的边界：什么是原型，什么是生产代码。但能把静态视觉稿变成半功能原型，已经是革命性的进步。
我觉得接下来变化最大的角色，会是产品经理（PM）和工程经理（EM）：PM要花更多时间在问题定义、指标和AI策略上；EM要在评估、安全和AI治理上花更多心思。
AI不会改变他们的“结果责任”，但会让“品味”成为新的竞争力。因为当每个人都能用prompt实现同样的功能时，真正的差异在于：谁能做出更有品味、更有判断的产品。
AI会让“新手更快上手”，同时也会让“高手更有杠杆”。能写spec、拆任务、懂架构、会审查的高级工程师，价值只会越来越高。整体来看，我对AI在工程领域的未来谨慎乐观。乐观的是工具进步很快；谨慎的是，人类监督仍然是核心。
“三人编程”的协作模式可能会出现
主持人：
现在我回想最优秀的资深工程师——他们的一天其实很像“多智能体协作”：他们带几个中级开发者、几个实习生，不断在 Slack 上被@：“请帮我解个 bug”“能帮我审下代码吗？”
他们来回切换上下文、做评审、提建议、安排工作、开会指导。某种意义上说，高级工程师早就在做“智能体编排”这件事了。
所以如果问我：未来谁最适合管理多个AI代理？毫无疑问，是资深开发者。新手当然也能用AI，但缺少经验，很难驾驭这种多线程协作。
资深开发者之所以能做到，是因为他们理解代码库，知道“好代码”长什么样，而且他们在评审中非常严格。
Addy Osmani:
我完全同意你的看法。而且我认为，开发者教育与团队培养方式也必须随之进化。
我记得当年刚入行时，大家强调“结对编程”。而未来，也许我们会看到“三人编程”——由一个新手、一个资深开发者，加上一个AI组成。
资深开发者可能会要求新人解释AI生成的代码，或引导他们理解代码如何与系统其他部分联动。AI 会成为帮助新人建立自信、理解全局的“教学助理”。
我们也开始看到一些有趣的讨论，比如团队角色可能会进一步细化或重新定义。像“前线部署工程师（forward-deployed engineer）”这样的角色正在重新受到关注，他们通常更接近产品或用户场景，可能会成为未来“AI辅助开发协作”的关键桥梁。
未来教育体系也会随之调整：高中、大学是否会教授“Prompt 工程”“上下文工程”的最佳实践？我们是否还能保持“系统设计思维”？这些问题都值得期待。
