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/.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 模板：

实现目标：<功能> 项目路径： 输入背景：

• 需求：<链接/描述>
• 设计方案：<链接>

具体任务：

• <任务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 模板：

验证目标： 改动文件：<清单> 相关需求：<链接> 执行策略：

• 单元测试覆盖改动逻辑
• 集成测试验证关键流程
• 边界测试找异常场景

产出：测试报告（通过数/总数 + 失败详情）

4. sessions_yield 等待完成
5. message.send("🧪 <feature> 测试完成，结果：<通过数>/<总数>")

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

阶段 5：交付期

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

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

异常处理

进度推送铁律

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