SDLC 工作流

软件开发生命周期规范化交付流程

需求 设计 开发 测试
Git:http://10.170.136.222/wang_xuefei/ai-plugin

四组角色体系

每组包含 Leader、Executor、Reviewer 三个角色,主工作流仅对接各组 Leader

产品组
product-leader product-executor product-reviewer
架构组
arch-leader arch-executor arch-reviewer
开发组
dev-leader dev-executor dev-reviewer
测试组
test-leader test-executor test-reviewer
编排原则 — 主工作流不直接调用 Executor 或 Reviewer。各组之间不直接跨组沟通,统一通过主工作流协调。

四阶段流程概览

逐阶段推进,层层门禁把关

需求

定义功能边界与验收标准

设计

制定技术方案与接口规约

</>

开发

编码实现并交付产物

测试

质量验证与交付完成

▸ 组内评审▸ 跨组评审▸ 阶段通过▸ 下一阶段
阶段门禁规则
需求通过 → 设计通过 → 开发通过 → 实现摘要跨组评审通过 → 测试通过 → 交付完成。任何阶段未通过,不得进入下一阶段。
主流程总览(含回流路径)
flowchart TD Start(["用户提需求"]) --> MW["主流程识别功能"] %% 需求阶段 MW --> REQ["需求阶段"] REQ --> REQ_LOOP["需求组闭环(≤6轮)
起草文档 → 独立评审"] REQ_LOOP -->|"通过"| REQ_CX{"需求跨组评审
arch/dev/test(参考意见)"} REQ_LOOP -->|"超限未过"| BLOCK1(["流程阻塞"]) REQ_CX -->|"通过"| DES REQ_CX -->|"采纳建议"| REQ_LOOP REQ_CX -->|"不采纳"| DES %% 设计阶段 DES["设计阶段"] --> DES_LOOP["设计组闭环(≤6轮)
起草详细设计 → 独立评审"] DES_LOOP -->|"通过"| DES_CX{"设计跨组评审
product可否决
dev/test(参考意见)"} DES_LOOP -->|"回流至产品组"| REQ_LOOP DES_CX -->|"通过"| DEV DES_CX -->|"被否决"| DES_LOOP %% 开发阶段 DEV["开发阶段"] --> DEV_LOOP["开发组闭环(≤6轮)
编码并更新实现摘要 → 评审"] DEV_LOOP -->|"通过"| DEV_CX{"实现摘要跨组评审
product/arch可否决
test(参考意见)"} DEV_LOOP -->|"回流至架构组"| DES_LOOP DEV_LOOP -->|"回流至产品组"| REQ_LOOP DEV_CX -->|"通过"| TEST DEV_CX -->|"否决"| DEV_LOOP %% 测试阶段 TEST["测试阶段"] --> TC1["测试闭环(用例)
设计并评审用例"] TC1 -->|"通过"| TC1_CX{"用例跨组评审
product/arch/dev可否决"} TC1_CX -->|"通过"| TC2 TC1_CX -->|"否决"| TC1 TC2["测试闭环(执行)
执行测试并评审报告"] -->|"通过"| TC2_CX{"报告跨组评审
product/arch/dev可否决"} TC2_CX -->|"通过"| TC3 TC2_CX -->|"否决"| TC2 TC3["测试闭环(手册)
编写并评审手册
(仅组内)"] -->|"通过"| DONE(["交付完成"]) %% 测试回流分流 TC1 -->|"回流至开发组"| TRIAGE TC2 -->|"回流至开发组"| TRIAGE TRIAGE{"dev 分流判断
实现与设计一致?"} TRIAGE -->|"一致:设计问题"| DES_LOOP TRIAGE -->|"不一致:实现偏差"| DEV_LOOP TRIAGE -->|"混合"| MIX["先修实现偏差
设计缺陷回流架构"] MIX --> DES_LOOP

阶段详解

每个阶段均经历「组内修订闭环 → 组内评审通过 → 跨组评审」后进入下一阶段

1

需求阶段

product-leader 接收任务
executor 起草需求文档
reviewer 独立评审
组内修订闭环 (上限 6 轮)
跨组评审无否决权

产物:docs/{功能名}-需求文档.md
跨组评审:arch-leader(检查技术可行性)、dev-leader(检查实现歧义)、test-leader(检查可测试性)— 三方仅提供参考意见

2

设计阶段

arch-leader 接收需求文档
executor 起草详细设计
reviewer 独立评审
组内修订闭环 (上限 6 轮)
product-leader 有否决权 dev/test 仅参考

产物:docs/{功能名}-详细设计.md
跨组评审:product-leader(检查需求偏离)、dev-leader(检查落地性)、test-leader(检查可测试性)

3

开发阶段

dev-leader 接收设计文档
executor 编写代码实现
reviewer 独立评审
组内修订闭环 (上限 6 轮)
product & arch 有否决权 test 仅参考

产物:源代码 + docs/{功能名}-实现摘要.md
实现摘要跨组评审:product-leader(检查功能点映射)、arch-leader(检查架构风险)、test-leader(检查偏离对测试影响)
特殊规则:测试回流至开发组时,dev-leader 须先对照设计文档检查实现与设计是否一致;若一致则问题在设计层面,应继续回流至架构组

4

测试阶段

测试阶段分三个子环节顺序推进,每个子环节有独立的组内评审和跨组评审。

测试用例设计与评审
executor 设计用例 → reviewer 评审
跨组:三方均有否决权
测试执行与报告评审
执行测试 → 整理报告 → 组内评审
跨组:三方均有否决权
使用手册编写与评审
仅需组内评审
product-leader 单点参考 (无否决权)
三组均有否决权 (用例 + 报告) 使用手册无否决权

产物:docs/{功能名}-测试用例.md、docs/{功能名}-测试报告.md、docs/{功能名}-使用手册.md
评审重点:product 检查需求覆盖度 100% | arch 检查架构风险点覆盖 | dev 检查代码路径覆盖与前端交互分层


跨组评审机制

每阶段组内评审通过后,由主工作流并行收集跨组评审结论统一判断

需求文档评审 arch-leader / dev-leader / test-leader 无否决权
设计文档评审 product-leader / dev-leader / test-leader product 有否决权
实现摘要评审 product-leader / arch-leader / test-leader product & arch 有否决权
测试用例评审 product-leader / arch-leader / dev-leader 三方均有否决权
测试报告评审 product-leader / arch-leader / dev-leader 三方均有否决权
使用手册评审 product-leader (单点参考) 仅参考,无否决权
跨组评审结果处理 — 主工作流并行收集同一轮所有跨组评审结论,再统一汇总判断。具备否决权的 leader 返回"不通过"且问题归属为"当前产物"时,该轮评审整体不通过,回传当前阶段 leader 修订。
跨组评审流程
flowchart TD TRIGGER(["阶段组内评审通过"]) --> MW_ORG["主流程并行发起跨组评审"] MW_ORG --> L1["评审方 A"] MW_ORG --> L2["评审方 B"] MW_ORG --> L3["评审方 C"] L1 --> COLLECT["主流程汇总结论"] L2 --> COLLECT L3 --> COLLECT COLLECT --> R{"汇总结果"} R -->|"全部通过"| NEXT(["进入下一阶段"]) R -->|"有否决票"| BACK["回传给当前阶段 leader
修订后重走:组内评审→跨组评审"] R -->|"仅参考意见未过"| ASK{"当前阶段 leader
是否采纳参考意见?"} ASK -->|"采纳并修订"| BACK ASK -->|"不采纳并留痕"| NEXT

回流机制

下游发现上游问题时,统一通过主工作流回流处理

回流规则

  • 各组 leader/executor/reviewer 不直接跨组沟通
  • 下游发现上游问题 → 当前 leader 反馈给主工作流
  • 主工作流读取反馈并决定回流目标
  • 需求定义不清 → 回流至 产品组
  • 设计方案不合理 → 回流至 架构组
  • 实现错误或遗漏 → 回流至 开发组

回流重入规则

  • 被回流阶段必须重新走完整闭环
  • 产物发生实质修改 → 必须重新评审
  • 上游修订通过 → 下游重新走全链路
  • 上游返回「实质变化」→ 下游组外轮次重置为 0
  • 上游仅「文案微调」→ 组外轮次不重置
  • 待澄清项逐级回溯:需求←设计←开发←测试
回流连击控制 — 同向回流连击达到 10 次时,主工作流停止该方向自动重入并向用户升级。跨阶段累计回流达 50 次时同样停止。
测试回流开发分流判断流程
flowchart TD T_BACK(["测试回流开发组
附缺陷清单"]) --> MW_PASS["主流程转交反馈"] MW_PASS --> DL_RECV["dev-leader 接收反馈"] DL_RECV --> CHECK["对照设计与代码
逐条核对缺陷"] CHECK --> C1{"分类结果"} C1 -->|"全一致:设计问题"| SKIP["跳过组内修订
直接返回不通过"] SKIP --> BACK_ARCH(["回流架构组重做设计"]) C1 -->|"全不一致:实现偏差"| FIX_ALL["组织 dev-executor
修复全部缺陷"] FIX_ALL --> REVIEW_ALL["dev-reviewer 评审"] REVIEW_ALL -->|"通过"| PASS(["返回通过
附修订范围+更新摘要"]) REVIEW_ALL -->|"不通过"| FIX_ALL C1 -->|"部分一致+部分不一致"| SPLIT["按缺陷逐条分流"] SPLIT --> FIX_PART["先修实现偏差部分"] FIX_PART --> REV_PART["dev-reviewer 评审修订"] REV_PART -->|"通过"| MIXED_RETURN(["返回不通过
实现偏差已修
设计缺陷待解"]) MIXED_RETURN --> BACK_ARCH2(["设计缺陷经主流程回流架构组"]) REV_PART -->|"不通过"| FIX_PART

轮次限制规则

各阶段设定组内、组外轮次上限,防止无限循环

阶段 组内轮次上限 组外轮次上限 最多调起 否决权持有者
需求阶段 6 轮 5 轮 6 次 — (无否决权)
设计阶段 6 轮 5 轮 6 次 product-leader
开发阶段 6 轮 20 轮 21 次 product + arch
测试阶段 每子环节 6 轮 40 轮 41 次 product + arch + dev

全局累计限制

  • 跨阶段累计回流上限 50 次
  • 同向回流连击上限 10 次
  • 任一上限触发 → 停止自动重入
  • 向用户升级当前阻塞

轮次重置条件

  • 组内轮次:每次重新调起 leader 时归零
  • 组外轮次:上游返回实质变化时重置
  • 跨组评审重入 → 组外轮次不重置
  • 上游返回文案微调 → 不重置

阶段产物映射

每个阶段形成可复用、已落盘的明确产物文件

阶段 产物路径 内容
需求 docs/{功能名}-需求文档.md 功能边界与验收标准
设计 docs/{功能名}-详细设计.md 技术方案与接口规约
开发 源代码 + docs/{功能名}-实现摘要.md 代码 + 功能点设计项映射
测试 docs/{功能名}-测试用例.md
docs/{功能名}-测试报告.md
docs/{功能名}-使用手册.md
测试用例 / 测试报告 / 使用手册

OpenCode 部署位置说明

以下为三个 install.sh 脚本部署的各文件目标路径

安装模式--global 安装到用户目录,--project [PATH] 安装到指定项目目录。
目录类型 Global 模式 Project 模式
Skills ~/.opencode/skills/ {项目}/.opencode/skills/
Agents ~/.config/opencode/agents/ {项目}/.opencode/agents/
Commands ~/.config/opencode/commands/ {项目}/.opencode/commands/
Plugins ~/.config/opencode/plugins/ {项目}/.opencode/plugins/
SDLC 工作流 (sdlc/install.sh)
Skill sdlc-workflow/SKILL.md 源: sdlc/skills/sdlc-workflow/SKILL.md
Agents
4 个 Leader
product-leader.md
arch-leader.md
dev-leader.md
test-leader.md
→ Agents 目录
源: sdlc/agents/*.md
Command sdlc.md → Commands 目录
Plugin sdlc-tracker.ts → Plugins 目录 (跨阶段轮次追踪)
共享 Agent 池 — SDLC 的 8 个 Executor 和 Reviewer(product/arch/dev/test 的 executor 与 reviewer)由 pool/install.sh 统一安装到 Agents 目录,被 SDLC 和 TDD 复用。所有文件通过 符号链接 方式安装,指向源代码仓库中的实际文件。