他们没有利益冲动去推销新概念，更没有时间沉迷话术，他们面对的只有实打实的线上系统、真金白银的技术债和凌晨的报警电话。也正因为如此，他们的结论比任何口号都更值得参考。
在 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 sonnet 3.5 发布，那是个转折点，质量突然大幅提升。再到四周前，如果你有关注新闻——几乎所有 AI 编码工具都一口同声说：“Agent 是未来。”这个转变来得非常快。
所以我们要聊聊：在这个新世界里，我们怎么做“软件工程”？怎么构建“对 AI 友好的代码”？给你们几点建议：
规范统一的文档和编码规范：你们团队到底用哪个包？哪个框架？别人不知道，AI 更不知道。写下来，告诉它你们要走哪条路。
可复现的开发环境：你那套开发环境是不是很独特、配置乱七八糟？别这样。
可测性强：测试能本地跑吗？跑得快吗？测试越好写越好跑，AI 才能帮得上忙。
清晰的功能边界：明确告诉 AI 哪些事可以做，哪些别碰。
清晰地定义任务和工作内容：因为 AI 的表现会和你预期的一样。就像我不会给团队中的任何一位工程师一个模糊的任务，比如：“你能让这个按钮有点不同的效果吗？”但我看到太多工程师在用类似这样的方式对 AI 提问。
这对我来说很有意思，因为这听起来其实就是软件工程的本质。理想情况下，你的软件工程体系应该具备这些特性；如果不具备，你可能会觉得生产力很差，因为你有自定义的测试基础架构、自定义的开发环境……你需要为 AI 提供和人类工程师一样的工具，因为它正在做的工作其实是一样的——写代码。
我从来没有一次就写出完美代码的经历。我的代码总是会有错误，我运行测试，它失败了；我有一个代码格式检查器，它会修复它等等。但我们似乎对 AI 有一个不合理的期望，认为它能写出完美的代码，我不明白为什么。
所以，当你作为软件工程师考虑使用 AI 时，你必须确保你的系统就像你期望其他工程师那样运作，因为 AI 也是在写代码。
接下来说的是代码审查，这无疑是最重要的技能。我觉得作为一个行业，我们已经有点遗忘这个技能了。我们可能应该一直在面试中考察代码审查能力，而不是那种深奥的 LeetCode 问题。我们应该问：“你能阅读别人的代码并评价它的好坏吗？”
我认为这个能力会变得越来越重要，因为将来会有越来越多的代码由 AI 代理生成。而我们今天的代码审查工具，说实话非常糟糕。我现在拿到的是一个变更文件📄列表，它是按字典序排序的：好吧，文件📄 A 改了，那我就看看 A 文件📄的改动，再看看 B 文件📄的改动。但这并不是理解软件变更的正确方式——按文件📄顺序思考是没有意义的。
我认为我们会看到代码审查方式的大变革，而这是我们需要在招聘中评估的技能，也是我们自己要重新熟悉的技能。
5“我有一些建议”
我想再给大家分享一些关键要点，特别是针对那些不太信任 AI、但又想尝试使用 AI 的工程师。以下是我想给你们的一些建议：
AI 说话像人，但其实它是台机器。
我最近和 AI 有个互动，我在对它“吼”，因为它没完成我想要它做的事情。它回复说：“对不起，我只是略读了那个文件📄，没有仔细阅读。”我就想，这是什么意思？软件怎么“略读”文件📄？这在软件领域根本不是个概念。
其实是因为大型语言模型是基于全世界的数据训练出来的，它读过成千上万封邮件，其中有人说：“对不起，我没有认真看你的文档，我只是略读了一下。”于是它学会了：当有人对我生气时，我可以这样回复。
所以我们不能轻信 LLM 所说的它“正在做”的事情，因为它其实并没有真正做那些事情。它只是生成文本，它输出的文本不一定代表它实际上做了那些事。阅读 LLM 输出内容时，请一定记住这一点🕐️。
有时候代码只是“不一样”而已。
如果 LLM 生成的代码和你写的不一样，也没关系。就像坐在你旁边的同事写的代码也可能和你不一样一样，所以接受这一点🕐️。如果你想强迫它写出和你风格完全一致的代码，你当然可以付出那份努力。但你需要分辨清楚：这段代码是更好，还是只是风格不同？
学会放手这一点🕐️，这正是我们使用代码风格检查器、规则系统和编码规范指南的原因——就是为了不再争论“函数到底应该怎么写才对”。如果可以的话，就放下那些执念吧。
编写规则文件📄。
告诉 AI 你希望它怎么做。我每次开始一个项目都会写一个文件📄，说明我使用的技术栈、希望它遵守的编码规范。这些内容会成为我给 LLM 输入上下文的一部分。
“定义 - 创建 - 优化”循环。
创建一个文档，让 LLM 帮你生成它。比如你说“我要做这个功能”，让它帮你写一个 Markdown 文件📄，列出完整的计划。保存这个计划作为 Markdown 文件📄，并将其作为上下文的一部分。接着让 AI 根据这个文档创建东西。运行这个代理，根据你的文件📄执行任务。然后你可以修改它的输出，继续优化它。你可以通过代码补全等方式进行微调，然后不断重复这个循环：先制定计划、再创建、再微调。
这样一来，你不仅能学会如何更有效地提示 LLM 获取你想要的代码，还能显著提升你的编码效率。而且，只要你愿意放下“代码必须按我那样写”这种执念，只关注“代码是否能正确工作”，你就能变得高效得多。
参考链接：
https://www.youtube.com/watch?v=Dc3qOA9WOnE
https://www.finalroundai.com/blog/what-ctos-think-about-vibe-coding
声明：本文为 InfoQ 整理，不代表平台观点，未经许可禁止转载。
