原文链接：Vibe Coding is not an excuse for low-quality work，2025.04.18, by Addy Osmani。
“加速前进，破坏更多事物。”
这个对硅谷旧口号的改编在"氛围编程"（vibe coding）进入讨论时，正在工程界引发回响。是的，AI 辅助开发正在改变我们构建软件的方式，但这并不能成为放弃严谨性、代码审查或工艺水平的借口。 "氛围编程"不能成为低质量工作的挡箭牌。
让我们先肯定其优势：AI 辅助编码_确实_可能成为变革者。它降低了门槛，让新程序员和非程序员只需描述需求就能生成可用软件。某一方面 AI 辅助工具释放了创造力——更多人可以通过定制软件解决问题，这种趋势被称作个人软件的解绑（使用小型 AI 工具替代通用应用），即使资深工程师也能从中获益。
但正如任何经验丰富的工程师所言：如果半路掉轮子，速度毫无意义。这里正是表象与现实的分水岭——在构建可维护、健壮软件时，"氛围"与"现实"之间的差距开始显现。
残酷现实：质量不会自动生成
尽管炒作不断，氛围编程仍受到资深开发者的诸多质疑。核心批评在于：AI能快速吐出代码，并不意味着这些代码质量合格。事实上，全盘接受 AI 输出可能非常危险。那句玩笑式的抱怨_"两个工程师现在能制造 50 人的技术债务"_包含着真实成分。未经审查的 AI 代码会指数级放大技术债务——那些让软件脆弱且维护成本高昂的隐患。
许多早期氛围编程项目表面光鲜（"能跑就上线！"），实则暗藏雷区：缺乏错误处理、性能低下、可疑的安全实践、逻辑脆弱的代码。可以说这类项目建立在流沙之上。我使用过“纸牌屋代码” 这个术语——指"看似完整却在现实压力下崩塌"的代码。如果你见过初级开发者的首个大型功能模块：_看似_可用，却在意外输入下崩溃，就能理解这个比喻。AI 能快速生成大量代码，但数量≠质量。
这些风险绝非理论假设。以可维护性为例：如果 AI 编写的模块晦涩复杂，谁来维护？如果连原作者都不完全理解 AI 的解决方案，未来修改将成为噩梦。安全性是另一大隐患——AI 可能生成_看似_可用实则存在 SQL 注入漏洞或不安全错误处理的代码。未经严格审查，这些都可能溜进生产环境。还存在提示过拟合风险：AI 会严格按指令行事，而指令可能并非真实需求。人类编码者常在实施过程中调整设计，发现错误假设，而 AI 不会察觉这些偏差——除非人类介入修正。
这并非否定AI能写出优秀代码（有时确实可以），而是强调需要上下文、审查和专业判断来区分优劣。2025 年的我们，本质上在使用一个热情但缺乏经验的助手。正如你不会让应届生独立设计整个系统，也不应盲目信任 AI 代码。"AI魔法"的炒作需要与软件工程原则的现实接轨。
那么如何取得平衡？关键在于不要全盘否定氛围编程——它_确实_极具价值——而是以规范方式整合。工程师应将AI视为_已知局限的工具_，而非神秘代码精灵。实践中，这意味着保持人类介入，坚守质量标准。让我们具体探讨实施方式。
AI 作为实习生，而非替代者（保持人类监督）
有效使用氛围编程需要转变思维：将 AI 视为团队中速度惊人但资历尚浅的开发者。换言之，你——高级工程师或团队负责人——仍需对结果负责。AI 可能产出初稿代码，但你必须严格审查、优化并验证其质量。
成功整合 AI 的资深开发者会自然遵循以下模式。当AI助手建议代码时，他们不会直接点击"接受"：
- 逐行理解AI 所写内容，如同审查新人代码
- 重构为清晰模块（AI 输出常呈现臃肿结构）
- 补充边缘情况处理（空值检查、输入验证等）
- 强化类型与接口（将隐式假设转为显式契约）
- 质疑架构选择（是否采用低效方案？是否引入不必要全局状态？）
- 编写测试（或至少手动验证）——如同审查同事的 PR
通过这种方式，你将_工程智慧_注入 AI 生成的代码。这种组合威力强大：AI 快速产出大量代码，你的监督确保其可靠性。研究表明，资深开发者从 AI 工具中获益更多，因为他们具备引导 AI 和修正错误的知识储备。
由此得出关键原则：永远不要未经审查就合并 AI 代码。将其视为新人代码：逐行检查，确保完全理解。遇到困惑处，切勿假设AI更高明——通常并非如此。可通过优化提示要求澄清，或自行重写。在团队中，开发者应准备好在代码审查中解释AI生成的代码。"能用就行"的说辞无效——团队需要确信代码具备可理解性和可维护性。
另一最佳实践：保持人类主导设计决策。用 AI 实施，而非决定基础架构。例如，可用氛围编程快速创建基于现有模式的 CRUD REST API（明确定义的工作），但不应让 AI "设计可扩展微服务架构"后盲目遵循。高层设计和关键决策应由人类主导，AI 仅处理繁琐部分。本质上，让 AI 处理_苦力活_，而非_脑力活_。
沟通与文档同样至关重要。若使用 AI 生成重要算法或陌生库代码，请记录选择该方案的原因（如同自行研发后所做）。未来维护者（或未来的你）不应猜测 AI 代码的意图。有些团队甚至会记录重要代码的生成提示，有效留存"对话"轨迹。这在调试时很有帮助：可以看到赋予 AI 的初始假设。
总之，人类监督不是"锦上添花"——而是必备条件。一旦移除人类监督，就是在用软件质量玩俄罗斯轮盘赌。在 AI 真正具备资深工程师的全局理解力之前（我们尚未到达），氛围编程必须是合作关系：AI 加速，人类验证。
高质量氛围编程守则（实用指南）
我们将讨论提炼为可操作的团队守则，视作新的_"快速前进但不破坏一切"_手册——在享受编码氛围时确保质量的护栏。
- 守则1：永远审查 AI 代码——无例外。所有 AI 代码都应视为初级工程师所写。进行个人或同行审查（涵盖 Copilot/ChatGPT 等各类 AI 工具）。没时间审查？那就没时间使用。盲目合并等于自找麻烦。
- 守则2：建立并遵守编码标准——AI 会模仿训练数据中的各类代码（良莠不齐）。定义团队的风格指南、架构模式和最佳实践，确保 AI 代码重构合规。例如规定"所有函数需 JSDoc 注释和单元测试"，则 AI 输出必须添加这些内容。若项目采用分层架构，禁止 AI 在 UI 代码中插入临时数据库调用——修正以适配架构层。可创建静态分析检查项来捕捉常见 AI 错误（如标记过时 API 使用或过度复杂函数），自动化控制 AI 贡献的质量。
- 守则3：用 AI 加速，而非自动驾驶——实际应用时，用氛围编程加速明确任务，而非代替思考。适用场景：生成模板、搭建组件、语言转换、根据伪代码草拟简单算法。风险场景：在最小指导下让 AI 从头设计模块，或生成你不熟悉领域的代码（将无法判断正误）。若计划保留代码，请退出氛围模式——转入工程模式进行加固。
- 守则4：测试！测试！测试！——AI 不保证正确性。为 AI 代码的关键路径编写测试。AI 生成的测试可能遗漏边界情况（或因相同错误逻辑虚假通过），需辅以手动测试（特别是面向用户的功能）：点击 UI、尝试非常规输入、观察行为。许多氛围编程应用在"理想路径"表现正常，却因意外输入崩溃——务必在用户发现前捕获。
- 守则5：迭代优化——不要接受不满意的初稿。氛围编程是迭代对话。若初始输出笨拙，可要求 AI 改进（"简化代码"、"拆分为小函数"等），或自行重构。推荐**循环使用 **AI：获取实现→识别弱点→提示修正/手动调整→重复。
- 守则6：懂得拒绝——有时氛围编程并非合适工具。负责任的使用包括识别需要手动编码或深度设计的场景。例如关键安全模块可能需要谨慎设计，仅用小部分 AI 辅助；若 AI 持续产出复杂方案解决简单问题，应及时手动编码——最终可能更省时。重要是避免过度依赖 AI 解决所有问题。别让"AI 做的"成为不理解代码的借口。若多次尝试未果，请接管控制权用传统方式编码——至少能获得完整理解。
- 守则7：记录与知识共享——确保 AI 代码与手写代码同等（或更）详细地记录。如有非明显决策或可能引发困惑处，添加注释。团队讨论时，明确哪些是AI生成。这有助于审查者特别关注相关部分。
遵循这些守则，团队可在享受氛围编程效率红利的同时控制风险。视其为增强而非替代人类开发者。目标是与 AI 协同创作：让 AI 高速处理重复性工作，人类负责创造性与批判性思考。
氛围编程的适用场景（及其局限）
认清氛围编程的优劣战场同样重要。并非所有项目/任务都同样适合 AI 驱动的工作流。根据行业讨论和早期经验总结：
优势场景：
- _快速原型开发_是氛围编程的甜蜜点。用 AI 助手快速搭建原型或概念验证极其高效（此时可接受临时方案）。许多工程师在周末项目中纯用 AI 编码成功验证概念。一次性脚本/内部工具（如日志解析脚本、个人自动化小工具、团队内部仪表盘）也适用——低风险场景无需生产级完美，氛围编程可节省时间。
- 适用于学习探索。在新语言/API 中使用 AI 生成示例可加速学习（需要对照官方文档验证！）。探索模式下，即使 AI 代码不完美，也提供可调整的学习材料。如同配备可展示尝试方案的教学助理。
- AI 擅长结构化/模板化任务。如创建 10 个相似数据类，或实现固定 CRUD 层。只要模式清晰，AI 可高效处理这类机械重复工作（需验证模式遵循正确性）。
劣势场景：
- _企业级软件/复杂系统_中氛围编程常遇挫。需要深刻业务理解、高并发、严格安全/合规性的领域不可全权托付AI。例如支付类金融科技应用或航天控制系统需满足现行 AI 无法保证的标准。这些领域可局部使用 AI 辅助，但最终产品必须依赖人类专业知识和严格 QA。
- 不擅长长期可维护性。需多人协作多年的代码库，若以 AI 代码拼凑开局将埋下隐患。缺乏强指导会导致架构混乱。通常更好的选择是前期投入构建清晰框架（可用 AI 辅助），而非通过连续提示拼凑产品。许多先行者发现，氛围编程节省的初期时间会在后期代码清理/重构时加倍偿还。
- 关键算法/优化需谨慎。AI 可生成排序算法或数据库查询，但如需高度优化（如定制内存管理例程或亚线性时间复杂度算法），仍需人类的才智和深刻理解。AI 可能给出小数据有效、大规模崩溃的方案且不予警示，而人类性能工程师会从开始就考虑这些因素。
- 可解释性/清晰度优先的场景可能不适用。当需要他人（或审计方）易读易推理的代码时，若 AI 产出复杂方案可能损害清晰度。在AI能稳定产出简洁结构化代码前（当前常有过冗或奇怪抽象），需人类介入保持简洁。
总之，氛围编程是强力加速器，而非万能药。
在速度重于打磨、有迭代修正余地的场景使用。避免将其作为关键任务软件的终极方案——如同用赛车手驾驶校车：工具错配。或许未来 AI 足够先进时，氛围编程能成为默认方案——但_今日尚未到来_。当前，它最适合作为正确问题的助手，配合适当监督。
结论：负责任地"氛围"——拥抱趋势，坚守工艺
氛围编程及 AI 辅助开发整体代表着工具的飞跃。它将长期存在并持续进化。前瞻性工程团队不应忽视——善用 AI 者将超越拒用者，正如早期采用自动化框架的团队超越手工编码者。本文主旨并非否定氛围编程，而是主张在保持工程纪律的前提下开放接纳。
核心启示：没有质量的速度毫无意义。更快交付漏洞百出、难以维护的代码是虚假胜利——只是在加速冲向悬崖。优秀工程师会平衡二者：用 AI 提速却_不_增加破坏（至少不比现有程度更糟！）。关键在于找到 AI 承担重活、人类确保稳固的甜蜜点。
技术主管与工程经理的当务之急是：确立 AI 作为_负责任工具_的基调。鼓励氛围编程实验，同时建立保障代码库的预期（可通过前述守则）。对 AI 贡献实施强制代码审查，创建"这合理吗？"的安全提问环境，投资团队 AI 协作技能提升（包括提示编写和批判性评估训练）。这是类似转向高级语言或分布式版本控制的新技能——早适应者早获益。
我们还需牢记软件工程的核心：解决用户问题、创建可靠系统、持续学习。氛围编程是手段而非目的。若有助于更好更快服务用户，善莫大焉。但若诱使我们跳过用户依赖的质量安全审查，就必须约束。基础要素——清晰思维、理解需求、为变化设计、彻底测试——始终至关重要，甚至更甚。
最终，我们的信条应是："快速前进，但不破坏事物——若破坏，确保知道如何修复。" 借助氛围极速编码，同时以工程卓越夯实基础。AI 可与工艺共存——在工匠手中，它是强大的凿子，但仍然需要工匠之手的引导，才能创造真正持久优质的产物。
朋友们，请谨慎前行。拥抱未来，勿忘立身之本。氛围编程不是降低工作质量的借口，而是_人机协同_提升成就的机遇。领悟此道的团队不仅能快速前进——更能建造值得留存的事物。
