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

---

新智元报道  

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

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

它用几分钟生成原型。

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

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

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

这就是正在发生的现实。

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

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

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编程，只靠提示词恐远远不够。

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能帮助我们实现这一目标。

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

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

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

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

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

AI的兴起，也不例外。

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

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

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

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

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

AI并未改变这一点。

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

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

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

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

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

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

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

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

1. 把模糊问题转化为明确的执行意图；

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

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

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

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

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