# Software Dev Workflow

> 软件开发5阶段工作流模板：需求拆解→调研→设计→编码→验证→交付

- Skill: `easyindie/software-dev-workflow` (Agent Skill)
- Install (CLI): `npx skillmds@latest add easyindie/software-dev-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/easyindie/software-dev-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: EasyIndie (https://skillmd.com/u/easyindie)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/easyindie/software-dev-workflow

---


# 软件开发工作流

## 概述

Conductor 调度的标准 5 阶段工作流模板，覆盖从需求到交付的全流程。

## 阶段总览

```
收到需求 → 需求拆解 → 决策期(可选) → 设计期 → 实现期 → 验证期 → 交付期
```

## 阶段 0：需求接收与拆解

1. 收到需求后 `message.send("✅ 收到，正在拆解")`
2. 判断需求清晰度：
   - **清晰** → 进入下一阶段
   - **模糊** → 向用户提问澄清（3 个以内问题，一次性问完）
   - **简单改动**（几行代码、修文案）→ 直接跳至实现期
3. 拆解任务范围：
   - 需要调研？→ 进入决策期
   - 需要设计？→ 进入设计期
   - 仅代码改动？→ 直接进入实现期

## 阶段 1：决策期（可选）

触发条件：技术方案不确定、多候选方案、需评估三方依赖

```
1. message.send("🔍 正在调研 <topic>...")
2. sessions_spawn(research-agent, task=...)
   task 模板：
   ```
   调研目标：<明确的问题>
   背景：<上下文>
   期望产出：
   - 候选方案对比（至少2个）
   - 推荐方案及理由
   - 不选方案及原因
   - 风险说明
   交付路径：spec/research/<topic>.md
   ```
3. sessions_yield 等待完成
4. message.send("🔍 <topic> 调研完成")
5. 审核调研报告：
   - 必须有明确推荐方案
   - 必须有风险说明
   - 缺少 → 要求补充后继续
```

门禁：调研确认前不进入设计期

## 阶段 2：设计期

触发条件：新功能、重构、架构变更、交互变更

```
按需并行调用：
- 有界面交互 → sessions_spawn(ux-agent, task=...) → spec/ux/*.md
- 有架构变更 → sessions_spawn(architect-agent, task=...) → spec/architecture/*.md  
- 有 API 变更 → sessions_spawn(architect-agent, task=...) → spec/api/*.md

每个 spawn 前后各推送一次进度
```

门禁：
- [ ] 设计中涉及的外部接口已确认
- [ ] 设计无已知冲突
- [ ] 风险已评估
- [ ] 设计未确认 → 不进入编码

## 阶段 3：实现期

```
1. 整理输入（需求文档 + 设计方案 + 调研报告）
2. message.send("🛠️ 正在编码实现 <feature>...")
3. sessions_spawn(coding-agent, task=...)
   task 模板：
   ```
   实现目标：<功能>
   项目路径：<repo>
   输入背景：
   - 需求：<链接/描述>
   - 设计方案：<链接>
   
   具体任务：
   - <任务1>
   - <任务2>
   
   约束：
   - 必须保留现有测试通过
   - 代码风格：<项目约定>
   
   产出：
   - 改动的文件清单
   - 关键实现说明（如需要）
   ```
4. sessions_yield 等待完成
5. message.send("🛠️ <feature> 编码完成")
6. 审核编码结果
```

编码中发现架构问题 → 暂停编码，回设计期修订

## 阶段 4：验证期

```
1. 汇总改动内容给 qa-agent
2. message.send("🧪 正在执行 <feature> 测试...")
3. sessions_spawn(qa-agent, task=...)
   task 模板：
   ```
   验证目标：<feature>
   改动文件：<清单>
   相关需求：<链接>
   执行策略：
   - 单元测试覆盖改动逻辑
   - 集成测试验证关键流程
   - 边界测试找异常场景
   
   产出：测试报告（通过数/总数 + 失败详情）
   ```
4. sessions_yield 等待完成
5. message.send("🧪 <feature> 测试完成，结果：<通过数>/<总数>")
```

全部通过 → 进入交付期
有失败 → 返回编码修复

## 阶段 5：交付期

```
需要部署 → sessions_spawn(devops-agent, task=...) 且前置 message.send("📦 正在部署...")
需要文案 → sessions_spawn(growth-agent, task=...)

最终汇总：
✅ 全部完成！
📋 需求: <功能名称>
📂 改动文件: <文件清单>
🧪 测试结果: <通过/失败>
📦 部署状态: <已部署/待部署>
⚠️ 风险: <如有>
```

## 异常处理

| 场景 | 处理 |
|------|------|
| 子 agent 无响应 | 重试一次，仍无响应则报告用户 |
| 设计冲突 | conductor 消解，必要时让用户决策 |
| 编码发现问题 | 暂停编码，派 architect-agent 修订 |
| 测试严重失败 | 阻塞上线，返回 coding-agent 修复 |
| 需求变更 | 暂停，重新评估影响范围 |
| 子 agent 返回不符合预期 | 明确不足后重新 spawn |

## 进度推送铁律

- sessions_spawn 之前必须先推进度
- sessions_yield 返回后必须先推完成状态
- 异常捕获后必须立即推问题