wangmian/OneOS1.2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
王冕
2026-07-28 15:50:35 +08:00
parent b14425da5a
commit 5d51a6bf7a
1393 changed files with 488042 additions and 10046 deletions
Download Patch File Download Diff File Expand all files Collapse all files

83
.claude/skills/AutoRDO/SKILL.md Normal file
View File

@@ -0,0 +1,83 @@
---
name: AutoRDO
description: >-
AutoRDO (Requirement Description Optimization): cleans fragmented chat logs,
voice transcripts, oral notes, and feedback ledgers into written title and description;
auto-detects 类型/优先级/标签/提交部门/提交人 from content; maps OneOS modules via oneos-domain.md;
splits multi-line into multiple results; if any 待确认 exists, MUST switch to Plan mode
for choice-based confirmation. Does not change Yunxiao status or create tasks.
Pair with YunxiaoPMapp for cloud write; never load yunxiao-requirement-lifecycle.
---
# AutoRDO
**Requirement Description Optimization**（需求描述优化）。
将碎片化、通俗化文字（聊天/录音/反馈台账）在**保留原意**前提下拆解为**标题、描述**，并**自动识别**类型、优先级、标签、提交部门、提交人，供入库写入云效需求。
多行/多条独立诉求 → **自动拆成多份**转译结果。
**强制**：清洗结果中**只要存在任意「待确认」**，Agent **必须立刻** `SwitchMode` → **plan**，逐条用选择题消解；**无需**用户再说「确认待确认」。无待确认则可直接交定稿。
## 边界（强制）
| 做 | 不做 |
|---|---|
| 提炼标题与书面描述；自动识别类型/优先级/标签/提交部门/提交人 | 改云效状态 / 建任务 / **直接**打云效标签 |
| 多行/多条 → 多份转译结果 | 写成完整 AutoPRD / 臆造业务结论 |
| 有待确认 → 强制 Plan 逐条确认 | 停在初稿等口令；把猜测写入定稿 |
| 去除描述**结尾句号** | 加载 `yunxiao-requirement-lifecycle` |
云效建单与打标由 **`$YunxiaoPMapp`** 负责；本 Skill 只出清洗稿与**推荐元数据**。
## 何时使用
- 口令含 `AutoRDO` / `清洗聊天` / `录音整理` / `原始诉求`
- 粘贴反馈台账（含部门/优先级/模块列）或口述碎片
- YunxiaoPMapp「记录需求」前必须先跑本 Skill（材料为碎片/台账时）
## 输入
- 聊天、会议速记、口述、录音转写
- **多行/台账**：含反馈人、所属部门、业务模块、优先级、PC或移动端等列时优先采信列值
- 确认阶段补充文字
## 处理规则
**强制前置**：ONE-OS 材料先 Read [references/oneos-domain.md](references/oneos-domain.md)，元数据规则见 [references/meta-fields.md](references/meta-fields.md)，再按 [references/rules.md](references/rules.md) 执行。
1. **多条拆解** → 每条独立成稿
2. **OneOS 对齐** → 模块/部门标准名
3. **元数据识别** → 类型、优先级、标签、提交部门、提交人（显式列 > 正文标记 > 语义推断；不确定 → 待确认）
4. **标题 + 描述转译** → 去口语、去结尾句号
5. **有待确认 → 强制 Plan** → 见 [references/confirm-pending.md](references/confirm-pending.md)
## 输出
```markdown
## 原始诉求（AutoRDO）
**标题**：<清晰标题>
**类型**：【新增】|【优化】
**优先级**：P1-高|P2-中|P3-低
**标签**：<标准模块>[, PC端|小程序]
**提交部门**：<标准部门名或空>
**提交人**：<姓名或空>
**描述**：
<转译正文；无结尾句号>
反馈：<有则附日期/禅道/状态/端>
待确认：
- …
```
多条时先写「共 N 条」，再 `### 1` … `### N`。
交 YunxiaoPMapp 示例：`记录需求：标题=…；类型=…；优先级=…；标签=…；提交部门=…；提交人=…；描述=…`
## 口令
```text
AutoRDO：<粘贴聊天或台账行>
AutoRDO：录音转写如下 …
按下列补充消解待确认：
<补充说明>
```

4
.claude/skills/AutoRDO/agents/openai.yaml Normal file
View File

@@ -0,0 +1,4 @@
interface:
display_name: "AutoRDO"
short_description: "清洗诉求并识别类型优先级标签部门提交人"
default_prompt: "按 AutoRDO 清洗：先读 oneos-domain.md 与 meta-fields.md；多行拆多条；出标题+描述+类型/优先级/标签/提交部门/提交人。有待确认则同轮强制切 Plan 用选择题消解；不改云效、不直接打标、不贴词典全文。"

126
.claude/skills/AutoRDO/references/confirm-pending.md Normal file
View File

