# 全流程分步说明：产品 → 开发 → 测试 → 发版

> 把整条链路拆成**按顺序执行的步骤**，每步说清：谁做、做什么、云效上变成什么、下一步谁接。  
> 读完应能照着口令/动作走完一轮（标准路径）。  
> 日期：2026-07-24

---

## 先记住三件事

1. **需求状态 = 阶段真相**  
   看需求状态就知道现在卡在哪一段（分析中 / 待开发 / 开发中 / 待测试…）。
2. **每条需求只有 1 个【交付】容器**  
   分析、设计、开发、测试都挂在这个交付下面（子项），不要再建第二个【交付】。
3. **编号说话，不靠标题查**  
   口令尽量带 `ONEOS-xx`；改标题不影响关联。

```text
需求（状态主轴）
  └─【交付】（容器，关联到需求）
        ├─【分析】【设计】     ← 产品建
        ├─【开发】…            ← 开发建
        └─【测试】             ← 开发提测时建
【发版】另建，挂迭代 + 范围内需求
```

---

## 总步骤一览（共 18 步）

| 阶段 | 步骤 | 一句话 |
|---|---|---|
| **产品** | 1～6 | 从记诉求到交棒给何斐 |
| **开发** | 7～12 | 从拆任务到提测 |
| **测试** | 13～15 | 从接测到测试完成 |
| **发版** | 16～17 | 从建发版到发布结果 |
| **收口** | 18 | 产品验收关闭 |

---

## 阶段 A｜产品（步骤 1～6）

### 步骤 1｜记录需求

| | |
|---|---|
| **谁** | 产品 / AI（YunxiaoPMapp） |
| **做什么** | 把聊天、录音、口述先洗成 AutoRDO，再建一条**产品类需求** |
| **需求状态** | **待处理** |
| **云效任务** | 不建任何任务 |
| **描述里写** | `## 原始诉求（AutoRDO）`；编号区先空着 |
| **口令例** | `记录需求：…；推进至=暂不推进` |
| **为什么** | 先落盘，避免口头需求丢；还没确认值不值得做 |

---

### 步骤 2｜受理确认

| | |
|---|---|
| **谁** | 产品 |
| **做什么** | 确认要做：定优先级、打标签（从云效标签里点选） |
| **需求状态** | **已确认** |
| **云效任务** | 仍不建任务 |
| **口令例** | `受理确认：ONEOS-xx` |
| **为什么** | 和「还没想清楚」的待处理分开；确认后才进分析/设计 |

---

### 步骤 3｜开始分析

| | |
|---|---|
| **谁** | 产品 / AI |
| **做什么** | ① 建 **【交付】**（整条需求的唯一容器，关联到需求）② 建 **【分析】**（挂在交付**子项**下） |
| **需求状态** | **分析中** |
| **云效任务** | 【交付】+【分析】 |
| **口令例** | `开始分析：ONEOS-xx` |
| **验收** | 打开【交付】→「关联项」有需求；「子项」有【分析】 |
| **为什么** | 分析要有落点；后续设计/开发/测试都挂同一棵树 |

---

### 步骤 4｜开始设计

| | |
|---|---|
| **谁** | 产品 / AI |
| **做什么** | 建 **【设计】**（子项挂交付）；收口【分析】计划时间 |
| **需求状态** | **设计中** |
| **云效任务** | 新增【设计】 |
| **口令例** | `开始设计：ONEOS-xx；交付=…；分析=…` |
| **为什么** | 进入原型/方案设计；分析阶段收口 |

---

### 步骤 5｜设计完成

| | |
|---|---|
| **谁** | 产品 / AI |
| **做什么** | 收口【设计】；跑 AutoPRD，把**产品说明**灌进【交付】描述；挂原型 ZIP/截图等附件 |
| **需求状态** | **设计完成** |
| **口令例** | `设计完成：ONEOS-xx；设计=…；原型=…` |
| **为什么** | 开发接手时看的是【交付】里的产品说明，不是聊天记录 |

