@chongyan/autospec 1.0.1

package/knowledge/process/02-design.md

@@ -0,0 +1,123 @@
+# 方案设计
+
+## 目标
+将需求文档转化为可指导编码的技术方案，选择合理的架构和技术路线。
+
+## 输入
+经需求评审通过的结构化需求文档（含关键假设清单）。
+
+## 核心动作
+1. 分析需求的技术挑战和关键决策点
+2. 设计系统架构（分层、模块划分、组件关系）
+3. 设计数据模型（实体、关系、存储选型）
+4. 设计接口/API（输入输出、协议、错误处理）
+5. 技术选型（框架、工具、第三方服务）
+6. 评估方案的trade-off，记录决策理由（选了什么、为什么、放弃了什么）
+7. 校验需求阶段的关键假设，更新假设状态
+
+## 输出
+技术方案文档，包含：
+- 架构设计（含架构图）
+- 数据模型设计
+- 接口/API设计
+- 技术选型及理由
+- 关键决策记录（选了什么、为什么、放弃了什么）
+- 风险评估和应对策略
+- 预估工作量和拆分计划
+- **关键假设清单**（继承需求阶段 + 本阶段新增，标注已确认/待确认）
+- **证据清单**（支撑设计合理性的依据：参考项目、性能数据、技术文档等）
+
+## 团队对抗审查
+
+### 触发机制
+方案设计开始前，继承或重新评估复杂度（参考 `skills/support/complexity-assessor.md`）：
+
+| 复杂度级别 | 参与角色 | 说明 |
+|------------|----------|------|
+| 简单（≤5分） | 技术负责人 | 快速通道 |
+| 中等（6-8分） | 技术负责人、相关工程师 | 引入工程师视角 |
+| 复杂（≥9分） | 技术负责人、全部相关工程师 | 完整团队 |
+
+### 强制触发规则
+以下场景强制引入特定角色（不受复杂度影响）：
+- 涉及新架构/框架 → 技术负责人（已包含则跳过）
+- 跨系统变更 → 技术负责人、运维工程师
+- 新服务部署 → 运维工程师
+- 涉及用户数据 → 安全工程师
+- 涉及支付/资金交易 → 安全工程师
+
+### 对抗审查流程
+1. **并行启动角色Agent**：每个角色独立审查（信息隔离）
+2. **各角色关注点**：
+   - 技术负责人：架构合理性、过度设计检查、技术选型
+   - 后端工程师：API设计、数据库设计、性能（如涉及）
+   - 前端工程师：组件设计、状态管理、用户体验（如涉及）
+   - 数据工程师：数据模型、ETL设计（如涉及）
+   - AI工程师：模型选型、评估方案（如涉及）
+   - 安全工程师：安全设计、数据保护（如触发）
+   - 运维工程师：部署方案、监控设计（如触发）
+3. **汇总意见**：生成团队对抗审查报告
+4. **处理分歧**：
+   - 一致通过 → 进入方案文档生成
+   - 有分歧 → 标记NEEDS CLARIFICATION，交互模式等待用户决策
+   - 有重大问题 → 返回修正
+
+### 与现有流程的关系
+- 团队对抗审查在 Layer 2 之前执行
+- 团队对抗审查不通过 → 不进入 Layer 2
+- 简单任务可跳过团队对抗审查，直接使用 design-reviewer
+
+## 质量关卡
+
+### Layer 1: 确定性验证
+- [ ] 方案文档符合规定的schema格式
+- [ ] 接口定义可自动校验（如OpenAPI schema）
+- [ ] 数据模型可自动校验（如ERD schema）
+- [ ] 需求文档中的每条功能点在方案中有对应设计（覆盖率检查）
+
+### Layer 2: AI审查（design-reviewer执行）
+必须满足：
+- [ ] 方案覆盖需求文档中的所有功能点（参考 methodology/checklists/design.md）
+- [ ] 关键技术决策有明确理由，不是拍脑袋
+- [ ] 接口定义清晰，前后端/模块间可独立开发
+- [ ] 不过度设计：复杂度与需求匹配
+- [ ] 需求阶段的关键假设已校验，无矛盾
+
+建议满足：
+- [ ] 考虑了可扩展性（未来可能的变化方向）
+- [ ] 有性能预估和瓶颈分析
+- [ ] 标注了技术风险和降级方案
+
+输出格式：通过/不通过 + 逐项判定 + 证据 + 修复建议
+
+## 关键假设
+本阶段典型假设：
+- 技术选型的适配性假设
+- 性能和并发的预估假设
+- 第三方服务的可用性假设
+- 数据量级和增长率的假设
+
+规则：待确认假设超过3个 → 升级人工确认。
+
+## AI自主决策边界
+| 决策类型 | 处理方式 |
+|---------|---------|
+| 架构级决策（单体vs微服务等） | **必须人工确认** |
+| 设计选型有多个可行方案 | **必须人工选择** |
+| 涉及新技术引入 | **必须人工评估风险** |
+| 技术选型（栈内已有方案） | AI自主 |
+| 模块划分和分层 | AI自主 |
+| 接口定义的具体字段 | AI自主 |
+| 不确定的技术决策 | AI做合理默认+标记NEEDS CLARIFICATION（最多3个） |
+
+## 反模式清单
+1. **过度设计**：为不存在的需求预留扩展。检测：每个设计决策回溯到具体需求，无法回溯的删除
+2. **技术偏好驱动**：选自己熟悉的而非最合适的。检测：至少列出2个备选方案并对比
+3. **忽略非功能需求**：只设计功能不考虑性能/安全。检测：用checklist强制覆盖
+4. **假设漂移**：设计方案偏离需求阶段的关键假设。检测：逐项校验继承假设
+5. **PPT架构**：画了漂亮的图但不可落地。检测：每个组件必须有具体技术实现方案
+
+## 常见问题
+- **过度设计**：为不存在的需求预留扩展。应对：每个设计决策回溯到具体需求
+- **技术选型偏好**：选自己熟悉的而非最合适的。应对：至少列出2个备选方案并对比
+- **忽略非功能需求**：只设计功能不考虑性能/安全。应对：用checklist强制覆盖