@@ -0,0 +1,126 @@
# AutoRDO · 待确认逐条 Plan 确认
## 目标
清洗稿中的「待确认」经产品经理**逐条人工确认**后，回填进标题/描述，得到可交 YunxiaoPMapp 的定稿。
确认过程**优先选择题**；选项用 [oneos-domain.md](oneos-domain.md) 辅助生成；也支持用补充说明/需求描述文字直接消解待确认点。
## 何时进入（强制）
```text
清洗初稿产出后：
若任一需求含「待确认」→ 同轮必须 SwitchMode → plan
若全部无待确认 → 不必进 Plan，初稿即定稿
```
- **触发条件只有一条**：存在待确认（单条或多条中任意一点）
- **禁止**要求用户再说「确认待确认」「开始确认」才进 Plan
- 用户在 Plan 中可用选择题作答，也可粘贴补充说明消解
**不进 Plan 的唯一情况**：清洗结果中没有任何「待确认」条目。
## Plan 门禁（强制）
1. 清洗初稿写出后（可先展示初稿摘要），**立刻** `SwitchMode` → **plan**，说明：存在待确认，须逐条确认后再回填定稿；本阶段仍**不写云效**
2. Plan 列出：待确认的**需求条号**、每条下的待确认点清单、推荐确认方式（选择题 / 文字补充）
3. **用户确认 / 批准 Plan / 「执行」之前**：禁止把未确认内容写进定稿描述
4. 批准后：按条推进确认 → 回填 → 输出定稿
## 逐条确认顺序
```text
需求 1 的待确认点 1 → 点 2 → … → 需求 1 定稿片段
需求 2 的待确认点 1 → …
…
全部完成后输出「已确认定稿」全集
```
- **一次只推进一个待确认点**（或同一点下的一组互斥选项），避免一屏堆十几个问题
- 多条需求时，Plan 清单可注明建议从第 1 条起；用户可指定跳过或改序
- 某条无「待确认」→ 跳过，保留初稿即可
## 确认方式（优先选择）
每个待确认点按下列优先级出题：
| 优先级 | 方式 | 适用 |
|---|---|---|
| 1 | **选择题**（2–5 个互斥选项 + 可选「其他/我补充」） | 模块归属、部门名称、类型/优先级、是否/范围、枚举字段、拆条边界等 |
| 2 | **多选** | 明确可多选的范围（如适用端：PC+H5） |
| 3 | **文字补充** | 无法枚举、需自由描述字段清单/规则细节时 |
### 选项如何用 OneOS 词典生成
先 Read `oneos-domain.md`，再出选项：
- **模块名不清**：候选 = 词典中相关条线的标准模块名（如还车应结款 / 违章管理 / 还车管理），勿自造模块
- **部门/角色口语**：候选 = 第 1 节标准名（业管→业务管理组，安全小组→安全部 等）+「保持单据原文分区名」
- **跨条线联动**：选项写清主责模块 vs 联动对象；标题只挂主责，联动写描述
- **故事点细节**：仅当材料或用户补充已暗示时，才把词典闭环中的合理分支列为选项；**禁止**把未提及的故事点细节默认选中
每题结构建议：
```text
【需求 n · 待确认 k】<待确认原文>
依据词典，请选择：
A. …
B. …
C. …
D. 其他（请补充一句）
也可用一段需求描述直接回答本点
```
## 用需求描述补充
用户可用以下任一方式消解待确认，**不必**每题都点选：
- 粘贴一段补充说明 / 功能规则 / 字段清单
- 回复「按下列描述确认：…」
- 对某一待确认点直接写答案句
Agent 须：
1. 将补充文字**映射**到对应待确认点（可一次消解多点）
2. 写入该条**描述**（书面化、去结尾句号），从「待确认」列表**移除已消解项**
3. 补充仍含糊的部分 → 保留或新开「待确认」，继续选择题
4. **不**把补充里未说的内容脑补进去
## 回填定稿规则
确认完成后，对该条输出「已确认」版本：
```markdown
### n（已确认）
## 原始诉求（AutoRDO）
**标题**：…
**描述**：
<初稿 + 已确认信息合并；无结尾句号>
待确认：
- （无则写「无」或省略本段）
```
- 标题若因模块/动作确认而需微调，可改，并在确认回合说明改了什么
- 未确认点**不得**假装已确认；可标「本条暂缓，待确认仍保留」
- 全部条完成后，给总览：已确认条数 / 仍含待确认条数
## 口令
```text
AutoRDO：<材料> → 有待确认则自动进 Plan
按下列补充消解待确认：
<粘贴补充说明>
第 6 条待确认选 A；第 7 条补充：字段非必填，计入应补汇总
```
（「确认待确认」等口令**不再作为**进 Plan 的前置条件；有待确认即强制进。）
## 不做
- 确认阶段仍不改云效、不建任务
- 不把 `oneos-domain.md` 全文贴进定稿
- 不跳过 Plan 直接把「猜的答案」写进描述
- 不等用户额外口令才进 Plan（有待确认必须进）

96
.claude/skills/AutoRDO/references/meta-fields.md Normal file
View File

