> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 氛围编程者不会调试 - URL: https://www.hubwiz.com/blog/vibe-coders-cant-debug/ - Published: 2026-05-17T11:24:17.000Z - Updated: 2026-10-13T15:58:42.000Z - Description: 你可以用提示词写出初稿。但你无法在凌晨三点，当你的追踪信息不一致、日志在欺骗你时，用提示词穿越分布式系统中的海森堡 bug。 - Author: admin - Tags: VIBE CODING, #Import 2026-10-14 14:41 有一种 Pull Request 我经常看到。 代码能跑。测试通过。作者能用简单的语言解释它的功能。但如果你问他们*为什么*某一行代码在那里，或者边界情况发生时会发生什么，你就会看到那种茫然的目光。他们没有写出这些代码。他们向 AI 描述需求，接受了输出，反复调整直到 CI 变绿，然后就直接发布了。 这就是 vibe coding。而且现在它无处不在。 ## 1、实际情况是什么 Cursor、GitHub Copilot、Windsurf、Claude Code——选一个你喜欢的工具。它们的卖点都一样：描述你想要什么，AI 来构建，你快速推进。这确实令人印象深刻。我见过工程师在二十分钟内搭建出完整的 CRUD API。这在两年前需要整整一个下午。 但有一笔隐性成本，没有人计算过。 当你自己编写代码时——即使是糟糕的代码——你也在构建一个心智模型。你知道问题埋在哪里。你在干净的解决方案和务实的方案之间做出了取舍。这些知识是承重墙。当凌晨两点生产环境告急时，正是这些知识让调试成为可能。 Vibe coding 跳过了这一步。你最终得到的是*存在*但并未真正*被理解*的代码。那是别人留在你代码库中的笔迹。 ## 2、数字不会说谎 GitHub 自己在 2025 年末的数据显示，AI 辅助开发者每周交付的代码量增加了约 55%。这听起来很棒，直到你看到后续数据：AI 辅助代码库中 bug 率在生产环境中高出 2-3 倍，且其中大部分是逻辑错误——不是语法错误，不是类型不匹配，而是*错误的行为*。那种只有在真实负载下或真实用户做了意料之外的事情时才会暴露的 bug。 从个人经验来看，我在三家不同的公司都观察到了这种模式。快速初始开发。然后，大约 6-12 个月后，出现了一个无人能解释的减速。代码库扩大了，但开发速度却下降了。PR 审查需要更长时间。简单的修改会破坏意料之外的东西。团队不再拥有自己系统的心智地图，因为他们不是构建它的人——他们是通过提示词将其召唤出来的。 技术债务一直存在。但这次不同。这是*理解力*债务。 ## 3、不过，辩护者也有道理 我不想在这里当一个对着云大喊大叫的老头。"自己写代码"的阵营忽略了一些真实的成本。 样板代码确实令人灵魂崩溃。搭建认证系统、编写迁移脚本、连接 API 客户端——没有人会在第 40 次编写同样的模式时学到任何东西。如果 AI 处理这些例行公事的工作，那其实是好事。这样就有更多时间处理真正有趣的问题。 而且，并非每个代码库的每一层都需要被理解。一个发布 MVP 的初创公司不需要他们的三人团队对每一个生成的工具函数都有百科全书式的了解。先把产品推出去，验证想法，然后在需要的时候重构。 问题不在于使用 AI 写代码。而在于把 AI 的输出当作一个你从不追问的黑箱。 ## 4、我看到的有效做法 那些处理得好的工程师，把 AI 的输出当作代码审查来对待，而不是复制粘贴。 他们会阅读模型生成的内容。他们会提出异议。他们会做出修改。他们让 AI 解释特定的部分，不是因为他们读不懂代码，而是作为一种强制手段来揭示隐藏的假设。如果解释说不通，代码很可能就有问题。 我开始在团队中推广一个习惯：在接受 AI 建议之前，向一只橡皮鸭解释它。大声说出来。这个函数*实际上*是做什么的？它的失败模式是什么？如果你不能在 30 秒内回答这些问题，你还没有真正拥有那段代码。 这不算什么。但它能保持心智模型的完整。 ## 5、招聘已经在失效 让人不舒服的地方在这里。 面试流程越来越脱离现实。在沙盒环境中做 LeetCode 风格的题目，且不能使用 AI。这已经不再是任何人实际工作的方式了。但换成无人监控的作业题，你又无法分辨候选人真正知道什么，以及 Claude 告诉了他们什么。 我见过初级工程师顺利通过技术面试，然后在入职第一周 struggling 修复一个 10 行的 bug——因为调试过程——实际阅读错误信息、形成假设、检查假设——是他们从未锻炼过的肌肉。他们只会让 AI 来修复问题。 这不是一代人的失败。这是一个工具问题。我们在教人们刀刃是干什么的之前，就把电动工具交给了他们。 ## 6、仍然重要的技能 调试。就是它。 你可以用提示词写出初稿。但你无法在凌晨三点，当你的追踪信息不一致、日志在欺骗你时，用提示词穿越分布式系统中的海森堡 bug。这需要心智模型、从痛苦中建立起来的模式识别能力，以及在没有安全网的情况下形成和检验假设的能力。 顺便说一句，AI 在这方面真的很差。让它调试一个微妙的并发问题，它会自信地给出看起来合理但错误的建议。因为它没有你的上下文，没有你系统的历史，也没有那种来自以前见过这种问题的直觉。 这种直觉是通过自己编写和破坏代码来建立的。没有捷径。 ## 7、未来的走向 我认为我们最终会进入一个双峰世界。在扎实的基础上将 AI 用作加速器的工程师，将变得极其高效。在建立基础之前就把 AI 当作拐杖的工程师，将会碰上一堵天花板——而且是坚硬的那种。 工具不会消失。它们会变得更好。所以答案不是回避它们；而是对自己保持诚实，认清自己真正理解什么。 Vibe coding 对原型来说没问题。对一次性脚本来说没问题。对没人关心的部分来说没问题。 对于重要的部分——那些你将来需要维护、调试、扩展，并向后来者解释的部分——你最好理解你交付了什么。 否则，当它崩溃时，你将以痛苦的方式明白这一点。 --- 原文链接: [Vibe Coding Is Real, and It's Creating Devs Who Can't Debug](https://dev.to/taskconcierge/vibe-coding-is-real-and-its-creating-devs-who-cant-debug-3je?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)