用vibe coding方式开发应用或AI智能体，听起来好得不像真的。一名开发者只需通过提示词推进计划，几分钟而不是几天就能得到一个可运行原型的代码。修复和改进通过迭代完成，直到开发者对结果满意为止。根据State of Code开发者调查，48%的受访者已在新项目中采用vibe coding，62%的人认为它有效。但96%的人并不完全相信AI生成的代码在功能上是正确的。

这种担忧是有道理的。《State of AI Versus Human Code Generation》报告显示，AI提交的拉取请求（pull request）中，关键问题的数量是开发者提交的1.4倍，重大问题的数量是1.7倍。SAS杰出软件开发者Brett Smith表示："开发者本来就会写糟糕的代码，而AI帮助他们更快地写出糟糕的代码。谬误在于组织假定AI生成的代码天然正确，而不是让它接受与其他任何版本发布相同的测试、验证和质量标准。"

让AI代码生成接受与传统代码相同的测试可能还不够。有报告指出，目前全球41%的代码由AI生成。为开发者编写代码而部署的代码评审、安全扫描和测试实践，可能无法支撑AI生成代码带来的体量、复杂性和新风险。这些数据并不说明vibe coding不好，但它们确实表明开发者应该放慢速度，避免代价高昂的错误。以下是需要避免的七个坏习惯。

一、绕过需求环节

ThoughtSpot首席数据与AI策略师Sonny Rivera表示："我见过的一个常见错误是，团队欢呼Claude和Codex等助手把想法变成洞察的速度有多快，却忽略了瓶颈已经上移到了产品管理和语义层面。忽视这一转变，你就会得到与期望相反的结果：交付更慢、质量更低。"

vibe coding不应该为那些开发者明知会导致软件风险和开发返工的过时行为大开绿灯。从想法到代码需要基本的产品负责人纪律，包括定义利益相关者、识别用户需求以及制定用户故事验收标准。

如何避免这一错误：许多代码生成和vibe coding工具支持开发者的工作流，却没有提供与利益相关者的正式协作流程。规格驱动开发（spec-driven development）是弥补这一缺口的一种方式。团队可以与AI协作创建产品需求文档和架构工件，进行修改，然后再将其反馈给AI生成代码。

二、轻信AI选择的依赖组件

Sonatype首席产品开发官Mitchell Johnson提醒vibe coder，AI编写的代码只是问题的一部分。"AI越来越多地还在替你决定应用依赖哪些开源组件。如果这些决策不是基于当前情报，而是基于模型几个月前学到的东西，你可能会在不知不觉中建立在过时、被弃维护或有风险的依赖之上。"

企业在标准化软件开发技术栈方面一直举步维艰。久而久之，许多企业最终背负了在不同开发平台和版本间维护应用的技术债，增加了成本，也在扩展应用时制造了复杂性。如果没有明确规格说明vibe coding工具可以使用哪些框架、组件、库及其版本来构建解决方案，这一风险还会被放大。

如何避免这一错误：提供架构要求，指定可用组件目录，并频繁更新这些文档，因为开源和第三方组件的部署可能触发新风险。此外，审查每个vibe coding应用的软件物料清单（SBOM）以及集成的API。

三、事后才补非功能性需求

受监管行业的公司都有围绕安全性、可靠性、审计等非功能性需求的开发标准。即使应用没有具体的性能和可扩展性要求，开发者也会积累经验，对用户期望有一个大致的把握。但如果没有指南，vibe coding工具就会自行做出假设，并采用一种无法扩展的开发策略。

Southworks CTO Johnny Halife表示："编码智能体确实能显著提升你的生产力，但它们在非功能性需求方面很弱。只要跳过设计阶段，任何复杂事物的架构、加固和组件化都会做得很草率。这些部分要在有人参与的情况下完成，把它们锁定下来，然后再让智能体跑起来，因为生产力提升真正存在于这里，而不是在提示'帮我建一个应用'里。"

如何避免这一错误：创建一个分类的非功能性需求库，供开发团队在任何新项目或概念验证中取用。执行这一步骤，确保应用及AI智能体特有的非功能性需求被捕获并与AI编码工具共享。

四、授予过多的数据库访问权限

团队里的新开发者并不总是清楚开发数据库里有什么。一个由生产数据构建、十年前合规的用户注册数据库，可能已不满足今天的数据隐私要求。对开发和测试环境的管控少于生产环境的组织，在让AI代码生成器访问这些环境之前，可能会发现自己需要先解决新的数据治理风险。

