3.4 KiB
3.4 KiB
AI 拆解无需求ID分组设计
背景
0 到 1 项目中，需求池可能只录入一条宽泛需求，例如“做一个充值功能”。产品原型里通常会有更多细粒度批注，例如金额输入、支付渠道、支付结果、充值记录、异常提示等。旧规则只拆关联需求命中的内容，原型中未命中关联需求的批注只进入 noteOnly 报告，容易漏掉真实要开发和测试的功能点。
决策
AI 拆解继续以当前版本关联需求为正式范围锚点，但原型中明确可拆、且没有匹配到关联需求的功能批注，也可以生成 DevTask / TestCase 草案。
这类草案不创建 Requirement，不进入需求池，也不加入版本关联需求列表。它们只在开发任务和测试用例中形成一个展示分组：
无需求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 行为
开发任务和测试用例列表按需求分组时：
- 正式关联需求分组按版本关联需求顺序展示。
- 无需求ID分组排在正式需求之后，标题格式为
无需求ID · {requirementName}。 - 不显示“原型发现”标记。
- 详情抽屉中可以展示引用来源，方便追溯到原型批注。
不做
- 不自动创建 Requirement。
- 不把无需求ID分组加入版本关联需求列表。
- 不把无需求ID分组计入需求池统计。
- 不用隐藏 Requirement 作为技术兜底。