vibe coding 怎么用：十步从一句话走到上线

先选工具

怎么开始：5 步

1. 选一个很小的项目
2. 用一句话描述目标
3. 让 AI 拆成功能清单
4. 先做最小版本（MVP）
5. 运行、反馈、继续迭代

适合： 个人小工具、表单/管理系统、网页/落地页、内容整理工具、MVP 原型验证。
不适合一开始就上： 大型综合 App、高安全系统（金融/医疗）、高并发生产后端、问题本身都说不清的项目。

第一句可以这样说：

我想做一个待办管理工具，支持新增任务、分类标签、状态管理和简单统计。先帮我拆成功能清单，并做一个最小可用版本。

术语： 自然语言 · 意图 · 迭代 · MVP · 原型

先填 7 个字段

1. 用户是谁
2. 解决什么问题
3. 核心流程是什么
4. 输入是什么
5. 输出是什么
6. 什么算完成
7. 本版不做什么

最小需求模板同一套字段：用户 / 问题 / 核心流程 / 输入 / 输出 / 成功标准 / 本版不做。

模糊 vs 可执行（记账 App）

术语： Spec · User Story · Scope · Acceptance Criteria · Non-goals

常见错误： 只说「帮我做个 App」；一上来塞太多功能；不说明用户；不定义完成标准；不写本版不做。

先找核心动作（三问）

1. 用户最核心的动作是什么？
2. 完成哪个动作后，用户就能感受到价值？
3. 哪些功能现在不做也能成立？

MVP 三分法

例子：任务管理工具

• MVP 只做：创建任务、标记完成、分类标签、本地保存
• 暂时不做：团队协作、日历同步、项目甘特图、权限系统

术语： MVP · 核心循环 · 原型 · 迭代 · Must-have / Should-have

常见错误： 还没跑通就想做完整产品；首页+登录+支付+分析一次全要；没有最小可行版本；每轮加功能却不管体验。

三种路线

让 AI 先输出技术建议清单

• 推荐什么技术栈？
• 为什么选这个栈？
• 文件结构怎么排？
• 以后扩展难不难？
• 哪些部分现在先跳过？

选择依据四问

懂不懂代码？要不要长期维护？要不要数据库？要不要登录权限（Auth）？

术语： Tech Stack · Frontend · Backend · Database · Auth · Scaffold

常见错误： 新手一上来选复杂架构；临时 demo 和长期项目不分；放任 AI 随便定栈；不考虑维护成本。

第一轮要产出这些

页面结构 · 路由设计 · 核心组件 · 数据模型 · 文件夹结构 · 基础样式 · 运行方式

推荐 src/ 结构（图上示意）

1
src/
2
  app/
3
  components/
4
  hooks/
5
  lib/
6
  services/
7
  styles/
8
  types/
9
  tests/

数据模型先想清楚（Task 例）

让 AI 先解释结构

每个文件夹做什么 · 核心数据怎么流动 · 哪些文件以后会扩展 · 哪些地方暂时留空

术语： Scaffold · Routes · Components · Schema · File Structure · Data Model

常见错误： 第一轮就堆满功能；页面/数据/逻辑搅在一起；没有清晰文件结构；后面一改就全乱。

每页至少考虑 6 种状态

给 AI 的指令模板：

请为这个页面同时设计正常、空、加载、错误、提交成功、移动端 6 种状态，并说明每种状态触发条件。

任务列表页例子： 空=「还没有任务」+ 新建；加载=「正在读取任务」骨架屏；错误=读取失败 + 重试；成功=新增成功 + 查看；移动端=列表改单列。

术语： UI State · Empty State · Loading State · Error State · Responsive Layout · Toast / Feedback

常见错误： 只做正常态；没错误提示；表单提交无反馈；不看移动端；空数据直接白屏/崩。

调试流程 6 步

运行 → 错误日志 → 让 AI 解释原因 → 最小修复 → 重跑 → 验证是否修好

你要给 AI 的六要素

完整错误信息 · 终端日志 · 相关文件 · 操作步骤 · 预期结果 · 实际结果

让 AI 必须答 4 件事

1. 错在哪里
2. 为什么错
3. 它要改哪里
4. 怎么验证修好了

推荐指令：

请先解释这个错误的原因，不要直接大改代码。然后给出最小修复方案，并说明修复后我应该如何验证。

术语： Error Log · Stack Trace · Patch · Debug Loop · Re-run · Verify

常见错误： 只说「报错了」；只贴截图不贴日志；一次让 AI 大改很多文件；修完不重跑；不检查是否引入新问题。

每次改动后先看 6 件事

1. 改了哪些文件
2. 每个文件为什么改
3. 有没有无关改动
4. 有没有删掉旧逻辑
5. 有没有硬编码
6. 有没有安全风险

让 AI 自己解释 diff

改动摘要 · 受影响文件 · 为什么这么改 · 潜在风险 · 如何验证

不要盲目 Accept All

涉及这些时尤其别一键全收：大面积重构 · 删除旧文件 · 修改依赖版本 · 改动鉴权逻辑 · 改动数据库结构

术语： Diff · Code Review · Regression · Breaking Change · Side Effect · Hardcoded Value

常见错误： 不看 diff；不知道改了哪些文件；小修变大修；修一个 bug 引入三个新 bug；不让 AI 说明风险。

手动验收 6 问

1. 核心流程能否走通？
2. 空输入会怎样？
3. 错误输入会怎样？
4. 刷新后数据是否保留？
5. 移动端是否正常？
6. 失败时有没有提示？

测试层级（由浅到深）

手动点一遍 → 写测试用例 → 边界情况 → 端到端（E2E）→ 移动端测试

让 AI 生成验收 checklist：

请根据这个功能，生成一份验收 checklist，包括正常流程、异常输入、空状态、移动端和数据保存测试。

例子：记账工具验收 —— 能新增支出；金额为空有错误提示；分类可选；刷新后记录还在；本月合计正确更新；移动端按钮不被挡住。

术语： Acceptance Criteria · Test Case · Edge Case · E2E Test · Regression Check

常见错误： 自己点一遍就当完；不测空数据；不测错误输入；不测移动端；不测刷新与持久化。

上线前 8 项检查

部署平台 · 环境变量 · 数据库 · 登录权限 · API Key · 域名 · 构建命令 · 日志查看方式

常见部署平台（图上）

让 AI 生成部署清单：

请根据当前项目结构生成一份部署 checklist，包括环境变量、数据库、构建命令、权限配置、日志查看和回滚方案。

上线后继续做

收集反馈 · 修 bug · 补功能 · 改 UI · 优化性能 · 做版本记录

术语： Deploy · Environment Variables · API Key · Logs · Rollback · Iteration

常见错误： 本地能跑就当完；API Key 写死在代码里；不上生产看日志；没有回滚方案；不做版本记录。