氛围编程将死!谷歌总监警告:只会写Prompt的程序员,2026年将被淘汰

  新智元报道

  编辑:KingHZ

  AI 不止,编程不死!Chrome 工程大佬 Addy Osmani 宣言:AI 加速开发,但人类专家仍是质量守护神!

  如果你还在怀疑 AI 会不会取代编程,答案可能已经悄悄写进代码库了。

  在 Chrome 这种影响数十亿人的超级工程里,AI 早就不是「帮你补几行代码」的玩具了。

  它用几分钟生成原型。

  它快速扫过日志,标出 bug。

  它甚至参与架构讨论,提出方案备选。

  在 Anthropic,Claude Code 写下了自己约 90% 的代码;在谷歌 Chrome 团队,AI 被系统性地引入测试、性能分析和缺陷修复流程。

  这就是正在发生的现实。

  一个更残酷的问题随之而来:AI编程进入「下半场」,靠感觉写代码的 Vibe Coding,还站得住吗?

  谷歌云 AI 总监、Chrome 前工程负责人 Addy Osmani 断言,Vibe Coding 已撞南墙,而 AI 辅助编程即将崛起。

  AI 编程,已经进入下半场。

  Vibe Coding,再见!

  AI 编程迎来下半场

  Osmani 并不反 AI。

  相反,他是最早、最深度使用 AI 的那一批工程负责人。

  他见过那种场景:

  代码看起来能跑。但没人知道它为什么能跑。更没人知道,它什么时候会出事。

  正因为如此,他对「氛围编程」(Vibe Coding)泼了一盆冷水:

vibe coding 可以玩玩,但没有测试和明确规范就容易变成一团糟。

  正是 Addy Osmani 作为工程负责人的老辣之处——在所有人都在狂欢时,他看到了系统崩溃的风险。

  作为长期活跃在 Web 技术与开发工具交汇点的大牛,Osmani 在接受专访时,结合亲身经历,谈到像 GitHub Copilot 或谷歌 Gemini 这样的 AI 助手,正彻底改变所谓「vibe coding」(氛围编程)。

AI 正在重塑编程方式,但「氛围编程」(vibe coding)正在成为一种风险,而不是优势。

  2025 年的谷歌 Chrome 团队,AI 已深度介入自动化测试、性能分析与优化、以及 bug 定位与修复。

  在合适的流程设计下,整体生产力提升约 30%。

  但他紧接着强调了一句话,几乎是全文的「安全阀」:

