凌晨2点查Bug、成天收拾AI“烂摊子”……在18位CTO眼中的“Vibe Coding”，竟多是「生产噩梦」？

抖音快讯 2025年08月19日 20:03 1 admin

【CSDN 编者按】AI 正在加速改变软件开发的方式，Vibe Coding更是成为了不少团队的“新玩具”。它让开发者能够在短时间内拼凑出看似完美的代码，快速上线 MVP，甚至一夜之间就能跑通一个 SaaS 原型。但在真实的生产环境里，这种做法却暴露出越来越多的隐患：性能崩溃、安全漏洞、难以维护的混乱代码，以及 CTO 们口中的“信任债务”。

基于此，本文作者团队采访了 18 位 CTO，谈到所谓的 Vibe Coding时，其中有 16 位都表示在生产环境里遭遇过严重Bug。

原文链接：https://www.finalroundai.com/blog/what-ctos-think-about-vibe-coding

作者 | Kaustubh Saini

翻译 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

投稿或寻求报道：zhanghy@csdn.net

AI 曾许诺让每个人都能成为“10 倍开发者”，但现实却是：初级工程师被迫变成了“提示工程师”，而资深开发者则沦为“代码清洁工”，整天都忙着收拾 AI 留下的烂摊子——这就是当下真实的行业写照。

外界还在吹捧“周末用 AI Prompt 就能写出一个应用”，但企业内部却被 AI 生成的代码拖得举步维艰：这些代码看起来完美，却在上线后频频崩溃。

所以我们决定去问一问那些真正要收拾残局的人：在 2025 年仍带队打仗的18 位 CTO 和技术负责人。

不同于 GitHub CEO Thomas Dohmke 那种“拥抱 AI，否则就离开IT行业”的口号，也不同于社交媒体上极力鼓吹 Vibe Coding 工具的网红，这些受访的 CTO 不会向你推销课程，也没有卖工具的压力。他们一直在做的，是凌晨 2 点带着团队排查线上故障，并长期承担依赖 AI 进行开发所带来的后果。

他们的经历揭示了一个越来越清晰的事实：Vibe Coding 确实能让功能快速上线，但同时也在制造更多难以偿还、正在拖垮工程团队的技术债，甚至可能会威胁产品的长期可持续性。

在我们采访的 18 位负责人中，有 16 位亲身遇到过 Vibe Coding 引发的线上事故。只有 3 位给出了正面反馈，但即便如此，他们也强调了严格的使用边界——总体来看，有 14 位 CTO 认为 Vibe Coding 带来的长期问题远大于短期收益。

下面，就是这些 CTO 分享的真实案例和思考。这些故事说明，最有价值的开发者并不是那些能疯狂调用 AI 生成代码的人，而是能设计系统、排查复杂问题、真正理解业务逻辑的人。

定义 Vibe Coding 的生产灾难

“Vibe Coding 看似是一条提高效率的捷径，但实际上就是死路一条。”Let Set Go 的 CTO Ritesh Joshi 警告说。最近，他的团队就遭遇了一次典型的 Vibe Coding 灾难：

“一名开发者用 AI 生成了一段数据库查询代码，语法完全正确，但性能极差。测试小数据集时没问题，但一旦上线遇到真实流量，系统就慢到几乎不能用。问题不在于代码语法，而在于底层架构。”

Cirrus Bridge 创始人兼首席架构师 Patric Edwards 遇到的情况则更加惊险，甚至涉及安全漏洞：

“一名初级开发者，把 AI 生成的代码和 Stack Overflow 上的片段拼在一起，‘凭感觉（Vibe）’写出了一个用户权限系统。开发和测试阶段一切正常，甚至 QA 也没发现问题。然而，上线两周后我们才发现，已被禁用的用户账号仍可访问部分后台工具，因为访问逻辑是建立在'当时似乎能用'的倒置真实性检查基础上的。”

为了这个 Bug，Patric Edwards 花了整整两天才完全排查清楚。他把这种情况称为 “信任债务”：“它迫使你的高级工程师变成了长期的代码侦探，不得不反复逆向分析这些‘凭感觉写的逻辑’，只为发布一个稳定的更新。”

Patric Edwards 总结道：“Vibe Coding 或许能让你偶尔冲过终点线，但长远看，它只会带来一些缓慢、隐蔽却代价高昂的系统性问题。而且，没有任何 AI 工具能帮你重构团队文化。”