@@ -0,0 +1,96 @@
# AutoRDO · 元数据自动识别
从粘贴内容（台账表格行、聊天、口述）自动识别下列字段，写入每条原始诉求输出；**不**直接改云效打标（打标由 YunxiaoPMapp 执行）。
## 输出字段
| 字段 | 说明 | 无依据时 |
|---|---|---|
| **类型** | `【新增】` / `【优化】`（与云效标题前缀一致） | 默认 `【优化】`，并列入待确认 |
| **优先级** | `P1-高` / `P2-中` / `P3-低` | 默认 `P2-中`，高不确定则待确认 |
| **标签** | 主模块标签（对齐 `oneos-domain.md` 标准模块名）；可附端标签 `PC端` / `小程序` | 仅模块不确定则待确认 |
| **提交部门** | 映射到词典标准部门名 | 材料无部门且无法推断 → 待确认或空 |
| **提交人** | 反馈人/用户姓名 | 材料无人名 → 空（不臆造） |
## 识别优先级
```text
1. 显式列/字段（反馈台账：优先级、所属部门、反馈方、业务模块、PC或移动端…）
2. 正文中的明确标记（P1、【优化】、@某人、部门署名）
3. 语义推断（用词 + oneos-domain 模块/部门）
4. 仍不确定 → 待确认（选择题），禁止假装已确认
```
## 类型（【新增】/【优化】）
| 信号 | 类型 |
|---|---|
| 新增、增加、支持、允许、增加列/字段/入口、批量导入（首次能力） | 【新增】 |
| 优化、调整、修改、放开、更清晰、重构、移动至、改由、精确到、兼容 | 【优化】 |
| 台账/口令已写 `【新增】`/`【优化】` | 以显式为准 |
| 同时含新增与优化语义 | 以**主诉求**定类型；次要点写在描述 |
标题可带类型前缀供入库：`【优化】交车管理：…`；若用户只要裸标题，类型仍单独输出字段。
## 优先级
| 信号 | 优先级 |
|---|---|
| 列值 `P1-高` / `P1` / 紧急、阻塞、无法办理、P1 | `P1-高` |
| 列值 `P2-中` / `P2` | `P2-中` |
| 列值 `P3-低` / `P3` / 文案、置灰、体验微调 | `P3-低` |
| 无信号 | 默认 `P2-中` |
## 标签
1. **主标签** = 归属标准模块名（`oneos-domain.md`），如 `还车应结款`、`违章管理`、`交车管理`
2. 台账「业务模块」列优先；口语映射到标准名（验车管理→验车入库，调拨管理→车辆调拨）
3. **端标签**（可选，可多选）：材料含 `PC端`/`小程序`/`PC及小程序` 时写入
4. 「其他」「全局优化」「小程序审批中心」等非模块名：主标签用最贴近模块或 `系统全局`；勿发明云效不存在的随意标签名
5. 输出格式：逗号分隔，如 `还车应结款, PC端`
## 提交部门
| 材料常见写法 | 标准输出 |
|---|---|
| 业务管理部、业管、业务管理 | 业务管理组 |
| 运维部、运维 | 运维部 |
| 数智中心、数智、信息化 | 数智部 |
| 安全部、安全 | 安全部 |
| 财务部、财务 | 财务部 |
| 法务部、法务 | 法务部 |
| 采购部/采购组 | 按词典区分输出 |
台账「所属部门」列优先；聊天中「我们运维…」可推断，低置信度则待确认。
## 提交人
- 台账「反馈方/用户」「反馈人」列 → 原样作为提交人
- 聊天 @姓名、署名「张三：」→ 取该名
- 多人联合反馈 → 取主反馈人（首列/首个署名）；其余可写描述附注
- **禁止**用当前对话用户名冒充提交人（除非材料写明）
## 与描述附注的关系
- **结构化字段**（类型/优先级/标签/提交部门/提交人）单独成行，供 YunxiaoPMapp 建单口令复用
- 禅道编号、处理状态、反馈日期等 → 可放描述末行「反馈：…」附注，不升格为强制字段
## 输出模板（每条）
```markdown
## 原始诉求（AutoRDO）
**标题**：<清晰标题；可选带【新增】/【优化】前缀>
**类型**：【新增】|【优化】
**优先级**：P1-高|P2-中|P3-低
**标签**：<模块>[, PC端|小程序]
**提交部门**：<标准部门名或空>
**提交人**：<姓名或空>
**描述**：
<转译正文；无结尾句号>
反馈：<日期 · 原文部门 · 状态 · 禅道号 · 端 …>（有则写）
待确认：
- …
```

399
.claude/skills/AutoRDO/references/oneos-domain.md Normal file
View File

