devlab-spec-driven-devlisted

# devlab-spec-driven-dev ## 用途 将"AI 协作开发"从"边聊边改代码"升级为**spec 驱动**：先把需求沉淀为结构化提案（requirements / design / tasks），经人类审查确认后，再由 AI 分任务顺序执行并回归。适用于**任何**支持 spec 工作流的 AI IDE / Agent —— Kiro 的 `.kiro/specs/` 只是其中一个具体实现（见 `references/REFERENCE-KIRO-SPEC-EXAMPLE.md`）。 **核心价值**：把"意图"显式化、可审查、可追溯、可分任务并行/续跑，避免大改动中途失焦、返工、上下文丢失。 ## 适用场景 - 中大型功能/重构：需求有多个子任务、需要拆解与阶段验收。 - 多轮协作 / 跨会话续跑：需要一份稳定的"事实源"承接进度。 - 需要人类在关键决策点把关（架构、破坏性变更）的 AI 协作开发。 ## 不适用场景 - 一次性小改动（改个文案、修个明显 typo）——直接改即可，不必起 spec。 - 纯探索性调研（用 ask/研究类流程）。 ## 输入 - 需求描述（自然语言）。 - 目标代码库现状。 - 约束与偏好（语言、是否允许破坏性变更、测试力度等）。 ## 输出 - `specs/<name>/` 提案三件套：`requirements.md`（需求+验收标准）、`design.md`（技术设计）、`tasks.md`（可勾选任务清单）。 - 可选：`README.md` 概览、ADR 架构决策记录、`STATUS.md`/`UPDATE_SUMMARY.md` 进度跟踪。 - 分任务执行后的实现 + 回归结果。 ## 工作流 ``` Phase 1: 需求 → requirements.md → 澄清目标、边界、验收标准（每条需求可验证） → ⛔ Gate G1（human）：需求是否完整/无歧义 Phase 2: 设计 → design.md → 技术方案、模块划分、数据流、正确性属性、破坏性变更影响面 → 调研是否有成熟库/方案可复用 → ⛔ Gate G2（human）：设计与取舍确认 Phase 3: 任务拆解 → tasks.md → 拆为可独立勾选、可验证的任务（含依赖顺序） → ⛔ Gate G3（human）：任务粒度与顺序确认 Phase 4: 执行（Run all tasks） → 按 tasks.md 顺序执行；可委派子代理逐任务实现 → 每完成一个任务勾选状态、同步 tasks.md → 变更调用侧同步（破坏性变更） Phase 5: 回归与收尾 → 跑测试/评测；更新 STATUS；必要时回写 design（实现偏差） ``` ### 提案质量约束（默认规范，可按团队覆盖） 1. **语言一致**：提案与代码注释使用团队约定语言（本团队默认中文）。 2. **破坏性变更策略**：允许破坏性变更，但**必须同步变更所有调用侧**，不保留无意义的向后兼容代码。 3. **工程化思维**：方案要面向可维护性与复用，而非"为解决问题而解决"。 4. **测试力度适配**：保留必要的属性/单元测试，**减少不必要的测试以加快提案落地**；关键正确性属性必须覆盖。 5. **提案-实现一致**：实现偏离设计时，回写 design/tasks，保持事实源一致。 ### human-on-the-loop 决策门禁