一、什么是 Vibe Coding？

Vibe Coding，直译可以叫“氛围式编程”或“感觉式编程”。

它不是传统意义上的“我一行一行写代码”，而是：

你把想做的功能、页面、业务流程，用自然语言告诉 AI，然后让 AI 帮你生成代码、修改代码、运行测试、修复报错，最后逐步做出一个可用系统。

这个词最早由 Andrej Karpathy 在 2025 年提出并带火，后来随着 OpenAI Codex、Claude Code、GitHub Copilot Agent Mode 等工具发展，逐渐成为 AI 编程领域的热门说法。OpenAI 官方介绍 Codex 时，也明确提到它可以帮开发者写功能、回答代码库问题、修 Bug、提交 PR。 GitHub Copilot 的 Agent Mode 也强调可以分析代码、提出修改、运行测试并验证结果。

通俗点说：

以前是人写代码，AI 补代码。
现在是人定方向，AI 写代码，人来验收。

---

二、为什么 Vibe Coding 会突然火起来？

1、AI 不再只是“代码补全工具”

早期 AI 编程工具主要是补全几行代码，比如写一个方法、补一个 if 判断、生成一个 SQL。

现在不一样了。

新一代 AI Coding Agent 可以：

一、读取整个项目结构。
二、理解多个文件之间的关系。
三、根据需求修改多个文件。
四、运行命令和测试。
五、根据报错继续修复。
六、生成提交说明甚至 Pull Request。

VS Code 对 Copilot Agent Mode 的介绍中就提到，它可以像“自主协作程序员”一样执行多步骤任务，包括读文件、改文件、运行终端命令、看测试输出并循环修正。

所以 Vibe Coding 火起来，本质原因是：

AI 从“帮你补几行代码”，升级成了“帮你完成一段开发任务”。

---

三、Vibe Coding 适合什么场景？

1、适合快速做原型

比如你想做一个：

一、后台管理系统。
二、AI 聊天页面。
三、数据看板。
四、文件上传工具。
五、个人博客。
六、营销活动页面。
七、RAG 知识库 Demo。
八、微信小程序页面。

这些东西最适合 Vibe Coding。

因为它们的特点是：

需求相对明确、页面可视化强、业务逻辑不算特别复杂、可以快速迭代。

你可以直接对 AI 说：

帮我做一个后台管理页面，左侧是菜单，右侧是用户列表，支持搜索、分页、新增、编辑、删除，风格简洁一点。

AI 就能给你生成一版基础代码。

2、适合已有项目的小功能开发

比如：

一、增加一个导出 Excel 按钮。
二、给接口增加参数校验。
三、修复一个前端样式问题。
四、补充单元测试。
五、优化接口返回结构。
六、增加日志埋点。
七、补充异常处理。

这类任务边界清晰，非常适合交给 AI。

3、适合代码解释和项目理解

很多时候，开发最痛苦的不是写代码，而是看懂老项目。

Vibe Coding 可以帮你：

一、解释某个模块是干什么的。
二、梳理接口调用链路。
三、找出某个字段在哪里赋值。
四、总结某个类的核心逻辑。
五、分析为什么会报错。
六、生成项目结构说明。

这对接手老系统非常有帮助。

---

四、Vibe Coding 不适合什么场景？

1、不适合完全不审查就上线

这是最重要的一点。

Vibe Coding 不是“AI 写完就直接上线”。

AI 可能会：

一、写出能跑但不优雅的代码。
二、漏掉异常场景。
三、引入安全风险。
四、误改其他逻辑。
五、生成过度复杂的实现。
六、使用不符合团队规范的代码。
七、编造不存在的接口或依赖。

所以 Vibe Coding 的正确姿势不是“闭眼让 AI 干活”，而是：

AI 负责加速，人负责判断。

2、不适合高风险核心系统直接放手

例如：

一、支付系统。
二、资金清结算系统。
三、风控系统。
四、医疗诊断系统。
五、权限认证系统。
六、核心交易链路。

这些系统可以用 AI 辅助，但不能让 AI 完全自主修改后直接上线。

原因很简单：

这些系统错一次，代价太高。

---

五、Vibe Coding 的核心工作流

真正好用的 Vibe Coding，一般不是一句话让 AI 直接做完整系统，而是分阶段推进。

1、第一步：先讲清楚目标

不要上来就说：

帮我做一个系统。

这太模糊。

应该说：

我要做一个活动管理系统，主要给运营人员使用。核心功能包括活动列表、新建活动、编辑活动、查看活动数据。前端用 Vue3，后端用 Spring Boot，数据库用 MySQL。先帮我设计整体模块和接口。

这就清楚多了。

2、第二步：让 AI 先出方案，不要马上写代码

正确方式是：

先不要写代码，先帮我拆分功能模块、页面结构、接口设计、数据库表设计。

