新智元报道
编辑：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
