全流程分步说明：产品 → 开发 → 测试 → 发版
把整条链路拆成按顺序执行的步骤，每步说清：谁做、做什么、云效上变成什么、下一步谁接。
读完应能照着口令/动作走完一轮（标准路径）。
日期：2026-07-24
先记住三件事
- 需求状态 = 阶段真相
看需求状态就知道现在卡在哪一段（分析中 / 待开发 / 开发中 / 待测试…）。
- 每条需求只有 1 个【交付】容器
分析、设计、开发、测试都挂在这个交付下面（子项），不要再建第二个【交付】。
- 编号说话，不靠标题查
口令尽量带 ONEOS-xx；改标题不影响关联。
总步骤一览（共 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｜业务验收 · 关闭
|
|
| 谁 |
产品 |
| 做什么 |
业务验收通过后，关闭需求，并收口【交付】 |
| 需求状态 |
→ 已关闭 |
| 为什么 |
全链路结束；树上任务与需求一致收口 |
状态主链（串起来看）
四个交棒口（最重要）
| 交棒 |
交出人 |
接棒人 |
交出物 |
状态落点 |
| ① 产品→开发 |
产品 |
何斐 |
需求号 + 交付号 |
待开发 |
| ② 开发→测试 |
开发人 |
测试 |
【测试】任务已建好 |
待测试 |
| ③ 测试→发版 |
测试 |
发版 |
本需求用例全绿 |
测试完成 |
| ④ 发版→产品 |
发版 |
产品 |
发布完成 / 更新说明 |
发布完成 → 已关闭 |
谁在什么时候动（对照表）
| 步骤 |
产品 |
开发主管 |
开发人 |
测试 |
发版 |
| 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 |
云效规则与配置 |
