vibe coding 旨在尽可能通过 AI 完成代码，是一种以人工智能为核心的编程范式，开发者通过自然语言向 AI 描述意图，由 AI 生成可执行代码。期间我们会遇到以下痛点：

1，没有将自己的想法清楚的告诉 AI，AI 生成的项目很可能会杂乱无章，导致后续维护和学习困难，甚至根本跑不起来。 2，同时 vibe coding 期间可能遇到很多自己不熟悉的技术。因为自己不熟悉该语言，编译过程中出现什么问题，必须要 AI 解决，如果给出模糊的问题描述或者在一开始生成了错误的代码，AI 很可能处理不了问题，导致编程时间大大提高

因此为了增加效率，我总结出来了 vibe coding 的最佳实践

vibe coding 方案选型

本人由于财力不足，所选的方案永远是免费优先，性价比高其次

1，AI 原生 IDE：以 Cursor、Trae 为代表，它们重新设计了编辑器，将 AI 深度集成到开发的每一个环节。这类工具支持跨多文件编辑，你可以用自然语言一次性修改整个页面的样式。推荐 Trae，免费版本也可以有不错的体验，模型优先选择 GLM 高版本，国际版可选用 Claude、GPT。缺点是如果是比较新的模型，使用免费版需要排队

2，智能终端助手：代表是 Claude Code、Gemini CLI、CodeX。这类工具将 AI 能力注入终端，特别适合处理大型、复杂的代码库。你可以在终端里直接通过对话让它完成整个全栈重构任务。它的优势在于处理复杂任务的深度和连贯性，无需离开终端环境。性价比选型方案为 Claude + GLM 4.7

3，VS Code 智能插件：如果你不想更换 IDE，Continue、Roo Code、Kilo Code 等插件是不错的选择。不过它们的功能相对较弱，不支持跨文件编辑，也不支持自然语言描述

除去 AI 编程选型，平时的聊天模型也推荐 GLM，比起 deepseek、kimi 等模型，GLM 使用起来更加优秀，如果能翻墙推荐 GPT。多模态模型推荐豆包，如果能翻墙推荐 Gemini。搜索模型推荐 GLM 的深度研究和秘塔

vibe coding 最佳实践

PRD

在让 AI 生成任何代码之前，规划是至关重要的一步。许多新手常犯的错误是直接给出一个含糊的提示，然后期望 AI 一次性构建出完整应用。这种做法往往导致生成的内容与预期不符，甚至需要反复重来。为了避免这种情况，开发者需要在编码前投入时间进行需求分析和技术方案设计，将模糊的想法转化为清晰的蓝图

编写产品需求文档（PRD）：在编写任何提示前，先撰写一份产品需求文档（PRD）。PRD 应详细记录应用的核心功能、用户流程、数据模型、界面布局、技术选型等关键信息。例如，明确应用有哪些页面、每个页面的功能，以及后端将采用何种框架和数据库等。这份 PRD 将成为后续所有提示的源真相（Source of Truth），确保 AI 在每个阶段都有明确的上下文和目标。以下是 prompt：

你是一个专业的产品经理，你负责根据用户的需求，编写产品需求文档（PRD）。PRD 应详细记录应用的设计目标、核心功能、用户流程、界面布局等关键信息。你所编写的 PRD 为后续的开发和测试提供了清晰的方向和参考，需求文档会用于后续的代码生成。因此需要逻辑清晰避免歧义。

用户的需求如下：
xxxx

PRD 的投入看似增加前期工作量，实则是最高效的步骤之一。它将原本抽象的需求细化为具体可执行的任务，避免了在开发过程中因为需求不清晰而反复修改。正如实践所示，编写 PRD 能够将“模棱两可的请求转变为结构化、可预测的 AI 输出”

技术方案

AI 生成代码前，需要给出技术方案、技术选型、选型版本

在规划阶段，开发者应与 AI 协作确定技术方案，包括前端框架、后端语言、数据库等选型，并在技术方案中予以记录。明确的技术选型有助于 AI 在后续编码时有据可依，避免在实现过程中随意更换技术栈导致的混乱。

你是一个专业的系统架构师，接下来你将和我——你的同事一起负责根据用户的需求文档，编写技术方案，包括确定技术选型、选型版本、架构设计等。你所编写的技术方案为后续的开发和测试提供了清晰的方向和参考，技术方案会用于后续的代码生成。

现在请根据用户的需求文档，编写技术方案，技术方案需要保存到 技术方案.md 文件中，方案需要包含以下内容：

1，技术选型：根据用户需求，确定前端框架（如 React、Vue）、后端语言（如 Node.js、Python）、数据库（如 MySQL、MongoDB）等技术选型。每个选型都应包括版本号，防止后续生成代码时出现版本不一致的问题。
2，架构设计：根据用户需求，设计应用的架构。包括前端架构（如组件化、状态管理）、后端架构（如微服务、RESTful API）等。架构设计应考虑可扩展性、可维护性和性能。
3，数据库设计：根据用户需求，设计数据库模型。包括表结构、索引、约束等。数据库设计应考虑数据一致性、完整性和性能。
4，接口设计：根据用户需求，设计 API 接口。包括请求方法（如 GET、POST）、请求参数、响应格式等。接口设计应考虑可扩展性、可维护性和性能。
5，如果按照上述方案设计，我们需要什么样子的项目结构，每个文件和文件夹有什么用都需要说明，方便后续维护

代码生成

你是一个专业的全栈开发工程师，你负责根据用户的需求文档和技术方案，编写全栈应用的代码。你所编写的代码需要符合最佳实践，包括代码质量、可维护性、可扩展性等。请注意，你的代码需要：

1，代码需要详细注释，方便后续维护和学习
2，严格按照技术方案设计，不允许随意更换技术栈

现在请生成代码

结构化编码

分步实施与验证：将整个项目拆解为一系列小步骤，逐步实现。切忌一次性让 AI 生成整个应用。一种行之有效的做法是按照前端、后端、数据库、认证等模块依次推进。例如，先让 AI 生成前端页面，验证界面和交互无误后，再继续生成后端逻辑，然后是数据库连接，接着是用户认证，最后是支付集成等。每完成一个步骤，都立即验证其正确性，然后再进行下一步。避免一次性给出巨量提示。

AI 并非全能，一次性处理过多任务容易出错或产生混乱。将大任务拆分为小任务，不仅降低了每次生成的难度，也使开发者能够掌控每个环节。例如，与其提示“构建一个包含用户注册、登录、博客发布和评论功能的全栈应用”，不如拆分为“先实现用户注册和登录功能”，完成后端接口和前端页面并测试通过后，再提示“增加博客发布功能”，依此类推。这样，每一步的上下文都清晰且相关，AI 更容易产出符合预期的代码。

每步验证：及时纠错，防止返工。验证是结构化编码中不可或缺的一环。每完成一个模块或功能，开发者都应亲自运行和测试生成的代码，检查功能是否符合预期、代码是否干净、数据模型是否合理、是否存在安全隐患等。这种及时验证能够尽早发现并修正问题，避免在错误的基础上叠加新的代码层。如果等到项目后期才发现早期架构或逻辑有误，可能需要推翻重来，浪费大量时间和资源。因此，宁可多花时间在早期验证，也不要贪图进度而忽视问题的累积。