【小哈划重点：一名新人把 AI建议和Stack Overflow代码片段拼凑起来，写了个用户权限系统。测试和QA全部通过，上线后两周才发现已注销的用户依然访问某些后端工具。原因只是一个“看似合理”的真假逻辑反了。修复这漏洞，资深工程师花了整整两天。】
不像GitHub CEO Thomas Dohmke那样，一边喊着“要么拥抱AI，要么离开”，一边忙着卖Copilot订阅，真正带队写代码、扛事故的CTO们，对“氛围编程”的态度冷静得多，也残酷得多。
他们没有利益冲动去推销新概念，更没有时间沉迷话术，他们面对的只有实打实的线上系统、真金白银的技术债和凌晨的报警电话。也正因为如此，他们的结论比任何口号都更值得参考。
在CTO的叙述里，氛围编程并不是“生产力革命”，而是一场接二连三的灾难。
一位CTO说得很直白：“氛围编程看似捷径，但本质是死路。”
Let Set Go的CTO Ritesh Joshi的团队刚经历过一次“教科书式”事故：开发者用AI生成了一段数据库查询，小样本下毫无问题，但一旦遇到真实流量，系统立刻被拖到爬不动。问题不是语法有错误，而是底层架构。
Cirrus Bridge的创始人兼首席软件架构师Patric Edwards也分享过一次“惊心动魄”的经历：一名新人把 AI建议和Stack Overflow代码片段拼凑起来，写了个用户权限系统。测试和QA全部通过，上线后两周才发现已注销的用户依然访问某些后端工具。原因只是一个“看似合理”的真假逻辑反了。修复这漏洞，资深工程师花了整整两天。
对他来说，这不是bug，而是一种“信任债”：高级工程师被迫长期当侦探，反复逆向解读基于vibes拼出来的逻辑，只为发布一个稳定更新。
AlgoCademy的CTO Mircea Dima遇到过更隐蔽的状况。一位开发者用AI写了二分查找实现，并被用于核心搜索功能，结果上线一周后发现在特定输入下会悄悄出错，直接导致生产系统宕机，造成用户流失。Dima总结说：“问题不在于AI会犯错，而在于vibe coding创造了一种危险局面——你只有等到系统真正崩溃，才会发现问题。”
App Makers LA的CEO Daniel Haiem的团队也被狠狠教训过。一名开发者用Firebase和npm包“vibe-coded”了整个认证流程。“在只支持简单登录时它能跑，但当我们需要多角色权限和区域隐私规则时，它彻底崩塌。没人能搞清楚各模块间的关联，中间件分散在六个文件里，没有逻辑模型，只有vibes。最后我们只能推倒重写，因为调试就像考古。”
Akveo的高级全栈工程师Mikhail Hryb既见识过AI开发的强大，也见证过彻底的灾难：“有个项目几乎完全靠vibe coding搭出来。MVP的确两天就交付了，而不是一周。但没人审核AI生成的代码。初级开发者写的烂代码至少还能读懂；AI生成的没人看过，结果就是一堆胡言乱语。不可调试、难以扩展、维护痛苦。”
AI写得快，CTO修得更快。氛围编程或许让功能上线飞快，但真正支撑生产环境的，是懂系统、能排查、懂业务逻辑的工程师。CTO们用脚投下的票，说明了这条捷径根本走不通。
与这些一线CTO的实践经验相呼应，Augment Code的工程和产品负责人Chris Kelly最近以Vibes Won’t Cut It为题发表了一次演讲。在分享中，他详细探讨了“氛围编码”在生产级软件开发中的局限性，强调情境在软件工程中的关键作用，而不仅仅是编写代码。
Kelly拥有超过15年的软件开发经验，曾在New Relic、GitHub、Salesforce和FireHydrant等公司帮助开发者提升生产力。他的观点直指核心：仅靠直觉和AI生成的代码不足以构建强大、可直接投入生产的应用程序，真正可靠的产品依赖的是结构化的软件开发方法。
以下为其演讲内容整理，供读者参考。
1
氛围编程行不通
如果你还没准备好，我得提醒你一个不太妙的事：到明年这个时候，我们当中可能有一半人已经不在这个行业了，至少如果你相信当下那些关于AI和AI编程的各种炒作的话。
外界铺天盖地地在宣传这个东西，但我觉得他们大概率是错了。
不是因为我认为AI编程没前景，而是因为这些人可能已经很多年没有真正接触过一个生产环境了。他们说AI现在可以生成30%的代码，可那可能根本不是他们想象的那样。
2
不要小看生产环境的任何一行代码
AI写的代码，归根结底还是“代码”。有些人没有意识到，他们日常工作的代码基座庞大，几乎每一个关于架构、基础设施的决策都已经有人帮他们做了。比如说，如果我生成了30%的代码，对比的是每天在数百万行现有代码之上新增几千行而已，那这个30%其实没有多少“腾挪空间”可言，这些代码本来就只能干很有限的事情。说白了，就是多一个按钮而已。
没有冒犯的意思，但我接下来可能要吐槽一下Meta。如果你跟Meta的工程师聊过，你会听到这样的故事：有工程师花了六个月时间，在广告平台上造了一个按钮。这六个月，他的全部工作就是那个按钮。你说这样的系统，还有多少空间留给AI来“发挥”？
再说一遍，AI还是在写代码。这些代码的本质和我们过去五十年写的一样，语言也一样，没啥本质变化。而且，这些代码最终还是要在生产环境里跑。如果你没运营过一个大型的生产系统，就算你写了一行再漂亮的代码，放到复杂系统里照样可能出故障。复杂系统会有“涌现行为（emergemt behavior）”，不是你单看一行代码就能预判的。
那当系统出问题了，谁来修？谁来排查？谁来理解这些微妙之处？如果我们不再需要软件工程师，那这些工作由谁来做？我觉得，我们依然需要软件工程师。
历史其实一直在重演，这不是我第一次被告知“你的职业要完了”。我干这行也有些年头了，回头看看，比如十五年前DevOps革命、云计算起来的时候，那些天天在机房里插机器、起内核的系统管理员们，现在都涨工资了，而且做的事也更有价值、更开心了。这次也一样，不过是抽象层级更高了点。拖拉机的出现没有终结农业，只是让马和农场工人少了些。产业当然会变，但“种地”这件事还在。
3
写代码跟写生产级软件不是一回事
如果你没听过vibe coding，我简单解释一下。vibe coding就是完全让AI写代码，人基本不看代码，也不管结构，只关心它是不是能跑起来、是不是做了我想让它做的事。可以跑？那就继续往前推，不用管内部细节，不用编辑检查，直接放行。
但我今天要讲的，不是vibe coding。我要讲的是：怎么写“能跑在生产环境上的代码”。
我说“生产环境”，指的是你要做到99.99%的可用性，这意味着你面对的是成千上万的用户、以GB为单位的数据流。这是支撑整个互联网的软件，靠vibe是搞不定的。
这里有个很大的误解需要澄清：写代码本身不是软件工程师的“本职工作”。就像蓝图不是建筑师的工作本身，它只是工作产出的一部分。
作为软件工程师，代码只是我的“交付物”之一，我其实做的是成千上万个决策：我要构建什么、结构如何、引哪些包、做哪些权衡。所以请大家不要混淆“生成代码”和“软件工程的艺术与技艺”——这完全是两回事。
LLM很擅长生成代码，但那跟“写生产级软件”根本不是一回事。
Stack Overflow的创始人Jeff Atwood曾说过一句话：“最好的代码，是不存在的代码。”这话说得对，每一行代码，都是一种负担。我得维护它、调试它。所以每一行AI生成的代码，最后都成了我的责任。
我们过去花太多时间在想“AI可以生成多少代码”。但说真的，这根本不重要。AI生成得越多，我和我的系统反而负担越大，我们应该让代码越少越好。
所有代码都有权衡：某个包性能更好，但可能更难维护；某种模式可扩展，但可能有副作用。
对比三种架构：单体架构、微服务架构、事件驱动系统。
试想你在每种架构下造一个“航班预订系统”，需要做成千上万个决策。而LLM不做决策，它只会生成“模式”。但在某个规模之上，模式就不再适用了。
有人运行过那种有点像雪花的有“怪癖（idiosyncrasies）”的生产软件吗？那种只有“Bob知道它哪块逻辑是怎么跑的“，或者是“只有Jane能修“，因为是她六年前写的，但她早就离职了，没人敢动那块代码。
那才是真实世界中的软件。当系统足够复杂，所有的“模式匹配”都失效了，因为没有哪个模式能囊括这些独特的细节。
系统半夜崩了怎么办？我这讲的是“我当年背呼叫器”的PTSD——凌晨两点软件挂了，vibes可救不了你，总得有人查出问题在哪。
那什么才是软件工程师真正的“工作”？对我来说，是安全地修改软件。
我这二十年，一直在思考这个问题：如何加新功能、改老代码，而不把系统搞挂，让用户照样能正常使用，让数据安全、业务持续运转。
我为此干了很多事，比如：学习大量代码基础、用版本控制、写单元测试、用类型系统约束、做渐进式部署……
那AI能不能帮我们？它能不能利用上下文，理解更多代码？或许可以。我们在Augment做的工作就是这个。我们认为，上下文才是AI编程里最关键的部分。所以我们相信这个问题是能解决的。
但这不改变一个事实：我仍然得关心生产系统。
4
怎么写出让AI也能接手的代码？
假设我们认了，未来真的来了，AI写代码成了日常。那问题来了：你怎么写出让AI也能接手的代码？
我在这个圈子混很久了，说点我的观察：职业软件工程师是我见过接受AI最慢的一批人。以前工具一更新，大家冲得比谁都快。版本控制系统换代、云转型——我早年在GitHub，看着这些潮流一波波涌起，开发者都乐此不疲地跟着跑。但AI不一样，现在很多工程师根本不碰，说“这玩意做不了我该做的事”。
为什么？我有一些猜测，但说实话我也没完全搞明白。
几年前，AI编码工具基本上像一堆砖头——勉强能用，但干不了什么事。直到大约一年前，claude sonnet3.5发布，那是个转折点，质量突然大幅提升。再到四周前，如果你有关注新闻——几乎所有AI编码工具都一口同声说：“Agent是未来。”这个转变来得非常快。
所以我们要聊聊：在这个新世界里，我们怎么做“软件工程”？怎么构建“对AI友好的代码”？给你们几点建议：
1. 规范统一的文档和编码规范：你们团队到底用哪个包？哪个框架？别人不知道，AI更不知道。写下来，告诉它你们要走哪条路。
2. 可复现的开发环境：你那套开发环境是不是很独特、配置乱七八糟？别这样。
3. 可测性强：测试能本地跑吗？跑得快吗？测试越好写越好跑，AI才能帮得上忙。
4. 清晰的功能边界：明确告诉AI哪些事可以做，哪些别碰。
5. 清晰地定义任务和工作内容：因为AI的表现会和你预期的一样。就像我不会给团队中的任何一位工程师一个模糊的任务，比如：“你能让这个按钮有点不同的效果吗？”但我看到太多工程师在用类似这样的方式对AI提问。
这对我来说很有意思，因为这听起来其实就是软件工程的本质。理想情况下，你的软件工程体系应该具备这些特性；如果不具备，你可能会觉得生产力很差，因为你有自定义的测试基础架构、自定义的开发环境……你需要为AI提供和人类工程师一样的工具，因为它正在做的工作其实是一样的——写代码。
我从来没有一次就写出完美代码的经历。我的代码总是会有错误，我运行测试，它失败了；我有一个代码格式检查器，它会修复它等等。但我们似乎对AI有一个不合理的期望，认为它能写出完美的代码，我不明白为什么。
所以，当你作为软件工程师考虑使用AI时，你必须确保你的系统就像你期望其他工程师那样运作，因为AI也是在写代码。
接下来说的是代码审查，这无疑是最重要的技能。我觉得作为一个行业，我们已经有点遗忘这个技能了。我们可能应该一直在面试中考察代码审查能力，而不是那种深奥的LeetCode问题。我们应该问：“你能阅读别人的代码并评价它的好坏吗？”
我认为这个能力会变得越来越重要，因为将来会有越来越多的代码由AI代理生成。而我们今天的代码审查工具，说实话非常糟糕。我现在拿到的是一个变更文件列表，它是按字典序排序的：好吧，文件A改了，那我就看看A文件的改动，再看看B文件的改动。但这并不是理解软件变更的正确方式——按文件顺序思考是没有意义的。
我认为我们会看到代码审查方式的大变革，而这是我们需要在招聘中评估的技能，也是我们自己要重新熟悉的技能。
5
“我有一些建议”
我想再给大家分享一些关键要点，特别是针对那些不太信任AI、但又想尝试使用AI的工程师。以下是我想给你们的一些建议：
1. AI说话像人，但其实它是台机器。
我最近和AI有个互动，我在对它“吼”，因为它没完成我想要它做的事情。它回复说：“对不起，我只是略读了那个文件，没有仔细阅读。”我就想，这是什么意思？软件怎么“略读”文件？这在软件领域根本不是个概念。
其实是因为大型语言模型是基于全世界的数据训练出来的，它读过成千上万封邮件，其中有人说：“对不起，我没有认真看你的文档，我只是略读了一下。”于是它学会了：当有人对我生气时，我可以这样回复。
所以我们不能轻信LLM所说的它“正在做”的事情，因为它其实并没有真正做那些事情。它只是生成文本，它输出的文本不一定代表它实际上做了那些事。阅读LLM输出内容时，请一定记住这一点。
2. 有时候代码只是“不一样”而已。
如果LLM生成的代码和你写的不一样，也没关系。就像坐在你旁边的同事写的代码也可能和你不一样一样，所以接受这一点。如果你想强迫它写出和你风格完全一致的代码，你当然可以付出那份努力。但你需要分辨清楚：这段代码是更好，还是只是风格不同？
学会放手这一点，这正是我们使用代码风格检查器、规则系统和编码规范指南的原因——就是为了不再争论“函数到底应该怎么写才对”。如果可以的话，就放下那些执念吧。
3. 编写规则文件。
告诉AI你希望它怎么做。我每次开始一个项目都会写一个文件，说明我使用的技术栈、希望它遵守的编码规范。这些内容会成为我给LLM输入上下文的一部分。
4.“定义 - 创建 - 优化”循环。
创建一个文档，让LLM帮你生成它。比如你说“我要做这个功能”，让它帮你写一个Markdown文件，列出完整的计划。保存这个计划作为Markdown文件，并将其作为上下文的一部分。接着让AI根据这个文档创建东西。运行这个代理，根据你的文件执行任务。然后你可以修改它的输出，继续优化它。你可以通过代码补全等方式进行微调，然后不断重复这个循环：先制定计划、再创建、再微调。
这样一来，你不仅能学会如何更有效地提示LLM获取你想要的代码，还能显著提升你的编码效率。而且，只要你愿意放下“代码必须按我那样写”这种执念，只关注“代码是否能正确工作”，你就能变得高效得多。
参考链接：
https://www.youtube.com/watch?v=Dc3qOA9WOnE
https://www.finalroundai.com/blog/what-ctos-think-about-vibe-coding
声明：本文为 InfoQ 整理，不代表平台观点，未经许可禁止转载。
编译｜宇琪、Tina
(文章插图未收录)
https://mp.weixin.qq.com/s/RGQOYAiiVvn0Una-m2OrJg
