Chapter 7 – SDD 四核心之三 – 工作流
完成以下任务：
1，有了“规则”和“技能”，如何让 AI 按照软件工程流程进行开发？
2，介绍：“工作流 / Workflow”
3，Review 以下 “New Feature Development” 工作流：
# Workflow - New Requirement
新功能开发的完整工作流程
---
## 第一步：编写规格文档
首先判断功能类型：
- **全新功能**：在项目根目录创建 `specs/feature-name/` 文件夹
- **已有功能的子功能**：直接在已有的 `specs/feature-name/` 文件夹中更新
### 1.1 需求规格
- 使用 `atdd` 技能
- 将需求转化为用户故事和 Gherkin 格式的验收标准
- **全新功能**：创建 `specs/feature-name/req-feature-name.md`
- **子功能**：将新的用户故事和 AC 插入到 `req-feature-name.md` 的合适位置
- **依赖：** 无
### 1.2 设计规格
- 使用 `Fullstack` 技能
- **基于需求规格**，设计技术架构、API、数据模型
- **全新功能**：创建 `specs/feature-name/design-feature-name.md`
- **子功能**：在 `design-feature-name.md` 中新增或修改相关章节
- **依赖：** 需求规格必须先完成
### 1.3 UI 设计规格
- 使用 `Frontend Design` 技能
- **基于需求规格和设计规格**，设计界面布局、交互、组件
- **全新功能**：创建 `specs/feature-name/ui-feature-name.md`
- **子功能**：在 `ui-feature-name.md` 中新增或修改相关章节
- **依赖：** 需求规格和设计规格必须先完成
### 1.4 规格一致性检查
检查三个规格文档的一致性：
- [ ] 设计规格中的 API 是否满足需求规格中的所有场景
- [ ] UI 规格中的界面元素是否覆盖需求规格中的所有用户操作
- [ ] 设计规格中的数据模型是否支持 UI 规格中的所有展示需求
- [ ] 三个规格中的术语和命名是否一致
- [ ] 没有遗漏的功能点或边界情况
### 1.5 用户审核
- 请用户人工审核三个规格文档
- 确认需求理解正确、设计合理、UI 符合预期
- 未通过则返回修改，重新进行一致性检查
---
## 第二步：TDD 开发
### 2.1 开发原则
- 使用 `tdd` 技能
- 遵循 `Incremental Delivery` 规则：完整交付一个功能再开始下一个
- 遵循 `test-strategy` 规则：确保测试覆盖率和质量
### 2.2 开发流程（Red-Green-Refactor）
1. **Red（红灯）** - 为当前功能编写测试，测试失败
2. **Green（绿灯）** - 实现最小代码使测试通过
3. **Refactor（重构）** - 优化代码，保持测试通过
4. **Commit（提交）** - 每个测试通过后立即 git commit
- Commit message 格式：`test: add test for [feature]` 或 `feat: implement [feature]`
- 保持小步提交，便于回滚和追踪
5. 重复步骤 1-4 直到功能完成
### 2.3 Git Commit 时机
- ✅ 每个测试通过后立即 commit
- ✅ 重构完成后 commit（如果有）
- ❌ 不要等到整个功能完成才 commit
- ❌ 不要在测试失败时 commit
### 2.4 文档同步
- 如果开发过程中发现规格需要调整
- 使用 `update-docs` 技能立即更新对应的规格文档
- 在 commit message 中注明规格变更：`docs: update spec for [reason]`
- 确保代码和规格始终保持同步
---
## 第三步：DoD 验收
### 3.1 自动检查
使用 `dod` 技能自动执行以下检查：
**代码质量：**
- [ ] 所有测试通过（单元 + 集成 + e2e）
- [ ] 测试覆盖率达标（≥80% 整体，100% 关键路径）
- [ ] 无 lint 错误
- [ ] 无 TypeScript 类型错误
**功能完整性：**
- [ ] 所有验收标准（AC）已实现
- [ ] 错误处理已实现
- [ ] 边界情况已处理
**文档同步：**
- [ ] 规格文档已更新（如有变更）
- [ ] API 文档已更新（如适用）
**版本控制：**
- [ ] 代码已提交到 Git
- [ ] Commit message 清晰描述变更
- [ ] 无未追踪的临时文件
- [ ] 分支已推送到远程仓库
**非功能性要求：**
- [ ] 无明显性能问题
- [ ] 无安全漏洞（SQL注入、XSS等）
- [ ] 日志记录完整
### 3.2 人工测试
- 请用户按照 `req-feature-name.md` 中的验收标准手工测试功能
- 确认功能符合预期
- 记录测试结果
### 3.3 标记完成
如果所有检查通过：
- 在 `specs/feature-name/req-feature-name.md` 中标记功能为 ✅ 已完成
- 记录完成时间和验收人
- 示例：`✅ 已完成 - 2026-04-06 by Ethan Huang`
如果检查未通过：
- 列出所有失败项
- 修复后重新运行 DoD 检查
- 不要标记为完成
---
## 工作流检查点
| 阶段 | 检查点 | 产物 |
|------|--------|------|
| 规格编写 | 用户审核通过 | 3个规格文档 |
| TDD开发 | 所有测试通过 | 代码 + 测试 + Git commits |
| DoD验收 | 自检 + 人工测试通过 | 可交付功能 |
---
## 依赖的规则和技能
**规则（必须先创建）：**
- Incremental Delivery
- DoD
- test-strategy
**技能（已有）：**
- atdd
- Fullstack
- Frontend Design
- tdd
- dod
- update-docs
4，用新功能开发工作流开发一个新功能
- 第一步：问 AI：如何执行这个工作流？
- 第二步：让 AI 帮你们写一个新功能开发的技能，来执行这个工作流
- 第三步：使用这个工作流 / 技能完成一个新功能的开发
5，挑战：写一个新的工作流
- Change Requirement
- Bug fixing
- Testing
- Code Refactory
6，加载 rules, skills & workflows