@@ -0,0 +1,399 @@
# ONE-OS 业务领域词典（供 AutoRDO 对齐）
> 来源：业务条线说明原型 `lease-business-line-overview`
> 用途：清洗标题/描述时，优先用下列**标准模块名、部门名、闭环表述**对齐，避免口语臆造模块或错挂条线。
> 系统定位：1 套系统 · 5 大业务条线闭环 · 3 大数据底座 · 演进方向为业财一体
> **强制**：本文件只用于理解与用词对齐；**禁止**把本词典全文贴进云效描述或 AutoRDO 输出稿。
---
## 0. 系统总览
| 维度 | 口径 |
|---|---|
| 平台名 | ONE-OS（亦写作 OneOS） |
| 五大业务条线 | 租赁 · 能源 · 运维 · 安全 · 物流 |
| 三大数据底座 | 车辆资产运营情况 · 各业务条线盈亏情况 · 里程调度情况 |
| 现阶段 | 业务驱动 · 财务手工维护（收款/付款/核销多人工） |
| 演进方向 | 业财闭环一体化（打通财务 YS，「收款记录」「付款记录」与业务台账双向回写） |
**标题提炼提示**：口述涉及合同/台账/交还车/氢费/证照/调度时，先归入对应条线再落模块名；跨条线联动（如还车应结款联动违章事故）在描述中写明联动对象，标题以主责模块为准。
---
## 1. 业务部门 / 角色词典（标准用词）
清洗时统一下列名称；同义口语请映射到标准名。
| 标准名称 | 常见口语/别称 | 主要出现条线 |
|---|---|---|
| 业务管理组 | 业管、业务管理 | 租赁、运维、安全、物流 |
| 业务管理组-能源部 | 能源组、业管能源、业务管理部-能源组 | 能源、租赁还车 |
| 业务服务组 | 业务服务 | 物流 |
| 业务员 | 业务 | 租赁 |
| 调度岗 | 调度 | 物流 |
| 法务部 | 法务 | 租赁、运维采购合同 |
| 财务部 | 财务 | 租赁评级、能源账户、运维付款/维保、安全违章事故、物流台账 |
| 安全部 | 安全 | 租赁评级、证照、安全条线 |
| 运维部 | 运维、区域操作员 | 运维全链路、交还车、租赁提车后交车 |
| 采购部 | 采购 | 能源加氢站、运维采购合同/验车 |
| 采购组 | 采购组 | 供应商管理（能源/运维） |
| 数智部 | 数智、信息化 | 合同模板电子化、能源扩展 |
| 董事长 | 老板、总 | 非标合同、资产出售过户报废确认 |
| 司机 | 提车司机、内部司机 | 交车培训、故障、安全培训 |
| 加氢站 / 签约加氢站 | 站点、站方 | 能源 |
**组织边界提示**
- 「采购组」侧重供应商主数据；「采购部」侧重站点管理与采购/三方租赁合同。
- 「业务管理组」与「业务管理组-能源部」勿混用；氢费、加氢对账默认能源部。
- 物流调度明确：**非 TMS**，不做配载与承运商调度。
---
## 2. 功能模块总表（按条线）
### 2.1 租赁业务条线（6 模块 · 全链路闭环）
**条线闭环**：客户评级决定是否可签 → 标准模板支撑签约 → 租赁合同进入履约 → 提车应收对齐后交车 → 台账承接租期账单 → 还车应结款会签归档。
| 步 | 模块名 | 一句话定位 | 责任部门 |
|---|---|---|---|
| 1 | 客户管理 | 准入评级 · 决定能否签约、走哪条流程 | 业务管理组、法务部、财务部、安全部 |
| 2 | 标准合同管理 | 模板配置 · 支撑电子合同一键发起 | 法务部、数智部 |
| 3 | 租赁合同 | 签约发起 · 标准 / 非标 / 禁止三条路径 | 业务员、法务部 |
| 4 | 提车应收款 | 应收生成 · 实收对齐 · 触发交车 | 业务员、法务部、业务管理组、运维部 |
| 5 | 租赁业务台账 | 交车后账单 · 周期收费与实收延续 | 运维部、业务员、业务管理组 |
| 6 | 还车应结款 | 还车结算 · 多部门会签 · 归档闭环 | 业务管理组、安全部、运维部、业务管理组-能源部 |
**关键结果标签（客户管理）**：可标准签约 · 可签·走非标 · 禁止签约·高风险
---
### 2.2 能源业务条线（6 模块 · 业财闭环）
**条线闭环**：供应商主数据支撑站点绑定 → 签约站账号与订单主动上报 → 非签约站氢费补录对账 → 客户对账单关联收款 → 加氢记录标记已付款 → 成熟后向采购端与司机端延伸。
| 步 | 模块名 | 一句话定位 | 责任部门 |
|---|---|---|---|
| 1 | 供应商管理 | 加氢/充电站供应商 · 站点绑定与业财直连 | 采购组、财务部 |
| 2 | 加氢站管理 | 签约站 / 非签约站 · 账号、余额与价格 | 采购部、加氢站 |
| 3 | 加氢订单 | 主动上报 · PLC 自动采集 · 预约接单 | 签约加氢站、业务管理组-能源部 |
| 4 | 车辆氢费明细 | 非签约站补录 · 对账归档 · 余额关联 | 业务管理组-能源部 |
| 5 | 氢费账户 | 客户预付款 · 对账单 · 业财收款闭环 | 业务管理组-能源部、财务部 |
| 6 | 扩展规划 | 上游采购 · 下游司机服务 | 采购部、业务管理组-能源部、数智部 |
---
### 2.3 运维管理条线（15 模块）
**主线（main）**：验车入库 → 上牌 → 证照 → 备车 → 交车 → 还车 → 出售/过户/报废出库
**并行能力（support）**：供应商、采购合同、替换车、故障、年审、维保、异动、调拨（无严格先后）
**条线闭环**：供应商与采购合同入库 → 上牌证照与备车整备 → 交车/替换/还车闭环 → 故障与年审维保 → 异动调拨 → 出售/过户/报废审批出库。
| 步 | 模块名 | 轨道 | 一句话定位 | 责任部门 |
|---|---|---|---|---|
| 1 | 供应商管理 | support | 整车厂 / 三方租赁 · 付款底座 | 采购组、财务部 |
| 2 | 车辆采购 / 三方租赁合同 | support | 车型数量 · 付款关联 · 验车任务 | 采购部、法务部、财务部 |
| 3 | 验车入库 | main | 采购 / 三方来源 · 验完自动入库 | 运维部、采购部 |
| 4 | 车辆上牌 | main | 车架号入库 · 完成牌证登记 | 运维部 |
| 5 | 证照管理 | main | 一车一档 · 到期待办推送 | 运维部、安全部 |
| 6 | 备车管理 | main | 交车前整备 · 随时可交付 | 运维部 |
| 7 | 交车管理 | main | 司机培训留痕 · 区域派单 · OCR 比对 · 电子签 | 运维部、业务管理组、司机 |
| 8 | 替换车管理 | support | 临时 / 永久替换 · 费用自动核算 | 运维部、业务管理组 |
| 9 | 还车管理 | main | 区域派单 · 费用自动计算 · 电子签 | 运维部、业务管理组 |
| 10 | 故障管理 | support | AI 助手 + 人工 · 证据链归档 | 运维部、司机 |
| 11 | 年审记录 | support | 提前 3 个月 · OCR 刷新证照 | 运维部 |
| 12 | 维修与保养记录 | support | 费用汇总 · 业财一体 · 盈亏核算 | 运维部、财务部 |
| 13 | 车辆异动 | support | 出库维修 / 年审 / 保养 · 成本归集 | 运维部 |
| 14 | 车辆调拨 | support | 跨区调拨 · 运维权转移 | 运维部、业务管理组 |
| 15 | 车辆出售、过户、报废 | main | 资产变更审批 · 过程留痕 · 自动出库 | 运维部、董事长、财务部 |
---
### 2.4 安全管理条线（6 模块 · 安全闭环）
**条线闭环**：司机信息与证照 → 定期培训与资料库学习 → 违规记录关联评级 → 违章/事故登记 → 联动还车应结款与代处理费用。
| 步 | 模块名 | 一句话定位 | 责任部门 |
|---|---|---|---|
| 1 | 司机管理 | 物流内部司机 · 信息证照一体 | 安全部、业务管理组 |
| 2 | 内部司机培训 | 定期安全培训 · 证据链留痕 | 安全部、司机 |
| 3 | 安全培训资料库 | 资料上传 · APP / 小程序学习 | 安全部、司机 |
| 4 | 违规记录 | 司机违规 · 关联评级 | 安全部、业务管理组 |
| 5 | 违章管理 | 分值罚款 · 还车联动 · 代处理 | 安全部、财务部、业务管理组 |
| 6 | 事故管理 | 权责划分 · 保险赔付 · 还车联动 | 安全部、财务部、业务管理组 |
---
### 2.5 物流业务条线（3 模块 · 经营闭环）
**条线闭环**：物流合同生效 → 轻量调度派车（交车后可办结）→ 办结自动生成物流业务明细 → 汇总盈亏 → 汇集项目盈亏表 → 演进关联收款记录完成业财闭环。
| 步 | 模块名 | 一句话定位 | 责任部门 |
|---|---|---|---|
| 1 | 物流合同 | 关键信息录入 · 业务确认生效 · 可派车 | 业务管理组、业务服务组 |
| 2 | 调度任务 | 轻量派车 · 交还车校验 · 办结出车 | 业务服务组、调度岗、运维部 |
| 3 | 物流台账 | 任务自动生成 · 补录导入 · 盈亏核算 | 业务服务组、财务部 |
---
### 2.6 三大数据底座（管理决策层，非业务条线）
| 底座 | 看什么 | 主要数据来源条线 |
|---|---|---|
| 车辆资产运营情况 | 规模 · 结构 · 健康度 · 品牌型号出勤率下钻省市 | 运维、车辆管理、证照/保险、交车/备车 |
| 各业务条线盈亏情况 | 收入 · 成本 · 利润（条线/项目/单车） | 租赁台账、物流台账、氢费账户、收款、维保/事故/违章 |
| 里程调度情况 | 里程补贴 · 客户履约 · 智能替换与运维干预 | 车机/GPS/人工里程、客户里程约定、替换车、运维干预 |
---
## 3. 流程闭环速查（端到端一句话）
| 条线 | 闭环一句话 |
|---|---|
| 租赁 | 客户 → 模板 → 签约 → 提车应收 → 交车 → 台账账单 → 还车应结款归档 |
| 能源 | 供应商 → 加氢站 → 订单采集 → 氢费明细 → 客户账户收款 → 记录已付款 |
| 运维 | 采购/验车入库 → 牌证备车 → 交还车 → 维保故障 → 异动调拨 → 处置出库 |
| 安全 | 司机档案 → 培训资料 → 违规评级 → 违章事故 → 还车应结款费用 |
| 物流 | 合同生效 → 调度派车办结 → 台账明细/盈亏 →（演进）收款业财闭环 |
| 系统级 | 五条线业务闭环 → 三大数据底座决策 → 打通财务 YS 业财一体 |
**高频跨模块联动（写描述时勿漏）**
- 租赁签约路径依赖**客户管理**评级（标准 / 非标 / 禁止）
- **提车应收**对齐后触发运维**交车**；交车成功生成**租赁业务台账**
- **还车管理**完成后生成**还车应结款**；安全**违章/事故**费用写入应结项
- 运维**采购/三方租赁合同**自动生成**验车入库**任务
- 物流**调度办结**须车辆已**交车**；办结自动写**物流台账**
- 能源签约站**加氢订单**与非签约站**氢费明细**统一进入**氢费账户**对账收款
---
## 4. 故事点（按模块：起点 → 怎么运作 → 闭环）
> 结构对齐页面「起点 / 怎么运作 / 闭环」。标题用「模块名 + 核心动作」；描述保留谁发起、关键规则、闭环结果，不升格成完整 PRD。
> 下列为各模块业务事实摘要，用于**识别归属与用词**；材料未提及的细节**不得**脑补进描述。
### 4.1 租赁
#### 客户管理
- **起点**：业务管理组维护客户基础信息，作为后续合同与账单的统一客户主数据
- **怎么运作**：法务每 3 个月评估法律风险；财务实时维护财务风险等级；安全实时维护安全风险等级；系统综合形成签约策略
- **闭环**：未达禁止标准可签；偏离常规范式走「非标准流程」；达禁止标准禁止新签，现有合同标「高风险」并通知业务跟进或终止
#### 标准合同管理
- **起点**：法务部维护各车型试用/正式等标准模板，明确条款边界与风控要求
- **怎么运作**：数智部按模板配置电子合同；条款可设「触发车型」；「风控红线」被改进非标审批；「锁定区域」不可随意改
- **闭环**：业务员直选模板走标准流程；触碰红线或锁定区外修改转法务非标审批
#### 租赁合同
- **起点**：业务员选羚牛签约主体与乙方客户；系统按评级判标准/非标/禁止
- **怎么运作**：合同要素实时反写电子合同预览；生成电子合同/条款附件/授权委托书；越界转非标；支持续签、转正式、转三方、增值服务、授权委托书、主动终止等
- **闭环**：审批通过进入履约并串联提车应收、交车、台账；非标须法务与董事长确认后放行
#### 提车应收款
- **起点**：提交租赁合同审批时，按合同条款自动生成提车应收金额
- **怎么运作**：法务在「收款记录」导入到账（后期对接 YS/银企直联）；业务/业管关联账单并分配金额；实收对齐后标记完成
- **闭环**：应收完成后按约定生成交车任务，属地运维执行交车
#### 租赁业务台账
- **起点**：运维交车成功后自动生成该车租赁账单，应付款日初始「待设置」
- **怎么运作**：设置应付款日后生成首期应收；提车实收写入首期；溢出并入第二期减免
- **闭环**：持续记录每期应收/实收/状态，支撑租期运营与还车结算
#### 还车应结款
- **起点**：运维完成还车后自动生成还车应结款任务
- **怎么运作**：业管、安全、运维、能源各自完成部门审批；汇总应退/应补；应补关联收款记录、应退关联付款记录
- **闭环**：业管发起总审批；完成后自动归档，租赁单条业务全链路闭环
---
### 4.2 能源
#### 供应商管理
- **起点**：加氢站/充电站作为供应商纳入统一体系，采购组维护基础信息与结算要素
- **怎么运作**：创建站点时绑定供应商；氢费/电费对账支持直连付款；收付款明细关联财务记录；支撑付款/收款申请审批
- **闭环**：供应商主数据与站点、对账、财务贯通，打好能源业财基础
#### 加氢站管理
- **起点**：采购部统一管理签约站/非签约站；签约站须关联供应商与系统账号
- **怎么运作**：签约站账号登录加氢订单（PC/移动/H5）；预付款余额；营业状态；成本价关联氢费记录；能源部形成对账单并发起付款（后期对接 YS）
- **闭环**：站点/账号/余额/价格/营业状态集中管理，签约站可自助上报
#### 加氢订单
- **起点**：签约站登录后多渠道上报订单；PLC 站点可自动获取
- **怎么运作**：多端快速识别记录；PLC 自动获取；联动「小羚羚」预约接单，司机确认；进入加氢记录供对账
- **闭环**：主动上报或自动采集，预约在线闭环，减少手工补录
#### 车辆氢费明细
- **起点**：非签约站氢费由业务管理组-能源部手动维护
- **怎么运作**：录入并关联站点/车辆/客户；对账后标「已对账」归档；联动预付款余额与客户能源账户；OCR 与电子围栏辅助核对
- **闭环**：签约/非签约氢费统一归集，余额变动可追溯
#### 氢费账户
- **起点**：管理客户氢费预付款余额与客户对账单
- **怎么运作**：维护余额变动；生成对账单；关联「收款记录」；收款后加氢记录标「已付款」；支持充值/开票直达财务（替代钉钉，对接 YS）
- **闭环**：明细→对账→收款全链路可核对，付款状态与财务实收一致
#### 扩展规划
- **起点**：条线成熟后向上游采购与下游司机服务延伸
- **怎么运作**：上游氢气采购；下游外部氢能车司机服务；与现有供应商/站点/订单/账户衔接
- **闭环**：覆盖「采购—站点—用氢—结算—司机服务」更大范围生态
---
### 4.3 运维
#### 供应商管理
- **起点**：整车厂、三方租赁企业纳入供应商体系
- **怎么运作**：维护档案；为采购/三方租赁合同提供主数据；支撑付款底座
- **闭环**：与采购合同、付款记录贯通
#### 车辆采购 / 三方租赁合同
- **起点**：向整车厂/三方租赁厂商发起采购或三方租赁合同
- **怎么运作**：创建审批；关联付款记录；按条款自动生成验车任务
- **闭环**：合同、付款、验车联动，入库合规入口
#### 验车入库
- **起点**：对采购或三方来源氢能车执行验车
- **怎么运作**：接收验车任务；记录过程与问题；验完自动入库
- **闭环**：验车结果与合同、库存绑定，来源可审计
#### 车辆上牌
- **起点**：对仅有车架号的新车执行上牌
- **怎么运作**：筛选待上牌车；录入/同步牌照；更新库存状态
- **闭环**：牌证完整，为证照与交车提供前置条件
#### 证照管理
- **起点**：行驶证、道路运输证、登记证、特种设备证/标识、加氢卡、安全阀、压力表等一车一档
- **怎么运作**：维护档案与有效期；临近到期生成年审/等评/换证待办；推送运维/安全
- **闭环**：证照全生命周期管理，降低漏办与违规风险
#### 备车管理
- **起点**：日常提前整备，确保交车任务可随时交付
- **怎么运作**：按计划/库存策略发起检查；记录整备项与责任人
- **闭环**：交车前置完成，提升交付效率与质量一致性
#### 交车管理
- **起点**：承接租赁/物流交车任务，按区域派属地运维；司机先完成在线培训并留痕
- **怎么运作**：司机上传身份证/驾驶证/从业资格证、签名与现场拍照；交付证照及保险有效车辆；记录里程/氢量/电量/位置；OCR 胎纹；还车时比对算磨损等费用；E 签宝电子签归档
- **闭环**：培训与交车数据完整可查，为还车费用与争议提供依据
#### 替换车管理
- **起点**：因客户或车辆原因发起临时/永久替换
- **怎么运作**：选类型与新旧车；完成替换交还；客户原因自动算费用差
- **闭环**：过程可追踪、费用可核算，履约不中断
#### 还车管理
- **起点**：处理业务/业管还车任务，按区域派属地运维
- **怎么运作**：记录还车时间/里程/氢电量/位置；OCR 胎纹对比算磨损费；按里程与氢电差算费用；E 签宝确认归档
- **闭环**：费用依据交还对比自动出具
#### 故障管理
- **起点**：微信 AI 故障助手或人工记录故障关键信息
- **怎么运作**：记时间地点车型紧急程度；留存图文视频聊天证据；运维处理至关闭；形成待办统计；沉淀品牌故障类型统计支撑采购论证
- **闭环**：全过程留痕，证据链完整
#### 年审记录
- **起点**：按行驶证审验有效期提前 3 个月生成年审任务
- **怎么运作**：按车按月归集；完成后 OCR 新行驶证刷新证照；按月量化完成率
- **闭环**：任务不遗漏，证照与办理结果同步
#### 维修与保养记录
- **起点**：运维手动维护负责车辆维保记录（首期）
- **怎么运作**：配件费/人工费汇总；按承担方（客户/我司）生成客户账单或计入运维成本；计入车辆盈亏
- **闭环**：维保成本可追溯可分摊，支撑单车盈亏与对客户计费
#### 车辆异动
- **起点**：因当地维修/年审/保养出库异动，须提前审批
- **怎么运作**：记异动前后氢电量里程；异动期间加氢记录归集为异动成本
- **闭环**：可审批可计量，避免成本漏记
#### 车辆调拨
- **起点**：车辆从 A 地调至 B 地运营，须提前审批
- **怎么运作**：记发起方/费用/运输；接收方确认；运维操作权由 A 转 B
- **闭环**：跨区调拨透明，责任属地随车切换
#### 车辆出售、过户、报废
- **起点**：达出售/过户/报废条件发起资产变更，录入交易方价格过户残值等
- **怎么运作**：提交申请；董事长确认；运维记录全过程归档；完成后退出运营并出库
- **闭环**：处置审批留痕，生命周期闭环至出库归档
---
### 4.4 安全
#### 司机管理
- **起点**：管理物流内部司机，支撑快速选取与档案维护
- **怎么运作**：维护基础信息与在职状态；管理驾驶证/从业资格证；与交车、台账联动
- **闭环**：主数据统一、证照可查，支撑调度与合规
#### 内部司机培训
- **起点**：定期开展安全培训并形成可追溯记录
- **怎么运作**：制定计划组织参训；记录时间内容参训人；形成证据链供交管查询
- **闭环**：培训电子归档，随时可调阅
#### 安全培训资料库
- **起点**：安全部上传培训与安全运营资料供司机学习
- **怎么运作**：维护课件制度指引；分类发布版本检索；司机经 APP/小程序学习
- **闭环**：资料集中更新，移动端可学可查
#### 违规记录
- **起点**：记录内部司机运营违规
- **怎么运作**：登记事件类型时间结果；关联司机档案；联动客户安全评级
- **闭环**：违规可追踪汇总，支撑选用与评级
#### 违章管理
- **起点**：记录交通违章并与还车应结款联动
- **怎么运作**：登记时间地点分值罚款及是否缴纳；未处理纳入还车结算；逾期未缴自动生成代处理费用
- **闭环**：违章可查，代处理费用与还车/财务口径一致
#### 事故管理
- **起点**：记录事故信息，支撑定责理赔与还车结算
- **怎么运作**：登记权责划分；记保险介入/赔付/上浮；联动还车应结款写入安全费用
- **闭环**：登记→赔付→上浮→应结款贯通，费用不遗漏
---
### 4.5 物流
#### 物流合同
- **起点**：创建物流运力服务合同，录客户/车型/车辆数/交车时间地点，上传附件
- **怎么运作**：录入项目与合同要素；业务确认生效后可创建轻量调度并提示运维交车
- **闭环**：合同成为调度派车与交车的上游凭证
#### 调度任务
- **起点**：在生效合同下创建出车任务，派车派司机；非 TMS
- **怎么运作**：选合同、计划出车日、线路、是否多趟与计价口径；未交车须先交车；办结确认实际出车后自动生成物流业务明细一行
- **闭环**：出车事实追溯到合同与车牌，驱动台账落账
#### 物流台账
- **起点**：承接调度办结自动生成的出车明细，导入/行编辑补录异常与历史
- **怎么运作**：办结写入营收侧并算金额/总成本/盈亏；氢费/ETC 等成本可手工补录；汇集项目盈亏表；演进关联「收款记录」
- **闭环**：收入与司机/车辆成本同台账可核对，盈亏可对接财务实收
---
## 5. AutoRDO 应用约定
1. **标题**：优先 `模块标准名：核心动作/结果`（10–30 字），模块名以本词典为准（例：`验车入库：采购与三方租赁合同自动生成验车记录及入库`）
2. **条线归属**：一句需求只挂一个主模块；跨条线联动写在描述里，不硬塞进标题
3. **部门用词**：口语「业管/能源组/运维」等映射到第 1 节标准名
4. **闭环口径**：若材料只讲做到一半，闭环写实际说到的结果，缺的标「待确认」
5. **不做**：不把本词典全文贴进云效描述或输出稿；不脑补材料未出现的故事点细节
6. **业财关键词**：收款记录、付款记录、对账单、应收/实收、YS、银企直联、E 签宝、小羚羚、PLC——保留原文业务对象名，勿随意改写
---
## 6. 条线演进（辅助理解，非强制写入描述）
| 条线 | 现阶段 | 演进方向 |
|---|---|---|
| 租赁 | 合同电子化 · 业务闭环化 | 移动端商城直连发起合同，后续自动打通 |
| 能源 | 手工维护氢费明细 | 签约站主动上报，能源部转为核对确认 |
| 运维 | 车辆使用环节闭环 | 入库→运作→出库全链路 |
| 安全 | 司机安全全链条 | 与客户安全评级挂钩、事前预判 |
| 物流 | 合同 + 调度办结落账 | 成本自动回填、司机在线、关联收款；不做完整 TMS |
| 系统 | 业务驱动 · 财务手工 | 打通 YS · 业财一体 |

