第七章：如何用 AI 从零开发一个完整项目

---

真实案例，不讲空话

这一章我们不讲空话，直接走一个完整案例。

项目：TodoFlow — 一个给个人和小团队使用的待办事项管理工具。

功能不复杂，但足够覆盖一个真实项目的主流程：

• 用户注册和登录
• 待办事项新增、编辑、删除
• 状态切换（待办 / 进行中 / 完成）
• 标签分类
• 截止日期
• 简单统计看板

技术栈：

• 前端：React + TypeScript + Ant Design
• 后端：FastAPI + SQLAlchemy
• 数据库：PostgreSQL
• 部署：Docker Compose

---

第一步：需求分析（不要跳过这一步）

为什么需求分析是第一步？

最差的做法是上来就说"帮我做个 Todo App"然后让 AI 直接写代码。

那个做法的问题是：你会得到一堆代码，但可能做了 60% 你不需要的功能，漏了 40% 你真正需要的。

更好的做法是先让 AI 帮你收敛需求，把模糊的想法变成清晰的任务列表。

需求分析 Prompt

我们要做一个 Todo 管理工具 MVP，请先帮我补全需求，不要写代码。

目标用户：
1. 个人用户（主要）
2. 小团队（次要）

初步想到的功能：
1. 新增待办
2. 编辑待办
3. 删除待办
4. 标记完成
5. 标签分类
6. 截止日期提醒

请帮我：
1. 区分 MVP 必须做的功能 vs 可以延后做的功能
2. 补充我可能遗漏的功能点
3. 列出信息架构（页面和核心实体）
4. 指出潜在的歧义点（需要我决策的地方）

AI 可能帮你发现的遗漏

通过这一步，AI 往往会帮你发现一些你没想到的问题：

• 待办是否支持优先级？（重要 vs 不重要）
• 删除是软删除（回收站）还是直接删？
• 截止日期是只展示，还是要推送提醒？
• 标签是全局的还是每个用户独立的？
• 完成的待办是否要归档，还是一直显示？
• 小团队协作时，待办能否分配给特定成员？

这些问题不是 AI 在刁难你，而是真正落地时必须回答的。 越早澄清，越少返工。

---

第二步：技术选型

当需求基本清楚后，再让 AI 帮你做技术决策。

技术选型 Prompt

请为一个 Todo SaaS MVP 做技术选型建议。

约束条件：
1. 2 周内要出可演示版本
2. 只有 1-2 个开发者
3. 后续可能扩展为小团队协作功能

请从以下角度比较：
1. React vs Vue（前端框架）
2. FastAPI vs NestJS（后端框架）
3. PostgreSQL vs SQLite（数据库）

评估维度：
- 开发速度（初始搭建 + 功能实现速度）
- 部署复杂度
- 后续扩展性

最后给出你的推荐方案和核心理由

典型的 AI 回复和你应该怎么用它

AI 会给你一个比较表和推荐，但最终决定权在你。关键是看它的理由，而不是直接接受推荐。

比如它推荐 SQLite，理由是"开发简单、不需要单独启动数据库"。但如果你预期三个月后要支持多用户并发写入，这个决定可能需要修正。

---

第三步：数据库设计

这一步很适合让 AI 先出草稿，但你必须 review。

数据库设计 Prompt

请为 TodoFlow MVP 设计数据库表结构。

实体（至少）：
1. 用户（User）
2. 待办事项（Todo）
3. 标签（Tag）

业务规则：
1. 一个用户可以有多个待办
2. 一个待办可以绑定多个标签（多对多）
3. 待办有状态：todo / in_progress / done
4. 待办有优先级：low / medium / high
5. 待办支持截止日期（可为空）
6. 软删除（deleted_at 字段，不真实删除）

请输出：
1. 每张表的字段、类型、约束、默认值
2. 主外键关系
3. 推荐加索引的字段（及原因）
4. 需要特别注意的设计细节

