Vibe Coding开发前的 7 个关键步骤

第一步：把想法聊清楚

把你的想法完整地说出来。注意，是“完整地”,不是"简洁地"。

比如你想做个记账工具，别只说“帮我做个记账 App"。你得说清楚:

为什么要做这个?现有的记账App哪里不满意?

核心功能是什么?记录收支?生成报表?设置预算?

谁会用这个工具?就你自己，还是想给朋友用?

使用场景是什么?每天记一次，还是花钱就记?

这个过程其实是在帮你自己理清思路。很多时候，你以为自己想清楚了，真说出来才发现到处是模糊地带。

于是，第一步就是跟AI聊天，像跟朋友聊天一样，把脑子里的想法全倒出来，细节越多越好。

填充下面这份prompt


我想做一个[产品名称]
主要是为了解决[什么问题]
目标用户是[谁]
核心功能包括:
[功能一]
[功能二]
[功能三]
我希望它能 [达到什么效果]

然后继续和ai交流，知道ai达到你的理想型

第二步：要一份 PRD

聊完之后，别急着写代码。让AI帮你把刚才的对话整理成一份PRD，也就是产品需求文档。

直接说:帮我把刚才聊的内容整理成一份产品需求文档。并且写入PRD.md AI会给你输出一个结构化的文档

然后，认真读这份PRD。

这是整个流程里最容易被跳过，但其实最关键的一步。逐条对照你的原始想法，看AI理解的跟你想的是不是一回事。

发现不对的地方，现在就改。改PRD花5分钟，改代码可能要花5个小时。

把PRD当作你和AI之间的"合同”，确保双方理解一致。

第三步：明确项目目标

做什么搞清楚了，接下来要想清楚：做到什么程度?

这个问题直接决定了技术方案的选择。

可以这样说:


这个项目主要是我自己用，目标是低成本实现，

在本地运行就可以，不需要考虑多人使用的情况

或者：


这个项目我想做成可以release的产品，

需要考虑用户数据安全、性能优化和未来扩展性。

第四步：确定技术

目标明确了，就可以让AI推荐技术栈了。

一个实用的prompt模板：


帮我根据上面内容，推荐合适的技术栈，并说明为什么这样选择。

AI会告诉你前端用什么框架、后端用什么语言、数据库选什么、需要哪些工具库。

比如做个简单的网页工具，React+Node.js+ SQLite就够了。不需要上Kubernetes、微服务这些大杀器。

第五步：要一份架构设计

技术栈定了，接下来要一份系统架构设计。

可以这样问AI：


根据这个PRD，请为我设计一个适合个人项目的轻量架构，包括:

- 项目目录结构
- 核心模块划分
- 数据模型设计
- 代码规范建议

我希望这个项目：[本地运行/可部署/需要扩展性]
然后把上面架构设计写入ARCHITECTURE.md

AI会给你输出完整的目录结构和划分


|project/  
||—————src/  
||  |—————components/ #UI组件
||  |—————services/ #业务逻辑
||  |—————utils/  #工具函数
||  |—————config/  #配置文件
||—————public/  
||—————tests/
|—————README.md

第六步：整理项目文档

现在你手上有了PRD、技术栈、架构设计，接下来要把这些内容整理成文档，保存在项目里。

建议创建这几个文件:

和AI沟通进行创建README.md


帮我结合上面内容创建一个README.md
要求：
- 项目简介：这个项目是干什么的
- 如何运行：怎么把项目跑起来
- 技术栈：用了哪些技术
项目内容PRD.md和ARCHITECTURE.md和README.md
都要跟随着项目文件更改进行更新！

下面文件AI已经创建了

~~PRD.md~~

~~产品定位~~

~~核心功能列表~~

~~用户使用流程~~

~~ARCHITECTURE.md~~

~~技术栈选择及原因~~

~~核心模块说明~~

~~数据模型设计~~

~~代码规范~~

只要使用 Cursor/Claude Code/Trae 等工具，它能直接访问你的项目文件夹，会自动读取项目根目录的文档。

于是每次你和AI对话，它都已经“知道”了你的项目架构和规范。不需要反复上传文档。

最后一个提醒:文档要跟着项目更新。

如果你调整了架构、改变了某个设计，记得让AI同步更新文档（手动更新）。

否则AI会按照过时的文档理解项目，导致新代码跟现有代码对不上。

第七步:设置

Git 版本管理

在写第一行代码之前，最后一件必须做的事：设置 Git版本管理。

Git是做什么的?

