Vibe Coding零基础教程：6分钟用AI开发本地应用

什么是Vibe Coding？

Vibe Coding是一种全新的AI编程方式——你只需要用自然语言描述需求，AI负责全部代码实现。B站UP主「安」通过一个真实案例完整展示了这套流程：用AI开发一个AI工具管理器，支持手动添加工具、搜索工具、一键直达官网下载。整个开发过程基本只使用自然语言与AI沟通，没有手写一行代码。

这种模式的核心逻辑是：你当产品经理，AI当程序员。听起来简单，但实际操作中需要一套清晰的方法论。UP主将全过程拆解为四个阶段——需求整理、环境搭建、方案设计、技术实现，新手掌握这四个阶段就足以开发出自己的本地应用。

第一阶段：需求整理

从痛点出发，让AI帮你定义产品

UP主的痛点很具体：关注了很多AI工具，但每次查看都要打开收藏夹一页一页翻，效率极低。和AI聊了这个问题后，AI建议做一个AI工具管理器，形式为本地网页。

确定方向后，UP主让AI梳理了一份200到300字的需求描述文档。这一步看似简单，但非常关键——清晰的需求文档是后续所有开发环节的基础。需求越明确，AI实现出来的东西越接近你想要的效果。

需求文档 在 AI 辅助开发中扮演的角色，比传统软件开发中更为关键。原因在于你与 AI 之间唯一的沟通渠道就是文字，需求写得越模糊，AI 自行补全的空间就越大，偏离你真实想法的概率也越高。

一份适合喂给 AI 的需求文档通常包含四要素：目标用户是谁、要解决什么具体问题、核心功能有哪些（最好按优先级排序）、明确不需要的功能（避免 AI 自作主张加功能）。篇幅控制在 200 到 300 字最合适——太短信息不足，太长则会让 AI 在细节中迷失重点。文中建议先让 AI 主动提问澄清，再定稿需求，这一步相当于免费做了一次需求评审，能提前暴露你没想到的边界情况。

第二阶段：环境搭建

初始化Git仓库

在合适的路径下新建一个以项目命名的文件夹，把文件夹拖进AI Agent变成一个项目。然后告诉AI将当前项目初始化为一个Git仓库——Git是版本管理器，确保开发成果不丢失、不混乱。

初始化完成后打开项目文件夹似乎没有任何变化，实际上AI已经在后台创建了Git隐藏文件。

Git 是目前最主流的分布式版本控制系统，最初由 Linux 之父 Linus Torvalds 在 2005 年创建。它的核心能力是记录文件的每一次变化，让开发者可以在任意时间点查看历史版本、对比差异、回退到旧状态，或在多个分支上并行开发而互不干扰。

在 Vibe Coding 场景中，Git 的作用被进一步放大：由于代码由 AI 生成，人工审查成本高、出错概率也更高，Git 就成了唯一可靠的"安全网"。每次 AI 完成一个功能就提交一次（Commit），等于给项目打一个存档点；一旦后续迭代把功能改坏，直接回退到上一个可用版本即可，不必从头重写。文中所说的"Git 隐藏文件"指的是 .git 目录，它默认隐藏，存储了所有提交历史和分支信息，删除它等于放弃整个版本历史，因此千万不要手动清理。

创建三个基础文件

将需求发给AI进行对齐，并让AI主动询问它不了解的问题。确认AI对项目的理解无误后，让它创建基础文件。简单项目理论上只需要一个Agent文件，但UP主建议养成好习惯，每次都创建三个文件：

• Agent文件：记录开发规则和注意事项
• Readme文件：记录项目情况
• Gitignore文件：告诉Git哪些内容不需要纳入版本管理，避免推送敏感信息、密钥、缓存等到远程仓库

两条关键规则

UP主特别强调在Agent文件中写入两条规则，这是整个开发流程的安全网：

规则一：每个独立功能完成后，先自行测试和代码自查，确认通过后提交Git Commit。 Git Commit相当于游戏存档，每轮重要开发完成后都自动存档，如果功能失败或不好用，可以随时回退到之前的版本。

规则二：所有开发在独立工作树中完成，经体验验收并允许后才能合并到主版本。 工作树机制是这套流程的精髓——主干保存软件主版本，分支在智能体的隐藏工作树目录下运行。每次开发新功能时，AI会把主版本代码复制一份到隔离的工作树中，独立开发、测试、提交，再交由你审查和体验。这样一来，即使有bug也不会影响主版本运行。

