68 lines
6.2 KiB
Markdown
68 lines
6.2 KiB
Markdown
# 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
|