就在这种看似不可阻挡的浪潮中，Google 的资深工程负责人 Addy Osmani 却选择站在浪头对面。他在 Google 掌管着庞大的工程体系，也长期深耕前端生态，如今却提出：Vibe Coding 不是未来，它只是幻觉。
Addy 的核心观点非常尖锐。他认为，Vibe Coding 在融资叙事中的狂热，与它在工程现实中的脆弱，形成了巨大反差。这种方式适合原型、适合探索、适合灵感碰撞，却绝对不适合作为生产级系统的基石。他甚至直言，把 Vibe Coding 当工程，只会把你推向一个无法维护、无法扩展、无法交代的深坑。
Addy 对“多智能体协作”的态度也很泼冷水。外界热衷讨论如何让多个 AI 同时并行完成任务，仿佛这是一条通往超级效率的捷径。但 Addy 认为，多智能体只是把混乱放大成指数级。如果工程师无法审查、无法解释这些代理之间的通信与逻辑，那么所谓的“自动化协作”不过是一场更大型的技术债游戏。他甚至预言，未来一段时间内，最棘手的线上事故，反而很可能来自这类“我们以为它能自己搞定”的自动化 agent 系统。
在团队管理上，他也给出了与主流完全相反的判断。很多公司认为 AI 会降低门槛、让新人更快上手，但 Addy 却认为，AI 时代最容易迷失的正是新人。快捷的生成让他们误以为自己理解了系统，但只要遇到一个模型解决不了的问题，他们就像被抽走了地基，连站稳的能力都没有。他认为未来的工程教育必须重新训练“系统理解”“调试能力”“批判性思考”，否则新人会被 AI 容易生成的幻觉淹没。
在这个所有公司都想讲 AI 故事、所有工具都主打自动化的时代，Addy 希望大家重新看见一个被忽略已久的事实——工程从来不是“写出代码”，而是“理解系统、负责后果”。
以下是全文翻译。
主持人：你写过不少书，尤其是那本讲怎么打造高效工程团队的，上线差不多已经一年了。你最近的新书叫《Beyond Vibe Coding》，你在 Substack 上也持续写 Vibe Coding 和 AI 辅助工程（AI-assisted engineering）相关的文章和思考。你自己怎么定义 Vibe Coding？在你看来，它和 AI 辅助工程到底有什么本质区别？
Addy Osmani：是的，我经常跟别人强调，在我心里，Vibe Coding 和 AI 辅助工程完全不是一回事。这层区分非常重要。如果因为 AI 的出现，就顺手把“工程学本身”的价值矮化了，那会让很多新手误以为，构建一个真正能跑在生产环境里的软件系统，是一件简单到只需要丢给模型的事情。
我一般会从两个角度来定义 Vibe Coding。简单说，Vibe Coding 是一种“整个人沉浸在和 AI 共创的创意流里的状态”，你更多是在给出抽象的、高层次的提示，而不是一行一行去敲代码，在某种意义上，你甚至刻意把“写代码”这件事淡化、遗忘掉。
这个概念最早可以追溯到 Andrej Karpathy 的说法。他强调的是一种“接受 AI 建议但不过度审查”的工作方式，重点放在高速、频繁、可以不断推倒重来的实验性迭代上。就我个人体验而言，这种方式非常适合做原型、搭建 MVP（最小可行产品）、以及处在学习和探索阶段的项目。很多生产团队也发现，当他们只是想快速验证一个想法，摸一个组件的大致形态，或者搭一个产品雏形时，用 Vibe Coding 的方式确实很高效。它真正追求的是速度和探索感，而不是结构化、可维护性、稳定性这些在大规模生产环境下必须死盯的事情。
从这个角度看，我一直认为 Vibe Coding 和 AI 辅助工程其实是一条光谱的两端。Vibe Coding 更像是自由的创作和探索，AI 辅助工程则更靠近传统的软件工程方法，它需要清晰的规划，需要成体系的需求说明，需要完整且可追溯的上下文。在 AI 辅助工程的模式里，AI 是一个非常强的协作者，但它绝对不是工程原则的替身。
AI 可以参与整个软件开发生命周期，帮你生成样板代码，帮你调试，帮你做部署和一些重复性工作，但最终的方向盘仍然在工程师手里。你要负责架构设计，要对代码审查负责，要真正理解绝大多数由 AI 生成的内容。你得为系统的安全性、可扩展性、可维护性兜底。AI 的确可以帮你提速，但这不意味着你可以把责任、判断和后果一股脑“甩锅”给它。
说到根上，我觉得很多人习惯把 AI 当作“倍增器”，这一点没错，只是他们往往忽略了倍增器的前提。你的专业能力越扎实，你从 AI 工具里获得的回报就越大。反过来，如果你只是刚入行，或者还没经历过那些传统工程最佳实践的训练，你会很容易被 AI 提供的“快捷感”误导。倘若你真的在意生产级质量，你就不应该把任何一段你自己都解释不清楚的代码提交进主干。你根本不能指望哪天再回头，让 AI 帮你把这些混乱拆开、理顺，大多数时候这件事根本行不通。
Addy 是如何使用 AI 工具的
主持人：那说回你自己。你个人在日常工作里，是怎么使用这些工具的？包括 Vibe Coding 和更偏工程范式的 AI 辅助模式。
Addy Osmani：这段时间我更多在实践的是“规范驱动开发”（spec-driven development）。也就是说，在真正开始写任何东西之前，我会先把自己要构建的内容想清楚、写明白——功能是什么，边界在哪里，预期行为是什么。
当然，我依然会在很多场景下用 Vibe Coding。比方说，我要写一个个人小工具，做一个一次性的脚本，或者想把脑子里的点子立刻变成一个可以跑起来的 demo。以前如果产品经理或者工程师突然冒出一个想法，我们可能会用白板画个线框，或者在纸上随手勾几笔。现在我可以直接用 Vibe Coding 搭一个可以运行的原型，把它丢进一个 Pull Request 里，或者在聊天工具里发给团队，边演示边说：“你看，我想的是大概这样的效果。”这种方式在表达想法、拉齐预期上真的很有力量，我特别喜欢 Vibe Coding 在这方面带来的“高保真表达”。
主持人：的确，现在 Vibe Coding 这么火，就是因为它给了大家这种近乎“魔法般”的体验。你输一段提示，几乎立刻就有一个能跑的应用冒出来，看上去就像一键把想法变成了软件。不过，它有一个很大的盲区，就是完全不考虑团队已有的上下文和沉淀下来的知识。
每一个提示词，其实只基于你当下告诉模型的那一点点信息，而不是基于整个团队长期积累的认知。可真正的产品开发正好相反，它本质上是集体经验的堆叠：每一个功能背后都有用户需求和客户请求的历史，每一个 PR 都和产品路线图有关系，每一份文档里都埋着讨论记录和决策脉络。这些“隐性上下文”，几句提示词根本承载不住，AI 也无法凭空感知。
像 Linear 做的 Agents，其实就是在填补这一块空白。它们直接运行在你的开发系统内部，能看到当前冲刺里被阻塞的 issue，能读到项目目标、历史讨论、设计文档，甚至还能看到客户反馈。当你让它生成一个 PR 或实现某个功能时，它不是凭借一两个 prompt 即兴发挥，而是在一个完整的团队语境里做决策。对我来说，这才更接近真正的 AI 驱动开发，它的关键词不是“快”，而是“在充分上下文之上的有意图构建”。
Addy Osmani：是的，但这并不意味着我们可以把 Vibe Coding 阶段产出的原型代码，直接原封不动塞进生产系统。
当你对一个组件或一个功能的愿景已经比较清楚的时候，下一步应该做的事情，是把这些愿景写实，写成一句一句可执行的期望，例如“我们真正想要的行为是什么”“什么情况算达标，什么情况算失败”。一旦你把这些东西写出来，你从模型里得到的输出质量几乎都会明显提升。相反，如果你始终只是“跟着 vibe 走”，那就等于把架构、抽象、实现细节全部交还给模型去随意裁决。这在只做创意和原型的时候问题不大，一旦进入产品工程阶段，就远远不够了。
对我来说，“规范驱动开发”一直是个非常核心的习惯。我同样极其看重测试。只要你愿意用测试去验证 AI 生成代码的正确性，风险就会被压下来很多。即便你用的是当下最强的模型，它也仍然可能输出那些看起来很合理、实际上却乱七八糟的实现。有了测试，你可以立刻知道哪一块出了问题，项目也能持续保持在一种“绿灯状态”。
顺便提一句，我们团队刚刚发布了 Chrome DevTools MCP。这件事对我很重要，因为它本质上在解决质量问题。过去几年，我看到太多工程师在遇到 Bug 时，第一反应就是：“嗨 LLM，这个按钮好像不对劲，帮我修下。”这其实也是一种“跟着 vibe 走”的行为。
如果你能让 AI 工具真正“看到”页面，比如注入浏览器上下文，让它理解 DOM、布局、控制台报错这些真实信息，AI 就能更准确地识别哪些地方渲染错了，哪些脚本在报错，进而给出更好的修复建议。MCP 的设计初衷就是把这些上下文拉进来，让 AI 不再只是靠猜。也正因为如此，我对 MCP 特别兴奋，因为它让我们能更自然地把各种工具接入到工作流中，而不是简单给一个 prompt 就完事。
除此之外，我越来越清楚一件事：想真正用好这些工具，必须持续投入学习。每当有新的模型、新的平台发布，我都会自己上手试，并且鼓励团队互相分享使用经验。这种“集体练级”的文化非常关键，它能在高速变化的环境下给团队提供一定的心理安全感，让大家觉得自己不是一个人在硬顶，而是在一起摸索新的工作方式。
人类监督和代码审查变得更重要
主持人：你一直在谷歌这样的大公司工作，你看到的内部情况是什么样的？其他团队在使用这些 AI 工具时，有没有什么让你印象特别深刻的成功经验或翻车案例？
Addy Osmani：在 Google 这样体量的大公司，我们有一整套迭代了很多年的“大规模工程体系”。AI 的出现并没有让这些原则失效，我们仍然极度强调质量、验证和各个环节的尽职审查。
有趣的是，我们在大公司里看到的趋势，和很多初创公司经历的非常相似。比如对“提示词工程”重视程度的提升，再比如最近讨论越来越多的“上下文工程”——如何为模型构建最合适的上下文，让它输出的东西更可靠、更可复现。为了这件事，我们花了非常多的时间，去确保每一个项目都能给模型提供准确的描述、配套的文件、真实的示例，而这些材料在模型的原始训练数据里往往是不存在的。
在过去几年里，我几乎把生活的每一个角落都拿来试验 AI，这让我更清楚哪些场景真的能带来生产力提升，哪些地方则还停留在“玩具”阶段。我也会不断提醒团队，在把任务交给 AI 之前，先问自己一句话：“如果把这个问题交给 AI，它能帮我更快解决，还是只会让我兜更多弯路？”哪怕只是认真思考这个问题，也能帮助我们更好地理解 AI 的边界，以及它真正的优势在哪里。
很多传统软件工程师其实对 AI 并不熟悉，所以我会刻意推动团队里的负责人，去深入理解模型评测、基准测试这些东西，也会让大家去摸清楚像 RAG、微调这种核心能力。原因很简单，我们做的已经不只是“写开发工具”了，AI 还会直接改变用户体验、产品形态以及工程流程。只有理解这两端之间的连结，才有可能正确地设计系统。
这一切带给我的最大感受之一，就是“人类监督永远不能被抽走”。我们已经遇到过太多外部贡献者，他们善意地用 LLM 自动生成 PR，初衷是想帮忙，结果却给维护者平添了巨大的负担。
主持人：是的，我也看到 Hashimoto 在社交媒体上吐槽过这一点。很多人出于好意提交 AI 生成的代码，最后却让维护者压力山大。
Addy Osmani：没错。我很喜欢观察不同开发者群体对 AI 的态度变化。最近有一份研究就指出，一旦团队引入 AI，代码产出速度的确会大幅提升，但人工审查很快就会成为新的“卡脖子环节”。PR 的数量上来了，但真正有经验的人精力是有限的，那谁来审？
于是一些团队开始尝试让 AI 来做代码审查，从表面看，这似乎是个精巧的闭环：AI 写，AI 审，人类只需最后点点头。但如果写代码的是 AI，审代码的也是 AI，而人类压根没有真正读懂这段代码，那我们根本无法确定最终上线的系统到底在做什么。
就我个人来说，我也在同时使用很多工具，像 Kline、Cursor、Copilot、VS Code 等等。我有一个习惯，就是会去看这些工具在生成解决方案时的“思考过程”。它做了什么选择，为什么这么拆，哪些逻辑是它自动补全的，哪些部分是它自己改写的。我会在 PR 之前，把这些东西尽量看懂，因为最终那段代码是我要负责维护的。
就在昨晚，我还遇到一个 bug。代码看起来完全没问题，一切都像是“照规范写”的，但功能就是跑不起来。我让模型帮我排查了好几轮，它也在不断修改、尝试不同路径，可始终没有找到症结所在。最后，这件事还是得回到我自己身上，今晚我得老老实实去调试。如果当时我没有认真读懂那段代码，只是“相信 AI 总能搞定”，那现在我就像被扔进一片陌生的丛林，只能在黑暗里乱摸。
主持人：是啊，这其实就是“专业工程师”和“只会提示词工程师”的区别。任何人都可以往输入框里敲几句指令，但不是每个人都可以解释一个系统、修复一个棘手的问题，更不是每个人都能说清楚这套东西为什么能运行。在任何行业里，真正的专业都是建立在原理理解之上的。如果你完全不知道代码内部是怎么工作的，那公司为什么还需要你？
Addy Osmani：我非常同意这个说法。现在随着 Claude Code、Gemini CLI、Open Code 等终端工具的兴起，“多智能体并行协作”这个话题变得很热，大家都在想是否可以让多个 AI 同时分工协作，自动完成一整条任务链。从概念上看，这听起来既前卫又酷，但如果你在这个过程中抽掉了人工审查，那你只是在用更快的速度堆积技术债。短期内也许看不出问题，长期来看一定要付出更高的代价。
也正是这些观察，让我提出了一个我很在意的概念，我把它叫作“70% 问题”（the 70% problem）。
AI 只能做到 70%，剩下 30% 得靠你自己
主持人：那就展开讲讲吧。你说的“70% 问题”具体指什么？你是怎么意识到这种现象的？从你六个月前写那篇文章到现在，这个问题有缓解还是反而变得更明显了？
Addy Osmani：当然可以。虽然模型本身和相关工具的质量在持续进步，但所谓“70% 问题”讲的是一种非常顽固的现象。大语言模型通常可以在非常短的时间里，帮你搭出一个大约“七成可用”的应用雏形，可一旦进入最后那 30%，它们就常常会卡住。
你可以把这最后 30% 理解为一个“最后一公里”的难题。这里面藏着无数开发者都很熟悉的坑，我常用“两步退回模式”来形容。你可能用几个提示词，带着模型一步步搭好了一个功能，看上去一切顺利，但当你再给它一个新指令，要求做一点看起来不大的调整时，它突然就“跑偏”了。UI 可能被整体重写，组件的内部逻辑被完全改写，甚至你刚刚确认过的一些细节又被它自己推翻。
在这种混乱里，隐藏着非常高的可维护性成本和极其模糊的责任边界。当你给出的指令不够具体，把真正的设计和实现决策交还给模型时，你会发现收益很快开始递减。
类似的例子在 Hacker News 上比比皆是。各种安全漏洞、API 密钥泄露、XSS 攻击层出不穷，很多问题的源头都是一样的：开发者沉迷在“感觉不错”的创作流里，在没有系统性思考的情况下，让 AI 写了大部分关键逻辑。
所以，那些“凭感觉写出来”的东西，用在 MVP 或者仅用来做内部原型完全没问题。一旦你想把它真正并入团队代码库，面向真实用户和生产环境，它就必须被重写，按照生产级的质量标准，从头到尾再过一遍。
所有这些安全和质量问题，最后都在传递同一个信号：无论 AI 多强，人类都必须保持在环。
主持人：是的，我们现在已经听过太多类似的故事。很多产品经理或者非技术背景的创始人，会用 AI 在几天乃至几个小时里搭出一个看上去不错的原型，于是立刻兴奋地认为，“那我们马上就能上线了”。可是真正往后推的时候，要么项目卡死，要么进度远远超出预期。从“一两天能搞定”的乐观估计，变成“十几天甚至一个月都收不回来”。
你在那篇关于“70% 问题”的文章中也提到，经验丰富的工程师往往可以比较顺利地把那最后 30% 补全，而经验不足的工程师很容易在这一步陷入困局，甚至被 AI 带来的一种“虚假的自信感”困住。
Addy Osmani：
没错。最后这 30%，是很多初级工程师、新人和实习生最容易崩溃的地方。他们经常会一遍又一遍地对模型说“再试试”“再帮我修一次”，但是当 AI 无法再靠小修小补解决问题的时候，他们很可能就彻底没有思路了，因为他们缺少的是调试、分析以及定位问题的基础能力。
这其实也说明，批判性思维和系统性解决问题的能力，依然是计算机科学最核心的素养。任何人都能用高层次的 prompt 让 AI 输出一段“看起来能跑”的代码，但这和“值得信任、可以上生产”是两回事。我们已经看到太多案例，一开始看似没问题，最后却以一种惨烈的方式崩溃。
主持人：这让我想到一个发生在 AI 工具出现之前的故事。当年我在 Uber 带过一个新人，他是从一家小型创业公司跳过来的。入职一周后我去问他感觉怎么样，他非常焦虑地说：“太难了，我现在正在读整个代码库。”
我当时整个人都愣住了：“你是说你要把 Uber 的后端代码全部读完？那可是几百万行啊。”他说：“我每次换工作都会把公司的代码全读一遍，这样我才能真正理解系统。”
我其实非常敬佩他这种“想从根上搞懂一切”的动机，但我也告诉他：“你没必要把每一行都读完，你真正需要的是理解结构，知道关键的东西在哪里。”
这件事让我想到一件事：如果你把这种“理解系统”的能力外包给 AI，那迟早有一天你会被它反向“绑架”。当模型的上下文窗口塞满了，或者那天模型状态不对，整段对话历史突然没法用了，你瞬间就会掉进一个无助的深坑。你唯一的选项可能就是换一个模型，或者清空上下文再来一遍，甚至只能把整个过程重启。这种状态会让人感觉自己已经失去了对系统的任何掌控。
Addy Osmani：
是的，你形容得非常准确。无论你是一个资深工程师，还是一个享受 Vibe Coding 的开发者，都有几件事是必须牢牢记住的，它们会帮你在这个时代保住自己的掌控感。
如何与自动化 Agents 协作
主持人：你刚才提到“保持最佳结果”，这让我想到一个很现实的问题。AI 和 Vibe Coding 的确能让功能上线的速度变得非常快，但“快”并不等于“对”。你可能只是更快地做错事情。那你又怎么判断自己做的东西是不是有效？这个功能真正在数据上有没有提升转化率，有没有改善留存？如果没有良好的度量体系，你其实是在盲目做决策。
Addy Osmani：完全同意。要想高效地使用 AI，你必须诚实地面对模型的限制，比如它的上下文窗口永远是有限的。这意味着你在和 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 复制粘贴答案”强得多，但它生成的内容依旧需要经过人的审查和打磨，才能真的达到生产级的水准。
主持人：这让我想到十年前那个 Stack Overflow 称王的时代。那时候如果我们要验证邮箱格式，大概率会去搜一条“email validation regex”，然后复制点赞最多的那条答案直接用。那当然比从头写要快很多，但后来我们发现，不少正解其实有安全隐患，要么边界情况没考虑，要么在实战环境里会引发一堆奇怪的问题。
现在 AI 生成代码，在某种程度上就是把这个模式放大到了整个开发过程。
Addy Osmani：完全正确。现在我经常会听到有人问：“既然 AI 已经能帮我写代码了，那我还需要第三方库干嘛？”这和当年问“我既然可以复制 Stack Overflow 的答案，干嘛还要用库”是非常像的。
但任何一个有经验的工程师都会立刻想到另一个问题：如果你选择自己手写这套功能，那后续所有的维护责任——包括安全修复、平台兼容性问题、未来的演进和更新——都由你一个人扛。而使用一个成熟的依赖库，则意味着你可以和社区一起共享这些修复和演进。
这就是工程里的权衡。你要么承担更多自主维护的风险，要么把一部分责任交给外部组件，每一种选择都有代价，这些都是必须在设计阶段说清楚的。
产品经理和工程经理的角色变化
主持人：那站在整个工程流程的角度，你觉得 AI 带来的新工作流里，有哪些是传统软件工程时代几乎做不到，或者很难做到的事情？
Addy Osmani：我觉得最值得期待的一个方向，是“异步后台 AI 代理”（asynchronous background coding agents）。你可以想象这样一种场景：有一批 AI 代理在后台默默工作，帮你改测试、帮你迁移依赖库、帮你补上暗黑模式，甚至帮你清理一些历史遗留问题。只要它们能做到结果可验证、合并无冲突，那将会是一股非常强大的生产力。
真正的难点在于，当你像一个指挥家一样同时调动多个 AI 代理时，什么样的控制界面才是合理的。人类的注意力是有限的，即使我真的可以开二十个终端，让不同的模型同时跑不同的任务，我能用心高质量 review 的结果其实只有一小部分。所以，你必须像管理 Sprint 一样，帮助这些代理聚焦在最有价值的任务上。
另一个正在发生的趋势，是我会称之为“Vibe Designing”的东西。设计师也在进入一种 AI 驱动的协作状态。像 Figma、Shopify 这些团队都在尝试，让设计师用 AI 直接生成可交互的原型，再交给工程师去做“生产化”。
主持人：我听说 Shopify 有一个团队，设计师们几乎人手一个 Cursor。他们先在 Figma 里出设计稿，然后用 Cursor 让 AI 按照设计生成一个能跑的前端原型，再拿给工程师一起评估和讨论。虽然不是直接上线的代码，但比起只看静态图，这种方式让跨职能协作的质量直接上了一个台阶。
Addy Osmani：我也非常佩服 Shopify 团队的这些实践，它们证明了 AI 协作不仅是概念，而是真正在落地。当然，这一切的前提是边界要清晰：哪些东西只是原型，哪些才是真正的生产代码。能把静态视觉稿快速变成半功能原型，本身就是一场革命。
我认为接下来角色变化最大的，可能会是产品经理（PM）和工程经理（EM）。PM 需要把更多时间投入到问题定义、指标体系和 AI 策略上，他们要决定在哪里引入 AI，如何衡量它的价值。EM 则要在评估体系、安全性和 AI 治理上投入更多精力。
AI 并不会改变他们“对结果负责”的本质职责，但它会让“品味”本身变成一种更强的竞争力。当每个人都能用 prompt 造出“差不多功能”的时候，真正拉开差距的，反而是谁能做出更有判断、更有质感的产品。
AI 会让新手更快上手，也会让高手的杠杆更大。那些能写 spec、会拆任务、懂架构、擅长审查的高级工程师，价值只会越来越高。整体来说，我对 AI 在工程领域的未来是谨慎乐观的。乐观在工具进步的速度确实惊人，谨慎在于，人类监督这个角色无论如何都不能被挤掉。
“三人编程”的协作模式可能会出现
主持人：如果回顾我见过的那些最优秀的资深工程师，他们一天的工作状态，某种意义上已经很像是在做“多智能体协作”了。他们带着几个中级工程师、几个实习生，一天到晚在 Slack 里被 @，不是“帮忙看个 bug”，就是“能不能帮我审一下这段代码”。
他们不断切换上下文，来回在多个任务之间穿梭，做评审、提建议、拆需求、开会指导。某种程度上说，这些高级工程师早就已经在做“人肉版的智能体编排系统”。
所以如果你问我，未来谁最适合管理多个 AI 代理，我会毫不犹豫地说是资深开发者。新手当然也能用 AI，但由于缺乏经验，很难驾驭这种多线程协同。资深开发者之所以能办到，是因为他们对代码库有整体现实感，知道“好代码”长什么样，也习惯在评审时保持严格标准。
Addy Osmani：我完全同意这个判断。我也认为，开发者教育和团队培养方式，都必须随着这股变革一起升级。
我刚入行的时候，大家最推崇的是“结对编程”。而我非常相信，在不远的未来，我们会越来越常见一种“三人编程”的模式，一个新手，一个资深开发者，再加上一个 AI。资深开发者可能会要求新人大声解释 AI 生成的代码，或者带着他们一起梳理这段代码是如何和系统其他部分勾连的。AI 在其中扮演的是“教学助理”的角色，帮新人建立自信，建立对全局的理解，而不是替代他们的思考。
我们已经能看到一些有趣的讨论苗头，团队中的角色也许会进一步被细分或重新定义。比如“前线部署工程师”（forward-deployed engineer）这样的角色又重新被提起来，这类工程师通常离产品和用户场景更近，很有可能会成为未来“AI 辅助开发协作”中的关键桥梁。
教育体系也会受到这股变化的牵引。高中、大学会不会开始系统教授“Prompt 工程”和“上下文工程”的最佳实践？我们能不能在这些新课程涌现的同时，仍然守住“系统设计思维”这块根基？这些都是我非常期待看到答案的问题。
稿件经采用可获邀进入Z Finance内部社群，优秀者将成为签约作者，00后更有机会成为Z Finance的早期共创成员。