Redgate Software集团产品经理Tim Dalton指出："在数据库中使用AI编码工具会带来巨大的数据合规问题，因为开发者忽视了自己的开发和测试环境中存有什么，把未脱敏的生产数据暴露给一个随时可能让这些信息重新浮现的工具。AI生成的测试用例可能把PII（个人身份信息）直接嵌入脚本，最终进入版本控制系统，等审计中发现泄露时，它已经出现了几十次。在把任何AI工具集成到工作流之前，团队需要确保数据已得到妥善脱敏、清理和治理——真正达到可以与AI一起使用的安全标准。"

如何避免这一错误：数据治理团队应创建一个测试清单，在允许AI代码生成器访问任何数据源之前对其进行验证，并定义其数据访问权限。

五、定义功能时没有考虑RBAC

在构建云原生应用时，一个关键错误是在不考虑用户访问需求的情况下开发功能。其中一些应用可能只需要小型重构即可叠加安全要求，而更复杂的场景可能需要重新工程化。对于没有在功能需求中预先定义访问护栏的vibe coding应用来说，成本和风险会成倍放大。

Kong AI专家解决方案工程师Jason Matis表示："陷阱在于，人们在vibe coding的应用中很少添加覆盖安全和权限的所有必要功能。通常只是一个走'快乐路径'（happy path）的开放式构建，这对最小可行产品来说很好，但对生产环境来说很糟糕。当认证、权限和可观测性存在于基础设施而不是应用代码中时，应用是怎么构建的都无所谓——护栏已经就位了。"

如何避免这一错误：为基于角色的访问控制（RBAC）制定标准，并创建可复用的软件组件来管理它们。创建一个按功能记录访问控制的模板，并在vibe coding实现时纳入这些要求。

六、依赖手动测试

根据《World Quality Report》，许多组织的自动化测试覆盖率低于33%。该报告确定了八个质量工程生成式AI用例，如测试用例设计、需求分析和缺陷分析，它们在生产环境的采用率均低于50%。这就提出了一个问题：在激进推行AI代码生成和vibe coding实践的组织中，持续测试是否足够成熟、是否具备足够的规模。

Marker Collective首席产品官Andrew Wyatt表示："团队在vibe coding中犯的一个错误是，仅依靠评审来发现AI出错的地方。更好的模式是把你的工程标准转化为工作流无法跳过的护栏：测试、类型检查、代码检查器（linter）、安全检查、评估（eval）和可观测性要求，在代码被接受之前运行。AI的速度可以快得惊人，但流程应该让那些显而易见的错误难以被发布出去。"

RSI工程总监兼AI卓越中心负责人Harshil Shah表示，新的经验法则是：你的评估套件的增长速度应该快于你的代码库。"不投资自动化评估和回归测试装置的团队，本质上是在发布模型的信心，而不是它的正确性。"

如何避免这一错误：对于那些认为vibe coding能让其绕过管理软件开发生命周期（SDLC）最佳实践的组织来说，手动测试或没有正式的测试实践是重大风险，在测试AI智能体时尤其如此。

七、跳过可观测性

如今的开发者普遍理解在应用、数据运维和AI智能体中构建可观测性的重要性。当使用AI代码生成器和vibe coding时，SDLC的部分环节被自动化，AI代替开发者做出决策。DevOps团队应审查AI代码生成器和vibe coding平台的可观测性能力，以便将结果和代码追溯到AI的决策步骤。

Grafana Labs AI高级总监Mat Ryer表示："vibe coding把SDLC的每个阶段都变成了AI在替你做决策的场所，除非你留意观察，否则你看不到这些决策——比如当一段提示生成了某个函数的初稿时，当一个测试套件的编写速度比人工评审还快时，当流水线说安全、一次部署就这样发出去时。"

EY Global Consulting Delivery Services的EY杰出技术专家兼AI工程负责人Raghuveer Subodha表示，一个常见的错误是通过模糊的提示让AI抓自己的bug，比如让它"修复代码"。"这样提示时，AI会添加大量的异常处理程序，以确保代码能编译和运行，而不是去诊断问题。更好的做法是让AI生成完整的堆栈跟踪，并实现结构化日志，以便识别和解决错误。"

如何避免这一错误：在开发AI智能体时，Ryer建议从头到尾整体对待可观测性，理解AI为什么做出某个决策，审查哪里出了问题，并审查修复方案的各种选项。

还有一个显而易见且重大的错误要避免，那就是在未评估购买选项的情况下就决定自建软件能力。vibe coding让开发应用和AI智能体变得更容易，并不意味着企业拥有该解决方案及其持续维护成本就是好主意。开发者还应考虑"vibe no-coding"（vibe无代码），即AI在SaaS基础设施上生成应用，并利用其平台安全和治理能力。

vibe coding为加速软件开发创造了新机会，但在速度、风险和新复杂性面前跟不上节奏，是DevOps团队承受不起的错误。