AI 永远没有质量保证。 质量,只能来自人类的专业判断。

  在 Chrome 这种超大型工程中,如果不严格审查 AI 生成的代码,你可能要收拾 AI 的「烂摊子」,这些代码

  可能违反 Web 标准

  可能引入微妙的性能下降

  可能在极端用户场景下失效

  这些问题,AI看不出来,但专家一眼就能看穿。

  这正是 Osmani 所说的「70% 问题」:AI 能在项目前 70% 阶段如鱼得水,但剩下的 30%,只有经验丰富的工程师才能搞定,尤其在如浏览器引擎这类庞大系统中更是如此。

  非工程师使用 AI 进行编程时,往往会遇到一堵令人沮丧的墙

  这种趋势并不只出现谷歌。

  观点或许可以反驳,但数据不会撒谎。

  2025 年底,Stack Overflow 的开发者调查显示:

  开发者对 AI 准确性的信任度,从往年的 40% 下降至今年的 29%;

  对 AI 的正面评价率,从去年的 72% 逐年降至 60%。

  因为大家发现了「AI 悖论」:代码写得快,产品却交付得慢,AI 写的 bug 得你来擦屁股。

  另一项调查,呼应了这一发现。

  GitLab 与哈里斯民意调查机构合作,访问了3,266 名从事软件开发、IT 运维和安全工作的专业人士。

  结果显示,尽管团队部署速度比以往更快,但低效流程正在消耗他们的时间,而这些问题仅靠 AI 无法解决。

  70% 的受访者表示 AI 正使合规管理变得更困难,76% 的人指出大多数合规问题在部署后才被发现。

  73% 的人遇到过「氛围编码」问题,即通过自然语言提示生成的代码,缺乏对代码的清晰理解。

  代码的未来关乎信任,而不仅仅是工具。

  很多「AI 辅助工程」(AI-assisted engineering)被包装成「氛围编码」(vibe coding)。

  比如美国某科技大厂团队使用 AI,总体来看,从功能提案到上线,开发速度提升了约 30%。

  但在 Addy Osmani 看来,这不是「Vibe Coding」,而是典型的「AI 辅助工程」。

  与氛围编程相比,「AI 辅助工程」最大的不同是人类工程师始终牢牢掌控全局,负责系统架构,审查并理解每一行 AI 生成的代码,并确保最终产品安全、可扩展且易于维护。

  而氛围编程优先考虑速度与探索,而非专业应用所要求的正确性与可维护性。

  要想在实际中真正用好 AI 编程,只靠提示词恐远远不够。

  AI 编程不是为了更快的编码

  Osmani 直言:现在代码写得更快了,可上线却更慢了,都是因为审查环节被跳过、假设没人验证。

  程序员还不会被取代,他担心的是另一种更隐蔽的风险:

  过度依赖 AI,导致核心工程能力退化

  不理解生成结果,只是机械接受

  在大型系统中放大 AI 的偏见与幻觉

  他提出了「AI 初稿」模式:AI 先出草稿,人类再加测试、提交上线。

  传送门:https://addyo.substack.com/p/my-llm-coding-workflow-going-into

  使用大语言模型编程,并非一键式魔法——它「困难且反直觉」,要获得出色成果需要学习新的模式。

  批判性思维,依然是关键。

  经过一年的项目实践,他逐渐形成了一套与许多经验丰富的开发者类似的工作流程:将大语言模型视为强大的结对编程伙伴,它需要清晰的方向、上下文和监督,而非自主判断。

  规划先行:先明确规范,再编写代码

  分块迭代:将任务拆解为可管理的小模块

  提供充分上下文与引导

  选择合适的模型并灵活切换

  在整个软件开发生命周期中利用 AI 编程

  人类必须握紧方向盘:验证、测试、审查一切

  善用版本控制与自动化工具:频繁提交代码,将版本控制系统作为安全网;绝不提交你无法解释的代码。

  通过规则和示例定制 AI 的行为

  把测试与自动化视为倍增器

  持续学习与适应,用 AI 放大你的技能

  特别是最后一点,将每次与 AI 协作编程都视为一次学习机会,而你的知识越丰富,AI 能提供的帮助就越大,从而形成一个良性循环。

  这个模式普遍适用:如果你具备扎实的软件工程基础,AI 能将你的生产力提升数倍。如果基础薄弱,AI 反而可能放大困惑。

  对于那些担心使用 AI 会削弱自身能力的人:他的观点恰恰相反,如果方法得当,结果会是积极的。

  总体来看,AI 工具会放大你的专业知识。

  所以,他的建议是:「继续磨练你的技艺,并利用 AI 来加速这个过程。也要有意识地定期进行不带 AI 的独立编程,以保持你原始技能的敏锐度。

  归根结底,这是「1=1>2」:「开发者 +AI」组合的力量远超任何单独一方。

  而这个组合中的开发者这一半,必须尽到自己的本分。

  AI 真正的作用是更快地迭代和实验,通过更快速的探索,有可能催生出更好的解决方案。

  但这有个重要前提:我们必须坚守工程原则,将 AI 视为工具,而非良好软件实践的替代品。

  请记住:AI 编程的目标不是更快地写出更多代码,而是构建更好的软件。

  如果运用得当,AI 能帮助我们实现这一目标。

  但「更好」究竟意味着什么,以及如何实现它,最终仍取决于我们自身。

  2026 开发者必杀技

  软件工程,始终在不断变化。

  从汇编语言到高级编程,从本地服务器到云计算,如今又从手动编码迈入 AI 辅助开发。

  每一次飞跃都自动化了编程的某些方面,而每一次开发者都随之适应,并找到了更广阔的天地。

  过去的创新,几乎总是为开发者带来了更多工作、更多增长、更多机会。

  AI 的兴起,也不例外。

  它并非让开发者变得无关紧要,而是在重塑成功所需的能力组合。

  编程中那枯燥的 70% 正变得更容易;而那富有挑战性的 30%,正成为我们价值中更为关键的部分。

  AI 不会来抢你的饭碗,它只是在放大人类不可替代的能力:判断力、创造力、以及那份把握全局的直觉。

  到了 2026 年,真正的核心竞争力,可能是你知道什么时候让 AI 干活,什么时候该亲自上场。

  卓越的软件工程始终关乎解决问题,而不仅仅是编写代码。

  AI 并未改变这一点。

  如今,随着软件实现成本越来越低,软件工程师的角色并没有变得不重要,反而让我们看清了什么才是一直以来真正重要的能力:对问题的深入理解。

  你需要理解问题、从客户和内部团队收集足够的上下文信息,并把工作进行清晰地拆解和结构化,因为 AI 是基于这些输入来直接执行的。

  设计的关键,是判断什么重要、哪些限制存在、哪些取舍是可接受的。

  好的产品工作,本质上是对「清晰度」的追求:什么样的执行,才真正值得去做。

  在这个新阶段,主导并管理AI智能体的工作流程,成了一种新的「手艺」

  而交付的成果,过去是代码,现在是提供给智能体的规范。

  那些「能最快把开发需求翻译成代码」的人,在未来并不能脱颖而出。

  未来真正的赢家,是那些能做到以下三点的人:

  把模糊问题转化为明确的执行意图;

  设计出让「好结果」自然而然发生的上下文结构;

  区分真正重要的东西,和那些「只是能跑起来」的东西。

  这其实和商业世界的变化如出一辙

  当分发的成本趋近于零,真正有价值的是品味和策划;

  当实现的成本趋近于零,真正有价值的是对问题的定义能力与判断力。

  软件工程这门技艺,在变化中进化。

  它一直如此,但它仍然是「技艺」。

  参考资料:

  https://x.com/addyosmani/status/2007899127925854536

  https://x.com/karrisaarinen/status/2007534281011155419

  https://x.com/addyosmani/status/2005768629691019544

  https://x.com/addyosmani/status/1960034046177923457

  https://byteiota.com/ai-tools-hit-84-adoption-but-sentiment-crashes-to-60/

  https://betanews.com/2025/11/11/the-ai-paradox-gitlab-finds-faster-coding-is-slowing-teams-down/

  https://newsletter.pragmaticengineer.com/p/beyond-vibe-coding-with-addy-osmani

  https://addyo.substack.com/p/my-llm-coding-workflow-going-into

  https://addyo.substack.com/p/the-70-problem-hard-truths-about

  https://addyo.substack.com/p/beyond-the-70-maximizing-the-human