通过一个花园跟踪器应用实例手把手教会您使用Vibe Code

• Vibe 编码让任何人都能通过与人工智能对话来构建功能齐全的应用程序，但 48% 的人工智能生成的代码都存在安全漏洞。
• 教我奶奶开发一个花园追踪应用程序的经历，恰恰展现了 Vibe 编码的优势和劣势。
• 2025 TEA 应用程序的安全漏洞暴露了在缺乏安全审查的情况下快速开发应用程序，这些应用程序虽然功能强大，却隐藏着诸多漏洞。
• 你可以快速构建原型，但要让它们达到生产就绪状态则需要专业知识。

现在，我建立了一个框架，帮助你理解“Vibe 编码”的实际效果与它所承诺的有何不同，这样你就能透过营销噱头，真正地使用这款产品。

首先，什么是“Vibe编码”？

“Vibe 编码”是指用简单的英语描述你的需求，然后让AI为你编写代码。

特斯拉前AI总监、OpenAI联合创始人安德烈·卡帕西（Andrej Karpathy）于2025年2月创造了“vibe coding”这个术语。他在推特上写道：“有一种我称之为‘Vibe 编码’的新型编码方式，在这种方式中，你完全沉浸于感觉之中，拥抱指数级增长，甚至忘记代码的存在。”

这篇文章迅速获得了超过 500 万的浏览量，捕捉到了一种已经在科技界迅速传播的开发方法。

你无需学习编程语言，也无需费力钻研语法，只需告诉人工智能你想构建什么。人工智能会生成代码。你不再是程序员，而是产品经理，专注于应用程序应该做什么，而不是如何实现它。

为什么Vibe Coding现在如此重要？

据麦肯锡公司称，87% 的公司面临人才短缺，或预计在未来几年内将面临人才短缺。

Bolt.new、Lovable、Replit Agent 和 Cursor 等人工智能编码工具承诺通过提高现有开发人员的效率，并允许非开发人员快速测试他们的想法，来解决这个问题。

数据也印证了这种说法：

• 2025 年 3 月，Y Combinator 公布，在其 2025 年冬季孵化项目中，25% 的公司 95% 的代码库都是由人工智能生成的。
• 2025 年 4 月，微软 CEO 萨蒂亚·纳德拉透露，其代码库中有 20% 到 30% 是由人工智能编写的。
• YC 创业公司当前孵化的创业者中，有四分之一的代码库几乎完全由人工智能生成。
• 谷歌 CEO 桑达尔·皮查伊也公布了类似的数据，称谷歌超过 25% 的代码是由人工智能生成的。

我们已经从基本的自动补全功能发展到只需极少的人工干预即可编写完整的应用程序。

但是，正是这些让 Vibe Coding 易于使用的特性，例如自然语言输入、自动代码生成和自动复杂度处理，在应用程序需要扩展到第一个版本之后时，却会带来严重的问题。

Vibe Coding 究竟能构建什么？

何时才能真正使用 Vibe 编码进行开发取决于三件事：

• 你的应用需要有多复杂
• 你是否能够发现糟糕的代码和安全漏洞
• 你是否知道何时停止添加功能

如果你的应用需求很简单，并且你能识别技术差距并抵制不必要的功能添加，那么Vibe编码可以帮助你快速交付功能性成果。

然而，随着复杂性的增加，或者当你需要构建生产级应用时，专业的代码审查和架构规划就变得必不可少了。

第一小时发生了什么？简单的指令奏效了

目前至少有十几个 AI Vibe 编码平台，例如 Bolt、Lovable、OpenAI Code、Claude Code、Google Opal 等等。

我们一开始使用的是 VS Code 中的 OpenAI Codex 扩展，因为我已经订阅了，但我建议从 Bolt.new、Lovable 或 Vercel 开始，以获得更直观的Vibe编码体验。

我们的第一个任务是：“Build a garden tracking app where I can record what I planted, when I planted it, and how much I harvested. Include a way to see which plants performed best each season.”

这个提示之所以有效，是因为它包含了三个关键要素：

• 清晰的数据结构（植物名称、种植日期、收获量、季节）
• 明确的输出（按季节进行性能比较）
• 具体的用例背景（个人花园跟踪）