package/knowledge/process/03-implementation.md

@@ -0,0 +1,90 @@
+# 编码实现（含研发自测）
+
+## 目标
+将技术方案忠实落地为可运行代码，并通过研发自测验证基本正确性。
+
+## 输入
+经方案评审通过的技术方案文档（含关键假设清单）。
+
+## 核心动作
+
+### 编码（code-implementer执行）
+1. 按方案设计的架构和模块划分编写代码
+2. 严格遵循方案中的接口定义和数据模型
+3. 编写必要的注释（逻辑不自明的地方）
+4. 遵循项目编码规范
+5. 校验设计阶段的关键假设，在代码中体现约束
+
+### 研发自测（test-generator + test-coverage-reviewer执行）
+6. 编写单元测试，覆盖核心逻辑
+7. 编写集成测试，验证模块间交互
+8. 本地运行全部测试通过
+9. 自查代码与方案的一致性
+
+> 研发自测是编码阶段的一部分，不是独立阶段——写完代码就该自测，自测通过才有资格提交审查。
+
+## 输出
+自测通过的代码，包含：
+- 功能代码
+- 单元测试和集成测试
+- 自测报告（覆盖了什么、测试结果）
+- **关键假设清单**（继承设计阶段 + 实现中新发现的假设）
+- **证据清单**（测试通过截图/日志、覆盖率报告）
+
+## 质量关卡
+
+### Layer 1: 确定性验证
+- [ ] 编译通过（零错误）
+- [ ] 所有单元测试通过
+- [ ] 所有集成测试通过
+- [ ] lint检查通过（零违规或仅warning）
+- [ ] 类型检查通过（如适用）
+
+**Layer 1不过，不进Layer 2。**
+
+### Layer 2: AI审查（code-reviewer执行）
+必须满足：
+- [ ] 代码实现与技术方案一致，未自作主张偏离设计（参考 methodology/checklists/code.md）
+- [ ] 单元测试覆盖核心逻辑路径
+- [ ] 无明显安全漏洞（SQL注入、XSS、越权等OWASP Top 10）
+- [ ] 设计阶段的关键假设在代码中得到正确体现
+
+建议满足：
+- [ ] 测试覆盖边界条件和异常路径
+- [ ] 代码可读性良好，命名清晰
+- [ ] 无硬编码的配置项
+- [ ] 错误处理完善
+
+输出格式：通过/不通过 + 逐项判定 + 证据 + 修复建议
+
+## 关键假设
+本阶段典型假设：
+- 第三方库API行为的假设
+- 并发/线程安全的假设
+- 数据格式和编码的假设
+- 环境和依赖版本的假设
+
+规则：待确认假设超过3个 → 升级人工确认。
+
+## AI自主决策边界
+| 决策类型 | 处理方式 |
+|---------|---------|
+| 发现方案有缺陷需要调整 | **必须人工确认是否回退设计** |
+| 方案未覆盖的边界情况 | **人工决定处理方式** |
+| 实现细节（变量命名、代码组织） | AI自主 |
+| 测试用例设计 | AI自主 |
+| 错误处理策略（方案内） | AI自主 |
+| 不确定的实现决策 | AI做合理默认+标记NEEDS CLARIFICATION（最多3个） |
+
+## 反模式清单
+1. **偏离设计**：编码时觉得方案不好，自行修改。检测：逐项对照方案接口和数据模型
+2. **自测走过场**：只测happy path。检测：checklist强制要求覆盖异常路径
+3. **过度优化**：在实现阶段做性能优化。检测：先正确后优化，除非方案明确要求
+4. **蛮力修复**：测试不过用@JsonIgnore、跳过测试、增加内存。检测：禁止skip/ignore注解
+5. **虚假成功声明**：测试红灯时称代码完成。检测：Layer 1确定性验证不可绕过
+6. **重复造轮子**：不搜索项目已有工具/组件就新建。检测：新建文件前搜索同名/同功能
+
+## 常见问题
+- **偏离设计**：编码时觉得方案不好，自行修改。应对：严格对照方案，有异议回退到设计阶段
+- **自测走过场**：只测happy path。应对：checklist强制要求覆盖异常路径
+- **过度优化**：在实现阶段做性能优化。应对：先正确，后优化，除非方案明确要求

