氛围编程将死！谷歌总监警告：只会写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