第29期 | 实战3：AI驱动开发全流程
第29期 | 实战3：AI驱动开发全流程
🎯 今天你将学会
- 体验一个完整功能从 0 到 1 用 AI 协作开发的全过程
- 记录 AI 参与度——AI 做了多少、你做了多少
- 分析效率提升——对比传统开发 vs AI 协作开发的时间差异
- 总结 AI 协作开发的最佳实践和踩坑记录
📖 核心知识
AI 驱动开发的完整流程
这不是一个理论框架——这是我实际做一个功能的完整记录。任务：给博客系统添加「标签管理系统」。
五阶段流程：
1. 需求分析 → 你主导（AI 辅助梳理） 2. 方案设计 → 你决策（AI 提供选项） 3. 代码实现 → AI 主导（你审查） 4. 测试验证 → AI 生成（你审查 + 执行） 5. 文档完善 → AI 主导（你审查）阶段1：需求分析（5分钟）
我的初始需求描述：
「博客需要标签管理功能——能创建、编辑、删除标签，搜索标签，给文章分配标签。」
这个描述太模糊了。我用 AI 来帮我把模糊需求变成清晰需求：
Prompt：
我的初始需求：博客需要标签管理功能——能创建、编辑、删除标签，搜索标签，给文章分配标签。 帮我把这个需求拆解成具体的功能点列表，标注优先级（P0必须/P1重要/P2可选）和依赖关系。AI 拆解的需求列表：
| 功能点 | 优先级 | 依赖 |
|---|---|---|
| Tag 数据模型（id, name, color, slug） | P0 | 无 |
| Tag CRUD（创建/编辑/删除） | P0 | Tag 数据模型 |
| Tag 搜索（模糊匹配） | P1 | Tag 数据模型 |
| 文章-标签关联（多对多） | P0 | Tag 数据模型 + Article 数据模型 |
| TagFilter 组件（博客列表页按标签过滤） | P1 | 文章-标签关联 |
| 标签颜色自定义 | P2 | Tag CRUD |
| 标签使用统计（每个标签有多少文章） | P2 | 文章-标签关联 |
我的调整：P2 功能先不做，先实现 P0 + P1。
AI 参与度：需求拆解 AI 做了 80%，我调整了 20%（砍掉 P2）。时间 5 分钟 vs 传统方式 15 分钟。
阶段2：方案设计（10分钟）
Prompt：
项目：React 18 + TypeScript + Zustand + Tailwind + Vite 目录结构：feature-based（src/features/xxx/） 为标签管理系统设计方案： 1. 数据模型设计（TypeScript 类型定义） 2. 状态管理方案（Zustand store 设计） 3. 组件架构（需要哪些组件，各自职责） 4. API 层设计（需要哪些接口） 5. 路由设计（标签管理页面的 URL） 参考现有 blog feature 的设计风格：@src/features/blog/AI 方案输出：
数据模型：
interfaceTag{id:string;name:string;slug:string;// URL 友好的标识，自动生成color:string;// 标签颜色，默认 #666createdAt:string;}interfaceArticleTag{articleId:string;tagId:string;}组件架构：
src/features/tag/ ├── components/ │ ├── TagList.tsx — 标签列表（带搜索、分页） │ ├── TagForm.tsx — 创建/编辑标签表单 │ ├── TagFilter.tsx — 博客列表页的标签过滤 │ └── TagBadge.tsx — 标签展示徽章（用在文章卡片和详情页） ├── store/ │ └── tagStore.ts — Zustand store（CRUD + 搜索 + 统计） ├── services/ │ └── tagService.ts — API 接口层 ├── hooks/ │ └── useTags.ts — 便捷 hooks └── types/ │ └── index.ts — 类型定义我的决策调整：
- ✅ 数据模型设计合理——slug 自动生成是好主意
- ✅ 组件架构清晰——TagBadge 是我没想到的，但很有用
- ❌ API 层我不需要——这是纯前端项目，标签数据用 localStorage mock
- ✅ store 设计合理——同意
AI 参与度：方案设计 AI 做了 70%，我调整了 30%（砍掉 API 层，改用 mock 数据）。时间 10 分钟 vs 传统方式 30 分钟。
阶段3：代码实现（30分钟）
我用 Composer + CRISP Prompt 逐个实现组件：
实现 TagBadge（5分钟）：
@src/features/tag/types/index.ts 创建 TagBadge 组件： - 展示标签名 + 标签颜色的小徽章 - 支持两种尺寸：sm（用在卡片上）和 md（用在详情页） - Props：tag: Tag, size: 'sm' | 'md', onClick?: () => void - 样式：圆角背景色 + 白色文字，背景色用 tag.colorAI 生成 → 我审查 → ✅ 直接可用，不需要修改。
实现 TagForm（8分钟）：
@src/features/tag/types/index.ts @src/features/tag/store/tagStore.ts 创建 TagForm 组件： - 创建新标签 / 编辑已有标签的表单 - Props：mode: 'create' | 'edit', initialTag?: Tag, onSubmit, onCancel - 表单字段：name（必填，2-20字符）、color（选色器，默认#666） - name 输入时自动生成 slug（中文转拼音，英文直接 slugify） - 验证：name 不能为空、不能重复（查 store） - 提交后调用 store 的 createTag / updateTagAI 生成 → 我审查 → 发现 2 个问题：
- 验证用了
window.alert→ 改为 inline error message - slug 生成只处理了英文 → 追加中文拼音处理
追加修改 → 2 分钟 → 最终可用。
实现 TagList（8分钟）：
@src/features/tag/types/index.ts @src/features/tag/store/tagStore.ts @TagBadge.tsx 创建 TagList 组件： - 展示所有标签列表（用 TagBadge 展示每个标签） - 上方有搜索框（debounce 300ms，模糊匹配 name/slug） - 支持编辑（点击标签弹出 TagForm edit 模式） - 支持删除（点击删除按钮，弹出确认对话框） - 底部有「创建新标签」按钮AI 生成 → 审查 → ✅ 可用，只改了搜索为大小写不敏感。
实现 TagFilter（5分钟）：
@src/features/tag/types/index.ts @src/features/tag/store/tagStore.ts @TagBadge.tsx 创建 TagFilter 组件： - 博客列表页的标签过滤栏 - 展示所有标签（TagBadge sm 尺寸） - 点击标签切换选中/取消选中 - 「全部」按钮清除所有过滤 - 多标签组合过滤（选中的标签用 Set<string> 管理） - 过滤状态同步到 URL（?tags=react,typescript）AI 生成 → 审查 → ✅ 可用。
实现 tagStore（4分钟）：
之前方案阶段已经定义好了 store 结构，直接让 AI 按方案实现：
@src/features/tag/types/index.ts 按之前确认的方案实现 tagStore.ts： - state: tags, searchQuery, selectedTags, loading, error - actions: fetchTags, createTag, updateTag, deleteTag, setSearchQuery, toggleTag, clearFilter - computed: filteredTags（按搜索+选中标签过滤）、tagStats（每个标签的文章数） - persist tags 到 localStorageAI 参与度统计（代码实现阶段）：
| 组件 | AI 生成代码量 | 我审查+修改时间 | AI 占比 |
|---|---|---|---|
| TagBadge | 100% | 0 分钟（直接可用） | 100% |
| TagForm | 90% | 2 分钟 | 90% |
| TagList | 95% | 1 分钟 | 95% |
| TagFilter | 100% | 0 分钟 | 100% |
| tagStore | 100% | 0 分钟 | 100% |
总计：AI 写了 95% 的代码，我审查修改了 5%。时间 30 分钟 vs 传统方式约 2-3 小时。
阶段4：测试验证（15分钟）
AI 生成测试：
@src/features/tag/store/tagStore.ts 为 tagStore 生成测试用例： - 正常流程：fetchTags、createTag、updateTag、deleteTag - 边界情况：搜索为空、标签名重复、删除不存在标签 - 状态一致性：搜索 + 选中标签组合过滤 框架：VitestAI 生成 → 我补充了 2 个边界情况 → 运行测试 → 全部通过。
AI 参与度：测试代码 AI 生成 85%，我补充 15%。时间 15 分钟 vs 传统方式约 45 分钟。
阶段5：文档完善（5分钟）
为标签管理功能生成文档： 1. TagBadge 组件文档（Props 表格 + 使用示例） 2. tagStore 文档（state + actions + 使用示例） 3. 功能说明（在 README 中添加标签管理章节）AI 生成 → 我审查格式 → ✅ 直接使用。
全流程效率分析
| 阶段 | AI 协作时间 | 传统预估时间 | 效率提升 |
|---|---|---|---|
| 需求分析 | 5 分钟 | 15 分钟 | 3x |
| 方案设计 | 10 分钟 | 30 分钟 | 3x |
| 代码实现 | 30 分钟 | 150 分钟 | 5x |
| 测试验证 | 15 分钟 | 45 分钟 | 3x |
| 文档完善 | 5 分钟 | 30 分钟 | 6x |
| 总计 | 65 分钟 | 270 分钟 | 4.1x |
AI 参与度总结：
| 维度 | AI 占比 | 你占比 |
|---|---|---|
| 代码量 | 95% | 5%（审查修改） |
| 决策量 | 20% | 80%（需求、方案、验证） |
| 时间量 | 70%（生成等待+执行） | 30%（审查+决策+验证） |
核心发现：AI 写了绝大多数代码，但你做了绝大多数决策。效率提升的本质不是「AI 替你写代码」，而是「你把写代码的时间省下来，专注做决策和验证」。
常见误区
误区1：让 AI 从头到尾做完一切
AI 能写代码，但不能做业务决策。你必须参与需求分析和方案设计——否则 AI 的代码可能功能完整但方向不对。
误区2：不审查 AI 的代码直接用
95% 的 AI 代码是正确的，但 5% 的错误可能是最关键的——比如安全漏洞、性能问题、边界情况遗漏。审查是你的责任。
误区3：只看时间节省不看质量
AI 协作开发节省了 4 倍时间，但如果质量下降，节省的时间会在后续 Bug 修复中浪费掉。确保 AI 代码通过测试和审查后才算完成。
🤖 AI协作实战
实战：你自己做一个完整功能
选你项目中的一个新功能，按本期五阶段流程执行：
- 需求分析：用 AI 拆解需求，标注优先级
- 方案设计：用 AI 生成方案，你做关键决策
- 代码实现：用 Composer + CRISP Prompt 逐个实现
- 测试验证：用 AI 生成测试，运行并补充遗漏
- 文档完善：用 AI 生成文档
记录每个阶段的：
- 耗时
- AI 参与度（代码量占比）
- 遇到的问题和解决方式
- 效率提升倍数
把记录做成一个表格，像本期的效率分析表一样。
学到了什么：AI 协作开发不是「AI 替你做一切」，而是「你决策、AI 执行、你验证」。你的角色从「写代码的人」变成了「做决策和审查的人」——这要求你更懂架构和业务逻辑，而不是更少。
💻 动手练习
练习1（简单）：记录一个功能的 AI 参与度
选你最近做的一个功能（用 AI 协作的），记录 AI 在每个阶段的参与比例。跟本期的数据对比，看你的 AI 使用效率在什么水平。
练习2（中等）：按五阶段流程开发一个新功能
严格按本期的五阶段流程，从需求分析到文档完善，做一个新功能。每阶段记录耗时和 AI 参与度，做成效率分析表。
练习3（挑战）：对比实验：同一个功能两种方式
选一个小功能（比如 30 分钟能手写完的），分别用两种方式做：
- 方式 A：纯手写，不用 AI
- 方式 B：AI 协作，按五阶段流程
对比：时间、代码质量（Bug 数）、你对代码的理解深度。
写一份实验报告，结论是什么？AI 协作真的提升了效率吗？
📌 本期要点
- 五阶段流程：需求分析 → 方案设计 → 代码实现 → 测试验证 → 文档完善，你决策 AI执行
- AI 参与度：代码量 95% AI 写，决策量 80% 你做——效率来自分工明确
- 效率提升 4x：65 分钟 vs 270 分钟，但前提是审查质量不降
- 审查是你的责任：5% 的 AI 代码错误可能是最关键的——安全、性能、边界
- 你从「写代码的人」变成「做决策和审查的人」：这要求你更懂架构和业务逻辑
🔗 下期预告
下一期是模块三的复盘——AI 工具使用的红线。什么该让 AI 做、什么不该、如何避免过度依赖。你将建立一份个人 AI 使用准则。
如果你没有苹果电脑，需要上传ios到APPStore可以访问以下网站
iPA上传工具 - IPA解析与AppStore提交