氛围编程行不通！CTO们集体炮轰AI编程：不是失业，而是失控

不像 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 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”，作者是“宇琪，Tina”。