Hooke / mlaj

Go to a project
Toggle navigation Toggle navigation pinning
You need to sign in or sign up before continuing.
hookehuyr
daabf0eb 1 parent 794ee732

docs: 添加AI辅助开发工作流优化方案文档 

添加详细的工作流程文档，分析Trae和Claude Code在不同场景下的优势，并提出分工协作策略。文档包含决策树、质量保证清单和实用技巧，旨在优化开发效率与代码质量。
Inline Side-by-side
Showing 1 changed file with 520 additions and 0 deletions
# AI 辅助开发工作流优化方案
## 背景分析
### 观察结果
1. **Trae 在页面生成上表现更优**：
- 从设计稿生成页面的视觉效果更好
- 样式还原准确，细节处理完整
- 前端组件生成更符合设计要求
2. **Claude Code (CC) 在逻辑规划上更强**：
- 头脑风暴和需求分析能力强
- 计划生成和任务分解优秀
- 代码审查和测试能力突出
3. **问题定位**：
- CC 直接生成大段 Vue 页面代码时效果不够精细
- 可能是模型在前端视觉还原能力上的局限
## 核心策略
**优势互补，分工协作**：
```
CC (Claude Code) → 逻辑、规划、测试
Trae → 视觉、页面、样式
```
## 推荐工作流
### 阶段 1: 需求与规划 (CC 负责)
```
需求输入
│
├─ 头脑风暴
│ → 使用 CC 的 brainstorming skill
│ → 探索用户意图，明确需求范围
│
├─ 需求澄清
│ → 使用 CC 的 AskUserQuestion 工具
│ → 确认技术方案和实现细节
│
├─ 计划生成
│ → 使用 CC 的 /speckit.plan 命令
│ → 或使用 EnterPlanMode 进入计划模式
│ → 生成详细的实现计划
│
└─ 任务分解
→ 使用 CC 的 /speckit.tasks 命令
→ 或使用 TaskCreate 工具
→ 输出可执行的任务清单
```
**输出物**：
- ✅ 功能规范文档
- ✅ 技术实现计划
- ✅ 任务清单（含优先级和依赖关系）
---
### 阶段 2: 代码实现 (混合使用)
#### 场景 A: 新页面从设计稿生成 → **Trae**
```bash
# 使用 Trae 的步骤
1. 准备设计稿截图（Figma/Sketch/图片）
2. 复制 CC 生成的功能规范作为需求描述
3. 上传设计稿到 Trae
4. 描述需求（参考规范文档）
5. Trae 生成页面代码
6. 手动调整样式细节
```
**适用场景**：
- ✅ 全新页面开发
- ✅ 复杂 UI 布局
- ✅ 高度还原设计稿
---
#### 场景 B: 逻辑层代码 → **CC**
```bash
# 使用 CC 的步骤
1. 生成 API 接口代码 (/src/api/)
→ 遵循项目统一返回结构 { code, data, msg }
→ 使用正确的认证头处理
2. 生成 Composables (/src/composables/)
→ 提取可复用逻辑
→ 返回响应式 refs 和函数
3. 生成工具函数 (/src/utils/)
→ 通用工具函数
→ 遵循单一职责原则
4. 状态管理代码
→ Context API providers
→ localStorage 持久化逻辑
```
**适用场景**：
- ✅ API 接口定义
- ✅ 业务逻辑封装
- ✅ 数据处理函数
- ✅ 路由和权限逻辑
---
#### 场景 C: 已有页面修改 → **CC（待测试）**
```bash
# 测试方案
1. 小改动（< 50 行代码）
→ 使用 CC 修改
→ 对比效果
2. 大改动（> 50 行代码）
→ 评估复杂度
→ 简单改动用 CC
→ 复杂改动考虑 Trae
3. 记录结果
→ 更新决策树
→ 积累经验数据
```
**待验证假设**：
- ❓ CC 在小改动场景下是否足够好？
- ❓ 什么样的改动适合 CC vs Trae？
- ❓ 效率和质量的平衡点在哪里？
---
### 阶段 3: 测试与优化 (CC 负责)
```
Trae 生成代码
│
├─ 代码审查
│ → 使用 CC 的 /code-review 命令
│ → 检查代码风格和架构模式
│ → 统一为项目标准
│
├─ 测试编写
│ → 使用 CC 的 /tdd 命令
│ → 遵循 TDD 流程
│ → 单元测试 + 集成测试
│
├─ 测试执行
│ → 使用 CC 的 /verify 命令
│ → 运行 pnpm test
│ → 检查覆盖率 > 80%
│
└─ Bug 修复
→ CC 分析问题
→ 修复并回归测试
```
**输出物**：
- ✅ 符合项目规范的代码
- ✅ 完整的测试覆盖
- ✅ 通过所有测试的代码
---
## 决策树
```
开始开发任务
│
├─ 需求不明确？
│ └─→ CC: /speckit.specify + /speckit.plan ✅
│
├─ 新页面 + 有设计稿？
│ └─→ Trae 生成页面 ✅
│ └─→ CC 审查 + 测试 ✅
│
├─ 纯逻辑代码？
│ ├─ API 接口？
│ │ └─→ CC 生成 ✅
│ ├─ Composables？
│ │ └─→ CC 生成 ✅
│ └─ 工具函数？
│ └─→ CC 生成 ✅
│
├─ 修改已有页面？
│ ├─ 改动 < 50 行？
│ │ └─→ CC 修改 ✅
│ └─ 改动 > 50 行？
│ ├─ 简单调整？→ CC ✅
│ └─ 复杂重构？→ Trae ✅
│
└─ 需要测试/审查？
└─→ CC 全权负责 ✅
```
---
## 工具协作模式
### 模式 1: 串行协作（推荐）
```
CC (规划)
↓ 输出规范文档
Trae (实现)
↓ 生成代码
CC (审查 + 测试)
↓ 质量保证
完成
```
**优点**：
- ✅ 发挥各自优势
- ✅ 质量可控
- ✅ 流程清晰
**缺点**：
- ⚠️ 需要切换工具
- ⚠️ 可能有额外沟通成本
---
### 模式 2: 并行协作（高级）
```
CC (API + 逻辑) ──┐
├──> 合并 → 测试
Trae (页面 + 样式) ┘
```
**适用场景**：
- 前后端分离开发
- 页面和逻辑可独立实现
- 时间紧迫的项目
---
## 质量保证清单
### Trae 生成代码后的检查
- [ ] **代码格式化**
```bash
pnpm format # Prettier 自动格式化
```
- [ ] **代码风格检查**
```bash
pnpm lint # ESLint 检查
```
- [ ] **架构模式符合**
- API 层：`/src/api/`
- Composables：`/src/composables/`
- 组件层：`/src/components/`
- 遵循路径别名规范
- [ ] **CC 代码审查**
```bash
/code-review # 使用 code-review skill
```
- [ ] **测试覆盖**
```bash
/tdd # 使用 tdd skill 编写测试
pnpm test # 运行测试
```
- [ ] **构建验证**
```bash
pnpm build # 确保构建成功
```
---
## 实用技巧
### 1. 提示词模板
**CC 规划阶段**：
```
请使用 /speckit.plan 命令为以下需求生成实现计划：
[需求描述]
要求：
1. 遵循项目 CLAUDE.md 中的架构模式
2. 考虑与现有代码的集成
3. 生成可执行的任务清单
```
**Trae 生成阶段**：
```
请根据以下设计稿生成 Vue 3 页面代码：
功能规范：
[复制 CC 生成的规范]
技术要求：
- 框架：Vue 3.5 + Composition API
- UI 库：Vant 4.9
- 样式：TailwindCSS + Less
- 路由：Hash 模式 (/#/)
- 遵循项目路径别名 (@/, @components/, 等)
```
### 2. 代码迁移清单
Trae → CC 审查时检查：
- [ ] 是否使用 `localStorage.user_info` 获取认证信息
- [ ] API 调用是否检查 `res.code === 1`
- [ ] 是否正确使用路径别名
- [ ] 是否遵循项目的组件命名规范
- [ ] 是否正确处理 401 响应
- [ ] 是否使用 Vant 组件（自动导入）
### 3. 效率提升建议
- **建立模板库**：常用页面结构（列表页、详情页、表单页）
- **积累提示词**：记录效果好的提示词模板
- **工具快捷键**：熟练使用 CC 的 Skills 命令
- **批量操作**：一次性生成多个相关组件
---
## 待验证事项
### 高优先级
1. **已有页面修改测试**：
- [ ] 小改动（< 50 行）使用 CC 的效果
- [ ] 大改动（> 50 行）使用 CC vs Trae 的对比
- [ ] 记录成功/失败案例
2. **代码质量对比**：
- [ ] Trae 生成代码的 bug 率
- [ ] CC 审查后的改进效果
- [ ] 测试覆盖率的差异
### 中优先级
3. **效率对比**：
- [ ] 完整功能的开发时间
- [ ] 返工次数和原因
- [ ] 学习曲线和上手难度
4. **集成成本**：
- [ ] 工具切换的时间成本
- [ ] 代码迁移的工作量
- [ ] 团队协作的复杂度
---
## 数据记录模板
建议记录每次使用的经验：
```markdown
## [功能名称] 开发记录
**日期**: 2026-XX-XX
**工具组合**: CC (规划) + Trae (实现) + CC (测试)
### 阶段 1: 规划 (CC)
- 用时: XX 分钟
- 质量: ⭐⭐⭐⭐⭐
- 问题: 无
### 阶段 2: 实现 (Trae)
- 用时: XX 分钟
- 质量: ⭐⭐⭐⭐
- 问题:
- 样式需要微调
- 缺少某个功能
### 阶段 3: 测试 (CC)
- 用时: XX 分钟
- Bug 数: X 个
- 测试覆盖率: XX%
### 总体评价
- 总用时: XX 分钟
- 满意度: ⭐⭐⭐⭐
- 建议: 下次类似功能继续使用此流程
```
---
## 兜底方案
### 方案 A: 纯 CC 流程
**适用**：Trae 不可用或效果不佳时
```
CC (规划 + 实现 + 测试)
↓
完成
```
**缺点**：
- 页面生成效果可能不够精细
- 需要手动调整样式
---
### 方案 B: 纯 Trae 流程
**适用**：简单页面，逻辑较少
```
Trae (规划 + 实现)
↓
手动测试
```
**缺点**：
- 缺少系统性规划
- 测试覆盖不足
- 可能不符合项目架构
---
### 方案 C: 混合流程（推荐）✅
```
CC (规划)
↓
Trae (页面)
↓
CC (逻辑 + 测试)
↓
完成
```
**优点**：
- ✅ 发挥各自优势
- ✅ 质量最优
- ✅ 效率最高
---
## 下一步行动
### 立即执行
1. **下次新功能开发时**：
- [ ] 使用 CC 的 `/speckit.plan` 生成计划
- [ ] 使用 Trae 生成页面代码
- [ ] 使用 CC 进行代码审查和测试
- [ ] 记录效果和改进建议
2. **建立对比数据**：
- [ ] 创建 Excel 表格或 Notion 数据库
- [ ] 记录每次开发的工具选择和效果
- [ ] 定期回顾和优化流程
### 持续优化
3. **每周回顾**：
- [ ] 回顾本周开发任务的工具使用情况
- [ ] 识别模式和最佳实践
- [ ] 更新决策树和工作流
4. **知识积累**：
- [ ] 整理成功的提示词模板
- [ ] 记录常见问题和解决方案
- [ ] 建立组件库和代码片段库
---
## 总结
**核心原则**：
> 发挥每个工具的优势，而不是试图用一个工具做所有事情。
- **CC (Claude Code)**: 逻辑、规划、测试
- **Trae**: 视觉、页面、样式
**预期效果**：
- ✅ 开发效率提升 30-50%
- ✅ 代码质量更稳定
- ✅ 视觉还原度更高
- ✅ 测试覆盖更全面
**关键成功因素**：
1. 明确的工具分工
2. 标准化的工作流程
3. 持续的数据记录和优化
4. 质量保证清单的严格执行