6.0
关注
AI SCORE
技术实践2025-09-02 02:13
警惕"氛围编码"：AI 辅助的隐性技术债陷阱
DEV Community · Arindam Majumder #最佳实践#质量
Editor brief · 编辑速览
文章批评过度依赖 Claude/ChatGPT 而不理解代码本质的现象。提醒开发者应理性使用 AI 工具，避免积累看不见的技术债。
文章批评过度依赖 Claude/ChatGPT 而不理解代码本质的现象。提醒开发者应理性使用 AI 工具，避免积累看不见的技术债。
AI 辅助编码工具，如 Claude Code、ChatGPT 和 GitHub Copilot，简直是天赐良物。我每天都在用——生成模板代码、修复 bug、快速探索，甚至写文档。我完全支持用 AI 作为生产力提升和创意加速器。
但它们正在改变我们编写软件的方式——而且不全是好的。因为我们已经进入了 AI 采用的一个阶段，有些人开始在工作中进行"感觉编码"（vibe coding）。这可能预示着一种发展文化的到来，其中有意的设计被便利性和速度所取代。
Vibe coding 最初是快速搭建原型或业余项目的一种方式。你给模型下个提示，让它为你快速组装整个应用或功能——就这样！你可以在几分钟内测试你的概念。对初级开发者、独立创业者和正在创建快速演示的资深开发者来说，这非常完美。快速失败，如人们常说的那样。
但虽然这些是 vibe coding 的绝佳用例，vibe coding 已经演变成了一种与 AI agent 合作的工作方法，可以为各种用例生成代码——包括生产系统。
它涉及在没有太多手动输入或对生成代码理解的情况下提示 AI 编写代码。通常涉及模糊的指令、最少的验证，以及对输出的盲目信任。
它吸引 vibe coder 的地方在于速度快、毫不费力，而且不需要你理解底层语言或系统架构。但当你在没有对自己正在构建什么有强烈心智模型的情况下提示 AI 生成代码时，就成了——感觉优先，架构次之，测试最后（如果有的话）。
"给我构建一个具有 Stripe 集成和 PostgreSQL 后端的 REST API。"
很快，很诱人，通常"能用"。但在表面之下，你通过 vibe coding 写出的应用往往隐藏着脆弱的假设、不清晰的逻辑和结构混乱的蔓延。
从其核心来说，软件工程不仅仅是让代码工作。它关乎问题解决、设计可维护的架构、编写清晰且表达力强的逻辑、精确调试和确保长期可靠性。
因为，没错，你让那个 vibe coded 的微服务运行了——但错误处理怎么样？它是否遵循你组织的约定？AI 是否创造了一个具有奇怪命名不一致的数据模型？文件中是否有十种不同的写法在做同一件事？你的生产数据库还活着吗？
当你进行 vibe coding 时，你跳过了那些使代码在长期内可维护和可扩展的有意设计步骤，比如用意图命名变量、选择干净的结构和设计周密的流程。当 vibe coding 成为常态时，我们冒着风险把更深层次的思考放在一边，而这正是让工程师有效和系统有韧性的东西。
你正在快速冲向一个技术债务堆积的噩梦，没有地图，没有刹车。
现代编程语言已经抽象掉了硬件和内存管理。AI 添加了一个概率性的、非确定性的层，进一步模糊了逻辑。通过 AI，我们抽象的是意图。
但关键在于：AI 的输出是概率性的。这意味着：
相同的提示在不同运行中可能产生大不相同的结果。
相同的提示在不同运行中可能产生大不相同的结果。
措辞的轻微调整可能导致完全不同的架构选择。
措辞的轻微调整可能导致完全不同的架构选择。
你通常不知道模型为什么选择了它选择的。
这种 vibe coded 的模糊性对原型设计来说没问题，但对生产系统呢？不可预测性削弱了信任、控制和可靠性——这些是可扩展软件开发的关键品质。
这就像让一个混乱中立的法师重构你的代码库。
说实话：vibe coding 一开始感觉很棒。你在一小时内就得到了一个运行中的原型，而不是一周。
但没有适当的护栏，这种速度会导致：
不连贯的架构
不连贯的架构
不一致的模式
不一致的模式
不理解结构，未来的维护会变成痛苦的事。代码审查花时间成倍增加，你更容易遗漏东西。调试变成侦查工作。扩展变成猜测。你前期节省的时间后期可能花费更多。这还没有考虑到你正在制造的 PR 积压。
突然，你就身处一个能工作但不能碰的代码库中，除非你调用六小时的调试、一百万 token 的上下文窗口和三次心理治疗。
Vibe coded 的系统倾向于：
在边界情况下崩溃。
在边界情况下崩溃。
迷惑下一个开发者（甚至未来的你）。
迷惑下一个开发者（甚至未来的你）。
在生产中无声地失败。
在生产中无声地失败。
结果是什么？你花在审查、修复、解释和重写东西上的时间，比你通过提示所节省的要多得多。你创建了一个不仅脆弱的系统——它既脆弱又神秘。
AI 不会警告你它是否意外地通过 vibe coding 泄露敏感数据、硬编码 API 密钥或跳过输入验证。除非你完美地要求它，否则它不会强制域驱动设计或测试覆盖。
没有强大的工程直觉，vibe coding 可能导致真实世界的漏洞和脆弱的系统，特别是当安全是事后考虑而不是默认的时候。我们已经在 Tea Dating 应用泄露了 70,000 多个客户的私人信息和 AI 删除了 SaaStr 生产数据库的事件中看到了这一点。
除非显式要求，否则不写单元测试。
除非显式要求，否则不写单元测试。
理解你的威胁模型。
理解你的威胁模型。
遵循 OWASP 指南。
遵循 OWASP 指南。
除非提示完美，否则不验证用户输入。
除非提示完美，否则不验证用户输入。
负责任地日志记录（你好，硬编码的密钥和 PII 泄露）。
负责任地日志记录（你好，硬编码的密钥和 PII 泄露）。
如果你还没有强大的工程习惯，或者如果你不愿意即使在这个充满感觉的时代也坚持你目前的习惯，你永远不会知道这些东西是缺失的，直到它们在生产中狠狠咬你一口。
与 bug 的斗争、追踪堆栈跟踪和从错误中学习能构建技术直觉。这种挫折是学习路径的一部分，跳过它可能导致肤浅的自信和依赖。
没有奋斗，开发者无法构建独立解决陌生问题的肌肉，而那正是真正的专业知识所在。是的，调试很糟糕。但通过 12 层抽象追踪一个讨厌的 bug 会教你一些 LLM 永远教不了的东西。
系统的心智模型
系统的心智模型
在代码腐烂坏掉之前闻到它的直觉
在代码腐烂坏掉之前闻到它的直觉
当你跳过这个时，你在肤浅的理解上构建肤浅的自信。当事情出错时，你没有工具来修复它。
让我们给应得的地方点赞。Vibe coding 在以下方面很棒：
生成样板代码或重复任务
生成样板代码或重复任务
以交互方式教学编程概念
以交互方式教学编程概念
通过粗糙的模型传达产品想法
通过粗糙的模型传达产品想法
通过框架或模式进行头脑风暴
通过框架或模式进行头脑风暴
有意识地使用，它成为 vibe coder 的有用工具。盲目地使用，它成为一种责任。作为开发者和团队，我们需要理解在哪里划线。以及何时通过更严格的代码审查和单元测试来引入支持，以解决技术债务，在它在你的代码库中固化之前。
最大的风险不是 AI 杀死开发者的手艺。而是技术债务变得隐形。
当 AI 编码成为构建的默认方式时，系统看起来会很完整——但在底下，它们会很混乱、很脆弱、没有文档。没人会知道，除非他们试图扩展它们。
这在以下领域尤其重要：
安全关键系统
安全关键系统
然而，vibe coding 也有可能演变成开发的新层次，一种与手艺共存的东西，AI 处理模板代码和初步代码审查这样乏味的事情，人类关注系统背后的架构、伦理和设计。
这是我们想要发现自己所在的时间线，也是我们在 CodeRabbit 处理 AI 的方式。我们关注的是 AI 工具，它通过帮助你发现和防止技术债务和 bug 进入生产来补充你的编码 agent——而不是相反的方式。
这不是一篇反对 vibe coding 的文章。我每天都在我的工作流中使用 AI 编码 agent。但工具应该放大我们的技能，而不是取代它们。它们应该做那些乏味和重复的工作——而不是思考和策略。
Vibe coding 不是邪恶的，只是容易被滥用。真正的危险是让它成为你项目上的默认心态，而你团队的开发者还不理解他们在构建什么。
让我们拥抱 AI，但保持编码作为一种手艺活着，因为好的软件不仅仅是关于什么有效。它关乎什么能持久，在原始开发者走后还很久——以及在感觉消退后很久。
需要帮助将技术债务排除在生产之外？立即免费尝试我们的 AI 代码审查工具。