简单说，就是给你的项目创建“存档点”。就像玩游戏时的存档系统，每完成一个阶段就存个档，后面打不过了可以读档重来。

Git Skill

这里我们可以使用git相关的skill实现ai自动生成commit，也就是实现自动存档的功能

比如下面这个Skill:


---
name: commit-by-feature
description: Commits code changes by feature with a standardized multi-line commit message. Runs when the user makes code changes and asks to commit, or when the user explicitly requests a commit. Amends the last unpushed commit message when the user switches to another feature and has unpushed commits.
---

# 按功能提交（Commit by Feature）

在用户完成代码修改并要求提交、或用户明确要求提交时，按「功能」进行 git commit，并采用下方固定格式的 commit message。若用户在一个功能已 commit 后又在做另一功能的修改，且存在未 push 的 commit，则对**最近一次未 push 的 commit** 使用 `git commit --amend` 修改其 message，使其描述新功能。

## 何时执行

- 用户说「帮我 commit」「提交一下」「把更改 commit」等，或
- 用户完成一批代码修改后要求提交，或
- 用户说「修改刚才的 commit 说明」「改一下上次的 commit message」等（则执行 amend 流程）。

## Commit Message 格式（必须严格遵循）

整段作为 **commit message 正文**（不要用 `-m` 只写一行，用 `-m "第一行" -m "正文..."` 或写进文件再 `git commit -F`）。格式如下：

```
修改描述： [feat] 或 [fix] 或 [refactor] + 一句话概括（如：精简视频裁剪页面与回灌页面：在视频裁剪页移除xxx；在回灌页将设备 IP 默认改为 0.0.0.0。）
影响分析： all
是否自测： 是
自测内容： ui（或 doc / 接口 / 改动对应的文件夹路径 /等，按实际改动的自测范围填写）
测试建议： all
代码审查： 刘江涛
NOTE： all
项目编号： all
```

- **修改描述**：首行用 `[feat]` / `[fix]` / `[refactor]` 等前缀，后接简洁的功能/修复说明，多块功能用分号或「；」分隔。
- **影响分析 / 测试建议 / NOTE / 项目编号**：无特殊要求时填 `all`。
- **是否自测**：一般为「是」。
- **自测内容**：根据改动填 `ui`、`doc`、`接口`、`导出` 等。
- **代码审查**：固定为「刘江涛」。

## 执行步骤

### 1. 仅修改上一次 commit 的 message（amend）

当用户明确说「改 commit 说明」「修改上次的 commit」「amend」且当前有未 push 的 commit 时：

1. 运行 `git log -1 --oneline` 确认最近一次 commit。
2. 根据**当前工作区+暂存区的最新改动**（或用户口述）归纳「修改描述」。
3. 按上面格式写出完整 commit message。
4. 执行：`git commit --amend -m "修改描述： ..." -m "影响分析： all" -m "是否自测： 是" -m "自测内容： ..." -m "测试建议： all" -m "代码审查： 封凯" -m "NOTE： all" -m "项目编号： all"`
   或使用临时文件：`git commit --amend -F commit_msg.txt`（内容为上述多行）。
5. 告知用户已 amend 完成。

### 2. 按功能提交当前改动（新 commit）

当用户要求提交当前更改时：

1. **查看改动**：`git status`、`git diff`（及 `git diff --staged`）。根据修改的文件路径和 diff 内容判断属于哪一个或哪几个功能（例如：视频裁剪、回灌、帧头导出、日志分析、通用功能、系统设置等）。
2. **决定 commit 数量**：
   - 通常**一个功能一个 commit**；若改动明显属于同一功能，只生成一个 commit。
   - 若改动横跨多个互不相关的功能，可拆成多个 commit（先 add 第一批，commit；再 add 下一批，commit），每个 commit 的 message 都按本格式填写。
3. **撰写「修改描述」**：
   - 用 `[feat]` / `[fix]` / `[refactor]` 等开头。
   - 一句话概括该 commit 涉及的功能或修复，多点时用分号分隔。
   - 仅描述本 commit 包含的改动，不要写未改动的功能。
4. **填写其余字段**：影响分析、是否自测、自测内容、测试建议、代码审查、NOTE、项目编号按格式填好。
5. **执行提交**：
   - 先 `git add` 本功能相关文件，再 `git commit`，message 使用上述多行格式（可用多个 `-m` 或 `-F` 文件）。
   - 若拆多个 commit，重复 add + commit，每个 commit 对应一个功能的描述。

## 示例

**单功能单 commit：**