67
.claude/skills/AutoRDO/references/rules.md Normal file
View File

@@ -0,0 +1,67 @@
# AutoRDO 清洗与拆解细则
## 目标
碎片 → 可入库的书面「标题」与「描述」。保留原意；不写成产品 PRD。
多行/多条独立输入 → **多份**转译结果（一份需求一份稿）。
## 必做与精炼规则
| 规则 | 说明 |
|---|---|
| **多条拆解** | 输入为多条独立诉求时，**先拆后洗**：<br>• **拆分信号**（满足任一即可）：换行且每行一句独立诉求；`1. 2. 3.` / `-` / `*` 列表；表格多行；空行分段；「另外」「还有」「第二条」等显式分条<br>• **每条**各自输出一份标题+描述+待确认，**禁止**合并成一条大需求<br>• **不拆**：同一条需求内部的续写、补充说明、功能规则子点（属于描述细节，挂在该条下）<br>• **边界不清**：无法判断是一条还是多条时，在文首标「待确认：拆条边界」，并按最可能的分条给出结果，请用户校对 |
| **OneOS 领域对齐** | 涉及 ONE-OS / 羚牛业务时，**先读** [oneos-domain.md](oneos-domain.md)：<br>• 部门口语映射到标准名（业管→业务管理组，能源组→业务管理组-能源部 等）<br>• 标题模块名优先用词典标准名（如「验车入库」而非口语「验车管理」——若材料确指该模块）<br>• 跨条线联动写在描述，标题只挂主责模块<br>• **禁止**把词典全文或未在材料中出现的故事点细节写入输出 |
| **标题提炼** | 根据材料内容理解，自动概括简炼、清晰的标准需求标题：<br>• **内容理解**：准确识别归属的业务模块与核心动作/诉求（如：`验车入库：采购与三方租赁合同自动生成验车记录及入库`）。<br>• **自然流畅**：表达自然书面化，无需死板强求拼接固定句式；彻底剔除“我们要做一个”、“主要是用于”、“完成之后才能”等口语废话。<br>• **字数适中**：控制在 10-30 字内，能让读者一眼看懂需求核心。 |
| **元数据识别** | 详见 [meta-fields.md](meta-fields.md)。从台账列或正文自动识别并输出：<br>• **类型**：`【新增】`/`【优化】`<br>• **优先级**：`P1-高`/`P2-中`/`P3-低`<br>• **标签**：标准模块名（+ 可选 PC端/小程序）<br>• **提交部门**：映射词典标准名（业务管理部→业务管理组，数智中心→数智部 等）<br>• **提交人**：反馈方/用户列或署名<br>• 显式列优先；推断不确定则待确认；**不**直接写云效打标 |
| **描述转译** | 原文的转译结果，将口述/碎片材料转译为规范书面表达，保留原意（不改变谁要求什么、约束与例外；不替换成「更优方案」）；业财对象名（收款记录、付款记录、YS、E 签宝、小羚羚、PLC 等）按词典保留 |
| 书面化 | 口语改成完整句子或清晰短条目；主谓齐全 |
| 去口头禅 | 删除：嗯、啊、那个、就是说、然后呢、对对对、你懂吧 等 |
| 自我修正 | 以最后一次明确口径为准；若前后矛盾且未决，列入「待确认」 |
| 去重复 | 同一意思多轮确认只保留一处；多条拆解时，各条之间不要互相抄写无关内容 |
| 轻度格式 | 可用短标题/条目；禁止展开成总览/角色/流程图/故事点等 PRD 结构 |
| 去结尾句号 | 描述中每个句子或条目末尾去掉 `。`；保留 `？` `！` 若确为疑问/感叹 |
| 待确认 | 材料含糊处写 `待确认：…`，不臆造；**只要存在待确认，同轮强制**进入 [confirm-pending.md](confirm-pending.md) 的 Plan 逐条确认（无需用户再说「确认待确认」） |
| **待确认 Plan 确认** | 详见 [confirm-pending.md](confirm-pending.md)：<br>• 清洗结果含待确认 → **立刻** `SwitchMode` → plan<br>• 按需求条号**逐点**确认；**优先选择题**（2–5 项 +「其他/我补充」），选项用 `oneos-domain.md` 辅助<br>• 也支持用户粘贴**需求描述/补充说明**一次消解多点<br>• 确认后回填描述并移除已消解项；未确认不得写入定稿 |
## 多条拆解示例
**输入（多行）：**
```text
还车应结款生成后自动展示违章事故信息，不必等安全员提交
验车完成后才能车辆入库
氢费账户对账单要能关联收款记录
```
**输出**：3 份独立的「原始诉求（AutoRDO）」，每份各自标题+描述；不要揉成一条。
## 标题提炼对比示例
- ❌ **坏标题（直抄口语/带废话）**：`我们现在要做一个验车管理功能主要是采购合同和三方租赁合同自动形成验车记录验车完成之后才能车辆入库`
- ✅ **好标题（自然清晰，覆盖标准模块）**：`验车入库：采购与三方租赁合同自动生成验车记录及入库`（模块名对齐 oneos-domain）
## 不做
- 不生成 AutoPRD 十章或「产品说明」
- 不写验收清单、故事点、mermaid
- 不改云效、不建【交付】/分析/设计
- 不加载 `yunxiao-requirement-lifecycle`
- 不把多条独立诉求合并成一条「大杂烩」需求
## 录音
1. 已有转写 → 按上文清洗转写稿并拆解标题与描述；转写中若含多条独立诉求，同样先拆后洗
2. 仅音频 → 回报「请提供转写文本后再 AutoRDO」，停止声称已清洗完成
## 质量自检
- [ ] 多行/多条输入时，已按条拆成多份结果（条数与输入独立诉求数一致或已说明待确认边界）
- [ ] 已对照 `oneos-domain.md`（ONE-OS 相关材料）
- [ ] **标题清晰通顺**（标准模块名 + 核心动作，无死板句式绑定，无口语废话）
- [ ] 部门/业财关键词已映射或保留为词典标准口径
- [ ] **描述为原文的转译结果**，干系人能认出这是自己说的意思；未脑补词典故事点
- [ ] 无口头禅堆砌、无未决矛盾被写成定论
- [ ] 描述末尾无 `。`
- [ ] 未冒充完整 PRD；未把词典全文写入输出
- [ ] 已输出类型/优先级/标签/提交部门/提交人（有依据或已标待确认；未臆造提交人）
- [ ] 若存在待确认：已同轮强制进 Plan（未等「确认待确认」口令）；优先选择题、选项有词典依据；文字补充已映射到对应点；定稿无未确认臆造
- [ ] 若无待确认：未多余进 Plan