UP主强调这两点非常关键，它们之间的关系可以通过图示理解，暂时不明白可以截图多看几遍。

Git Commit（提交） 是 Git 中最基本的存档单位。一次 Commit 会记录当前所有被跟踪文件的状态，并附带一条说明信息（Commit Message），便于日后检索"这次改了什么、为什么改"。文中所说的"游戏存档"比喻非常贴切：只要 Commit 过，无论后续 AI 怎么改，都能通过 git checkout 或 git reset 回到那个时间点。

工作树（Worktree） 是 Git 2.5 之后引入的一项功能，允许同一个仓库同时检出多个工作目录，每个目录对应不同的分支，互相隔离却共享同一份 .git 历史。这意味着 AI 可以在一个隐藏的工作树目录里随意试验新功能，即使引入严重 bug，主目录里的稳定版本也丝毫不会受影响。只有当你在工作树里实际体验、确认满意后，才需要执行合并（Merge）操作把改动带回主分支。这正是文中"体验验收并允许后才能合并"这条规则的底层支撑。

第三阶段：方案设计

用可交互Demo代替文字方案

传统方案设计都是文字文档，很难直观体验。UP主的做法是要求AI交付一个可交互的demo。发出指令后，AI会读取Readme和Agent两个文件，分别了解做什么和怎么做。AI会自动选择工作树方式去开发demo，也可以手动勾选工作树按钮开发新功能。

对话框上方的小按钮会显示红字和绿字——红字代表减少的代码行数，绿字代表增加的行数。点开可以看到具体修改了哪些文件和代码。

快速迭代分类维度

AI完成demo后，整体交互和页面架构符合预期，但分类方式只有工具功能，缺少工具类型维度。UP主让AI增加分类维度后，成功增加了skill插件、开源项目等分类，与工具功能一一对应。

体验满意后，让AI在工作树中正式开发，确认无误再合并到主版本。

技术栈选择

合并主版本前，UP主先跟AI确定了技术栈。技术栈可以理解成厨具和食材——同一道菜可以用不同组合来做，成本和优势各不相同。本机网页比较简单，UP主选择了HTML/CSS/JavaScript，优势是依赖少。不需要懂技术术语，让AI根据成本、优势等条件推荐即可。确定后让AI输出一份技术方案保存到项目文件夹，再合并demo到主版本。

技术栈（Tech Stack） 指的是开发一个应用时选用的全部技术组合，通常包括前端框架、后端语言、数据库、构建工具和部署环境等。例如做同一个网页，既可以用原生 HTML/CSS/JavaScript，也可以用 React、Vue 或 Svelte，再搭配不同的后端服务。

不同技术栈的差异主要体现在三方面：上手成本（依赖越多、构建配置越复杂，学习曲线越陡）、运行性能（同样功能不同框架的渲染效率可能差数倍）、生态与可维护性（主流框架文档全、社区活跃，遇到问题容易搜到答案）。文中提到的 HTML/CSS/JavaScript 属于最轻量的原生方案，无需安装任何框架依赖，浏览器直接就能跑，非常适合本地自用的小工具。若未来要把这个 AI 工具管理器部署到线上并加数据库，技术栈大概率需要向带后端能力的方案升级，例如 Node.js + SQLite 或类似的轻量组合。

第四阶段：技术实现与迭代

通过截图反馈问题

正式开发完成后通过浏览器查看效果，问题很明显：页面缩得太小像一个卡片。UP主把页面截图发给AI修改，但第一版修改后仍然把整个页面做成了卡片。调整提示词把问题说得更清楚后再改一次，最终效果终于符合要求。

验收与测试

demo合并到主版本后，打开正式版AI工具管理器，尝试添加工具（以CC Switch为例），测试工具下载链接是否正常。成功实现了下载MacOS、Windows和Linux三种版本的跳转。陆续添加多个工具后，管理器的内容逐渐丰富。

核心经验总结

这套Vibe Coding流程之所以能跑通，有几个关键设计值得学习：

Git存档机制保证了每次迭代都可追溯、可回滚，降低了AI开发的试错成本。工作树隔离让新功能开发不影响主版本的稳定性，这是多人协作和持续迭代的基础设施。可交互Demo代替文字方案大幅降低了沟通成本，所见即所得。截图+提示词迭代是修正AI理解偏差的有效手段，关键在于把问题描述得足够具体。

目前这个AI工具管理器部署在本地，个人使用完全够用。如果要和朋友们一起分享，还需要部署到线上并接入数据库——UP主表示后续会单独出一期分享本地工具部署到线上的方法。