package/knowledge/process/04-review.md

@@ -0,0 +1,80 @@
+# 代码审查
+
+## 目标
+独立审查代码质量、安全性、性能，确保代码达到可合并标准。
+
+## 输入
+- 自测通过的代码（Layer 1确定性验证已通过）
+- 技术方案文档（对照设计）
+- 自测报告
+- 关键假设清单（累积至今）
+
+## 核心动作
+1. 检查代码与技术方案的一致性（逐项对照）
+2. 审查代码质量（可读性、可维护性、命名规范）
+3. 审查安全性（注入、越权、敏感信息泄露等OWASP Top 10）
+4. 审查性能（明显的性能问题、资源泄露、N+1查询）
+5. 审查测试充分性（覆盖率、边界条件）
+6. 校验关键假设的跨阶段一致性
+7. 输出审查意见（结构化格式，附证据）
+
+> **做审分离（DP2）**：代码审查必须由独立于编码实现的AI实例执行。
+
+## 输出
+审查报告，包含：
+- 结论：通过 / 不通过
+- 逐项审查结果（每项附证据引用）
+- 必须修复的问题（blocking）
+- 建议改进的问题（non-blocking）
+- 修复建议
+- **关键假设验证结果**（上游假设在代码中的体现是否正确）
+
+## 质量关卡
+
+### Layer 1: 确定性验证
+- [ ] 编译通过（在审查环境重新验证）
+- [ ] 所有测试通过（在审查环境重新运行）
+- [ ] lint通过
+- [ ] 类型检查通过
+
+### Layer 2: AI审查（独立code-reviewer执行）
+必须满足：
+- [ ] 无blocking级别的审查问题
+- [ ] 代码与方案设计一致
+- [ ] 无安全漏洞
+- [ ] 测试覆盖核心逻辑
+- [ ] 关键假设跨阶段一致
+
+建议满足：
+- [ ] non-blocking问题已记录，计划后续处理
+- [ ] 代码风格统一
+
+输出格式：通过/不通过 + 逐项判定 + 证据 + 修复建议
+
+## 关键假设
+本阶段重点校验：
+- 需求→设计→实现的假设链是否一致
+- 是否有假设在实现中被隐式修改但未更新文档
+
+规则：发现假设不一致 → 必须标记为blocking问题。
+
+## AI自主决策边界
+| 决策类型 | 处理方式 |
+|---------|---------|
+| 发现架构级问题（需重新设计） | **必须人工确认是否回退** |
+| 审查意见有争议 | **人工裁决** |
+| blocking vs non-blocking分类 | AI自主（有明确标准） |
+| 修复建议的具体方案 | AI自主 |
+| 代码风格问题的严重程度 | AI自主 |
+
+## 反模式清单
+1. **橡皮图章**：审查走过场，什么都通过。检测：每条"通过"必须附具体证据
+2. **吹毛求疵**：纠结代码风格等非关键问题。检测：区分blocking和non-blocking，风格问题不可blocking
+3. **缺乏上下文**：不了解需求和设计就审代码。检测：审查输入必须包含方案文档，审查步骤必须先读方案
+4. **假设漂移忽视**：不校验跨阶段假设一致性。检测：审查输出必须包含假设验证section
+5. **自我确认偏差**：做和审是同一个AI实例。检测：command-runner确保实例隔离
+
+## 常见问题
+- **橡皮图章**：审查走过场，什么都通过。应对：审类skill有明确评判标准，逐项检查
+- **吹毛求疵**：纠结代码风格等非关键问题。应对：区分blocking和non-blocking，不因风格问题阻塞
+- **缺乏上下文**：不了解需求和设计就审代码。应对：审查输入必须包含方案文档