几分钟之内，Codex 就生成了一个完整的应用程序。它包含一个 SQLite 数据库，其中包含植物、种植和收获的表；用于 CRUD 操作的 REST API 端点；一个包含数据表和输入表单的 Python 前端；以及基本的 CSS 样式。

它甚至还默认包含一些演示数据。

这个网页应用看起来不错。这就是“氛围编码”的强大之处，也是它最大的隐患。但在深入探讨之前，让我先解释一下 Codex 背后的设计思路。我试用了这个应用，弄清楚了我们现有的功能以及还需要哪些功能。

界面背后的故事

生成的代码为单用户应用做出了架构决策。数据库模式可以轻松处理新条目。API 遵循 RESTful 规范。前端组件在逻辑上是分离的。

然而，我注意到它默认情况下并未考虑关键的安全因素。它没有输入验证、没有身份验证层、没有速率限制、没有考虑 SQL 注入漏洞，也没有加密。

人工智能代理的架构假定用户是受信任的，且处于受控环境中。

考虑到这只是我奶奶的项目，没有其他人参与，这些疏漏的风险尚可控制。但是，对于任何考虑使用 Vibe Code 构建多用户 Web 应用程序的人来说，这些都是不容忽视的关键安全风险。

我经常在 Reddit 或 PostStatus 上看到相关的讨论：开发者之所以能够成功地迭代 AI 生成的代码，是因为他们发现了这些漏洞并实现了适当的安全层。非技术用户看到一个可以运行的应用程序，就想当然地认为它已经可以投入生产环境了。

第二个小时发生了什么？功能蔓延变得显而易见

应用程序运行正常，这一突破性的时刻帮助你建立了信心。我们开始思考如何改进。这时，Vibe Code 的局限性就显露出来了。

我们尝试了一项功能请求：“Add the ability to upload photos of each plant so I can see what they looked like at different growth stages.”

这个看似简单的请求引发了一系列架构上的复杂性。

需要修改的数据库模式和应用模块：

• 新增照片表，包含以下列：id、plant_id（外键）、photo_url、upload_date、growth_stage
• 植物与照片之间的关系定义（一对多）
• 现有数据的迁移策略

后端需要修改：

• 支持多部分表单处理的文件上传端点
• 文件存储方案（本地文件系统 vs. 云存储）
• 用于照片 CRUD 操作的新 API 端点
• 更新现有植物端点以包含照片数据

前端需要修改：

• 支持拖放的文件输入组件
• 图像预览功能
• 每个植物的照片库显示
• 更新现有植物卡片以显示缩略图
• 上传进度的加载状态

OpenAI Codex 尝试同时实现所有这些功能。最新的 GPT5-Codex-High 模型在收到请求后约 5 分钟内就完成了这项工作。

问题在于它生成了漏洞百出且不安全的代码。以下是出现的问题：

• 原始植物表结构发生了变化
• 引用旧架构的前端组件停止工作
• 新的照片组件与现有 UI 之间出现了 CSS 冲突（如屏幕截图所示）

此外，还存在过度设计的问题：Codex 生成了一个复杂的系统，其中包含不必要的图像处理和每张照片的数据采集等。

每次修复尝试都会引入新的问题。更新数据库架构，导致 API 崩溃；修复 API，导致前端崩溃；解决前端问题，又会发现新的后端 bug。原本只需 200 行代码就能完美运行的代码库，现在却扩展到了 1500 行，并且存在相互关联的依赖关系。

不可扩展架构的陷阱

该应用程序的架构仅针对我们最初一小时内提出的需求进行了优化。使用 Vibe 编码时，你必须非常具体，而这对于非开发人员来说正是难点所在。

如果人工智能实现了可扩展架构，你根本无法理解它的含义。

如果你已经开发了一个简单的应用程序，之后需要对其进行扩展，那么采用非可扩展架构就意味着你需要为人工智能从头开始重写代码。

最初一小时的架构假设：

• 单表设计（适用于简单数据）
• 直接 API 查询数据库（读取密集型操作速度快）
• 内联组件定义（适用于小型用户界面）
• 业务逻辑和数据访问没有分离（适用于简单的 CRUD 操作）

这些假设为何变成了限制：