---

### 步骤 6｜交棒开发（产品终点）

| | |
|---|---|
| **谁** | 产品 / AI |
| **做什么** | 需求改为待开发；**【交付】负责人改为何斐**（不新建开发/测试任务） |
| **需求状态** | **待开发** ★ |
| **交出什么** | 需求编号 +【交付】编号 |
| **口令例** | `交棒开发：ONEOS-xx；交付=…` |
| **为什么** | 产品部到此结束；技术经理从这里拆开发 |

> 旁路：急单可用**快轨**（跳过分析、直接待开发），仍交到同一终点「待开发 + 交付→何斐」。

---

## 阶段 B｜开发（步骤 7～12）

### 步骤 7｜分配开发任务

| | |
|---|---|
| **谁** | 开发主管何斐 / 开发 Skill |
| **做什么** | 输入**交付任务编号** → 自动建 **【开发】**；标题=`【开发】`+需求标题；**描述人工补**；指定开发人；自动写计划时间 |
| **关联** | 子项挂【交付】；关联项挂需求 |
| **需求状态** | 仍为 **待开发**（确认即可，一般不用再改） |
| **口令例** | `分配任务：交付=ONEOS-a；开发人=张三` |
| **为什么** | 一条需求可拆多个开发任务；都挂在同一交付下 |

---

### 步骤 8｜开始开发

| | |
|---|---|
| **谁** | 开发人员 |
| **做什么** | 口令带上**开发任务编号** |
| **开发任务** | → **处理中** |
| **需求状态** | → **开发中** |
| **口令例** | `开始开发：ONEOS-d` |
| **为什么** | 看板一眼能看出「正在写代码」 |

---

### 步骤 9｜写代码 / 提 MR

| | |
|---|---|
| **谁** | 开发人员 |
| **做什么** | 按【交付】里的产品说明实现；分支/MR 建议挂上开发任务编号与需求编号 |
| **需求状态** | 仍为 **开发中** |
| **为什么** | 代码可追溯到哪条开发任务、哪条需求 |

---

### 步骤 10｜AI 自测门禁（开发侧草案）

| | |
|---|---|
| **谁** | AI（开发完成后触发） |
| **做什么** | 找与**需求同标题**的测试计划 → 按用例自测 → 不过则自动提缺陷（标题含开发任务编号）并尝试修复，直到本计划用例全过 |
| **需求状态** | 仍为 **开发中**（未全过前） |
| **为什么** | 在正式提测前先挡住明显问题（属草案，规则可再收紧） |

---

### 步骤 11｜开发任务完成

| | |
|---|---|
| **谁** | 系统 / AI（用例全过之后） |
| **做什么** | 该条【开发】标为**已完成** |
| **需求状态** | → **开发完成**（若有多条开发，建议等**全部**完成再改，避免过早） |
| **为什么** | 标记「代码+门禁」这一段结束 |

---

### 步骤 12｜完成开发 · 正式提测

| | |
|---|---|
| **谁** | 开发人员（自测也完成） |
| **做什么** | 口令「完成开发」→ 自动建 **【测试】**（标题=`【测试】`+任务名）；子项挂【交付】；建议再关联需求；指派测试（如谢佳伟） |
| **需求状态** | → **待测试** ★ |
| **口令例** | `完成开发：ONEOS-d` |
| **为什么** | 开发交棒给测试；测试侧开始接单 |

---

## 阶段 C｜测试（步骤 13～15）

### 步骤 13｜接测试任务

| | |
|---|---|
| **谁** | 测试（谢佳伟等） |
| **做什么** | 打开【测试】任务；确认关联的需求与交付；准备/核对测试计划与用例包（建议按**需求编号**分包，比「同标题」更稳） |
| **需求状态** | **待测试** → 开始执行后改为 **测试中** |
| **为什么** | 正式测试以计划用例为准，不靠口头「测过了」 |

---

