第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 拆解的需求列表：

我的调整：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 — 类型定义

我的决策调整：

1. ✅ 数据模型设计合理——slug 自动生成是好主意
2. ✅ 组件架构清晰——TagBadge 是我没想到的，但很有用
3. ❌ API 层我不需要——这是纯前端项目，标签数据用 localStorage mock
4. ✅ 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.color

AI 生成 → 我审查 → ✅ 直接可用，不需要修改。

实现 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 / updateTag

AI 生成 → 我审查 → 发现 2 个问题：

1. 验证用了window.alert→ 改为 inline error message
2. 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 到 localStorage

AI 参与度统计（代码实现阶段）：

总计：AI 写了 95% 的代码，我审查修改了 5%。时间 30 分钟 vs 传统方式约 2-3 小时。

阶段4：测试验证（15分钟）

AI 生成测试：

@src/features/tag/store/tagStore.ts 为 tagStore 生成测试用例： - 正常流程：fetchTags、createTag、updateTag、deleteTag - 边界情况：搜索为空、标签名重复、删除不存在标签 - 状态一致性：搜索 + 选中标签组合过滤 框架：Vitest

AI 生成 → 我补充了 2 个边界情况 → 运行测试 → 全部通过。

AI 参与度：测试代码 AI 生成 85%，我补充 15%。时间 15 分钟 vs 传统方式约 45 分钟。

阶段5：文档完善（5分钟）

为标签管理功能生成文档： 1. TagBadge 组件文档（Props 表格 + 使用示例） 2. tagStore 文档（state + actions + 使用示例） 3. 功能说明（在 README 中添加标签管理章节）

AI 生成 → 我审查格式 → ✅ 直接使用。

全流程效率分析

AI 参与度总结：

核心发现：AI 写了绝大多数代码，但你做了绝大多数决策。效率提升的本质不是「AI 替你写代码」，而是「你把写代码的时间省下来，专注做决策和验证」。

常见误区

误区1：让 AI 从头到尾做完一切
AI 能写代码，但不能做业务决策。你必须参与需求分析和方案设计——否则 AI 的代码可能功能完整但方向不对。

误区2：不审查 AI 的代码直接用
95% 的 AI 代码是正确的，但 5% 的错误可能是最关键的——比如安全漏洞、性能问题、边界情况遗漏。审查是你的责任。

误区3：只看时间节省不看质量
AI 协作开发节省了 4 倍时间，但如果质量下降，节省的时间会在后续 Bug 修复中浪费掉。确保 AI 代码通过测试和审查后才算完成。

🤖 AI协作实战

实战：你自己做一个完整功能

选你项目中的一个新功能，按本期五阶段流程执行：

1. 需求分析：用 AI 拆解需求，标注优先级
2. 方案设计：用 AI 生成方案，你做关键决策
3. 代码实现：用 Composer + CRISP Prompt 逐个实现
4. 测试验证：用 AI 生成测试，运行并补充遗漏
5. 文档完善：用 AI 生成文档

记录每个阶段的：

• 耗时
• AI 参与度（代码量占比）
• 遇到的问题和解决方式
• 效率提升倍数

把记录做成一个表格，像本期的效率分析表一样。

学到了什么：AI 协作开发不是「AI 替你做一切」，而是「你决策、AI 执行、你验证」。你的角色从「写代码的人」变成了「做决策和审查的人」——这要求你更懂架构和业务逻辑，而不是更少。

💻 动手练习

练习1（简单）：记录一个功能的 AI 参与度

选你最近做的一个功能（用 AI 协作的），记录 AI 在每个阶段的参与比例。跟本期的数据对比，看你的 AI 使用效率在什么水平。

练习2（中等）：按五阶段流程开发一个新功能

严格按本期的五阶段流程，从需求分析到文档完善，做一个新功能。每阶段记录耗时和 AI 参与度，做成效率分析表。

练习3（挑战）：对比实验：同一个功能两种方式

选一个小功能（比如 30 分钟能手写完的），分别用两种方式做：

• 方式 A：纯手写，不用 AI
• 方式 B：AI 协作，按五阶段流程

对比：时间、代码质量（Bug 数）、你对代码的理解深度。
写一份实验报告，结论是什么？AI 协作真的提升了效率吗？

📌 本期要点

1. 五阶段流程：需求分析 → 方案设计 → 代码实现 → 测试验证 → 文档完善，你决策 AI执行
2. AI 参与度：代码量 95% AI 写，决策量 80% 你做——效率来自分工明确
3. 效率提升 4x：65 分钟 vs 270 分钟，但前提是审查质量不降
4. 审查是你的责任：5% 的 AI 代码错误可能是最关键的——安全、性能、边界
5. 你从「写代码的人」变成「做决策和审查的人」：这要求你更懂架构和业务逻辑

🔗 下期预告

下一期是模块三的复盘——AI 工具使用的红线。什么该让 AI 做、什么不该、如何避免过度依赖。你将建立一份个人 AI 使用准则。
如果你没有苹果电脑，需要上传ios到APPStore可以访问以下网站
iPA上传工具 - IPA解析与AppStore提交