package/knowledge/process/05-testing.md

@@ -0,0 +1,90 @@
+# QA测试
+
+## 目标
+独立于开发团队，从用户视角验证产品功能正确性、边界覆盖和整体质量。
+
+## 输入
+- 审查通过的代码（Layer 1+Layer 2均通过）
+- 结构化需求文档（对照验收标准）
+- 技术方案文档（理解设计意图）
+- 关键假设清单（累积至今，需最终验证）
+
+## 核心动作
+1. **制定测试方案**（test-planner执行）
+   - 基于需求文档梳理测试场景
+   - 设计端到端测试用例
+   - 规划边界条件和异常路径覆盖
+2. **执行系统测试**
+   - 功能验证：逐条对照验收标准
+   - 边界测试：极端值、空值、并发等
+   - 兼容性测试（如适用）
+3. **探索性测试**（exploratory-tester执行）
+   - 非预设路径的主动探索
+   - 模拟真实用户使用习惯
+4. **缺陷分析**（defect-analyzer执行）
+   - 发现的问题进行根因定位
+   - 评估严重性和影响范围
+   - 判断回归风险
+5. **关键假设最终验证**
+   - 校验需求→设计→实现全链路假设的一致性
+   - 在真实运行环境中验证假设是否成立
+
+## 输出
+测试报告，包含：
+- 测试方案和覆盖范围
+- 测试用例执行结果
+- 缺陷列表（含严重性、根因分析、复现步骤）
+- 结论：通过 / 不通过
+- 遗留风险评估
+- **关键假设最终验证结果**
+- **证据清单**（测试日志、截图、覆盖率数据）
+
+## 质量关卡
+
+### Layer 1: 确定性验证
+- [ ] 所有自动化测试用例执行通过
+- [ ] 端到端测试通过
+- [ ] 性能测试在可接受范围内（如适用）
+
+### Layer 2: AI审查（test-coverage-reviewer执行）
+必须满足：
+- [ ] 需求文档中所有验收标准逐条验证通过
+- [ ] 无严重（Critical/Major）级别缺陷
+- [ ] 核心用户场景端到端测试通过
+- [ ] 关键假设全链路验证通过
+
+建议满足：
+- [ ] 边界条件和异常路径有覆盖
+- [ ] 探索性测试已执行
+- [ ] 遗留风险已评估并记录
+
+输出格式：通过/不通过 + 逐项判定 + 证据 + 修复建议
+
+## 关键假设
+本阶段重点验证：
+- 全链路假设一致性（需求→设计→实现→测试）
+- 性能假设在真实环境中是否成立
+- 第三方服务在真实场景中的表现
+
+规则：关键假设验证失败 → 必须追溯到假设来源阶段回退修正。
+
+## AI自主决策边界
+| 决策类型 | 处理方式 |
+|---------|---------|
+| 缺陷是否为blocking需严重性判断 | **人工判断** |
+| 测试覆盖范围是否充分 | **人工确认**（涉及业务优先级） |
+| 测试用例设计 | AI自主 |
+| 缺陷根因分析 | AI自主 |
+| 测试执行顺序 | AI自主 |
+
+## 反模式清单
+1. **只测happy path**：不测边界和异常。检测：测试方案必须包含边界条件覆盖计划
+2. **测试与需求脱节**：测了很多但没对照验收标准。检测：逐条对照需求文档验收标准
+3. **缺陷描述不清**：无法复现。检测：每个缺陷必须包含复现步骤和环境信息
+4. **假设验证遗漏**：只测功能不验假设。检测：输出必须包含关键假设验证section
+5. **测试环境偏差**：测试环境与生产差异大导致结果不可信。检测：记录环境差异并评估影响
+
+## 常见问题
+- **只测happy path**：不测边界和异常。应对：测试方案必须包含边界条件覆盖计划
+- **测试与需求脱节**：测了很多但没对照验收标准。应对：逐条对照需求文档的验收标准
+- **缺陷描述不清**：无法复现。应对：每个缺陷必须包含复现步骤和环境信息