Review 数据库设计时的检查清单

拿到 AI 的输出后，重点检查：

• 是否过度设计（比如 MVP 阶段不需要的字段）
• 时间字段命名是否统一（created_at vs createTime）
• 是否有必要的唯一约束（email 唯一、手机号唯一）
• 多对多关系的中间表是否合理
• 软删除字段是否一致
• 外键是否有索引（查询性能）
• 是否缺少必要的 NOT NULL 约束

---

第四步：后端 API 开发

原则：一次只做一个模块

这一步最容易提速，也最容易乱。

坚守一个原则：一次只做一个模块。

不要说"帮我实现所有后端接口"，而是说"先只做用户认证模块"，做完验证了，再做下一个模块。

用户认证模块 Prompt

请实现用户认证模块（注册 + 登录）。

技术栈：
- FastAPI
- SQLAlchemy（async）
- PostgreSQL
- JWT（python-jose）
- 密码哈希（passlib + bcrypt）

已有的数据库模型（见上一步）：
[贴 User 表结构]

接口要求：
1. POST /auth/register
   - 输入：email、password、username
   - email 唯一校验
   - 密码哈希存储
   - 返回：user_id, email, username（不返回密码）

2. POST /auth/login
   - 输入：email、password
   - 校验密码
   - 返回：access_token（JWT，有效期 7 天）

3. GET /auth/me
   - 需要 Bearer Token
   - 返回当前用户信息

约束：
- 按 router / service / model / schema 分层
- 使用 Pydantic v2 做请求和响应验证
- 不要实现刷新 Token 逻辑（MVP 阶段不需要）

输出：
1. 目录结构
2. 分文件输出代码（app/auth/router.py, service.py, schema.py）
3. 最后给出 curl 测试示例（注册 + 登录）

Todo CRUD 模块 Prompt

请实现 Todo 的 CRUD 接口。

前置条件：
- 用户认证已完成（有 get_current_user 依赖）
- 已有 User 和 Todo 的 SQLAlchemy model

接口要求：
1. POST /todos - 创建待办
2. GET /todos - 查询待办列表（支持按状态、标签筛选，支持分页）
3. GET /todos/{id} - 查询单个待办
4. PUT /todos/{id} - 更新待办
5. DELETE /todos/{id} - 软删除待办
6. PATCH /todos/{id}/status - 单独修改状态

业务规则：
- 用户只能操作自己的待办（无法看到其他人的）
- 软删除（deleted_at 字段）
- 查询列表默认不返回已删除的

约束：
- 延用认证模块的分层结构
- 不要修改已有的 user 相关代码
- 分页默认 page=1, size=20

输出：
1. 分文件输出代码
2. 标注每个接口的权限要求

---

第五步：前端开发

前端非常适合 Vibe Coding，因为它反馈快——页面对不对，你一眼就能看出来。

但前端也最容易被 AI 改乱，所以最好按这个顺序来：

1. 先搭页面骨架（HTML 结构）
2. 再补交互逻辑
3. 再接真实接口
4. 最后优化样式细节

页面骨架 Prompt

请先实现 Todo 列表页的组件骨架，不要实现完整逻辑。

页面要求：
1. 顶部：搜索框 + "新建 Todo" 按钮
2. 左侧：标签筛选列表
3. 主区域：Todo 卡片列表
4. 每张 Todo 卡片显示：标题、状态、优先级、截止日期、标签、操作按钮

技术约束：
1. React + TypeScript
2. Ant Design 组件库
3. 先用 mock 数据（硬编码在组件里）
4. 不要接任何真实接口

输出要求：
1. 先给组件拆分图（哪些组件，各自的职责）
2. 再输出代码
3. 保持文件结构清晰

接入真实接口 Prompt

在上一步的基础上，把 mock 数据替换成真实接口调用。

已有的 API 规范：
[贴出上面后端接口的 OpenAPI 格式或简要说明]

