--- title: 260307-Vibe Coding 不是低质量工作的借口 description: 负责任的 AI 辅助开发实战指南 author: Addy Osmani source: https://addyo.substack.com/p/vibe-coding-is-not-an-excuse-for date: '2026-03-07' category: 01-core-concepts tags: - AI 辅助开发 - 代码质量 - 工程实践 - 技术债务 - 代码审查 --- # Vibe Coding 不是低质量工作的借口 **作者：Addy Osmani** **原文：[查看原文](https://addyo.substack.com/p/vibe-coding-is-not-an-excuse-for)** > ## 摘要 > > 负责任的 AI 辅助开发实战指南 --- **"更快行动，打破更多东西。"** ![](/images/articles/localized/01-core-concepts/vibe-coding-is-not-an-excuse-for-low-quality-work/01.jpg) 这句对硅谷旧口号的扭曲，随着"vibe coding"（氛围编程）进入聊天室，在最近的工程圈中回响**。是的，AI 辅助开发正在改变我们构建软件的方式，但这并不是放弃严谨、审查或工艺的免费通行证。**"Vibe coding"不是低质量工作的借口。 让我们先承认积极的一面：AI 辅助开发确实改变了软件的生产方式。它降低了实现门槛，让新手和非开发者也能通过清晰描述需求，生成可运行的软件。这释放了创造力——更多人可以用定制软件解决自己的具体问题，这也是一些人所说的[“个人软件解绑”](https://addyo.substack.com/p/personal-software-the-unbundling)趋势的一部分。对经验丰富的工程师来说，它同样能带来明显收益。 然而，正如任何经验丰富的工程师会告诉你的**，如果车轮在路上掉了，速度就毫无意义**。这就是裂缝开始显现的地方——在构建可维护、健壮软件的**氛围**和**现实**之间的差距中。 ## 残酷的真相：质量不是自动的 尽管热度很高，vibe coding 仍然遭到不少资深开发者的质疑。核心批评是：**实现速度变快，并不等于质量会自动达标**。如果把 AI 生成的结果不加审查地直接接入代码库，技术债务也会被同步放大。那句半开玩笑的话——**“两个工程师现在也许能制造出五十个人规模的技术债务”**——之所以传播开来，正是因为它点中了这一点。 许多早期的 vibe coding 项目表面上看起来已经“能用了”，但里面往往藏着一整串问题：错误处理不足、性能边界没想清楚、安全实践松散、逻辑结构脆弱。我曾把这类东西称作 **“[纸牌屋代码](https://addyo.substack.com/p/the-70-problem-hard-truths-about)”**——看起来完整，一旦进入真实环境的压力测试就开始松动。AI 的确可以快速产出大量代码，但数量从来不等于质量。 ![](/images/articles/localized/01-core-concepts/vibe-coding-is-not-an-excuse-for-low-quality-work/02.jpg) _[Forrest Brazeal](https://open.substack.com/users/2605615-forrest-brazeal?utm_source=mentions) 的这幅插图，形象地展示了一个核心事实：AI 生成结果很快，但工程责任并不会因此自动消失。_ 这些风险并不只是理论上的。先看可维护性：如果一个 AI 生成的模块结构晦涩、耦合过重，后面总得有人继续维护。要是连最初接手的人都说不清它为什么这么写，后续修改自然会越来越痛苦。安全也是同样的道理：如果任务描述和上下文里没有把安全边界、错误处理和输入约束说清楚，生成结果就可能留下 SQL 注入、XSS 或不安全异常处理等问题。再加上**过度拟合提示**——也就是输出只对齐字面要求，却没有对齐真实需求——最终都会在上线后反噬团队。 这并不是说 AI 不能写出好代码，而是说：**好结果依赖于足够的上下文、明确的约束和严格的审查**。如果把 AI 当成跳过工程判断的理由，问题就不在工具，而在工作方式本身。任何“工具会自动兜底”的想象，最终都得回到软件工程的基本原则上来。 那么，我们如何取得平衡？关键是**不要**完全抛弃 vibe coding——它**可以**非常有用——而是以一种有纪律的方式整合它。工程师必须将 AI 辅助视为一个*具有已知局限性*的工具，而不是一个神秘的代码精灵。在实践中，这意味着让人类参与循环并保持我们的质量标准。让我们探讨一下这看起来是什么样子。 ## 让人类始终留在回路里 要有效使用 vibe coding，最重要的心态转变是：**把 AI 当作高速度的实现协作者，而不是责任承接者**。换句话说，你——工程师、评审者或负责人——仍然要对结果负责。AI 可以快速给出第一稿，但是否进入代码库，仍然取决于你是否理解、验证并认可这份结果。 成功整合 AI 的经验丰富的开发者会直觉地遵循这种模式。当 AI 助手建议代码时，他们不会只是点击"接受"然后继续。相反，他们会： - **阅读并理解** AI 写出的内容，确认你能解释它的结构与意图。 - 如果 AI 的输出是单体或混乱的（通常是这样）**，重构**代码为干净、模块化的部分。高级工程师会将 AI 的大块代码分解为"更小、更专注的模块"以提高清晰度。 - **添加缺失的边缘情况处理**。AI 经常遗漏边角情况或错误条件，所以人类需要插入这些（空值检查、输入验证等）。 - **加强类型和接口**。如果 AI 使用了松散的类型或泄漏的抽象，人类可以加强它，将隐式假设转化为显式契约。 - **质疑架构**。AI 选择了一个低效的方法吗？也许它暴力破解了应该使用更优算法的东西，或者它引入了全局状态，而纯函数就足够了。人类应该批判性地检查这些决定。 - **编写测试**（或至少手动测试代码的行为）。像对待同事的任何 PR 一样对待 AI 代码：在测试之前不能合并。如果 AI 编写了单元测试（一些工具会这样做），请仔细检查这些测试不是表面的。 通过这样做，你才真正把工程判断注入到 AI 生成的代码里。这种组合的威力在于：AI 提供速度，人类提供边界、验证与取舍。也正因如此，基础更扎实的开发者通常能从 AI 工具中拿到更稳定的收益，因为他们更容易判断什么值得保留、什么必须重做。 因此，一个关键规则几乎不该有例外：**未经审查的 AI 代码，不要直接并入代码库。**你必须确保自己真正理解它。如果有一段实现你说不清楚，就继续补充约束、要求澄清，或者自己重写。AI 输出可以是草稿，但绝不能绕过审查。放到团队协作里，这意味着任何使用 AI 生成的大段代码，都应该能在代码审查中被清楚解释、被明确辩护，而不是靠“反正能跑”蒙混过关。 另一个最佳实践**：让人类掌控设计**。使用 AI 来实现，而不是决定基本架构。例如，你可以使用 vibe coding 根据现有模式快速创建一个 CRUD REST API——这是定义明确的工作。但你不应该要求 AI"为我们的产品设计一个可扩展的微服务架构"，然后盲目遵循它。高层设计和关键决策应该保持人类主导，AI 作为繁琐部分的帮手。本质上，让 AI 处理**苦力活**，而不是*脑力活*。 **沟通和文档**也变得至关重要。如果你提示 AI 生成一个非平凡的算法或使用一个不熟悉的库，花时间记录**为什么**选择了那个解决方案（就像你自己在研究后写的一样）。未来的维护者——或未来的你——不应该被留下猜测 AI 制作代码背后的意图。一些团队甚至记录用于生成重要代码的提示，有效地记录导致代码的"对话"。这在以后调试时会有所帮助：你可以看到给 AI 的假设。 总之**，人类监督不是"锦上添花"——它是强制性的**。一旦你将人类从循环中移除，你就只是在软件质量上掷骰子。在 AI 真正能够取代高级工程师的整体理解之前（我们还没有到那一步），vibe coding 必须是一种伙伴关系：AI 加速，人类验证。 ## Vibe Coding 的高质量实践规则 让我们将讨论具体化为一些可操作的规则和最佳实践，供采用 AI 辅助开发的团队使用。将这些视为新的*"快速行动，但不要打破一切"*手册——一套护栏，在你与代码"vibe"时保持**质量**高。 **规则 1：始终审查 AI 生成的代码**——没有例外。无论代码来自 Copilot、ChatGPT、Cursor 还是其他 AI 工具，只要它准备进入代码库，就必须经过审查。你可以自己审，也可以和同伴一起审；但如果你没有时间审查它，那就说明你还没有准备好接纳它。 **规则 2：建立编码标准并遵循它们** - AI 工具会模仿它们训练的任何代码，这是一个混合包。定义你团队的风格指南、架构模式和最佳实践，并确保任何 AI 生成的代码都被重构以符合。例如，如果你的规则是"所有函数都需要 JSDoc 注释和单元测试"，那么 AI 输出必须在完成之前获得这些注释和测试。如果你的项目使用特定的架构（比如，带有服务/存储库类的分层架构），不要让 AI 在 UI 代码中塞入一些临时的数据库调用——修复它以适应你的层。考虑创建**linting 或静态分析检查**，专门针对常见的 AI 错误（例如，标记使用已弃用的 API 或过于复杂的函数）。这自动化了对 AI 贡献的质量控制。 **规则 3：使用 AI 加速，而不是自动驾驶** - 在实践中，这意味着使用 vibe coding 来加速理解良好的任务，而不是为你思考。很好的用途：生成样板代码、搭建组件、将一种语言翻译成另一种语言、从伪代码起草简单算法。有风险的用途：让 AI 在最少指导下从头设计你的模块，或者在你根本不理解的领域生成代码（你不会知道它是否错误）。如果你打算保留代码，不要停留在 vibe 模式——切换到工程模式并加强它。 **规则 4：测试、测试、测试**——生成速度不会自动带来正确性。关键路径一定要有测试。即便 AI 能帮你补测试，也不要只依赖它生成的测试，因为同一套遗漏也可能同时出现在实现和测试里。对面向用户的功能，还要做手动验证：点一遍 UI，试一试异常输入，确认它不是只在“快乐路径”上看起来正常。 **规则 5：迭代和完善** - 如果第一次 AI 给你的东西不令人满意，不要接受它。Vibe coding 是一个迭代对话。如果初始输出笨拙或令人困惑，你可以提示 AI 改进它（"简化这段代码"，"将其拆分为更小的函数"等）。或者你可以拿草稿自己重构它。通常，一个好的方法是在**循环**中使用 AI：提示实现，识别弱点，然后提示修复或手动调整，并重复。 **规则 6：知道何时说不** - 有时，vibe coding 就不是正确的工具。负责任地使用它的一部分是识别需要手动编码或更深入设计工作的场景。例如，如果你正在处理一个关键的安全模块，你可能想要仔细设计它，也许只使用 AI 来协助小部分（如果有的话）。或者如果 AI 不断为一个简单问题生成复杂的解决方案，停下来自己写——你最终可能会节省时间。重要的是不要过度依赖 AI 来解决每个问题**。不要让"AI 做的"成为不理解自己代码的借口。**如果经过几次尝试 AI 没有生成你需要的东西，收回控制权并以老式方式编码；至少那时你会有完全的理解。 **规则 7：记录和分享知识** - 确保来自 AI 的任何代码都像手写代码一样彻底记录（如果不是更多的话）。如果有非显而易见的决定，或者你怀疑其他人可能会对 AI 生成的内容感到困惑，添加注释。在团队讨论中，公开说明什么是 AI 生成的，什么不是。这有助于审查者对这些部分给予额外关注。 遵循这些规则，团队可以享受 vibe coding 的生产力优势，同时减轻最坏的风险。将其视为**增强**人类开发者，而不是取代他们。目标是与 AI **共同创造**：让它以高速处理重复的苦差事，而人类处理创造性和批判性思维部分。 ## 何时 vibe coding 有效（何时失败） 同样重要的是要认识到**vibe coding 在哪里闪耀，在哪里不闪耀**。并非每个项目或任务都同样适合 AI 驱动的工作流程。以下是从行业讨论和早期经验中得出的细分： **👍 很好的用例**： - *快速原型设计*可能是 vibe coding 的最佳点。如果你有一个小应用或功能的想法，使用 AI 助手快速组合一个快速原型或概念验证可能非常有效。在这种情况下，你不介意代码有点粗糙；你只是想验证这个想法。许多工程师发现在周末项目中仅使用 AI 编码取得了成功——这是一种快速测试概念的有趣方式。另一个好的用例是**一次性脚本或内部工具**：例如，解析日志文件的脚本、自动化个人任务的小工具或团队的内部仪表板。这些通常是低风险的；如果脚本崩溃，这不是世界末日。在这里，vibe coding 可以节省时间，因为你不需要生产级的完美，只需要现在能工作的东西。 - Vibe coding 也适用于**学习和探索**。如果你在一个新语言或 API 中工作，要求 AI 生成示例可以加速你的学习。（当然，根据官方文档仔细检查 AI 的输出！）在探索模式下，即使 AI 的代码不完美，它也会给你材料来修补和学习。这就像有一个教学助手可以向你展示尝试，然后你再完善。 - 此外，AI 代码生成可以在**结构化、样板繁重的任务**中表现出色。需要创建 10 个类似的数据类吗？或者实现一个常规的 CRUD 层？AI 在这种机械重复方面很出色，让你从繁琐中解脱出来。只要模式清晰，AI 就会遵循它并为你节省按键（只需验证它正确遵循了模式）。 **👎 不太好的用例**： - 另一方面，*企业级软件和复杂系统*是 vibe coding 经常失败的地方。任何需要深入理解业务逻辑、大量并发、严格安全或合规性的东西都不是完全信任 AI 生成的东西。除非你明确说明，否则 AI 不知道你的业务约束或性能要求（即使那样，它也可能做不对）。例如，处理支付的金融科技应用或航空航天控制系统必须满足当前 AI 根本无法保证的标准。在这些领域，AI 可以在部分协助，但人类专业知识和仔细的 QA 对最终产品至关重要。 - Vibe coding 也在**长期可维护性**方面挣扎。如果你正在构建一个将存在多年并由许多开发者工作的代码库，用 AI 生成代码的大杂烩开始它可能是一个糟糕的基础。没有强有力的指导，架构可能不一致。通常最好在前期花额外的时间构建一个干净的框架（有或没有 AI 帮助），而不是通过连续的 AI 提示拼凑整个产品。许多早期采用者观察到，vibe coding 节省的初始时间可能会在项目需要扩展或适应时在代码清理和重构期间丢失。 - 另一个需要警惕的场景是**关键算法或优化**。AI 可以生成排序算法或数据库查询，当然——但如果你需要它高度优化（比如，自定义内存管理例程，或必须在次线性时间运行的算法），你就处于人类独创性和深入理解仍然优越的领域。AI 可能会给你在小数据上工作的东西，但在规模上崩溃，它不一定会警告你。人类性能工程师会从一开始就考虑这些因素进行设计和测试。 - 最后，任何**可解释性和清晰度**是首要任务的情况可能不适合 vibe coding。有时你需要其他人（或审计员）可以轻松阅读和推理的代码。如果 AI 想出了一个复杂的方法，它可能会妨碍清晰度。在 AI 能够可靠地生成简单且结构清晰的代码之前（它并不总是被激励这样做——有时它过于冗长或奇怪地抽象），需要人类的触摸来保持事情简单明了。 总之，_vibe coding 是一个强大的加速器，但不是银弹。_ 在速度比打磨更重要的地方使用它，在你有余地迭代和修复事情的地方使用它**。避免将其用作关键任务软件的一次性解决方案**——这就像雇用赛车手开校车；工作的错误工具。也许有一天 AI 会如此先进，以至于 vibe coding 真的可以成为所有开发的默认选择——但*今天不是那一天*。今天，它最适合作为正确问题的帮手，并有正确的监督。 ## 结论：负责任地 vibe - 拥抱氛围，但尊重工艺 Vibe coding 和一般的 AI 辅助软件开发代表了我们工具的激动人心的飞跃。它**将继续存在**，并且从这里开始只会变得更加复杂。前瞻性的工程团队不应该忽视它——那些有效利用 AI 的人可能会超越那些不这样做的人，就像拥抱早期自动化浪潮和更好框架的团队超越那些从头开始编写所有内容的团队一样。本文的信息*不是*拒绝 vibe coding，而是**以开放的眼光和完整的工程纪律来接近它**。 最大的收获是**没有质量的速度毫无意义**。更快地发布有错误、不可维护的代码是一个虚假的胜利——你只是在加速走向悬崖。最好的工程师会平衡两者：使用 AI 更快地移动*而不*打破东西（至少不会比我们已经打破的更多！）。这是关于找到那个甜蜜点，AI 做繁重的工作，人类确保一切都正确站立。 对于技术负责人和工程经理来说，行动号召很明确：设定 AI 是一个*负责任地*使用的工具的基调。鼓励使用 vibe coding 进行实验，但也建立期望（也许通过我们概述的一些规则）来保护你的代码库。对 AI 生成的贡献进行强制性代码审查，创造一个欢迎询问"嘿，这有意义吗？"的环境，并投资于提升你的团队以有效地*与* AI 一起工作。这甚至可能意味着培训开发者如何编写好的提示或如何批判性地评估 AI 建议。这是一套新的技能，类似于过去向高级语言或分布式版本控制的转变——那些更早适应的人将获得好处。 我们还应该从软件工程中真正重要的事情来看待：解决用户问题、创建可靠的系统和持续学习。Vibe coding 是达到目的的手段，而不是目的本身。如果它帮助我们更好更快地为用户服务，太棒了。但如果它诱使我们跳过用户最终依赖的尽职调查（如质量和安全），那么我们必须控制它。基本原则——清晰的思考、理解需求、为变化而设计、彻底测试——仍然和以往一样重要，如果不是更重要的话。 最后，也许精神应该是：**"快速行动，但不要打破东西——或者如果你打破了，确保你知道如何修复它们。"**利用氛围以光速编码，但用工程卓越的坚实基础支持它。AI 可以与工艺共存；事实上，在工匠手中，它可以是一个强大的凿子。但仍然需要工匠的手来引导那个凿子创造真正持久和精心制作的东西。 所以，开发者们，继续 vibe 吧——只是要小心。拥抱未来，但不要放弃让我们走到这里的原则**。Vibe coding 不是低质量工作的借口**；相反，它是一个机会，可以提升我们*当我们将人类判断与机器生成能力配对时*可以实现的目标。内化这一点的团队不仅会快速行动——他们会构建值得保留的东西。 编码愉快，保持氛围高*和*质量更高。 ![](/images/articles/localized/01-core-concepts/vibe-coding-is-not-an-excuse-for-low-quality-work/03.jpg)