package/knowledge/process/06-delivery.md

@@ -0,0 +1,88 @@
+# 交付部署
+
+## 目标
+将测试通过的代码安全、可控地部署到生产环境。
+
+## 输入
+- QA测试通过的代码
+- 测试报告（含遗留风险评估）
+- 关键假设清单（全链路已验证）
+
+## 核心动作
+1. **发布前置检查**（release-checker执行）
+   - 检查所有前置条件是否满足
+   - 确认遗留风险可接受
+   - 确认回滚方案就绪
+   - 检查宪法门禁（不可违反红线）
+2. **编写变更记录**
+   - 本次发布包含的功能/修复
+   - 影响范围
+   - 注意事项
+   - 关键假设和风险的最终状态
+3. **执行部署**（**必须人工确认**——不可逆动作）
+   - 按部署流程执行
+   - 监控部署过程
+4. **部署后验证**
+   - 冒烟测试：核心功能是否正常
+   - 监控指标：是否有异常波动
+   - 回滚方案验证：确认可快速回滚
+
+## 输出
+- 变更记录
+- 部署结果确认
+- 部署后验证报告
+- **证据清单**（部署日志、冒烟测试结果、监控截图）
+
+## 质量关卡
+
+### Layer 1: 确定性验证
+- [ ] 发布前置checklist全部通过（参考 methodology/checklists/release.md）
+- [ ] 回滚方案已确认且可执行
+- [ ] 变更记录已编写
+- [ ] 部署后冒烟测试通过
+- [ ] 监控指标无异常（自动化监控检查）
+
+### Layer 2: AI审查（release-checker执行）
+必须满足：
+- [ ] 所有前置条件满足
+- [ ] 遗留风险已评估且可接受
+- [ ] 回滚方案完整可行
+- [ ] 变更记录准确完整
+
+建议满足：
+- [ ] 监控告警已配置
+- [ ] 相关方已通知
+- [ ] 灰度/金丝雀策略已准备（如适用）
+
+输出格式：通过/不通过 + 逐项判定 + 证据 + 修复建议
+
+## 关键假设
+本阶段重点确认：
+- 部署环境与测试环境的一致性假设
+- 数据迁移的安全性假设
+- 服务依赖的可用性假设
+
+规则：任何假设存疑 → 暂停部署，人工评估。
+
+## AI自主决策边界
+| 决策类型 | 处理方式 |
+|---------|---------|
+| 生产环境部署执行 | **必须人工确认**（不可逆动作） |
+| 数据库迁移执行 | **必须人工确认**（不可逆动作） |
+| 部署后发现异常是否回滚 | **人工决定** |
+| 外部API调用/通知发送 | **必须人工确认**（不可逆动作） |
+| 变更记录编写 | AI自主 |
+| 前置检查执行 | AI自主 |
+| 冒烟测试执行 | AI自主 |
+
+## 反模式清单
+1. **带病上线**：有已知问题但赶工期。检测：遗留风险必须记录并人工确认可接受
+2. **忘记回滚方案**：出问题了不知道怎么回退。检测：回滚方案是前置检查的必选项
+3. **部署后不验证**：部署完就走人。检测：冒烟测试是质量关卡的必须项
+4. **自动执行不可逆动作**：未经人工确认就执行DB迁移/部署。检测：command-runner强制人工确认
+5. **环境差异忽视**：测试环境通过但生产环境不同。检测：前置检查包含环境一致性校验
+
+## 常见问题
+- **带病上线**：有已知问题但赶工期。应对：遗留风险必须记录并人工确认可接受
+- **忘记回滚方案**：出问题了不知道怎么回退。应对：回滚方案是发布前置检查的必选项
+- **部署后不验证**：部署完就走人。应对：冒烟测试是质量关卡的必须项

