扩展氢能站点、加氢记录与台账原型链路，新增工作台、车辆资产 H5、自营物流等原型，并同步导航注册、PRD 资源与交付技能。

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-21 17:15:39 +08:00
parent e39df1c7c8
commit a01d2ab708
242 changed files with 102296 additions and 4866 deletions
--- a/.claude/skills/AutoVUL/SKILL.md
+++ b/.claude/skills/AutoVUL/SKILL.md
@@ -0,0 +1,139 @@
+---
+name: AutoVUL
+description: >-
+  Generates OneOS PC version update logs from a Yunxiao (云效) iteration name by
+  loading all linked requirements, or from a pasted changelog list. Use when testers
+  or PMs say AutoVUL, 版本更新日志, 按迭代生成更新日志, 发版公告, or give a 迭代名称.
+---
+
+# AutoVUL（OneOS PC 版本更新日志）
+
+面向**测试人员发版**：输入云效**迭代名称** → 拉取该迭代关联需求 → 自动生成对外版本更新日志。
+
+也可手动粘贴变更清单（兜底）。**预计维护时长**由人工单独通知，不写进日志。
+
+## 何时使用
+
+- 测试说：`按 $AutoVUL` / `生成版本更新日志` / `按迭代 xxx 出更新日志`
+- 输入含云效「迭代名称」
+- 发版前需要统一文案口径
+
+## 主流程（测试 · 按迭代，默认）
+
+完整取数步骤见 [references/yunxiao-sprint.md](references/yunxiao-sprint.md)。
+
+```text
+1. 确认云效项目（缺省：统一运营管理平台PC端；可改）
+2. 向用户索取「迭代名称」（若口令里已带则直接用）
+3. 在云效查找该迭代 → 立即反馈成功或失败（见下）
+4. 成功：列出迭代内关联「需求」清单（编号 + 标题 + 状态）供用户快速核对
+5. 从每条需求提取变更素材（优先级见「素材优先级」）
+6. 按本文格式分类、合并、润色 → 输出成稿正文
+```
+
+### 迭代读取 · 成功 / 失败反馈（强制）
+
+查找迭代后**必须先反馈**，再继续或停止：
+
+| 结果 | 反馈文案（可微调，语义不变） | 下一步 |
+|------|------------------------------|--------|
+| 精确命中 1 个迭代 | `✅ 已找到迭代「{名称}」（状态：{状态}），关联需求 {N} 条。` | 继续拉需求并生成 |
+| 0 个匹配 | `❌ 未找到迭代「{输入}」。请核对后重新输入迭代名称（可复制云效迭代标题）。` | **停止生成**；等待用户重输 |
+| 多个模糊匹配 | `⚠️ 找到多个相似迭代：1)… 2)… 请回复序号或完整精确名称。` | 等用户选定后再继续 |
+| 登录/权限失败 | `❌ 无法访问云效（未登录或无权限）。请在浏览器登录云效后重试，或改用手动清单。` | 停止；提示登录或兜底 |
+| 迭代存在但 0 条需求 | `⚠️ 迭代「{名称}」已找到，但暂无关联需求。请确认规划后再试，或改用手动清单。` | 停止生成对外正文 |
+
+**失败后**：用户只需再发一次迭代名称（或纠正项目名），从步骤 2 重跑；不要要求用户重装 Skill。
+
+### 素材优先级（每条需求）
+
+| 顺序 | 来源 | 用法 |
+|------|------|------|
+| 1 | 需求描述中的「更新内容」段（非「更新内容·历史」） | 首选，直接改写成日志条目 |
+| 2 | AutoPRD「功能变更记录」中可对外部分 | 次选 |
+| 3 | 需求标题 + 简短描述摘要 | 仅当前两者皆空时；价值句可合理补全 |
+| — | 纯技术债、内部监控、未对用户开放 | **不写入**对外日志 |
+
+Bug 类需求（类型/标签含缺陷修复、或更新内容写「修复」）归入【Bug修复】；其余归【新功能】。边界不清优先 Bug修复。
+
+### 版本号与更新时间
+
+| 字段 | 规则 |
+|------|------|
+| 版本号 | 优先从迭代名解析（如含 `V1.1.5` / `1.1.5`）；解析不到再问用户 |
+| 更新时间 | 用户提供则用；未提供可写迭代计划开始日的 `MM月DD日HH:MM`，或先问 |
+| 产品线 | 默认 `OneOS PC版` |
+
+## 兜底流程（手动清单）
+
+无云效权限、或迭代为空时：用 [input-template.md](input-template.md) 粘贴清单，跳过迭代步骤，直接分类润色。
+
+## 固定输出格式
+
+```text
+OneOS PC版V{主.次.修订}更新日志：
+更新时间：{MM}月{DD}日{HH}:{MM}
+----------------------------------------------------
+【新功能】
+1「{模块名}」{做了什么}，{责任部门}可{用户价值 / 解决的问题}
+2「{模块名}」{…}
+
+【Bug修复】
+3「{模块名}」{修复了什么}，{责任部门}可{恢复的能力 / 避免的影响}
+```
+
+### 版式硬约束
+
+| 项 | 规则 |
+|----|------|
+| 标题 | `OneOS PC版V` + 版本号 + `更新日志：`（如 `V1.1.5`，无空格） |
+| 更新时间 | 仅开始时刻；`MM月DD日HH:MM`；**禁止**「预计x分钟内完成」 |
+| 分隔线 | `----------------------------------------------------` |
+| 分区 | 仅 `【新功能】` / `【Bug修复】`；空类整段省略 |
+| 序号 | 全篇连续，从 1 起 |
+| 模块名 | `「」`；与产品菜单正式名一致 |
+| 对外正文 | **不写**需求号、缺陷号、迭代 ID（核对清单可另附） |
+| 结尾 | 无签名、无「感谢使用」、无技术附录 |
+
+## 分类 / 合并 / 文案（成稿规则）
+
+| 归入【新功能】 | 归入【Bug修复】 | 不写进对外日志 |
+|----------------|-----------------|----------------|
+| 新增能力、新入口、新字段/流程、可感知体验优化 | 原有能力异常、报错、数据错、交互失效 | 技术债、无感性能、未开放灰度、仅内部监控 |
+
+- **同分区同模块**合并为一条，分点用 `；`
+- **跨分区**同模块分栏各写一条
+- 每条含：做什么 + 用户价值 + 责任部门自然嵌入（`{部门}人员可…`）
+- **禁止**「供…条线…使用」；部门对照 [module-role-mapping.md](module-role-mapping.md)
+- 禁止编造迭代内不存在的能力；存疑跳过或标待确认（不进正式成稿）
+- 单条建议 ≤100 字
+
+排序：先新功能后修复；同分区全员影响优先；资金/合规修复置修复区最前。
+
+## 输出纪律
+
+1. **先**输出迭代读取反馈（✅/❌/⚠️）
+2. 成功时：可先给「本迭代需求清单」短表（含编号，便于测试核对）
+3. 再输出**纯文本成稿正文**（默认不要 Markdown 大标题包裹成稿）
+4. 用户明确要求时，可在正文后附「分类依据 / 跳过项」
+
+## 发布前自检
+
+- [ ] 已反馈迭代查找结果；失败时未强行编造成稿
+- [ ] 成稿条目均可追溯到本迭代关联需求素材
+- [ ] 标题、时间行、分隔线正确；无预计时长
+- [ ] 同模块合并正确；每条含价值 + 部门自然嵌入
+- [ ] 对外正文无需求号/缺陷号/技术黑话；序号连续
+
+## 给测试同事的口令
+
+```text
+按 $AutoVUL 生成版本更新日志。
+项目：统一运营管理平台PC端
+迭代名称：V1.1.5发版迭代
+更新时间：07月16日16:00
+```
+
+迭代名写错时，按提示改完再发一次即可。
+
+手动兜底见 [input-template.md](input-template.md)；成稿范例见 [examples.md](examples.md)。
--- a/.claude/skills/AutoVUL/examples.md
+++ b/.claude/skills/AutoVUL/examples.md
@@ -0,0 +1,77 @@
+# AutoVUL 成稿与交互范例
+
+## 1. 迭代读取失败 → 重输
+
+**用户：**
+
+```text
+按 $AutoVUL，迭代名称：V1.1.5
+```
+
+**Agent：**
+
+```text
+❌ 未找到迭代「V1.1.5」。请核对后重新输入迭代名称（可复制云效迭代标题）。
+```
+
+**用户：**
+
+```text
+V1.1.5发版迭代
+```
+
+**Agent：**
+
+```text
+✅ 已找到迭代「V1.1.5发版迭代」（进行中），关联需求 3 条：
+1. ONEOSP-201 车辆管理运营城市展示优化
+2. ONEOSP-202 还车应结款租金计算修复
+3. ONEOSP-203 业务管理新增租赁物流统计
+
+OneOS PC版V1.1.5更新日志：
+更新时间：07月16日16:00
+----------------------------------------------------
+【新功能】
+1「车辆管理」优化车辆「运营城市」展示，运维部人员可快速辨认车辆所属运营区域及数据来源
+2「业务管理」新增租赁、物流业务统计模块，业务管理组、业务员可查看租赁经营数据，业务服务组、财务部可跟踪自营物流经营情况
+
+【Bug修复】
+3「还车应结款」修复租金费用项重复及计算错误，业务管理组、安全部、运维部、能源部人员还车结算金额更准确
+```
+
+## 2. 完整成稿风格基准（手动/迭代素材均可）
+
+> 责任部门对照：`module-role-mapping.md`（OneOS 业务条线说明）
+
+```text
+OneOS PC版V1.1.5更新日志：
+更新时间：07月16日16:00
+----------------------------------------------------
+【新功能】
+1「加氢站管理」升级新版加氢站模块，采购部可统一维护签约站与非签约站信息，签约加氢站可便捷管理站点日常运营
+2「车辆管理」优化车辆「运营城市」展示，运维部人员可快速辨认车辆所属运营区域及数据来源
+3「审批中心」支持按客户名称搜索关联合同，业务员、法务部审批时可快速定位合同；还车应结款添加照片附件后，业务管理组、安全部、运维部、能源部会签人员可在审批流中查看完整附件
+4「保险采购」支持保比价单按车辆单独勾选并分开提交审批，运维部、安全部人员可按车辆分批推进投保审批
+5「故障管理」增加「故障来源」字段展示，运维部人员可区分上报渠道并跟进处理
+6「证照管理」特种设备使用登记证/使用标识照片支持OCR识别，运维部、安全部人员可减少手工录入、加快证照建档
+7「全局显示」统一各模块列表分页样式与交互，各模块操作人员跨页面浏览时体验一致、上手更快
+8「交还车管理」支持交车/还车签章文件在线预览，运维部、业务管理组、司机可现场核对签章文件；提交时增加胎纹数据必填校验，减少漏填导致的后续结算争议
+9「还车应结款」调整安全部待办区域权限，安全部人员仅处理职责范围内的还车应结款审批
+10「业务管理」新增租赁、物流业务统计模块，业务管理组、业务员可查看租赁经营数据，业务服务组、财务部可跟踪自营物流经营情况
+
+【Bug修复】
+11「还车管理」修复签字单与还车检查单/还车应结款轮胎数据不一致，运维部、业务管理组人员还车验收与结算依据保持一致
+12「租赁合同」修复编辑合同提交时异常提示内容冗余，业务员、法务部人员可快速定位真正错误原因
+13「交还车管理」修复交车/还车签章客户名称关联错误，避免运维部、业务管理组、司机现场核对时客户信息张冠李戴
+14「车辆氢费明细」修复同客户不同生效时段、以及不同客户成本单价显示异常，能源部人员可准确核对氢费核算单价
+15「还车应结款」修复租金费用项重复及计算错误，业务管理组、安全部、运维部、能源部人员还车结算金额更准确
+```
+
+## 对照要点
+
+| 规则 | 体现 |
+|------|------|
+| 先反馈迭代结果 | 失败可重输；成功列出需求再成稿 |
+| 无预计时长 | 更新时间仅 `07月16日16:00` |
+| 对外无需求号 | 成稿正文不出现 ONEOSP-xxx |
+| 部门自然嵌入 | `运维部人员可…`，无「供…条线使用」 |
--- a/.claude/skills/AutoVUL/input-template.md
+++ b/.claude/skills/AutoVUL/input-template.md
@@ -0,0 +1,69 @@
+# AutoVUL · 输入模板
+
+## A. 测试人员 · 按云效迭代（推荐）
+
+复制下面口令发给 AI（改迭代名即可）：
+
+```text
+按 $AutoVUL 生成版本更新日志。
+项目：统一运营管理平台PC端
+迭代名称：
+更新时间：
+```
+
+### 期望反馈
+
+- 成功：`✅ 已找到迭代「…」，关联需求 N 条` → 随后输出成稿  
+- 失败：`❌ 未找到迭代「…」。请重新输入迭代名称` → 改名后再发一次即可  
+
+**说明**：预计维护时长由人工单独通知，不写入版本更新日志。
+
+---
+
+## B. 手动清单（云效不可用时兜底）
+
+### 版本元信息
+
+| 字段 | 填写 | 示例 |
+|------|------|------|
+| 产品线 | | OneOS PC版 |
+| 版本号 | | V1.1.5 |
+| 更新开始时间 | | 07月16日16:00 |
+| 发布范围 | 全量 / 灰度（说明） | 全量 |
+| 是否对外发布 | 是 / 否 | 是 |
+
+### 新功能（原始材料，可粗糙）
+
+| 模块 | 做了什么 | 解决什么问题 / 用户故事 | 业务条线 | 责任部门 | 是否写入日志 |
+|------|----------|-------------------------|----------|----------|--------------|
+| 例：加氢站管理 | 升级新版模块 | 统一维护站点 | 能源业务条线 | 采购部、加氢站 | 是 |
+| | | | | | |
+
+### Bug修复（原始材料，可粗糙）
+
+| 模块 | 原问题现象 | 修复后表现 | 对用户的影响 | 业务条线 | 责任部门 | 是否写入日志 |
+|------|------------|------------|--------------|----------|----------|--------------|
+| 例：还车应结款 | 租金费用项重复 | 金额正确 | 避免结算偏差 | 租赁业务条线 | 业务管理组、安全部、运维部、业务管理组-能源部 | 是 |
+| | | | | | | |
+
+### 明确不要写入对外日志
+
+- （如：重构、依赖升级、仅内部监控、未上线配置）
+
+### 粘贴给 AI
+
+```text
+请按 $AutoVUL 用下方手动清单生成成稿（跳过云效迭代）。
+要求：同模块合并；每条含「做什么 + 用户价值」；责任部门自然融入；只输出正文。
+
+【版本元信息】
+- 产品线：OneOS PC版
+- 版本号：V
+- 更新开始时间：
+
+【新功能】
+（粘贴）
+
+【Bug修复】
+（粘贴）
+```
--- a/.claude/skills/AutoVUL/module-role-mapping.md
+++ b/.claude/skills/AutoVUL/module-role-mapping.md
@@ -0,0 +1,60 @@
+# 模块 → 业务条线 / 责任部门对照
+
+> 数据源：OneOS「业务条线说明」页责任部门定义（租赁 / 能源 / 运维 / 安全 / 自营）  
+> 生成更新日志时，**适用对象**须从此表取 `roles`，不得自造部门名。
+
+## 五条业务条线
+
+| ID | 条线名称 |
+|----|----------|
+| lease | 租赁业务条线 |
+| energy | 能源业务条线 |
+| ops | 运维管理条线 |
+| safety | 安全管理条线 |
+| self-operated | 自营业务条线 |
+
+## 本版变更模块对照
+
+| 更新日志模块名 | 业务条线 | lines.ts 模块 | 责任部门（roles，原文） |
+|----------------|----------|---------------|-------------------------|
+| 加氢站管理 | 能源业务条线 | 加氢站管理 | 采购部、加氢站 |
+| 车辆管理 | 运维管理条线 | 验车入库 / 车辆管理（资产底座） | 运维部、采购部 |
+| 审批中心 | 跨条线 | 租赁合同 + 还车应结款（审批场景） | 业务员、法务部、业务管理组、安全部、运维部、业务管理组-能源部 |
+| 保险采购 | 运维管理条线 | 证照 / 保险（车辆资产关联） | 运维部、安全部 |
+| 故障管理 | 运维管理条线 | 故障管理 | 运维部、司机 |
+| 租赁合同 | 租赁业务条线 | 租赁合同 | 业务员、法务部 |
+| 证照管理 | 运维管理条线 | 证照管理 | 运维部、安全部 |
+| 全局显示 | 全系统 | 系统介绍（五条条线） | 业务管理组、运维部、采购部、安全部、法务部、财务部、业务管理组-能源部、业务服务组 |
+| 交还车管理 | 运维管理条线 | 交车管理 + 还车管理 | 运维部、业务管理组、司机 |
+| 还车应结款 | 租赁业务条线 | 还车应结款 | 业务管理组、安全部、运维部、业务管理组-能源部 |
+| 还车管理 | 运维管理条线 | 还车管理 | 运维部、业务管理组 |
+| 车辆氢费明细 | 能源业务条线 | 车辆氢费明细 | 业务管理组-能源部 |
+| 业务管理 · 租赁统计 | 租赁业务条线 | 租赁业务台账 / 客户管理 | 业务管理组、业务员 |
+| 业务管理 · 物流统计 | 自营业务条线 | 自营台账 | 业务服务组、财务部 |
+
+## 写法规则
+
+- 部门名与 `roles` **完全一致**（`业务管理组-能源部` 对外可简写「能源部人员」）
+- **禁止**「供…业务条线…使用」「供…人员使用」
+- **推荐**：`{部门}人员可…` / `{部门}可…` / `{部门}审批时可…`
+- 同模块合并后，多部门用顿号或分号自然串联
+- 找不到模块时：查 `lines.ts`；仍无则标「待产品确认」不进成稿
+
+## 自然表述示例
+
+| 模块 | 生硬（禁止） | 自然（推荐） |
+|------|--------------|--------------|
+| 车辆管理 | 供运维管理条线运维部使用 | 运维部人员可快速辨认车辆所属运营区域 |
+| 加氢站管理 | 供能源业务条线采购部、加氢站使用 | 采购部可统一维护站点信息，加氢站可便捷管理日常运营 |
+| 还车应结款 | 供租赁业务条线业务管理组…使用 | 业务管理组、安全部、运维部、能源部还车结算金额更准确 |
+
+## 常见错误（禁止）
+
+| 错误写法 | 正确写法 |
+|----------|----------|
+| 氢能运营业务人员 | 采购部、加氢站（能源 · 加氢站管理） |
+| 车辆运营及资产管理业务人员 | 运维部、采购部（运维 · 车辆管理） |
+| 各业务条线审批人员 | 业务员、法务部、…（按审批场景枚举） |
+| 保险采购业务人员 | 运维部、安全部 |
+| 还车结算业务人员 | 业务管理组、安全部、运维部、业务管理组-能源部 |
+| 经营分析及管理部门 | 业务管理组、业务服务组（分租赁 / 自营） |
--- a/.claude/skills/AutoVUL/references/yunxiao-sprint.md
+++ b/.claude/skills/AutoVUL/references/yunxiao-sprint.md
@@ -0,0 +1,81 @@
+# 云效迭代 → 需求清单（AutoVUL 取数）
+
+测试人员只提供**迭代名称**；Agent 负责在云效定位迭代、拉取关联需求、抽出更新素材。
+
+## 安全边界（强制）
+
+- **禁止**在对话、Skill、日志、成稿中写入 Token、密码、Cookie、私钥。
+- 优先复用**已登录浏览器会话**操作云效 Projex（与 `yunxiao-requirement-lifecycle` 一致）。
+- 若团队已配置本机环境变量访问 OpenAPI，可走 API；Token 只读自环境，永不回显。
+
+建议环境变量（可选，名称可按团队调整）：
+
+| 变量 | 用途 |
+|------|------|
+| `YUNXIAO_TOKEN` | 个人访问令牌（`x-yunxiao-token`） |
+| `YUNXIAO_DOMAIN` | 服务接入点域名 |
+| `YUNXIAO_ORG_ID` | 组织 ID（中心版） |
+| `YUNXIAO_PROJECT_ID` | 默认项目 ID（或运行时按项目名解析） |
+
+## 默认项目
+
+口令未指定时：`统一运营管理平台PC端`。项目名不精确时先问清再查迭代。
+
+## 判定顺序：解析迭代
+
+| 顺序 | 条件 | 结果 |
+|------|------|------|
+| 1 | 用户未给迭代名称 | 询问：「请输入云效迭代名称（可复制标题）」；不继续 |
+| 2 | 项目未确定 | 询问精确项目名；不继续 |
+| 3 | 云效不可访问 | `❌ 无法访问云效…`；不继续 |
+| 4 | 名称精确匹配 1 条迭代 | `✅ 已找到迭代…`；进入拉需求 |
+| 5 | 0 条 | `❌ 未找到迭代…请重新输入`；不继续 |
+| 6 | >1 条相似 | `⚠️ 多个相似…请回复序号或精确名称`；等用户选定 |
+| 7 | 命中但关联需求 0 | `⚠️ …暂无关联需求`；不生成对外正文 |
+
+匹配规则：先**全等**（去首尾空格）；全等失败再做包含/去空格模糊；模糊多条必须让用户确认，禁止擅自挑一个。
+
+## 拉取关联需求
+
+只收集工作项类型为**需求（Req）**且正式关联到该迭代的项。
+
+- **浏览器路径**：打开项目 → 迭代 → 该迭代规划/工作项列表 → 筛选类型=需求 → 导出或逐条打开描述。
+- **OpenAPI 路径（示意）**：
+  1. `ListSprints`：按项目列迭代，用 `name` 匹配用户输入，得到 `sprintId`
+  2. `SearchWorkitems`：`category=Req`，`spaceId=项目Id`，`conditions` 中按字段 `sprint` CONTAINS `[sprintId]`（以租户实际 fieldIdentifier 为准；可先在需求列表页过滤后复制 `workitem/list` 的 conditions）
+  3. 分页直到收齐（关注响应头 `x-total`）
+  4. 需要正文时再 `GetWorkitem` 取 description
+
+每条需求最少记录：
+
+| 字段 | 说明 |
+|------|------|
+| serialNumber | 如 ONEOSP-123（仅用于核对清单，**不进对外成稿**） |
+| subject | 标题 |
+| status | 状态展示名 |
+| description | 用于抽取「更新内容」 |
+| category / type / labels | 辅助判断新功能 vs 修复 |
+
+## 从描述抽「更新内容」
+
+1. 定位标题「更新内容」或「## 更新内容」段落
+2. **不要**把「更新内容·历史」并入本版素材（历史仅备查）
+3. 若无「更新内容」：用标题 + 需求说明摘要；仍无有效产品语义则跳过并在内部备注
+
+## 成功反馈后的核对清单（推荐短表）
+
+在生成成稿前输出，例如：
+
+```text
+✅ 已找到迭代「V1.1.5发版迭代」（进行中），关联需求 5 条：
+1. ONEOSP-101 保险采购比价分车提交
+2. ONEOSP-102 交还车签章预览
+…
+正在按 AutoVUL 格式生成更新日志…
+```
+
+用户若立刻纠正「某条不要进日志」，从素材中剔除后再出成稿。
+
+## 与发版任务关系
+
+本 Skill **只读**迭代与需求，**不创建**【发版】任务、不改云效状态。发版挂链仍用 `yunxiao-requirement-lifecycle`（如「准备发布」口令 / A08）。
--- a/.claude/skills/oneos-autoprd/SKILL.md
+++ b/.claude/skills/oneos-autoprd/SKILL.md
@@ -0,0 +1,183 @@
+---
+name: oneos-autoprd
+description: >-
+  Generates and keeps in sync OneOS AutoPRD (PM-facing requirements) plus Axhub
+  Make annotation directory Markdown/PRD; on 需求定稿/定稿/确认定稿/本次定稿 appends
+  functional release changelog below the PRD since last baseline. When a Yunxiao
+  requirement advances to 分析中/设计中/待开发, creates a same-titled linked task
+  (tag+create-time follow the requirement; 分析中/设计中 assignee=creator, 待开发
+  assignee=何斐). Use eagerly for prototypes, AutoPRD, or Yunxiao requirement
+  description/更新内容/stage advance—do not skip annotation sync, 定稿 changelog,
+  or stage-task creation.
+---
+
+# OneOS AutoPRD
+
+为 OneOS 业务模块生成**产品经理可读、可评审、可排期**的需求说明，并**自动挂到 Axhub Make 标注工具 → 原型目录**。
+
+另支持：**需求定稿**时汇总功能/逻辑变更记录；与云效组合时提供「需求说明 + 更新内容」；需求进入**分析中 / 设计中 / 待开发**时**自动创建与需求同名的关联任务**（规则见下，写在本 Skill，不改云效 Skill）。
+
+颗粒度对齐「保险采购」全模块 PRD：讲清做什么、谁用、故事点、正逆向、流程图与关键业务逻辑；**不写**表结构、接口、字段代码名、文件路径、实现清单。
+
+## 何时使用（含自动触发）
+
+**主动调用时**
+
+- AutoPRD、OneOS 需求说明、整模块 PRD、故事点 + 流程图
+
+**改原型时必须自动跟进（全局规则）**
+
+- 正在修改 `src/prototypes/<id>/` 下页面、交互、文案、判定、验收相关内容
+- 同一轮交付内同步更新 PRD Markdown + 标注目录，不得只改代码
+
+**需求定稿时（强制）**
+
+- 用户回复含：`需求定稿` / `定稿` / `确认定稿` / `本次定稿`
+- 执行 [references/release-changelog.md](references/release-changelog.md)：写第 10 章 + 更新基线
+
+**云效建需求 / 完善需求时（强制组合）**
+
+- 与 `$yunxiao-requirement-lifecycle` 一起使用时：先跑本 Skill，再写云效描述
+- **需求说明** ← PRD 正文（或浓缩交付口径 + 关键章节）
+- **更新内容** ← 第 10 章中**自上次定稿以来**的条目（无增量则「首版定稿 / 本轮无功能增量」）
+
+**云效需求推进至分析中 / 设计中 / 待开发时（强制）**
+
+- 无论口令来自本 Skill 还是云效 Skill，只要本轮把需求推到上述状态，就执行 [references/yunxiao-stage-tasks.md](references/yunxiao-stage-tasks.md)
+- 自动建**与需求同名**的任务并正式关联；标签与创建时间口径沿用需求；分析中/设计中负责人=创建人，待开发负责人=**何斐**
+
+不要用本 Skill 替代：需求探索访谈、设计比稿、纯样式微调（无产品语义变化时可跳过全量重写）。
+
+## 工作流
+
+### 主流程（写/同步 PRD）
+
+1. **定模块**：确认 OneOS 模块名与 `src/prototypes/<prototype-id>/`。
+2. **读上下文（只取产品语义）**  
+   - 用户说明、已确认口径、原型标注、`.spec/`、业务条线说明（`lines.ts`）  
+   - 忽略实现细节；字段名/接口改写成业务语言。
+3. **收敛边界**：做什么 / 不做什么、外部依赖、与其它模块关系。
+4. **按模板成文**：下方「输出结构」；缺关键信息最多问 1～2 个问题，其余写「假设」。
+5. **落盘 + 标注同步（强制）** — 见 [references/annotation-sync.md](references/annotation-sync.md)。
+
+   | 顺序 | 动作 |
+   |------|------|
+   | A | 写/更新 `src/prototypes/<id>/.spec/requirements-prd.md` |
+   | B | 写/更新 `src/resources/prd/<id>-autoprd.md` |
+   | C | 更新 `annotation-source.json` **顶层** `directory.nodes`（PRD 全文 + 推荐分章）；禁止只写 `data.directory` |
+   | D | 若存在 `scripts/sync-annotation-directory.mjs`，执行之 |
+
+6. **交付说明**：路径、标注目录入口、故事点合计、开放问题/假设。
+
+### 定稿流程（关键字触发）
+
+见 [references/release-changelog.md](references/release-changelog.md)。摘要：
+
+1. 读 PRD + `.spec/autoprd-baseline.json`
+2. 汇总自上次定稿以来的**功能/逻辑**变更（排除样式/UI/表结构）
+3. 追加到 `## 10. 功能变更记录`（最新在上）
+4. 更新基线 JSON + 标注目录
+5. 若同时发云效：本次定稿块 →「更新内容」；旧段 →「更新内容·历史」
+
+### 云效交接格式（给 yunxiao skill 直接粘贴）
+
+```markdown
+## 原型链接
+<对象存储或预览 URL>
+
+## 需求说明
+<AutoPRD 正文或交付口径 + 必要章节>
+
+## 更新内容
+<第 10 章本次定稿块；无则「首版定稿」或「本轮无功能/逻辑增量」>
+
+## 更新内容·历史
+<以往更新内容倒序，勿删除>
+```
+
+### 云效阶段任务（状态推进时强制）
+
+见 [references/yunxiao-stage-tasks.md](references/yunxiao-stage-tasks.md)。摘要：
+
+| 需求状态 | 任务标签 | 负责人 | 标题 |
+|----------|----------|--------|------|
+| 分析中 | 分析 | 需求创建人 | 与需求同名 |
+| 设计中 | 设计 | 需求创建人 | 与需求同名 |
+| 待开发 | 交付（或开发） | 何斐 | 与需求同名 |
+
+正式关联需求；创建时间口径沿用需求；同阶段未取消任务不重复建。
+
+## 写作硬约束
+
+**必须写**
+
+- 一句话定位 + 目标 / 非目标
+- 模块边界（含 mermaid 总览更好）
+- 角色与目标（角色名优先对齐业务条线说明）
+- **用户故事**（业务条线说明口径）+ Epic 级**故事点（SP）**粗估
+- 分功能**正向**与**逆向/边界**
+- 至少 1～2 个 **mermaid** 流程图
+- **关键业务逻辑**（业务话）
+- 验收清单 + 「交付口径」一段话
+- 定稿后：**功能变更记录**（第 10 章）
+
+**禁止写**
+
+- 数据库表、字段名、接口路径、代码路径、组件名、存储 key
+- 研发实现指令（可写「正式环境由审批中心回写」这类业务依赖）
+- 在变更记录里写样式/UI/表结构优化
+
+## 用户故事口径（强制 · 对齐业务条线说明）
+
+真相源：原型 **业务条线说明**（`lease-business-line-overview` / `lines.ts`）。  
+每条能力用「责任部门 → **起点** → **怎么运作** → **闭环**」叙述；**不要**用「作为…我希望…」宽表作主叙述。
+
+| 块 | 写什么 |
+|----|--------|
+| 角色 | 谁负责、谁协同 |
+| 起点 | 谁在什么前提下启动 |
+| 怎么运作 | 有序步骤，含跨角色协作 |
+| 关键结果 | 可选标签 |
+| 闭环 | 业务终点与可追溯性 |
+
+可选：`US-xx`、压缩句「作为…我想…以便…」、规模 S/M/L 或 SP（仅排期，不替代主叙述）。
+
+## 输出结构
+
+完整模板：[references/template.md](references/template.md)。
+
+```markdown
+# <模块名> · 产品需求说明（全模块）
+
+## 1. 一句话与目标
+## 2. 模块边界（最重要）
+## 3. 用户与角色
+## 4. 用户故事与故事点（业务条线说明口径）
+## 5. 功能模块说明（正向 / 逆向）
+## 6. 关键业务逻辑（必须对齐）
+## 7. 总览流程图
+## 8. 验收清单
+## 9. 交付口径
+## 10. 功能变更记录   ← 定稿后维护；日常改原型不强制每改必写
+```
+
+## 质量自检
+
+- [ ] 产品经理不看代码也能评审
+- [ ] 用户故事为起点 / 怎么运作 / 闭环
+- [ ] `.spec/requirements-prd.md` 已更新
+- [ ] 标注目录「产品需求说明（PRD）」已同步且正文一致
+- [ ] 定稿时：第 10 章 + `autoprd-baseline.json` 已更新
+- [ ] 推进至分析中/设计中/待开发时：同名任务已创建或复用，正式关联，负责人正确
+- [ ] 无表结构 / 接口 / 代码路径；变更记录无样式/UI 废话
+
+## 参考
+
+- 定稿变更日志：[references/release-changelog.md](references/release-changelog.md)
+- 云效阶段任务：[references/yunxiao-stage-tasks.md](references/yunxiao-stage-tasks.md)
+- 标注同步细则：[references/annotation-sync.md](references/annotation-sync.md)
+- 章节模板：[references/template.md](references/template.md)
+- 故事示例：[references/granularity-example.md](references/granularity-example.md)
+- 业务条线：`src/prototypes/lease-business-line-overview/lines.ts`
+- 复杂判定规格：配合项目规则 `business-logic-documentation`
+- 云效组合：`$yunxiao-requirement-lifecycle`（建需求时先本 Skill）
--- a/.claude/skills/oneos-autoprd/references/annotation-sync.md
+++ b/.claude/skills/oneos-autoprd/references/annotation-sync.md
@@ -0,0 +1,98 @@
+# Axhub 标注目录同步（强制）
+
+使用 OneOS AutoPRD 时，除资源库归档外，**必须**把 PRD 挂到 Axhub Make 标注工具的「原型目录」里，用户才能在右侧面板直接打开。
+
+## 落点（三份必须一致）
+
+| # | 路径 | 作用 |
+|---|------|------|
+| 1 | `src/prototypes/<prototype-id>/.spec/requirements-prd.md` | **主真相**：产品可读 PRD 全文 |
+| 2 | `src/prototypes/<prototype-id>/annotation-source.json` → **顶层** `directory.nodes` | **标注目录入口**：面板里可见的 Markdown/PRD |
+| 3 | `src/resources/prd/<prototype-id>-autoprd.md` | 资源库归档（可选但默认写） |
+
+可选：复杂判定另写 `.spec/<topic>.md`，目录里再挂一条，并在 PRD 里链过去（与 `business-logic-documentation` 一致）。
+
+## ⚠️ 目录必须写在文档顶层（常见踩坑）
+
+Wire format（与 `prototype-annotation` 一致）：
+
+```json
+{
+  "documentVersion": 1,
+  "format": "axhub-annotation-source",
+  "data": { "version": 2, "prototypeName": "...", "nodes": [] },
+  "markdownMap": {},
+  "assetMap": {},
+  "directory": { "nodes": [] }
+}
+```
+
+| 正确 | 错误 |
+|------|------|
+| 顶层 `directory.nodes` | 只写在 `data.directory` |
+| `PrototypeAnnotationHost` / Make 读的是 `source.directory` | 写在 `data` 下时右侧「原型目录」为空 |
+
+若误写在 `data.directory`：迁移到顶层 `directory`，并删除 `data.directory`，避免双源。
+
+## 目录节点写法（推荐）
+
+在说明根 `folder` 的 `children` **靠前**插入或更新：
+
+```json
+{
+  "type": "markdown",
+  "id": "<prefix>-doc-prd",
+  "title": "产品需求说明（PRD）",
+  "markdownPath": ".spec/requirements-prd.md",
+  "markdown": "<与 .spec/requirements-prd.md 相同的全文>"
+}
+```
+
+### 分章节 PRD（推荐，便于右侧目录浏览）
+
+在「产品需求说明（PRD）」旁增加文件夹 **「PRD 分章」**，按 PRD 的 `##` 一级标题拆成多个 `markdown` 子节点（标题用章节名，正文为该章全文）。专题规格（`.spec/<topic>.md`）放在 **「专题规格」** 文件夹。
+
+参考结构：
+
+```text
+folder  <模块>说明
+  markdown  产品需求说明（PRD）     ← 全文
+  folder    PRD 分章
+    markdown  1. 一句话与目标
+    markdown  2. 模块边界
+    …
+  folder    专题规格
+    markdown  <topic 标题>
+```
+
+有 `scripts/sync-annotation-directory.mjs` 的原型：改 PRD / `.spec` 后**必须执行**该脚本再生目录。
+
+定稿后第 10 章「功能变更记录」必须进入 PRD 全文节点；若有「PRD 分章」，同步该章节点。详见 [release-changelog.md](release-changelog.md)。
+
+约定：
+
+- `id`：`<短前缀>-doc-prd`（如 `ipc-doc-prd`、`wb-doc-prd`、`h5-va-doc-prd`）
+- `title`：优先「产品需求说明（PRD）」；已有「PRD」可保留不改名
+- **同时写** `markdownPath` + `markdown`：构建可内联路径，运行时目录也能直接读到正文
+- 若已有同 id / 同标题节点：只更新正文与 path，不新建重复入口
+- 遵守 `prototype-annotation-layout`：目录以 `markdown` 为主，不要用 `link`/`route` 顶替 PRD
+
+## 增量改原型时怎么更新
+
+1. 根据改动的文件路径确定 `<prototype-id>`。
+2. 读现有 `.spec/requirements-prd.md`（没有则按 AutoPRD 模板新建）。
+3. 只改受影响章节（故事、正逆向、关键逻辑、验收）；其余保留。
+4. 回写 `.spec` + `resources/prd` + **顶层** `annotation-source.json` → `directory`（正文与文件一致；含分章节点）。
+5. 若原型有 `scripts/sync-annotation-directory.mjs`，改完后执行它。
+
+## 可跳过全量重写的情况
+
+纯样式、无文案/无流程/无判定变化的微调：不必重写整份 PRD，但若改了用户可见文案或交互结果，仍须同步对应段落与目录节点。
+
+## 验收
+
+- [ ] `.spec/requirements-prd.md` 存在且为最新
+- [ ] `annotation-source.json` **顶层**有 `directory.nodes`（不是只在 `data` 下）
+- [ ] 标注目录能打开「产品需求说明（PRD）」且内容与文件一致
+- [ ] 若有「PRD 分章」：各章可单独打开
+- [ ] 用户故事仍为业务条线说明口径（起点 / 怎么运作 / 闭环）
--- a/.claude/skills/oneos-autoprd/references/granularity-example.md
+++ b/.claude/skills/oneos-autoprd/references/granularity-example.md
@@ -0,0 +1,58 @@
+# 颗粒度标杆与用户故事口径
+
+## 用户故事：对齐「业务条线说明」页面
+
+页面：`/prototypes/lease-business-line-overview`  
+数据：`src/prototypes/lease-business-line-overview/lines.ts`
+
+每个能力卡片的产品叙述结构：
+
+```text
+责任部门（roles）
+  → 起点（start）
+  → 怎么运作（process[]，有序）
+  → 关键结果（outcomes，可选）
+  → 闭环（closure）
+```
+
+AutoPRD 第 4 章必须用同一套结构写用户故事，而不是「作为…我希望…」宽表。
+
+### 示例（保险采购 · 交车合规，示意）
+
+#### US · 保险有效才允许交车
+- **角色**：采购部、运维部  
+- **起点**：采购或运营维护车辆交强险与商业险台账，作为交车前置合规数据。  
+- **怎么运作**：  
+  1. 在保险采购维护一车一档险种台账（录入 / 识别 / 导入）。  
+  2. 交车时系统校验交强 + 商业是否均为正常或临期。  
+  3. 不合规则拦截交车并给出可理解原因。  
+- **关键结果**：`允许交车` / `禁止交车 · 保险异常`  
+- **闭环**：交车合规与台账一致、可追溯；异常车辆不能进入履约运营。  
+- **排期（可选）**：US-17 · 规模 M · 作为采购/运维，我想维护交强+商业险并在交车时校验，以便不合规车辆无法交车。
+
+### 反例（不要作为主叙述）
+
+| 编号 | 用户故事 | SP |
+|------|----------|----|
+| B1 | 作为运营，我能看到失败原因 | 2 |
+
+↑ 信息太扁，缺少起点、协作步骤与闭环结果。
+
+---
+
+## AutoPRD 其余层次（仍要对齐）
+
+1. 一句话 + 目标/非目标  
+2. 模块边界（独立业务线写清「不自动同步」）  
+3. 角色表（命名对齐业务条线）  
+4. **用户故事：起点 / 怎么运作 / 闭环** + SP/规模  
+5. 分模块正逆向  
+6. 关键业务逻辑  
+7. mermaid 流程图  
+8. 验收清单  
+9. 交付口径  
+
+## 刻意不写
+
+- 表结构、接口、代码路径  
+- 用实现指令代替业务闭环描述  
--- a/.claude/skills/oneos-autoprd/references/release-changelog.md
+++ b/.claude/skills/oneos-autoprd/references/release-changelog.md
@@ -0,0 +1,78 @@
+# 功能变更记录（定稿触发）
+
+用户回复**需求定稿关键字**后，必须生成「自上次定稿以来」的功能变更日志，追加到 PRD **最下方**，并更新定稿基线。
+
+## 触发关键字（命中任一）
+
+`需求定稿` · `定稿` · `确认定稿` · `本次定稿`
+
+（可带模块名，如「保险采购需求定稿」。）
+
+## 写什么 / 不写什么
+
+| 要写（产品发版视角） | 不写 |
+|----------------------|------|
+| 哪个功能做了什么修改 | 布局、页面样式、UI 设计优化 |
+| 变更了什么业务逻辑 / 流程 / 验收口径 | 「优化了哪些表」「改了哪些字段/接口」 |
+| 用户可感知的交互结果变化 | 纯样式、动效、无语义文案微调 |
+
+条目口吻示例：
+
+- 「识别失败」：失败数可点击查看失败文件与原因；仅失败时也可打开明细  
+- 「比价单」：审批通过后仍须在保单管理另行录入正式保单（强调不自动同步）
+
+## 落点
+
+1. **PRD 文末章节**（强制）  
+   `src/prototypes/<id>/.spec/requirements-prd.md` → `## 10. 功能变更记录`  
+   新定稿块插在该章**最上方**（倒序：最新在上）；历史块保留。
+
+2. **定稿基线**（强制）  
+   `src/prototypes/<id>/.spec/autoprd-baseline.json`
+
+```json
+{
+  "prototypeId": "insurance-procurement",
+  "lastConfirmedAt": "2026-07-21T12:00:00+08:00",
+  "lastConfirmedLabel": "定稿 · 2026-07-21",
+  "summaryBullets": ["…", "…"]
+}
+```
+
+3. **标注目录**：同步更新「产品需求说明（PRD）」全文节点；若有「PRD 分章」，增加或更新「功能变更记录」分章。
+
+4. **云效交接**（若本轮同时走云效）：把**本次定稿块**正文作为需求描述「更新内容」；旧「更新内容」挪到「更新内容·历史」。
+
+## 定稿工作流
+
+1. 确认 `<prototype-id>`（从对话 / 打开文件 / 用户指名推断）。
+2. 读现有 PRD 与 `autoprd-baseline.json`（无基线则本轮视为**首版定稿**）。
+3. 收集自 `lastConfirmedAt` 以来的产品语义变更：  
+   对话确认口径 → 批注/操作说明 → PRD 新旧差异 →（可选）相关提交说明。  
+   过滤掉样式/表结构类改动。
+4. 若无功能增量：仍写定稿块，正文为「本轮无功能/逻辑增量（仅样式或未达产品语义变更）」或「首版定稿」。
+5. 追加 `### 定稿 · YYYY-MM-DD` + 条目列表到第 10 章顶部。
+6. 更新 `autoprd-baseline.json`；执行 annotation-sync。
+7. 向用户回报：基线时间、条目数、PRD 路径；若需发云效，提示可用口令。
+
+## PRD 章节格式
+
+```markdown
+## 10. 功能变更记录
+
+> 产品经理原型发版记录。仅记功能与业务逻辑变更；不含样式/UI/表结构。
+
+### 定稿 · 2026-07-21
+
+- 「能力名」：做了什么 / 逻辑如何变
+- …
+
+### 定稿 · 2026-07-10
+
+- …
+```
+
+## 与日常改原型的关系
+
+- **改原型过程中**：按 AutoPRD 主流程增量更新第 1–9 章；**不必**每改一次就写第 10 章。
+- **用户说定稿时**：才汇总写入第 10 章并刷新基线。
--- a/.claude/skills/oneos-autoprd/references/template.md
+++ b/.claude/skills/oneos-autoprd/references/template.md
@@ -0,0 +1,163 @@
+# OneOS AutoPRD 输出模板
+
+复制下列结构填写。方括号为占位。**第 4 章用户故事必须用业务条线说明口径。**
+
+```markdown
+# <模块名> · 产品需求说明（全模块）
+
+## 1. 一句话与目标
+
+**一句话**  
+<用一句话说明模块解决什么>
+
+**要解决的问题**  
+- …
+
+**本期目标**  
+1. …
+2. …
+
+**非目标（本期不做）**  
+- …
+
+## 2. 模块边界（最重要）
+
+（可选 mermaid：模块与外部系统关系）
+
+| 业务线 / 子域 | 做什么 | 不做什么 |
+|---------------|--------|----------|
+| … | … | … |
+
+**外部依赖（产品口径）**  
+| 依赖方 | 交互方式 | 产品要求 |
+|--------|----------|----------|
+| … | … | … |
+
+**关键约束**  
+- …
+
+## 3. 用户与角色
+
+| 角色 | 主要目标 |
+|------|----------|
+| … | … |
+
+> 角色名优先与「业务条线说明」一致（如业务管理组、采购部、运维部）。
+
+## 4. 用户故事与故事点（业务条线说明口径）
+
+> 故事点 / 规模供排期参考，可按团队基准调整。合计约 **N SP**（或 S/M/L 汇总说明）。
+
+按 Epic 或能力单元分组。**每一条**按下面四块写（对齐业务条线说明页：责任部门 → 起点 → 怎么运作 → 闭环）：
+
+### Epic A · <名称>（约 N SP）
+
+#### A1 · <能力标题>
+- **角色**：…
+- **起点**：…
+- **怎么运作**：
+  1. …
+  2. …
+  3. …
+- **关键结果**（可选）：`可…` / `禁止…`
+- **闭环**：…
+- **排期（可选）**：US-xx · 规模 S/M/L · 「作为…，我想…，以便…」
+
+#### A2 · <能力标题>
+…
+
+### Epic B · …
+
+## 5. 功能模块说明（正向 / 逆向）
+
+### 5.x <功能名>
+
+**正向**  
+1. …  
+2. …  
+
+**逆向 / 边界**  
+
+| 情况 | 系统表现 |
+|------|----------|
+| … | … |
+
+## 6. 关键业务逻辑（必须对齐）
+
+### 6.x <规则名>
+
+用编号优先级、表格或短列表写清业务规则。
+
+## 7. 总览流程图
+
+```mermaid
+flowchart TB
+  home[入口] --> a[能力A]
+  home --> b[能力B]
+```
+
+## 8. 验收清单（产品 / 测试）
+
+**子域 A**  
+- [ ] …  
+
+## 9. 交付口径
+
+> <一段可贴需求单开头的浓缩描述>
+
+## 10. 功能变更记录
+
+> 产品经理原型发版记录。仅记功能与业务逻辑变更；不含样式/UI/表结构。  
+> 由「需求定稿」关键字触发追加；日常改原型不强制每改必写。详见 [release-changelog.md](release-changelog.md)。
+
+### 定稿 · YYYY-MM-DD
+
+- 「<能力名>」：<做了什么 / 逻辑如何变>
+- …
+```
+
+成文后**必须**同步 Axhub 标注目录（见 [annotation-sync.md](annotation-sync.md)）：
+
+1. `src/prototypes/<id>/.spec/requirements-prd.md`
+2. `annotation-source.json` → 目录节点「产品需求说明（PRD）」（`markdownPath` + `markdown`）
+3. `src/resources/prd/<id>-autoprd.md`
+4. 定稿时另写：`src/prototypes/<id>/.spec/autoprd-baseline.json`
+
+## 用户故事写法（对照业务条线说明）
+
+业务条线说明页字段 → AutoPRD 字段：
+
+| 页面 | AutoPRD |
+|------|---------|
+| 责任部门标签 | **角色** |
+| 起点 | **起点** |
+| 怎么运作（有序列表） | **怎么运作** |
+| 结果色签 | **关键结果**（可选） |
+| 闭环 | **闭环** |
+
+示例口吻（摘自业务条线风格，非照抄某模块）：
+
+- **起点**：采购部维护交强与商业险台账，作为交车合规的前置数据。  
+- **怎么运作**：1. 运营录入或识别保单… 2. 运维交车时校验…  
+- **闭环**：核心险种有效则允许交车；异常则拦截并提示原因，过程可追溯。
+
+**不要**用下面这种宽表作为第 4 章唯一形态：
+
+| 编号 | 作为…我希望… | SP |
+|------|--------------|----|
+
+「作为…我想…以便…」只允许作为**排期可选一行**，主叙述必须是起点/怎么运作/闭环。
+
+## 正逆向写法约定
+
+- **正向**：用户成功完成任务的最短路径  
+- **逆向**：取消、关闭、禁用、冲突状态、不可操作项  
+- 审批类：写清「本页只读 / 在外部系统办理」  
+
+## 规模与故事点
+
+| 规模 | 建议含义 | 约 SP |
+|------|----------|-------|
+| S | 轻交互 / 列表展示 | 1～2 |
+| M | 标准流程 + 筛选详情 | 3～5 |
+| L | 状态机 / 跨模块 / 批量识别 | 6+ |
--- a/.claude/skills/oneos-autoprd/references/yunxiao-stage-tasks.md
+++ b/.claude/skills/oneos-autoprd/references/yunxiao-stage-tasks.md
@@ -0,0 +1,44 @@
+# 云效阶段任务自动创建（AutoPRD 负责）
+
+本规则写在 **oneos-autoprd**，不依赖改写 `yunxiao-requirement-lifecycle`。  
+凡本 Skill 参与的云效操作中，需求推进到下列状态时，**同一轮必须**建同名任务并正式关联需求。
+
+## 触发状态
+
+| 需求推进至 | 任务标签（右侧基础字段） | 负责人 | 任务标题 |
+|------------|--------------------------|--------|----------|
+| **分析中** | `分析` | **需求创建人**姓名 | 与需求标题**完全同名** |
+| **设计中** | `设计` | **需求创建人**姓名 | 与需求标题**完全同名** |
+| **待开发** | `交付`（若项目无「交付」标签则用 `开发`） | **何斐** | 与需求标题**完全同名** |
+
+## 强制字段与关系
+
+1. **正式关联需求**：父子或关联项；只挂标题不算关联。创建后必须在界面上能看到需求 ↔ 任务关系。
+2. **标签**：写入任务「标签」基础字段（见上表）；标题前缀不能代替标签。
+3. **创建时间沿用需求**：任务的创建时间（及标签侧可见的创建时间口径）尽量与**需求创建时间**一致。  
+   - 平台允许改创建时间 / 用 API 指定时：写成需求的创建时间。  
+   - 平台不允许：在任务描述首行注明 `创建时间口径=需求创建时间（YYYY-MM-DD HH:mm）`，并在回报里说明「平台限制未改系统创建时间」。
+4. **幂等**：同一需求、同一阶段标签下，已存在**未取消**且已正式关联的同名任务 → **不新建**，只校验负责人/标签/关联是否正确，缺则补齐。
+5. **顺序**：先确认需求已进入目标状态（或本轮动作将写入该状态），再创建/补齐任务；回报时给出任务编号与链接。
+
+## 执行步骤（apply 时）
+
+```text
+1. 读取需求：标题、创建人、创建时间、当前/目标状态、已关联任务列表
+2. 按上表确定本轮阶段标签与负责人
+3. 查重（需求ID + 阶段标签 + 未取消）
+4. 无则创建：标题=需求标题；标签=阶段标签；负责人=上表；创建时间口径=需求创建时间；正式关联需求
+5. 有则校验并修补标签/负责人/关联
+6. 回报：需求状态、任务编号、负责人、是否新建/复用
+```
+
+## 不在本规则内
+
+- 不自动建「测试 / 发版」任务（除非用户另行要求）。
+- 不因样式类 PRD 变更触发建任务；仅**需求状态**进入分析中/设计中/待开发时触发。
+- 云效生命周期细则、流水线、缺陷闭环仍可由 `$yunxiao-requirement-lifecycle` 配合执行；**本建任务逻辑以 AutoPRD 本文为准**。
+
+## 与定稿 / 需求说明的关系
+
+- 写「需求说明 / 更新内容」仍按 AutoPRD 主流程与定稿流程。
+- 推进到待开发且需要描述时：先 AutoPRD 文档，再改状态，再按本文件建任务（负责人何斐）。