• 单表设计无法对照片进行正确的关联数据建模
• 当模式发生变化时，直接查询需要完全重写
• 内联组件意味着更改会波及整个代码库
• 没有业务逻辑层意味着每个功能都直接访问数据库

我们已经错过了最佳时机。代码量太大，无法放弃。每次尝试修复都会消耗更多代币，试图挽救一个无法支持新需求的架构。

第三小时发生了什么？代码耗尽，勉强能用的代码出现了

照片上传功能实现后，我们尝试进行其他改进。

• “Add categories for plant types (vegetables, herbs, flowers)”
• “Show planting recommendations based on season”
• “Let me mark plants as favorites”

每个请求都遵循相同的模式：Codex 试图对一些看似简单的请求进行彻底的实现，引入了破坏性更改，创建了过度设计的解决方案，并消耗了数千个令牌来尝试修复由此产生的错误。

这款应用运行良好，对结果也很满意。

不过，作为一名开发者，我清楚地意识到，就代码而言，我们已经接近尾声了。再添加几个功能，这款应用就会变得一团糟。

为什么这是一个如此普遍的问题？

编码代理本质上是大型语言模型，它们被“提示”输出代码。

因此，它们也存在所有常规大型语言模型都会遇到的问题，包括：

• 不清楚预期结果是什么
• 随意调用函数（产生幻觉）
• 为简单的目标编写复杂的代码

此外，随着聊天记录的增长，编码代理会达到其上下文窗口的限制。

• 最初的架构决策及其原理
• 后续修改及其相互依赖关系
• 当前存在的错误及其根本原因
• 新功能的预期功能

每个新的提示都被孤立地解读，而没有完全理解架构历史。人工智能提出的解决方案对于单个功能来说似乎合理，但当与现有代码集成时，就会产生系统性冲突。

这篇 Reddit 指南强调：“When the chat gets very big, just open a new one. The AI context window is limited. If the chat is very big, it will forget everything earlier, forget any patterns and design, and start producing bad outputs.”

但开启新的聊天意味着丢失所有关于现有内容的上下文信息。提供这些上下文信息需要消耗令牌。即使是“总结”上下文，在代码层面上，我们仍然会遗漏一些重要的细节。

我们曾在较小规模下遇到过TEA应用的问题

TEA 应用在生产规模上展现了这种故障模式。该应用于 2023 年作为女性安全平台推出，用户数量迅速增长至 160 万。

随后，在 2025 年 7 月，该应用遭遇了灾难性的故障：

• 安全漏洞：安全研究人员发现了一个未受保护的 Firebase 存储桶，其中包含 72,000 张用户图片，包括 13,000 张验证自拍和政府颁发的身份证件。另一个数据库泄露了 110 万条私人消息。
• 技术缺陷：API 密钥硬编码在源代码中，Firebase 存储桶无需身份验证即可公开访问，没有运行时保护措施，也没有安全审查层。专家将这些漏洞归咎于“快节奏”的编码实践，在这种实践中，功能开发速度凌驾于安全架构之上。
• 结果：一位匿名 4chan 用户发现并分享了下载工具。48 小时内就出现了集体诉讼。该平台被迫关闭。平均每次数据泄露造成的损失高达 488 万美元。

TEA 的失败模式与我们之前在如此小的规模上遇到的情况如出一辙，这让我不禁思考，为什么人们不去验证 AI 生成的代码。

我们最初的实现运行良好；然而，功能的添加使架构变得复杂，新功能的安全考量被忽视，系统漏洞在不知不觉中暴露出来，容易被利用。

如何编写出流畅的代码，避免重蹈覆辙

如果你不是开发人员，完全避免这些问题是不可能的。但是，有一些方法可以最大限度地减少问题。

1. 坚持极简主义

在编写第一个提示之前，定义绝对最小的功能集，但始终要抵制在初始开发阶段添加功能的诱惑。

有效的范围界定框架：

1. 列出所有所需功能
2. 确定 3-5 个能够验证核心假设的功能
3. 在第一版中仅构建这些功能
4. 发布、验证并迭代

不要给出类似“Build me this whole feature”这样的指令。人工智能会胡乱猜测，生成糟糕的代码。将任何功能分解为至少 3-5 个顺序请求。

