Vibe Coding 是一种通过自然语言与 AI 协作完成软件开发的方式。
你负责描述目标、限制条件和验收标准，AI 负责阅读项目、生成代码、修改文件和运行检查，最后由你审查结果并决定下一步。
对于刚接触编程的新手来说，Vibe Coding 降低了开始写代码的门槛；对于有经验的开发者来说，它能够减少重复劳动，把更多时间留给需求分析、架构设计和结果验证。
本文将介绍：
- Vibe Coding 是什么
- Vibe Coding 改变了哪些开发流程
- 常见的 AI 编程工具
- 如何使用 Codex 完成第一个项目
- 如何编写有效的 AI 编程提示词
- 如何审查 AI 生成的代码
- 新手最容易踩的坑
Vibe Coding 是一种以自然语言驱动开发的协作方式。
在这种工作方式中，你不必从编写每一行代码开始，而是先告诉 AI：
- 你想解决什么问题
- 项目需要实现哪些功能
- 有哪些技术限制
- 什么情况才算完成
AI 根据这些信息阅读项目、生成或修改代码，然后由你检查代码差异、运行测试并确认结果。
Vibe Coding 这一说法由 Andrej Karpathy 在 2025 年提出，随后迅速进入开发者的日常讨论。
它最有价值的地方，并不是让人完全离开代码，而是把时间从重复输入转移到以下工作中：
- 判断需求是否合理
- 选择合适的实现方案
- 控制代码改动范围
- 检查生成结果
- 发现异常和安全风险
因此，Vibe Coding 并不等于“随便说一句，让 AI 包办一切”。
项目越真实、功能越复杂，人的判断、审查和验收就越重要。
传统开发通常从语法、API、函数和文件实现开始。
Vibe Coding 则更强调从最终结果开始思考：
- 用户需要完成什么操作
- 项目应该如何运行
- 数据应该如何保存
- 哪些异常情况需要处理
- 什么结果才算真正完成
开发者的工作重点也随之发生变化。
这个函数应该怎么写？
这个 API 应该怎么调用？
这个页面应该拆成几个组件？
这个语法为什么报错？
用户最终要完成什么？
哪些文件允许修改？
项目必须兼容什么环境？
哪些情况属于异常？
应该如何验证功能已经完成？
在 Vibe Coding 工作流中，开发者需要完成的核心任务包括：
- 把模糊想法整理成可执行任务
- 给 AI 提供必要的项目上下文
- 明确技术约束和禁止修改的范围
- 审查 AI 生成的代码差异
- 运行测试并检查异常情况
- 记录有效决策，供后续任务复用
AI 可以帮助你写代码，但不能替你定义什么才是正确结果。
近年的 AI 编程模型已经不再只能生成单个函数。
它们通常能够：
- 阅读多个项目文件
- 理解文件之间的调用关系
- 搜索已有代码
- 创建和修改文件
- 执行终端命令
- 运行测试和语法检查
- 根据报错继续修复问题
与此同时，AI 编辑器和终端编码代理也逐渐成熟。
当代码理解、文件编辑和命令执行三项能力结合后，一次对话就可以覆盖完整开发流程：
阅读项目
↓
理解需求
↓
制定修改方案
↓
生成或修改代码
↓
运行检查
↓
汇报结果
↓
人工审查
这也是 Vibe Coding 能够快速普及的重要原因。
目前常见的 AI 编程工具大致可以分为三类。
适合一边查看代码，一边与 AI 对话。
常见工具包括：
- Cursor
- Windsurf
- Visual Studio Code 中的 AI 编程插件
这类工具通常能够直接展示文件改动，适合需要频繁阅读和修改代码的项目。
适合直接在项目目录中执行完整任务。
常见工具包括：
- OpenAI Codex
- Claude Code
这类工具通常可以：
- 搜索项目文件
- 修改多个文件
- 运行终端命令
- 执行测试
- 根据错误继续迭代
对于已有项目、自动化脚本和后端开发，终端编码代理通常更加灵活。
适合快速生成页面、原型和 MVP。
常见工具包括：
- v0
- Bolt
- Lovable
这类工具上手速度较快，适合验证产品想法，但在复杂业务逻辑、长期维护和代码控制方面，仍然需要人工审查。
第一次尝试时，不必同时安装很多工具。
建议选择一个具备以下能力的工具：
- 可以读取项目文件
- 可以显示代码改动
- 可以运行命令
- 执行重要操作前能够让你确认
- 可以根据报错继续修改
先用一个工具完成小项目，再根据实际体验比较不同工具的差异。
下面使用 Codex 完成一个简单但相对完整的小项目。
这个项目不是只生成一个静态页面，而是创建一个可以实际使用的本地任务看板。
项目需要包含：
- 用户输入
- 状态变化
- 本地数据保存
- 空状态处理
- 移动端适配
- 基本异常检查
如果你还不了解 Codex，或者尚未完成安装和配置，可以先阅读：
完成 Codex 配置后，再继续下面的案例。
先创建一个空目录。
mkdir local-task-board
cd local-task-board然后在该目录中启动 Codex。
不同版本和运行环境的启动方式可能有所不同，请以你当前使用的 Codex 文档和终端提示为准。
将下面的任务描述发送给 Codex：
请创建一个本地任务看板，使用原生 HTML、CSS 和 JavaScript。
目标用户：
需要记录当天任务的个人开发者。
核心功能：
1. 新增任务
2. 标记任务为已完成
3. 删除任务
4. 显示当前未完成任务数量
数据要求：
使用 localStorage 保存任务。
刷新页面后，已经创建的任务仍然存在。
界面要求：
1. 桌面和手机端都能正常使用
2. 没有任务时显示明确的空状态
3. 长任务标题不能覆盖操作按钮
4. 已完成任务需要有清晰的视觉状态
技术约束：
1. 不使用外部框架
2. 不加载第三方 CDN
3. 只创建完成任务所必需的文件
4. 不添加与当前需求无关的功能
验收标准：
1. 启动本地服务后可以完整操作
2. 空白内容不能创建任务
3. 新增、完成和删除任务后，未完成数量正确
4. 刷新页面后数据仍然存在
5. 浏览器控制台没有报错
6. 在 390px 宽度下页面布局正常
开始修改前，请先说明准备创建哪些文件以及实现思路。
完成后，请运行必要检查，并汇报检查结果和手动验证步骤。
这段描述没有规定每一个函数应该怎样实现，但明确给出了项目边界。
它包含了六类关键信息：
| 信息类型 | 内容 |
|---|---|
| 目标用户 | 需要记录当天任务的个人开发者 |
| 核心功能 | 新增、完成、删除和数量统计 |
| 数据要求 | 使用 localStorage 保存 |
| 界面要求 | 桌面端、移动端和空状态 |
| 技术约束 | 不使用框架和第三方 CDN |
| 验收标准 | 功能、刷新、移动端和控制台检查 |
这种写法既给 AI 留出了实现空间，又让最终结果可以被明确判断。
相比之下，下面这种提示词就过于模糊：
帮我做一个好看的任务管理页面。
“好看”没有明确标准，“任务管理”也没有说明具体功能、数据保存方式和验收方法。
AI 完成代码后，不要只看最终页面。
先检查以下内容：
- AI 创建了哪些文件
- AI 修改了哪些代码
- 是否出现了不必要的依赖
- 数据保存逻辑是否合理
- 是否处理了空输入和异常状态
- 是否真正运行了检查命令
建议至少手动验证以下场景。
检查没有任务时：
- 页面是否显示明确提示
- 用户是否知道下一步应该做什么
- 页面是否出现大面积无意义留白
尝试输入：
空字符串
多个空格
换行符
程序应该阻止创建无效任务。
依次执行：
- 新增两个任务
- 完成一个任务
- 删除一个任务
- 取消任务完成状态
检查未完成数量是否始终正确。
创建任务后刷新页面。
确认：
- 任务仍然存在
- 完成状态没有丢失
- 未完成数量正确恢复
将浏览器宽度调整到约 390px，检查：
- 按钮和文字是否重叠
- 长任务标题是否自动换行
- 输入框是否超出屏幕
- 操作按钮是否容易点击
打开浏览器开发者工具，检查 Console 中是否存在：
- JavaScript 报错
- 资源加载失败
- 未处理异常
- 重复事件监听警告
发现问题后，不要只说：
效果不好，继续优化。
这种反馈缺少具体问题，AI 很难判断应该修改什么。
更有效的反馈应该包含：
- 出现问题的环境
- 可以观察到的现象
- 期望结果
- 不能破坏的现有部分
- 修改后的验证方式
例如：
在浏览器宽度为 390px 时，删除按钮会挤压任务标题，
较长的任务内容无法正常换行。
请保持当前视觉风格，不要修改数据结构和 localStorage 逻辑。
将每条任务调整为适合移动端的可换行布局，
确保长标题不会覆盖完成按钮和删除按钮。
修改完成后，请重新检查 390px 和 768px 两种宽度，
并说明具体修改了哪些 CSS 规则。
这种反馈比“再优化一下”更容易得到稳定结果。
一个相对可靠的 Vibe Coding 流程可以分为四个阶段：
描述 → 审查 → 验证 → 交付
首先说明要解决的问题，然后补充：
- 必要功能
- 当前项目背景
- 技术限制
- 禁止修改的内容
- 验收标准
对于已有项目，还应该告诉 AI：
- 应该先阅读哪些文件
- 哪些目录不能修改
- 是否允许安装新依赖
- 是否需要兼容旧版本
- 项目当前有哪些已知问题
例如：
请先阅读 README.md、package.json 和 src/auth 目录，
了解当前登录逻辑后再制定修改方案。
不要修改数据库表结构，不要更换现有 UI 组件库，
也不要调整与登录无关的页面。
明确范围可以减少 AI 对项目其他部分的意外修改。
AI 完成修改后，需要查看代码差异，也就是 Diff。
重点关注：
- 创建了哪些新文件
- 删除了哪些旧代码
- 修改是否超出需求范围
- 数据如何进入程序
- 数据如何被处理
- 数据最终保存到哪里
- 是否增加了新的依赖
- 是否重复实现了已有功能
遇到看不懂的代码，可以直接要求 AI 解释：
请逐段解释这次修改中的数据流。
重点说明：
1. 用户输入从哪里进入
2. 在哪里进行验证
3. 数据在什么位置保存
4. 页面如何根据数据重新渲染
5. 哪些代码负责处理异常
不要在不理解关键逻辑的情况下直接合并代码。
运行项目原有的检查命令，例如：
npm run lint
npm test
npm run build不同项目使用的命令并不相同，应以项目中的 README.md、package.json 或开发文档为准。
除了自动测试，还应该手动走一遍关键流程。
即使项目没有测试，也应该列出最小验收清单：
[ ] 页面可以正常打开
[ ] 核心功能可以完成
[ ] 无效输入会被拒绝
[ ] 刷新后数据状态正确
[ ] 移动端布局正常
[ ] 控制台没有报错
[ ] 原有功能没有被破坏
不要只凭页面“看起来能用”判断任务已经完成。
确认结果后再提交代码。
一次完整交付最好记录：
- 本次任务的目标
- 修改了哪些文件
- 采用了什么实现方案
- 为什么选择这个方案
- 使用了哪些验证命令
- 是否存在尚未解决的问题
例如：
任务目标：
为本地任务看板增加 localStorage 持久化。
主要修改：
- 新增任务序列化和读取逻辑
- 页面加载时恢复历史任务
- 完成和删除操作后同步更新存储
验证方式：
- 手动新增、完成和删除任务
- 刷新页面验证状态恢复
- 检查浏览器控制台
已知限制：
- 当前数据只保存在本地浏览器中
- 不支持多设备同步
这些记录会成为下一次开发任务的重要上下文，通常比临时提示词更有价值。
一个实用的 AI 编程任务描述，通常包含四类信息：
最终要解决什么问题？
为后台增加管理员登录功能。
当前项目使用什么技术？相关代码在哪里？
这是一个现有 PHP 项目，数据库访问统一使用 PDO。
登录相关页面位于 admin 目录。
哪些内容不能修改？必须兼容什么？
不引入新框架，不修改数据库表结构，
复用现有页面样式和数据库连接。
如何判断任务已经完成？
完成后运行 PHP 语法检查，
并列出登录成功、密码错误和未登录访问后台的验证步骤。
“帮我做登录功能”很难验收。
更清楚的写法是：
请在现有 PHP 项目中增加管理员登录功能。
开始前：
1. 先阅读现有数据库连接代码
2. 查看 admin 目录中的页面结构
3. 说明准备修改哪些文件
4. 不要立即修改代码，先给出实现方案
功能要求：
1. 管理员可以使用用户名和密码登录
2. 登录成功后进入后台首页
3. 未登录用户不能直接访问后台页面
4. 用户可以主动退出登录
5. 密码错误时显示通用错误信息
技术要求：
1. 复用现有 PDO 数据库连接
2. 不引入新框架
3. 密码使用 password_hash 和 password_verify
4. 登录成功后重新生成 Session ID
5. 数据库查询必须使用预处理语句
6. 连续登录失败需要限制请求频率
7. 不在日志中记录明文密码
验收标准：
1. 正确用户名和密码可以登录
2. 错误密码不能登录
3. 未登录访问后台时会跳转到登录页
4. 退出后不能继续访问后台
5. 运行 PHP 语法检查没有报错
6. 列出完整的手动验证步骤
不要修改与登录功能无关的页面。
完成后请汇报修改文件、检查命令和剩余风险。
具体不等于堆砌术语。
只写与结果有关的信息，通常比一段很长却没有验收条件的提示词更加有效。
即使项目可以正常运行，也需要快速检查关键风险。
检查用户输入是否经过验证。
需要注意：
- 是否接受空值
- 是否限制长度
- 是否验证数据类型
- 是否过滤非法格式
- 是否在服务端再次验证
前端验证只能改善用户体验，不能替代服务端验证。
将用户输入显示到页面时，需要根据输出环境进行转义。
否则可能引入跨站脚本攻击等安全问题。
检查数据库查询是否使用：
- 预处理语句
- 参数绑定
- 明确的字段列表
不要把用户输入直接拼接到 SQL 中。
权限检查不能只存在于前端界面。
隐藏按钮并不代表用户无法直接访问对应接口或后台地址。
真正的权限判断必须在服务端执行。
检查以下内容是否被写入代码、日志或 Git 仓库：
- API 密钥
- 数据库密码
- 访问令牌
- 私钥
- 用户隐私数据
- 生产环境配置
敏感信息应该通过环境变量或专门的密钥管理工具提供。
错误信息不应向普通用户泄露：
- 数据库结构
- 服务器绝对路径
- 内部接口地址
- 调用栈
- 密钥内容
- 调试信息
详细错误可以记录在安全的服务端日志中，但不应直接展示在页面上。
检查新改动是否破坏：
- 已有页面
- 原有接口
- 移动端布局
- 数据格式
- 构建流程
- 部署配置
AI 有时会顺便进行“大规模重构”。
需要检查是否产生：
- 不必要的依赖
- 重复代码
- 多余文件
- 未使用变量
- 与需求无关的格式化
- 超出任务范围的架构调整
一次任务的改动范围越小，通常越容易审查和回滚。
以下任务可以使用 AI 辅助，但不适合在无人审查的情况下自动完成：
- 支付系统
- 身份认证
- 权限管理
- 用户隐私数据处理
- 医疗数据处理
- 金融交易逻辑
- 生产数据库迁移
- 密钥和证书管理
- 高并发核心服务
- 高安全要求系统
这些场景不仅需要代码可以运行，还涉及安全、合规、数据完整性和业务风险。
最终结果必须由具备相关经验的人进行确认。
需求越多，隐藏依赖越多，定位错误就越困难。
不要一开始就要求 AI 同时完成：
用户系统
支付系统
管理后台
消息通知
数据分析
自动部署
更好的方式是把项目拆成独立闭环：
先完成任务新增
↓
再增加本地保存
↓
再增加编辑和删除
↓
再补充测试
↓
最后考虑部署
每次只增加一个可以独立验证的功能。
页面能够打开，并不代表以下内容正确：
- 数据处理
- 权限检查
- 错误分支
- 安全验证
- 数据持久化
- 移动端布局
养成查看 Diff 的习惯，至少理解关键函数和数据流。
不要在提示词中粘贴：
- 真实 API 密钥
- 数据库密码
- 生产环境令牌
- 用户个人数据
- 私钥文件
- 完整生产配置
应该使用占位值：
API_KEY=your_api_key_here
DATABASE_PASSWORD=your_database_password_here同时确认敏感文件已经加入 .gitignore。
.env
.env.local
*.pem
*.key当代码运行失败时，不要反复发送：
还是不行。
继续修复。
怎么又报错了？
应该提供可复现信息：
执行 npm run build 后失败。
完整报错：
粘贴错误信息
触发步骤：
1. 安装依赖
2. 执行 npm run build
3. 构建在处理 src/app.js 时失败
预期行为：
项目应该可以正常构建。
已经尝试：
1. 删除 node_modules 后重新安装
2. 检查 Node.js 版本
3. 重新执行构建
请先分析根本原因，再说明准备修改哪些文件。
可复现的信息越完整，AI 排查问题就越有效。
如果没有明确边界，AI 可能会修改大量无关文件。
建议提前说明：
只允许修改 src/task.js 和 src/task.css。
不要修改数据库结构、构建配置和其他页面。
如确实需要修改其他文件，请先说明原因。
“做完”“优化一下”“更加专业”都很难判断。
更有效的验收标准应该是可观察、可操作或可执行的：
在 390px 宽度下没有横向滚动条。
执行 npm test 后所有测试通过。
连续刷新页面三次后，任务数据仍然存在。
Vibe Coding 尤其适合结果容易验证、实现模式比较明确的工作。
例如：
- 产品概念页面
- 内部演示系统
- 简单交互原型
- 市场验证工具
例如：
- 新增数据
- 查询数据
- 编辑数据
- 删除数据
- 表格筛选
- 分页和搜索
例如：
- 登录页面
- 表单组件
- 数据卡片
- 响应式布局
- 弹窗和提示组件
例如：
- CSV 清洗
- 文件批量重命名
- 数据格式转换
- 日志统计
- 报表生成
例如：
- 批量处理文件
- 自动生成文档
- 定时整理数据
- 重复命令封装
- 开发环境初始化
例如：
- 补充单元测试
- 生成接口文档
- 解释遗留代码
- 整理 README
- 编写部署步骤
复杂算法、底层性能优化和高安全要求系统也可以使用 AI 辅助，但需要更严格的验证。
例如：
- 分布式系统
- 编译器和数据库内核
- 密码学实现
- 实时交易系统
- 大规模并发服务
- 复杂机器学习训练流程
- 对延迟高度敏感的程序
这些任务通常需要：
- 性能基准测试
- 压力测试
- 安全审查
- 架构评审
- 专业代码审查
- 线上监控和回滚方案
AI 可以提高实现效率，但不能替代专业判断。
学习 Vibe Coding 最有效的方法，不是收集更多工具名单，也不是寻找所谓的“万能提示词”。
真正有效的方法是完成一次完整闭环：
写清需求
↓
让 AI 阅读和修改项目
↓
查看代码 Diff
↓
运行检查和测试
↓
手动验证关键流程
↓
根据结果继续迭代
↓
记录最终决策
你可以从一个很小的项目开始，例如：
- 待办事项页面
- 记账工具
- Markdown 转换脚本
- 文件整理工具
- 简单数据看板
- 个人导航页
重点不是项目有多复杂，而是你是否完整经历了：
- 描述
- 修改
- 审查
- 验证
- 交付
Vibe Coding 降低了编写代码的起步门槛，但没有降低对结果负责的要求。
真正重要的能力，不只是会不会写提示词，而是能否：
- 说清楚目标
- 提供必要上下文
- 控制修改范围
- 设置明确验收标准
- 看懂关键代码
- 发现异常和安全风险
- 使用测试证明结果正确
当你能够稳定完成这些工作时，AI 才会从一个代码生成器，逐渐变成可靠的开发协作者。
不要一开始就要求 AI 构建一个完整产品。
从一个能够独立验证的小功能开始，完成你的第一个 Vibe Coding 闭环。