# AI 拆解无需求ID分组设计

## 背景

0 到 1 项目中，需求池可能只录入一条宽泛需求，例如“做一个充值功能”。产品原型里通常会有更多细粒度批注，例如金额输入、支付渠道、支付结果、充值记录、异常提示等。旧规则只拆关联需求命中的内容，原型中未命中关联需求的批注只进入 `noteOnly` 报告，容易漏掉真实要开发和测试的功能点。

## 决策

AI 拆解继续以当前版本关联需求为正式范围锚点，但原型中明确可拆、且没有匹配到关联需求的功能批注，也可以生成 DevTask / TestCase 草案。

这类草案不创建 Requirement，不进入需求池，也不加入版本关联需求列表。它们只在开发任务和测试用例中形成一个展示分组：

```text
无需求ID · 充值记录展示
```

分组只是一段展示用需求名称，不是正式需求实体。列表不额外显示“原型发现”等标记；草案本身仍按既有 AI 草案规则显示 `aiDraft` 视觉状态。

## 数据契约

DevTask 需要从“通过 `requirementId` 反查版本”调整为“直接归属版本”：

- `versionId`：必填，表示执行归属。
- `requirementId`：可选。有关联需求时填写；无正式需求 ID 时为空。
- `requirementName`：可选。无正式需求 ID 时作为分组展示名。
- `references[]`：仍必填，原型独有项至少包含 `prototype_note` 引用。

TestCase 已经主归属版本，保持同样语义：

- `versionId`：必填。
- `requirementId`：可选。
- `requirementName`：可选，用于无需求ID分组。
- `references[]`：仍必填。

旧数据兼容：没有 `versionId` 的 DevTask 可继续通过 `requirementId -> Requirement.versionId` 推导版本归属；新写入必须带 `versionId`。

## 对账报告

拆解报告从“匹配 / 单边 / 含糊”细化为：

- `matched`：关联需求和原型批注匹配，正常生成带 `requirementId` 的任务/用例。
- `reqOnly`：关联需求存在，但原型没有看到对应批注，提醒用户确认原型是否遗漏。
- `prototypeOnly`：原型有明确功能批注，但没有匹配到关联需求；生成无需求ID分组草案。
- `ambiguous`：原型批注含糊，无法形成稳定任务/用例，不自动写入。

`prototypeOnly` 不再只是提醒，它是可被用户采纳的草案来源。

## 派生规则

- 版本进度、阶段耗时、工作台、小宝预警等版本级聚合必须包含无需求ID分组下的 DevTask / TestCase。
- 需求进度、需求实际状态和需求关闭条件只统计带正式 `requirementId` 的 DevTask；无需求ID分组不影响任何 Requirement。
- 删除版本时，通过 `versionId` 清理对应 DevTask / TestCase / Bug；旧数据仍按 requirement 反查兼容。
- AI 重新拆解去重时，签名需要包含 `requirementId` 或 `requirementName`、任务类型、标题规范化和引用来源。

## UI 行为

开发任务和测试用例列表按需求分组时：

1. 正式关联需求分组按版本关联需求顺序展示。
2. 无需求ID分组排在正式需求之后，标题格式为 `无需求ID · {requirementName}`。
3. 不显示“原型发现”标记。
4. 详情抽屉中可以展示引用来源，方便追溯到原型批注。

## 不做

- 不自动创建 Requirement。
- 不把无需求ID分组加入版本关联需求列表。
- 不把无需求ID分组计入需求池统计。
- 不用隐藏 Requirement 作为技术兜底。