如果您无法确定最小功能集，请使用大多数人工智能编码工具中提供的“Plan mode”或“Chat mode”。

这使您能够用自然语言告诉智能体您的需求，并让 AI 计算出如何将应用程序拆分成各个功能或文件。

2. 每个可用功能完成后提交到Git

对于非开发人员来说，版本控制听起来可能很复杂，但它是必不可少的。Git 是一种版本控制工具，它会在新增功能破坏现有功能时创建还原点。

Vibe 编码的 Git 工作流程：

1. 在第一个提示之前初始化存储库
2. 在初始可用版本完成后提交
3. 为每个新增功能创建一个新分支
4. 在功能开发期间频繁提交
5. 在合并到主分支之前进行全面测试

如果您不熟悉 Git 命令，可以告诉您选择的编码智能体为您执行这些操作。

3. 在初始提示中设计可扩展性

您的第一个提示定义了代码库。简单的提示只会提供一个可用的应用程序，直到您开始要求添加新功能。

相反，从一开始就要求构建一个可扩展的架构。

• 无效的初始提示：“Build a garden tracking app where I can record what I planted and harvested.”
• 有效的初始提示：“Build a garden tracking app with an extensible database schema that can accommodate future features. Use a modular architecture where frontend components, API endpoints, and database access are separated. Include clear documentation of schema and API structure for future modifications.”

虽然这会增加初始阶段的令牌使用量，但当您开始添加新功能时，AI 无需浪费令牌来重构旧代码以适应请求。

4. 基于架构稳定性选择工具

• Bolt.new、Replit 代理和 Lovable：非常适合单会话原型和轻松部署。不适合多会话功能添加。架构会随着每次修改而变得越来越脆弱。
• Claude/OpenAI/Gemini 编码代理：有时对复杂的编码很有用，但与我们之前看到的可视化 Web 应用相比，它们可能感觉更复杂。
• Liftoff：非常适合作为 WordPress 的基础架构，拥有成熟的扩展模式。WordPress 架构的设计初衷就是为了方便修改和插件添加。它从一个经过实战检验的可扩展基础架构入手，解决了架构不可扩展的问题。

5. 从一开始就落实安全措施

与可扩展性类似，您需要在第一个提示中就集成安全措施。因此，除了要求构建可扩展的模块化架构之外，您还需要在初始提示中添加安全优先的组件。

以下是我在第一个提示中添加安全措施的示例：“Build a garden tracking app with bcrypt password hashing, input validation on all fields, parameterized SQL queries to prevent injection attacks, rate limiting on all API endpoints, and secrets stored in environment variables never exposed to frontend code.”

如果您正在构建面向客户端的应用程序，请记住以下几点：

• 永远不要信任客户端数据——在服务器端进行验证和清理
• 将密钥保存在环境变量中
• 验证每个操作的权限
• 使用通用错误消息——详细日志仅供开发人员使用
• 实施所有权检查以防止未经授权的数据访问
• 使用速率限制保护 API

6. 知道何时应该重新开始，何时应该继续

识别继续开发会浪费代币的迹象。

以下情况需要重新开始：

• 代币消耗超过 30 万且功能未正常使用
• 每次修复 bug 都会引入两个新 bug
• 架构修改破坏了多个现有功能
• 聊天记录超过 30 次交易
• 无法解释当前代码库架构

以下情况可以继续：

• 新功能与现有代码无缝集成
• bug 修复解决问题且无副作用
• 代币消耗保持在预算范围内
• 架构仍然清晰易懂

当 AI 出错并走错方向时，返回、更改提示并重新发送远比继续编写这段糟糕的代码要好得多。

7. 使用AI进行安全分析

构建核心功能后，将整个代码库复制到 Gemini 2.5 Pro 进行全面的安全分析。我之所以推荐这种语言模型，是因为它拥有两百万个代币的超大上下文窗口，可以将整个代码库迁移过去。

安全审查提示：“Act as a security expert. Analyze this complete codebase for vulnerabilities. Identify SQL injection risks, XSS vulnerabilities, authentication weaknesses, authorization flaws, credential exposure, and any OWASP Top 10 issues. Provide specific code locations and remediation recommendations.”

