一、Vibe Coding 项目开发流程
在Vibe Coding的模式下，如果对项目的规划不清楚，AI就会自由发挥，生成的代码效果可能与人脑中的预期相差甚远；所以要想尽可能减小这个偏差，就需要一个清晰完整的开发流程，具体来说，可以分为五步走：
- 需求研究 （Research)
- 产品需求文档 (PRD)
- 技术设计文档 (Tech Design)
- AI代理指令（AGENTS.md)
- 实现和迭代 （Build）
步骤一、需求研究
需求研究是对自己想做的产品的一个调研，具体来说分为三步：
-
明确产品定位（功能目标）：先问自己几个问题：我想解决什么问题？这个问题真的值得解决吗？我希望做出来的东西是什么样的？比如你想做一个记账应用，那就要想清楚：是给自己用还是给别人用？主要记录哪些类型的账目？需要哪些核心功能？
-
调研类似产品：去看看市面上有没有类似的产品，它们是怎么做的？有什么优点和缺点？可以搜索相关的应用或网站，看看别人的开源项目，或者直接问AI：“有哪些好用的记账应用？它们有什么特点？“ 这一步很重要，可以避免重复造轮子，也能给你提供灵感和参考。
-
记录发现：把自己的想法和调研结果记录下来，形成一个简单的文档，比如RESEARCH.md。这个文档不需要很正式，就像写日记一样，记录你的想法和发现就行。
# 记账应用需求研究 ## 目标 做一个简单易用的个人记账应用，帮助自己养成记账习惯。 ## 调研发现 - 市面上的记账应用功能都太复杂了 - 我只需要快速记录收入和支出 - 最好能看到每月的统计数据 ## 核心需求 1. 快速添加收支记录 2. 按日期查看记录 3. 查看月度统计 4. 数据本地存储
步骤二、产品需求文档（PRD）
完成需求研究后，自己脑中应该就有一个较为清晰的产品格式了，接下来就需要形成一份正式的PRD。
一个好的PRD可以让AI帮自己扩充完成，比如我们可以把这段prompt发给Gemini / ChatGPT
我要做一个记账应用，能快速记录收支，查看每月统计。
要简单易用，不要复杂的功能。
请帮我把这个需求扩展成完整的产品需求文档（PRD），
要包含：
1. 产品概述和目标用户
2. 详细的功能列表
3. 功能优先级（MVP 和后续版本）
4. 界面设计要求
5. 技术栈建议
6. 非功能性需求（性能、安全等）
根据LLM的输出，我们再根据自己的需求修改和完善
一份完整的PRD通常应该包含
- 产品概述 （简单介绍这个产品是什么）
- 目标用户（谁会用这个产品）
- 核心功能 (列出所有要做的功能)
- 功能优先级 (哪些是必须做的，哪些是可以后续添加的)
- 界面设计 (简单描述界面应该是什么样的）
- 技术栈建议
- 代码风格和架构模式
- 限制条件和边界场景
# 记账应用 PRD
## 产品概述
一个简单的个人记账应用，帮助用户快速记录日常收支。
## 目标用户
需要记账但不想用复杂应用的个人用户。
## 核心功能
### 必须做（MVP）
1. 添加收支记录
- 输入金额
- 选择类型（收入/支出）
- 选择分类（餐饮、交通、工资等）
- 添加备注（可选）
- 选择日期
2. 查看记录列表
- 按日期倒序显示
- 显示金额、类型、分类、备注
- 可以删除记录
3. 月度统计
- 显示当月总收入
- 显示当月总支出
- 显示当月结余
### 后续可以做
- 数据导出
- 图表展示
- 预算设置
- 多账户管理
## 界面设计
- 首页：显示记录列表和添加按钮
- 添加页面：表单输入
- 统计页面：展示月度数据
步骤三、技术设计文档（Tech Design）
这一步需要输出一个 TECH_DESIGN.md 文件，用来确定项目使用哪些技术栈以及确定大致的技术架构，TD文档需要包括：
- 技术栈选择（前端用什么、后端用什么、数据库用什么)
- 项目结构 (代码怎么组织)
- 数据模型 (需要存储哪些数据)
- 关键技术点（有哪些技术难点需要注意）
这里的技术栈选择可以参考现有的软件所采用的技术栈，也可以询问LLM，看下自己的需求适合通过哪些技术栈来进行实现。然后让AI输出一个完整的TDD
# 记账应用技术设计
## 技术栈
- 前端：React + TypeScript + Vite
- 样式：Tailwind CSS
- 数据存储：LocalStorage
- 部署：Vercel
## 项目结构
src/
components/ # 组件
pages/ # 页面
hooks/ # 自定义 Hooks
utils/ # 工具函数
types/ # 类型定义
## 数据模型
### Transaction（交易记录）
- id: string
- amount: number
- type: 'income' | 'expense'
- category: string
- note: string
- date: string
## 关键技术点
1. 使用 LocalStorage 存储数据
2. 使用 React Hooks 管理状态
3. 使用日期库处理日期（date-fns）
步骤四、AI agent指令
为了保证软件开发流程的顺畅，代码质量的稳定，通常需要遵循一定的代码开发规范。为了保证LLM输出的代码质量，我们需要一个文件告知LLM，在项目开发中需要遵循什么规则，这个文件命名为：AGENTS.md
AGENTS.md 是一个标准化的文件格式，用来指导AI编程工具如何工作。它就像是给AI的“工作手册”。这个标准由 OpenAl、Anthropic、Google 等公司共同推动，目前已经有超过8万个开源项目在使用。主流的 Al 编程工具， 比如 Cursor、Windsurf、Claude Code、Gemini CLl、GitHub Copilot 等都支持自动读取 AGENTS.md 文件。
AGENTS.md应该包含：项目概述、开发规范、测试要求、代码风格、注意事项等。(也可以交由AI生成并逐步完善)
# 记账应用 AI 开发指令
## 项目概述
这是一个简单的个人记账应用，使用 React + TypeScript 开发。
## 开发规范
- 使用 TypeScript，确保类型安全
- 组件使用函数式组件 + Hooks
- 使用 Tailwind CSS 编写样式
- 所有数据存储在 LocalStorage
## 代码风格
- 使用 ESLint 和 Prettier
- 组件名使用 PascalCase
- 函数名使用 camelCase
- 常量使用 UPPER_SNAKE_CASE
## 测试要求
- 每个功能完成后手动测试
- 确保数据正确存储和读取
- 测试各种边界情况
## 注意事项
- 保持代码简洁，避免过度设计
- 优先实现核心功能
- 确保移动端适配
步骤五、实现与迭代（Build）
对于复杂的项目，一步到位不现实，通常通过分步迭代实现：
-
生成基础框架：其实就是脚手架（前端可以直接通过官方脚手架直接生成）和后端框架
- 逐步实现核心功能：把项目拆解分成多个小功能，一个一个实现，这一步核心是先跑通核心业务流程、实现核心功能。每完成一个功能就测试是否可以正常运行，排除bug，界面是否符合预期
- 优化实现细节：在不影响功能的前提下，优化性能、改进用户体验、美化界面
避免失控
-
项目模块化：由于AI的上下文是有限的，随着项目信息量不断增大，它可能忘记之前的信息，导致生成的代码错误。所以我们要把项目的功能尽可能隔离开，把一个大项目分割成多个小模块。
- 举个例子，开发一个电商系统，可以把商品管理模块独立出来。当需要AI生成添加商品功能的代码时，只需要提供商品表的字段设计、添加商品的业务逻辑规则，不需要把支付结算、用户会员等关联不大的功能作为上下文提供给AI
-
限定修改范围：AI生成的代码没有那么可控，经常改A功能的同时把B功能也顺带修改了。这个问题很好解决，只要在提示词中限定修改范围即可
仅修改 components/AddTransaction.tsx 文件： 1. 添加表单验证功能 2. 保持现有的样式和布局 3. 不要改动其他文件 -
抽象与复用：假如我们要让AI生成2个布局一模一样的页面，它有时会很死板，生成完页面A之后，复制一遍页面A的代码来生成页面B。这样非常不利于大项目的维护，以后AI改了页面A，说不定页面B就忘了改。所以我们需要主动告诉AI:
请帮我抽象这个页面为可复用的组件， 让其他页面可以通过传入不同的参数来使用。 -
版本控制：每实现一个小功能 、 修正一个小bug，就提交一次代码
-
人工控制：AI有时会因缺乏关键上下文信息、或者自身能力的不足而陷入循环。比如改来改去总是出现同样的错误，或者一直在做无用功。这时就有必要人工介入了。可以尝试手动指定上下文、更换Prompt换个角度描述问题、清空对话历史重新开始，甚至手动修改部分代码给AI一个正确的方向。
-
多元AI协作：不同AI大模型擅长不同任务。如果单一大模型无法正常完成工作，可以利用其他大模型生成“教AI做事的方法和指令 比如，你在Cursor 中使用GPT 生成的代码有问题，你可以：
- 把代码和错误信息复制给Claude或Gemini
- 让它分析问题并给出修改建议
- 把修改建议再告诉GPT，让它修改代码