约束：
1. 使用 axios（项目已有封装在 src/api/client.ts）
2. 统一用 react-query 做接口状态管理
3. loading / error 状态都要处理
4. 不要改页面组件的结构，只改数据来源

先只接入 Todo 列表接口，新建/编辑下一步再做

---

第六步：测试

很多人一到 AI 编程就跳过测试，这是个大坑。AI 生成的代码错误率不低，没有测试就没有安全网。

手工测试清单（最实用）

请为 Todo 模块生成一份手工测试清单。

覆盖范围：
1. 新增 Todo
2. 编辑 Todo
3. 删除 Todo
4. 切换完成状态
5. 标签绑定
6. 筛选功能

请按以下格式输出每个测试用例：

**测试用例 X**
- 操作步骤：
- 预期结果：
- 需要关注的边界：

自动化测试（接口测试）

请为 Todo CRUD API 生成 pytest 测试用例。

要覆盖的场景：
1. 正常创建 Todo
2. 创建 Todo 时缺少必填字段（应返回 422）
3. 查询不属于自己的 Todo（应返回 404）
4. 软删除后在列表里不可见
5. 更新已完成的 Todo 状态

约束：
1. 使用 pytest + httpx
2. 使用 pytest fixture 管理测试数据
3. 每次测试后清理数据（隔离性）
4. 不要直接写 SQL，使用已有的 service 层

---

第七步：部署

这是另一个非常适合 AI 的场景，因为部署本身就充满模板化工作。

Docker 部署 Prompt

请为这个 React + FastAPI + PostgreSQL 项目生成最小部署方案。

项目结构：
- /frontend（React 项目，用 Vite 构建）
- /backend（FastAPI 项目）

要求：
1. 使用 Docker Compose
2. 三个容器：frontend, backend, database
3. frontend 用 nginx 托管，反向代理 API 请求到 backend
4. 给出 .env.example 文件（列出所有环境变量）
5. 给出本地启动步骤
6. 不考虑生产级高可用，先能跑起来

输出：
1. docker-compose.yml
2. frontend/Dockerfile
3. backend/Dockerfile
4. nginx/nginx.conf
5. .env.example
6. 启动说明（一页以内）

---

AI 真正参与完整项目时，最好的分工

任务	谁来做
定目标	你
需求澄清	AI 辅助，你决策
技术选型	AI 提供建议，你拍板
数据库表设计	AI 出初稿，你 review
接口实现	AI 生成，你验证
前端骨架	AI 生成，你调整
业务规则	你提供，AI 实现
测试用例	AI 辅助，你补充
部署脚本	AI 生成，你测试
架构决策	AI 提供选项，你判断

结论：AI 最擅长把"从 0 到 0.7"这段路走得飞快，但从"能跑"到"能长期维护"，仍然需要你掌舵。

---

完整项目里 AI 最容易出问题的地方

问题一：业务规则理解错误

AI 不知道你的特殊规则。你说"取消订单"，它不知道"已发货不能取消"。必须在 Prompt 里显式说明。

问题二：模块间接口不一致

AI 分别生成每个模块时，可能用了不同的错误码格式、不同的分页参数名。要在开发前统一规范，并在每个 Prompt 里带上约定。

问题三：越写越乱的数据流

前端越写越复杂时，AI 可能随手在组件里加 state，而不是用统一的状态管理。要明确约束状态管理方式。

问题四：测试总是被跳过

AI 很擅长写代码，但不会主动"提醒你要测试这个"。你需要在每个模块完成后主动说"现在帮我生成这个模块的测试用例"。

---

一句话总结

AI 最擅长把"从 0 到 0.7"这段路走得飞快，但从"能跑"到"能长期维护"，仍然需要你掌舵。

---

上一章：第六章 — 主流 Vibe Coding 工具大全
下一章：第八章 — 高级玩家怎么玩 Vibe Coding