这样做有两个好处：

一、避免 AI 一上来乱写。
二、你可以先审查设计是否合理。

Vibe Coding 最忌讳的就是：

需求没想清楚，代码先生成一大堆。

3、第三步：小步快跑，一次只做一个模块

不要让 AI 一次生成整个项目。

最好这样拆：

一、先生成数据库表。
二、再生成后端实体类。
三、再生成 Mapper / Repository。
四、再生成 Service。
五、再生成 Controller。
六、再生成前端页面。
七、最后联调接口。

每一步都检查。

这样 AI 出错时，问题范围比较小，容易修。

4、第四步：让 AI 自己解释代码

代码生成后，不要直接用。

你可以继续问：

解释一下你刚才生成的代码，每个文件分别负责什么？有没有潜在问题？

这样可以逼 AI 自查一遍。

有时候它会自己发现：

一、接口缺少校验。
二、字段命名不统一。
三、异常处理不完整。
四、分页逻辑不严谨。
五、返回结构不规范。

5、第五步：运行、报错、回贴给 AI

Vibe Coding 最常见的场景是：

AI 生成代码 → 你运行 → 报错 → 把错误贴给 AI → AI 修复。

比如：

启动报错如下，请根据错误原因修改代码，不要改无关文件。

这样 AI 会根据具体报错修复。

注意，一定要加一句：

不要改无关文件。

否则 AI 可能会“顺手”改一堆东西。

---

六、Vibe Coding 的提示词怎么写？

1、基础提示词模板

可以这样写：

你现在是一个资深软件工程师，请帮我完成下面任务。

【项目背景】
这是一个后台管理系统，给运营人员使用。

【技术栈】
前端：Vue3 + Element Plus
后端：Spring Boot + MyBatis Plus
数据库：MySQL

【任务目标】
实现活动列表功能。

【功能要求】
1、支持分页查询
2、支持按活动名称搜索
3、支持按状态筛选
4、列表字段包括：活动ID、活动名称、状态、创建时间、更新时间
5、接口返回统一 Result 格式

【要求】
1、先给出实现思路
2、再给出需要修改或新增的文件
3、最后生成代码
4、不要修改无关逻辑
5、代码要有必要注释

这个模板非常实用。

2、修 Bug 提示词模板

下面是项目运行时报错信息，请帮我分析原因并给出修改方案。

【报错信息】
粘贴错误日志

【要求】
1、先判断根因
2、说明涉及哪些文件
3、只修改必要代码
4、不要重构无关模块
5、给出修改后的完整代码片段

3、代码优化提示词模板

请帮我优化下面这段代码。

【优化目标】
1、提高可读性
2、减少重复代码
3、补充异常处理
4、保持原有功能不变

【要求】
1、先说明当前代码的问题
2、再给出优化方案
3、最后输出优化后的代码

4、接口设计提示词模板

请帮我设计一个用户管理模块的接口。

【功能】
1、新增用户
2、编辑用户
3、删除用户
4、分页查询用户
5、启用/禁用用户

【要求】
1、给出接口路径
2、给出请求参数
3、给出返回结构
4、说明每个接口的作用
5、接口风格保持 RESTful

---

七、Vibe Coding 应该怎么落地？

1、先选工具

常见工具包括：

一、Cursor。
二、GitHub Copilot。
三、Claude Code。
四、OpenAI Codex。
五、通义灵码。
六、Trae。
七、Windsurf。

OpenAI Codex 定位是 AI Coding Agent，可以在云端沙箱里处理任务，包括写功能、修 Bug、回答代码库问题、提交 PR。 GitHub Copilot 也已经把 Agent Mode 作为重要能力，强调可以分析代码、提出编辑并验证文件。

2、再定规范

Vibe Coding 要想稳定，必须有规范。

至少要准备：

一、代码风格规范。
二、接口返回规范。
三、异常处理规范。
四、日志打印规范。
五、数据库命名规范。
六、分支提交规范。
七、测试规范。

你可以在项目根目录放一个 AI_RULES.md 或 CONTRIBUTING.md。

里面写清楚：

1、后端使用 Spring Boot
2、接口返回统一使用 Result<T>
3、Controller 不写业务逻辑
4、Service 负责业务编排
5、Mapper 只负责数据库访问
6、异常统一抛 BusinessException
7、日志使用 slf4j
8、不要随意引入新依赖
9、不要修改无关文件
10、生成代码后必须说明修改点

这样 AI 生成代码时更容易遵守项目习惯。

3、再做任务拆分

不要这样提需求：

做一个完整电商系统。

应该拆成：

一、商品管理。
二、分类管理。
三、购物车。
四、订单创建。
五、订单支付。
六、订单查询。
七、库存扣减。
八、后台管理。

每个模块再拆成小任务。