修改描述： [feat] 帧头导出支持 MP4 视频并修复导出 0 帧问题；导出服务 JSON 改为使用 orjson。
影响分析： all
是否自测： 是
自测内容： 导出、MP4 视频
测试建议： all
代码审查： 刘江涛
NOTE： all
项目编号： all

**Amend 场景：**
用户已为「视频裁剪精简」commit 过一次，未 push，接着又做了「回灌页设备 IP 默认 0.0.0.0」的修改并希望把这两块合进同一个 commit 说明。则对最近一次 commit 执行 `git commit --amend`，将 message 改为同时包含「视频裁剪页精简」和「回灌页设备 IP 默认与选网卡自动填充」的修改描述。

## 注意事项

- 不要用单行 `-m "..."` 把多行格式挤成一行；用多行 message 或 `-F` 文件。
- 若仓库有 `.gitignore` 或未跟踪文件，只 add 用户明确要提交的或与当前功能明显相关的文件。
- 不执行 `git push`，除非用户明确要求推送。

从准备到开发

准备工作做完，就可以开发了。但记住几个原则:

1.先做MVP(最小可用版本)

不要一开始就追求完美。先做一个能跑、能用、实现核心功能的版本。后面再慢慢优化。

比如记账工具，第一版只要能记录收支、能查看列表就够了。报表、预算、数据分析这些可以后面加。

2.小步迭代

每次只做一个功能，做完测试没问题，再做下一个。

别一口气让AI写一大堆代码，那样出问题很难定位。

3.勤 commit

每完成一个小功能就commit一次。这是我们的安全网，别省。

4. 验证AI的代码

AI写的代码要自己测试。不要盲目相信，也不要过度怀疑,测试是最好的验证方式。

5.完成项目后沉淀技术文档

每次写完一个项目，沉淀一个技术文档和一些可复用的Skill，方便后面项目的开发和技术回顾

如果是完全零基础的新手，建议:

从简单项目开始。

别一上来就做复杂的。先做个待办事项管理、简易记账本、个人博客这种简单项目。

目的不是做出多牛的产品,而是把整个流程走一遍，体会每个步骤的作用。做完一个项目,流程就刻在脑子里了，也有了 Vibe Coding的感觉。

别害怕出错。

有Git在,出错了就回滚，没什么大不了的。多试几次，或者选择更厉害的模型。

附上前端美化Skill:

SKILL.md

anthropics

和每次变更的流水线(CHANGELOG.md)放在项目根目录就可以了，然后告诉AI你添加了变更流水线


# Changelog

本文件用于记录每次版本发布的“代码改动 + 文档改动”，并作为固定发布流程的执行清单。

遵循规范：
- 版本格式：`[主版本.次版本.修订]`，例如 `v1.0.0`
- 日期格式：`YYYY-MM-DD`
- 发布原则：没有文档更新说明的功能改动，不应发布

## 发布流程（固定）
1. 完成代码改动并本地验证（功能、接口、构建）。
2. 更新文档：至少检查 `PRD.md`、`ARCHITECTURE.md`、`README.md` 是否需要变更。
3. 填写本文件对应版本条目，明确“代码改动 + 文档改动”。
4. 复核发布清单，确认通过后再打版本标签/归档。

## 发布清单（每次发布必查）
- [ ] 代码改动已完成并自测通过
- [ ] 需求变化已同步到 `PRD.md`（如适用）
- [ ] 架构变化已同步到 `ARCHITECTURE.md`（如适用）
- [ ] 运行方式/依赖变化已同步到 `README.md`（如适用）
- [ ] 本次版本记录已写入 `CHANGELOG.md`

---

## [Unreleased]
### Added
- 待补充

### Changed
- 待补充

### Fixed
- 待补充

### Docs
- 待补充（必须填写文档变更；若无，请写“无”并说明原因）

### Release Checklist
- [ ] 代码改动已完成并验证
- [ ] 文档改动已同步
- [ ] 风险项已评估

---

## [v1.0.0] - 2026-04-16
### Added
- 初始化项目文档体系：`PRD.md`、`ARCHITECTURE.md`、`README.md`、`CHANGELOG.md`

### Changed
- 建立个人本地低成本架构基线，明确可扩展路线

### Fixed
- 无

### Docs
- 新增 `README.md`，补充项目简介、运行方式、技术栈
- 更新 `PRD.md`，补充文档联动维护要求
- 更新 `ARCHITECTURE.md`，补充文档联动更新约定

### Release Checklist
- [x] 代码改动已完成并验证
- [x] 文档改动已同步
- [x] 风险项已评估

作者：hllqk