这可以以极低的成本实现接近专业安全审查的效果。

虽然它不足以用于生产环境部署，但它可以在原型交付给用户之前识别出灾难性缺陷。

何时Vibe编码才能真正发挥商业价值？

即使 Vibe 编码目前还无法创建复杂的应用程序，也不必完全放弃它。以下几个例子说明了 Vibe 编码的原型或应用程序在哪些情况下真正具有意义。

• 快速概念验证：在数小时内构建原型以测试市场兴趣。平均验证成本从 15,000 美元到 100,000 美元以上降至 500 美元以下。使用 Vibe 编码来回答：“客户是否足够需要它？”
• 内部流程自动化：为您的团队提供工具，您可以控制访问权限并接受更高的风险承受能力，因为影响范围有限。内部工具可以迭代优化安全性，而不是从一开始就要求具备安全性。
• 开发前规范：在聘请开发人员之前了解需求，以减少代价高昂的沟通不畅。Vibe 编码的原型可以作为交互式需求文档。
• 用于融资的 MVP：向投资者展示功能，同时保持技术成熟度的透明性。许多初创公司使用基于氛围设计的最小可行产品 (MVP) 来获得种子资金，然后再组建专业团队进行完善的重建。

当专业发展成为不可或缺的一部分

任何处理用户数据的面向客户的应用程序都需要专业的安全审查。安全实施不当的成本远超快速编码所节省的费用。

以下情况需要专业审查：

• 多用户身份验证
• 支付处理
• 个人信息存储
• 面向公众的部署
• 涉及合规性要求的情况（例如 GDPR、CCPA、HIPAA）

微软 CEO 透露，该公司 30% 的代码现在由 AI 生成。谷歌也公布了类似的数据。两家公司都维持着完善的安全审查流程、自动化测试和人工监督。

无论代码生成方法如何，生产部署都需要类似的安全保障措施。

了解 AI 是否会取代开发人员，有助于您设定合理的预期，明确哪些功能可以安全地独立构建和部署。探索最佳的在线学习资源，学习代码，弥合快速编码原型和生产就绪系统之间的差距。

关于Vibe编码的常见问题

什么是 Vibe 编码？它与传统编程有何不同？

Vibe 编码是指通过向人工智能 (AI) 描述需求（使用简单的英语），由 AI 生成代码来构建应用程序的过程。与需要掌握编程语言知识的传统编程不同，Vibe 编码将重点放在产品管理和意图上，而不是手动编写代码。

非开发人员可以使用 Vibe 编码构建可用于生产环境的应用程序吗？

虽然 Vibe 编码可以让非开发人员快速构建功能性应用程序原型，但大多数 AI 生成的代码缺乏生产部署所需的安全性和健壮性。尽管如此，Vibe 编码的原型非常适合概念验证。

使用 AI 生成的代码进行应用程序开发的最大风险是什么？

最主要的风险包括安全漏洞（例如缺少验证、身份验证、速率限制和 SQL 注入防护）、架构不可扩展以及功能蔓延导致系统脆弱或崩溃。TEA 应用程序泄露事件就是一个缺乏适当安全审查的快速开发案例，最终导致了灾难性的后果。

何时才适合在实际商业项目中使用 Vibe 编码？

Vibe编码非常适合快速原型开发、内部工具、开发前期规范（需求收集）以及用于融资的MVP。但是，对于面向客户的应用程序或处理敏感数据的应用程序，务必投资于专业开发和安全审查。

小结

本次示例项目是维护着一个简化的花园追踪器，供个人使用。其中还添加了功能分析（以前导航栏按钮的位置并不固定），以便查看花园的生长情况。

这可以作为单用户应用程序使用。如果您正在构建一个供多用户使用的平台，您仍然可以创建 Vibe 编码的原型、MVP 等，以启动项目。但是，如果仅仅依赖 Vibe 编码而不了解其工作原理，那就只是在重蹈TEA应用程序的覆辙。

Vibe 编码使软件创建更加普及，同时也引入了新的责任。您可以在 30 分钟内构建应用程序。然而，在向用户发布产品之前，您必须了解架构限制、安全隐患和令牌消耗模式。

未来属于那些了解原型与量产之间差距的开发者。