Vibe Coding 的核心技巧是：

需求越小，AI 越准；需求越大，AI 越容易跑偏。

4、最后接入验证流程

AI 写完代码后，必须经过：

一、本地启动。
二、接口测试。
三、单元测试。
四、代码 Review。
五、安全检查。
六、灰度发布。

不要让 AI 直接决定上线。

---

八、一个完整案例：用 Vibe Coding 做活动管理系统

1、需求描述

我们要做一个活动管理系统，功能包括：

一、活动列表。
二、新建活动。
三、编辑活动。
四、删除活动。
五、活动状态管理。
六、活动数据查看。

2、第一轮提示词：让 AI 设计方案

我要做一个活动管理系统，给运营人员使用。

技术栈：
前端 Vue3 + Element Plus
后端 Spring Boot + MyBatis Plus
数据库 MySQL

功能：
1、活动列表
2、新建活动
3、编辑活动
4、删除活动
5、启用/停用活动
6、查看活动数据

请先不要写代码，先帮我设计：
1、功能模块
2、数据库表
3、后端接口
4、前端页面
5、开发顺序

3、第二轮提示词：生成数据库表

根据刚才的设计，先生成 MySQL 建表语句。

要求：
1、表名使用 t_activity
2、字段包括 id、activity_name、activity_type、status、start_time、end_time、creator、create_time、update_time、deleted
3、id 使用 bigint
4、deleted 用于逻辑删除
5、给出字段注释

4、第三轮提示词：生成后端接口

请基于 t_activity 表生成 Spring Boot 后端代码。

要求：
1、使用 MyBatis Plus
2、包含 Entity、Mapper、Service、ServiceImpl、Controller
3、支持分页查询、新增、编辑、删除、启用、停用
4、接口返回统一 Result<T>
5、Controller 不写复杂业务逻辑
6、不要引入不必要依赖

5、第四轮提示词：生成前端页面

请生成 Vue3 + Element Plus 活动管理页面。

要求：
1、顶部是搜索区
2、中间是表格
3、底部是分页
4、支持新增、编辑、删除、启用、停用
5、使用弹窗表单
6、接口地址和后端保持一致

6、第五轮提示词：联调和修 Bug

前端调用接口时报 404，下面是请求地址和后端 Controller 代码，请帮我检查路径是否一致，并给出修改方案。

这就是一个典型的 Vibe Coding 流程。

不是一次性“许愿”，而是：

设计 → 生成 → 运行 → 报错 → 修复 → 验收。

---

九、Vibe Coding 的关键能力

1、会描述需求

Vibe Coding 时代，最重要的不是“会不会敲代码”，而是“能不能把需求讲清楚”。

差的描述：

做个登录。

好的描述：

做一个登录接口，用户输入手机号和密码，后端校验用户是否存在、密码是否正确、账号是否被禁用。登录成功后返回 token、用户ID、用户名、角色列表。失败时返回明确错误信息。接口返回统一 Result 格式。

2、会拆任务

AI 不怕小任务，怕大而空的任务。

你越会拆，AI 越好用。

比如“做一个知识库系统”，可以拆成：

一、文件上传。
二、文件解析。
三、文本切片。
四、向量化。
五、向量入库。
六、问题检索。
七、上下文组装。
八、大模型回答。
九、回答引用来源。
十、日志记录。

这样 AI 才能一步步完成。

3、会验收结果

Vibe Coding 不是“让 AI 替你负责”，而是“让 AI 替你干活”。

最终质量还是要人来把关。

要重点检查：

一、代码能不能跑。
二、接口是否符合预期。
三、异常有没有处理。
四、权限有没有控制。
五、数据是否安全。
六、有没有误删误改。
七、性能是否可接受。

---

十、Vibe Coding 常见坑

1、需求太模糊

你说：

做一个好看的页面。

AI 不知道什么叫“好看”。

你应该说：

做一个偏企业后台风格的页面，整体简洁，白色背景，左侧菜单，右侧卡片布局，主色调蓝色，按钮圆角，不要太花哨。

2、一次性让 AI 改太多

比如：

帮我重构整个系统。

这很危险。

AI 可能会改坏很多地方。

应该改成：

只重构用户查询逻辑，不要修改新增、编辑、删除功能。

3、不看代码直接复制

这是大忌。

AI 生成的代码必须看。

尤其要看：

一、SQL 是否安全。
二、接口是否暴露敏感信息。
三、是否硬编码密钥。
四、是否引入奇怪依赖。
五、是否吞掉异常。
六、是否破坏原有逻辑。

4、不写约束

如果你不告诉 AI 规则，它就会自由发挥。

所以提示词里一定要写：

一、不要修改无关文件。
二、不要引入新依赖。
三、保持原有接口兼容。
四、先说明方案再写代码。
五、代码要能直接运行。