当“完美代码”在生产环境崩溃……

而 AlgoCademy 的 CTO Mircea Dima，遇到了 Vibe Coding 最危险的特性：看起来很完美的代码，突然灾难性地崩溃了。

“一名开发者写了一个二分查找的实现，被标记为可用，并被用于核心搜索功能中。结果我们花了一整周才发现，这段代码在某些输入下会静默失败——因为开发者不了解整除在我们的语言中是如何工作的。而 AI 并没有检查出来，最终导致生产环境崩溃、用户严重流失。”

Mircea Dima 表示，问题不在于 AI 会犯错，而在于 Vibe Coding 让团队陷入了一种“你不是在调试，而是在灭火”的困境：“这些问题不会立刻暴露，只有当系统在工作负载下开始动荡时，你才会发现灾难正在酝酿。”

至于App Makers LA 的首席执行官 Daniel Haiem，则非常精准地描述了 Vibe Coding 的幻觉问题：

“在产品开发早期，速度至上，此时 Vibe Coding 就像是魔法，初级或中级开发者都能用 AI 工具、Cursor 等，以闪电般的速度将工作功能串联起来。表面上看，功能上线了，客户也满意，大家击掌庆祝。但真相是什么？只是一个用杂乱无章的代码所堆积出来的叠叠乐罢了。”

他的团队很快就尝到了苦果：一名开发者用 Vibe Coding 写完了整个基于 Firebase 和 npm 包的身份认证流程。

“它在最初确实运行正常。但当我们需要支持多角色访问和区域隐私规则时，整个系统直接崩溃。没人能搞清楚哪些模块依赖哪些，中间件也分散在六个文件里，根本没有统一的思维模型。最后，我们只能推倒重写，因为调试工作就像考古一样。”

AI 助手的陷阱

Akveo 的高级全栈工程师 Mikhail Hryb 同时见识过 AI 辅助开发的好处与灾难。他承认，AI 工具在正确使用时非常强大：

“如果我脑子里已经有架构蓝图，Agent 可以帮我更快实现。比如我之前要处理一个复杂的 Stripe 集成，从没接触过。我把代码丢进 Cursor，请它帮我拆解，30 分钟内我就完全掌握了逻辑。”

但他也见过十分彻底的灾难：

“有个项目几乎完全靠 Vibe Coding 搭建。MVP 两天就交付l，比预期快得多。但没有任何人审查 AI 生成的代码。初级开发者写得乱至少还能读懂，但 AI 生成的代码如果没人监管，结果就是一堆乱码——无法调试、难以扩展、维护很痛苦。”

基于此，Mikhail Hryb 的结论很明确：“目前 AI 工具最多是‘副驾驶’，它们很适合辅助，但绝不能掌握方向盘。开发者仍然需要主导、思考、审查，并承担决策。”

上下文腐烂（Context Rot）

Artemii Shlesberg 则指出了 Vibe Coding 的一个隐性技术问题：上下文腐烂（context rot）：“大多数 AI 工具的上下文记忆都很有限。一旦会话过长，夹杂了错误尝试、幻觉代码或半成品逻辑，后续AI输出的质量就会呈指数级下滑。”

而这会导致他所说的“幻觉与自我肯定循环”。对于小型玩具应用来说，这种方法或许可行；但只要超过单页网站的复杂度，这种方法必然会导致崩溃。

除此之外，Artemii Shlesberg 还强调了维护方面的噩梦：“我曾接手过一些服务，代码‘能跑’，但无法测试、不安全、也无法扩展。有一次我们继承了一个明显由 AI 主导开发的功能，最后花在逆向工程上的时间，比从零重写还多。”

战略层面的隐患

Navan 的高级工程经理 Justin Otero 也提出了在 Vibe Coding 讨论中常被忽略的一个关键：上下文与任务类型。

“当团队说 AI 提升了巨大生产力时，必须先问：他们是在做什么类型的任务和代码库？是扩展或重构已有系统，还是完全从零构建？要知道，从零开发当然简单得多，但重构一个多年积累的系统就完全不同了。”

他指出，现有项目往往有 lint 规则、代码风格、架构模式、团队默契、历史债务等等，这些“部落知识”会直接影响 AI 是否真的能带来收益。