### 步骤 14｜执行用例 · 缺陷回流

| | |
|---|---|
| **谁** | 测试执行；失败时回流开发修 |
| **做什么** | 按用例执行；失败建缺陷 → 开发修复 → 再测 |
| **需求状态** | **测试中** |
| **为什么** | 质量关口；未绿不能进发版 |

---

### 步骤 15｜测试完成

| | |
|---|---|
| **谁** | 测试 / AI 辅助判定 |
| **做什么** | **本需求**相关用例全绿 →【测试】收口；通知发版对接人 |
| **需求状态** | → **测试完成** ★ |
| **注意** | 只卡本需求，不卡同迭代里别的需求 |
| **为什么** | 发版范围以「测试完成」的需求为准 |

---

## 阶段 D｜发版（步骤 16～17）

### 步骤 16｜建发版任务

| | |
|---|---|
| **谁** | 发版对接人（时生亮）· 手工或 AI |
| **做什么** | 建 **【发版】**；关联**迭代** + 本期内要上的需求（建议再挂交付/测试）；汇总更新说明 |
| **需求状态** | 进入发布流程时 → **发布中** |
| **为什么** | 一次发版可能含多条需求；要有明确范围清单 |

---

### 步骤 17｜发布结果回写

| | |
|---|---|
| **谁** | 发版对接人 / 流水线 |
| **做什么** | 执行发布 |
| **结果** | 成功 → **发布完成**；失败 → **发布失败**（可重试再进发布中） |
| **为什么** | 成败要回写云效，避免「以为发了其实没发」 |

---

## 阶段 E｜收口（步骤 18）

### 步骤 18｜业务验收 · 关闭

| | |
|---|---|
| **谁** | 产品 |
| **做什么** | 业务验收通过后，关闭需求，并收口【交付】 |
| **需求状态** | → **已关闭** |
| **为什么** | 全链路结束；树上任务与需求一致收口 |

---

## 状态主链（串起来看）

```text
待处理 → 已确认 → 分析中 → 设计中 → 设计完成
    → 待开发          ← 产品交棒给何斐
    → 开发中 → 开发完成
    → 待测试 → 测试中 → 测试完成
    → 发布中 → 发布完成（或发布失败可重试）
    → 已关闭          ← 产品验收关单
```

---

## 四个交棒口（最重要）

| 交棒 | 交出人 | 接棒人 | 交出物 | 状态落点 |
|---|---|---|---|---|
| ① 产品→开发 | 产品 | 何斐 | 需求号 + 交付号 | 待开发 |
| ② 开发→测试 | 开发人 | 测试 | 【测试】任务已建好 | 待测试 |
| ③ 测试→发版 | 测试 | 发版 | 本需求用例全绿 | 测试完成 |
| ④ 发版→产品 | 发版 | 产品 | 发布完成 / 更新说明 | 发布完成 → 已关闭 |

---

## 谁在什么时候动（对照表）

| 步骤 | 产品 | 开发主管 | 开发人 | 测试 | 发版 |
|---|---|---|---|---|---|
| 1～2 记需求/确认 | ● | | | | |
| 3～5 分析设计 | ● | | | | |
| 6 交棒 | ● | 接 | | | |
| 7 分配任务 | | ● | | | |
| 8～9 开始写码 | | | ● | | |
| 10～11 AI门禁/完成任务 | | | ●/AI | | |
| 12 提测 | | | ● | 接 | |
| 13～15 测试 | | | 修缺陷 | ● | |
| 16～17 发版 | | | | | ● |
| 18 关闭 | ● | | | | |

---

## 相关文档

| 文档 | 用途 |
|---|---|
| `docs-四角色泳道流程图.md` | 泳道图总览 |
| `docs-产品部流转流程图.md` | 产品 1～6 细规 |
| `docs-开发侧流转草案.md` | 开发 7～12 细规与待拍板 |
| `yunxiao-pipeline-handbook` | 云效规则与配置 |