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