CTO Joseph Leung 也给出了一个理解 Vibe Coding 局限性的框架：“Vibe Coding 适合把一个想法从 0 推到 0.7。但如果要把它当作开发主力，问题就会接踵而至。”

他解释称，通过 Vibe Coding 构建的产品，往往只在最初需求场景下能完全正常运行。一旦用户提出新的用例，就会立刻出现问题。

什么情况下，仍可进行 Vibe Coding？

当然，并不是所有技术负责人都全盘否定了 Vibe Coding。

例如，LittleHelp 创始人 Matt Cumming 就在战略性使用 Vibe Coding 后取得了一些成功：

“我可以在一天之内创建并部署一个功能完整的微型 SaaS Web 应用，而且几乎没有任何问题，这太疯狂了。上周末，我在周六想到了一个网络应用，周日就上线了。”

不过，这份成功的背后也有着沉重的教训——某次 Matt Cumming 花了一个多月业余时间开发的项目，几分钟内就被 AI 毁掉了。

如今，他和团队在用 AI 开发时，会严格遵守一些规范：“我们会先与 AI 合作写好功能规格文档和项目步骤，然后才开始写代码。另一个关键点是，让 AI 在新增功能上线前执行一次安全检查。”

关键区别是什么？Matt Cumming 把 Vibe Coding 用于一次性项目和原型开发，而不是需要长期支撑的生产系统。

Featured 公司 CEO Brett Farmiloe 也持类似态度，但同样强调限制条件：

“在我们收购并重启 Help a Reporter Out 时，Vibe Coding 确实帮了大忙。我们用 v0 快速搭建了网站和一些组件，并很快上线。但在像 Featured.com 这种已经成型的代码库里，Vibe Coding 生成的代码最多只能作为起点，后续必须由技术团队接手完善。”

总体而言，这两位领导者都将Vibe Coding视为起点，而不是终点。他们将其用于快速原型开发和新建项目，但在进入生产前必须由人工接管和审查。

风险最小化的做法

PureLogics 总裁兼 CTO Muhammad Atif 提供了一套务实的风险控制方案：“我们制定了保障措施，确保 AI 只是辅助而非主导，并且每一段 AI 生成的代码都必须经过上下文验证。”

他的团队有一条硬性规定：“每一行‘Vibe Code’都必须有架构层面的解释，哪怕只是在 PR 评论里写两句话，说明‘为什么要这么做’。”

Muhammad Atif 强调，“AI 工具只是副驾驶，而不是自动驾驶。Vibe Coding 也许能让功能更快上线，但如果牺牲了清晰性、上下文和可持续性，那它不过是换了马甲的技术债。”

最终底线

从这些 CTO 的实践来看，结论非常明确：Vibe Coding 在战略性使用时确实能带来价值，但它绝不能成为生产系统的根基。

那些真正利用好 AI 的团队，有几个共同点：

● 把 AI 当作增强手段，而不是工程基础的替代品；

● 设立明确的“护栏”，例如要求对 AI 生成代码给出架构层解释；

● 培养拥有批判性思维的团队，将其与普通的代码生成者区分开来。

对担心 AI 抢走饭碗的开发者来说，这些 CTO 也给出了不同的视角：真正学会负责任地使用 AI 的公司，未来需要的开发者只会更多——他们需要的是能正确引导 AI 工具、同时保持自身技术判断力的工程师。

因为当 Vibe Coding 的系统在生产环境里崩溃时，再多的 Prompt 也无法替代人类开发者对系统的深刻理解。

【活动分享】2025 全球机器学习技术大会（ML-Summit）北京站将于 2025 年 10 月 16-17 日在北京威斯汀酒店举办。大会共 12 大主题、50+ 海内外专家，聚焦大模型技术和应用变革。详情参考官网：https://ml-summit.org (或点击原文链接）。

小米16和16 Pro差异曝光！影像、设计、续航大比拼，你会选择谁？

实测辅助“埋雷微信抢红包扫雷控制尾数开挂软件”（详细透视教程）-哔哩哔哩

发表评论

凌晨2点查Bug、成天收拾AI“烂摊子”……在18位CTO眼中的“Vibe Coding”，竟多是「生产噩梦」？

小米16和16 Pro差异曝光！影像、设计、续航大比拼，你会选择谁？

实测辅助“埋雷微信抢红包扫雷控制尾数开挂软件”（详细透视教程）-哔哩哔哩

最新评论

最新留言

标签列表