package/knowledge/process/README.en.md

@@ -0,0 +1,38 @@
+# Development Pipeline
+
+This directory contains AutoSpec's development pipeline definitions, including 6 stages and 4 iteration modes.
+
+## Directory Structure
+
+```
+pipeline/
+├── overview.md         # Pipeline overview (startup gate + execution modes + full flow)
+├── 01-requirement.md   # Stage 1: Requirement Analysis
+├── 02-design.md        # Stage 2: Design Planning
+├── 03-implementation.md # Stage 3: Code Implementation
+├── 04-review.md        # Stage 4: Code Review
+├── 05-testing.md       # Stage 5: QA Testing
+└── 06-delivery.md      # Stage 6: Delivery
+```
+
+## Pipeline Overview
+
+```
+[Stage 0] → Requirement → Design → Implementation → Review → Testing → Delivery
+  Env Check      │            │           │            │         │          │
+                 ↓            ↓           ↓            ↓         ↓          ↓
+             [Layer 1+2]  [Layer 1+2] [Layer 1+2] [Layer 1+2] [Layer 1+2] [Layer 1+2]
+```
+
+## Iteration Modes
+
+| Mode | Stages | Description | Use Case |
+|------|--------|-------------|----------|
+| **Waterfall** | 01→02→03→04→05→06 | Full 6 stages | New features, major changes |
+| **Agile** | 01 + [02→03→04]×N + 05→06 | Story-driven cycles | Iterative development |
+| **Experiment** | 01→02→03 + Evaluation | Prototype + AI evaluation | Technical exploration |
+| **Hotfix** | 01→03→04→06 | Fast track | Emergency fixes |
+
+## Detailed Documentation
+
+For complete pipeline definitions, startup gate, and execution mode details, see [overview.md](overview.md).

package/knowledge/process/README.md

@@ -0,0 +1,48 @@
+# 研发流程
+
+本目录包含 AutoSpec 的研发流程定义，包括 6 个阶段和 4 种迭代模式。
+
+## 目录结构
+
+```
+process/
+├── overview.md         # 流程概览（启动门禁 + 执行模式 + 全流程）
+├── ai-sdlc.md        # AI-Enhanced SDLC 规范
+├── 01-requirement.md   # 阶段1：需求分析
+├── 02-design.md        # 阶段2：方案设计
+├── 03-implementation.md # 阶段3：编码实现
+├── 04-review.md        # 阶段4：代码审查
+├── 05-testing.md       # 阶段5：QA测试
+└── 06-delivery.md      # 阶段6：交付部署
+```
+
+## 流程概览
+
+```
+[Stage 0] → 需求分析 → 方案设计 → 编码实现 → 代码审查 → QA测试 → 交付部署
+  环境就绪      │           │           │           │          │          │
+               ↓           ↓           ↓           ↓          ↓          ↓
+           [双层验证]  [双层验证]  [双层验证]  [双层验证] [双层验证] [双层验证]
+```
+
+## 迭代模式
+
+| 模式 | 阶段 | 说明 | 场景 |
+|------|------|------|------|
+| **Waterfall** | 01→02→03→04→05→06 | 完整6阶段 | 新功能、重大变更 |
+| **Agile** | 01 + [02→03→04]×N + 05→06 | 故事驱动循环 | 迭代开发 |
+| **Experiment** | 01→02→03 + 效果评测 | 原型+AI评估 | 技术探索 |
+| **Hotfix** | 01→03→04→06 | 快速通道 | 紧急修复 |
+
+## 详细文档
+
+| 文件 | 说明 |
+|------|------|
+| [overview.md](overview.md) | 流程概览、启动门禁、执行模式、双层验证 |
+| [ai-sdlc.md](ai-sdlc.md) | AI-Enhanced SDLC 规范（AI 辅助各阶段的最佳实践） |
+| [01-requirement.md](01-requirement.md) | 需求分析阶段详细定义 |
+| [02-design.md](02-design.md) | 方案设计阶段详细定义 |
+| [03-implementation.md](03-implementation.md) | 编码实施阶段详细定义 |
+| [04-review.md](04-review.md) | 代码审查阶段详细定义 |
+| [05-testing.md](05-testing.md) | QA测试阶段详细定义 |
+| [06-delivery.md](06-delivery.md) | 交付部署阶段详细定义 |