docs(ai): 记录无需求ID拆解分组

docs/decisions.md

@@ -165,9 +165,10 @@
 
 **对应风险**：AI 可能把"上版本就有的功能"也当成"本次新做"。
 
-**应对**：要求 Agent 输出**对账报告**，三段：
+**应对**：要求 Agent 输出**对账报告**，结构化呈现：
 - ✅ 完美对应（需求 ↔ 原型注释 ↔ 任务）
-- ⚠️ 仅需求未见原型 / 仅原型未见需求
+- ⚠️ 需求未见原型
+- 无需求ID分组（原型有明确功能但没有匹配到关联需求）
 - ❓ 注释含糊无法转化
 
 **理由**：让历史版本入库的成本远高于让用户对账的成本。对账报告本来就是 AI 拆解的标配，能同时兜住"拆偏"和"拆漏"两类问题。让团队补需求清单，比让团队补历史原型容易。
@@ -378,7 +379,7 @@
 - Agent 对账优先按需求编号匹配；原型文本出现 `requirement.id` 或 `requirement.code` 时必须优先归到该需求。
 - 没有需求编号时，再按需求标题和需求概述做语义匹配。
 - 没有 QY 编号但命中了需求编号或需求概述时，允许只引用 `requirement`，`matched.noteIds` 返回空数组。
-- 只有编号和概述都匹配不到的原型批注，才进入 `noteOnly` 或 `ambiguous`。
+- 编号和概述都匹配不到、但能形成明确功能名称和任务范围的原型批注，进入 `prototypeOnly` 无需求ID分组；只有无法稳定转化为任务/用例的批注才进入 `ambiguous`。
 
 **理由**：需求编号是最稳定的对账锚点，需求概述是编号缺失时的业务语义兜底。把匹配证据先送进上下文，再用 prompt 明确优先级，比只依赖模型从截断文本里自由联想更稳定。
 
@@ -444,3 +445,18 @@
 - AI 只写入 `xiaobao-risk-insights` 缓存，不修改 Version、DevTask、TestCase、Bug、Requirement 或 Member。
 
 **理由**：规则结果可测试、可追溯、可复盘；AI 文案提升可读性，但不能替代系统事实判断。趋势、静默风险和置信度能弥补“当前风险等级”过于静态的问题。
+
+## 37. AI 拆解支持无需求ID分组，不自动补需求池
+
+**问题**：0 到 1 项目中，需求池可能只录入一条宽泛需求，例如“做一个充值功能”，而原型批注里已经包含更多细粒度功能。旧规则把“原型里有、关联需求里没有”的批注只放进 `noteOnly` 报告，不拆任务，会漏掉真实开发和测试范围。若让 AI 自动创建 Requirement 又会污染需求池和版本关联需求列表，让“正式需求范围”和“原型推断内容”混在一起。
+
+**决策**：
+- AI 拆解继续优先按关联需求匹配；匹配成功的草案带正式 `requirementId`。
+- 原型中明确可拆、但没有匹配到关联需求的批注，进入 `prototypeOnly`，也可以生成 DevTask / TestCase 草案。
+- `prototypeOnly` 草案不创建 Requirement，不加入需求池，也不加入版本关联需求列表。
+- 这类草案写入开发任务/测试用例时，`requirementId` 为空，使用 `requirementName` 作为展示分组名，列表标题为 `无需求ID · {requirementName}`。
+- 不额外展示“原型发现”标记；只有既有 `aiDraft` 草案视觉状态。
+- DevTask 需要直接归属版本（`versionId`），`requirementId` 改为可选；旧数据可继续通过 `requirementId -> Requirement.versionId` 兼容推导。
+- 版本级统计、工作台和风险预警统计包含无需求ID分组任务/用例；需求级进度和需求关闭条件只统计带正式 `requirementId` 的 DevTask。
+
+**理由**：关联需求代表人为确认的正式范围，不能被 AI 静默扩写；但原型批注也是当前版本真实交付范围的重要证据，不应该因为没有 REQID 被丢掉。无需求ID分组让任务和用例完整进入执行视图，同时保持需求池干净、关联需求列表可信。