新增 AutoRDO 需求清洗工作台与消息中枢，迭代 OneOS V2 设计规范及租赁合同/工作台/车辆等原型，同步云效技能与导航注册；并归档一批 legacy 原型快照。

Co-authored-by: Cursor <cursoragent@cursor.com>

.claude/skills/YunxiaoPM/docs-全流程分步说明.md

@@ -0,0 +1,318 @@
+# 全流程分步说明：产品 → 开发 → 测试 → 发版
+
+> 把整条链路拆成**按顺序执行的步骤**，每步说清：谁做、做什么、云效上变成什么、下一步谁接。  
+> 读完应能照着口令/动作走完一轮（标准路径）。  
+> 日期：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` | 云效规则与配置 |