---

十一、Vibe Coding 和传统开发有什么区别？

1、传统开发

传统开发流程是：

一、人理解需求。
二、人设计方案。
三、人写代码。
四、人调试。
五、人测试。
六、人上线。

2、Vibe Coding

Vibe Coding 流程变成：

一、人描述目标。
二、AI 生成方案。
三、人审查方案。
四、AI 生成代码。
五、人运行验证。
六、AI 修复问题。
七、人最终验收。

所以它不是完全替代开发，而是改变开发分工。

人从“代码生产者”，变成“需求定义者、方案审查者、质量把关者”。

---

十二、普通人能不能用 Vibe Coding？

可以，但要分层。

1、完全不会代码的人

可以用 Vibe Coding 做：

一、简单网页。
二、个人工具。
三、数据表单。
四、自动化脚本。
五、小程序原型。

但不建议直接做复杂商业系统。

因为你可能看不懂 AI 生成的风险。

2、懂一点代码的人

这是最适合 Vibe Coding 的人群。

因为你能：

一、看懂基本代码。
二、知道哪里报错。
三、能判断 AI 是否跑偏。
四、能做简单修改。

3、专业开发者

专业开发者用 Vibe Coding，效率提升会更明显。

因为他们知道：

一、怎么拆任务。
二、怎么写约束。
三、怎么做 Review。
四、怎么做测试。
五、怎么控制风险。

---

十三、企业团队怎么用 Vibe Coding？

1、建立 AI 开发规范

团队必须明确：

一、哪些代码可以让 AI 写。
二、哪些代码必须人工审查。
三、哪些模块禁止 AI 自动修改。
四、AI 生成代码如何提交。
五、AI 生成代码如何测试。

2、建立代码审查机制

AI 生成的代码也要走 Review。

不能因为是 AI 写的就跳过流程。

尤其是：

一、权限逻辑。
二、资金逻辑。
三、数据删除逻辑。
四、用户隐私数据。
五、第三方接口调用。

必须严格检查。

3、建立测试兜底

Vibe Coding 要想稳定，测试必须跟上。

包括：

一、单元测试。
二、接口测试。
三、回归测试。
四、异常测试。
五、权限测试。
六、性能测试。

没有测试，AI 写得越快，风险越大。

---

十四、Vibe Coding 的正确心态

1、不要神化 AI

AI 很强，但不是万能。

它能帮你写代码，但不一定理解真实业务。

它能生成页面，但不一定知道用户真正想怎么用。

它能修 Bug，但可能修出另一个 Bug。

2、不要排斥 AI

也不要觉得“AI 写代码不专业”。

现在主流工具都在向 Agent 化发展，OpenAI、GitHub、Anthropic 都在推动 AI Coding Agent。GitHub 还在 2025 年推出面向 Copilot 的 coding agent，并强调它集成在 GitHub 工作流中。

趋势已经很明显：

未来开发不是不用 AI，而是看谁更会指挥 AI。

3、把 AI 当成初级开发搭档

比较合理的定位是：

AI 像一个速度很快、知识面很广、但需要你明确指令和认真 Review 的开发助手。

你不能完全放手，但也没必要什么都自己写。

---

十五、Vibe Coding 最佳实践清单

1、每次只提一个明确任务

不要一次做太多。

2、先要方案，再要代码

先设计，后实现。

3、明确技术栈

比如 Java、Spring Boot、Vue3、React、MySQL、Redis。

4、明确代码规范

告诉 AI 使用什么返回格式、异常格式、命名规范。

5、限制修改范围

让 AI 只改相关文件。

6、要求解释修改点

每次生成代码后，让 AI 说明改了什么。

7、保留 Git 版本

每次 AI 修改前先提交一版，方便回滚。

8、必须运行测试

不要只看代码，要跑起来。

9、重要模块人工 Review

尤其是权限、资金、安全、数据删除。

10、把常用提示词沉淀下来

形成自己的 AI 开发提示词库。

---

十六、总结

Vibe Coding 的本质不是“不会代码也能随便做软件”，而是：

用自然语言驱动 AI，把开发过程从手写代码，升级为描述需求、拆解任务、审查方案、验证结果。

它最适合快速原型、小功能开发、代码解释、Bug 修复、页面搭建和自动化工具开发。

但它也有明显边界：

AI 可以帮你提速，不能替你负责。

真正靠谱的 Vibe Coding，一定不是“随便说一句让 AI 全做”，而是：

一、需求讲清楚。
二、任务拆得小。
三、规则写明白。
四、代码要审查。
五、测试要跑通。
六、上线要谨慎。

未来的软件开发，拼的不只是“谁代码写得快”，而是：

谁更会定义问题，谁更会指挥 AI，谁更能把 AI 生成的东西变成可靠产品。