feat(ai): 优化拆解目标和负责人推荐

docs/decisions.md

@@ -367,3 +367,40 @@
 - 加班记录不受工作日历过滤，但不按自然小时连续打卡计算；使用项目管理口径：每个自然日默认 9:00-12:00、13:00-18:00 计 8h，中间完整日期按 8h，首尾日期按填写的开始/结束时间裁剪，结束晚于 18:00 的当天额外计入超出时长。
 
 **理由**：正常任务耗时回答“工作时间里实际投入了多少”，加班记录回答“额外投入覆盖了多少项目工作量”。项目管理不做打卡，跨天记录不能把夜间空档算成工时；但节假日和周末仍允许记录，不受中国工作日历过滤。
+
+## 31. AI 原型拆解优先按需求编号匹配，再按需求概述兜底
+
+**问题**：原型文件里有些批注并不总是稳定写成 QY 编号，或者 QY 片段和需求之间没有显式绑定。仅按 QY 批注匹配会漏掉“原型里实际已有注释”的需求。
+
+**决策**：
+- 原型上下文提取不只围绕 QY 编号，也围绕当前版本关联需求的 `id`、`code`、`title`、`description` 命中片段。
+- Agent 对账优先按需求编号匹配；原型文本出现 `requirement.id` 或 `requirement.code` 时必须优先归到该需求。
+- 没有需求编号时，再按需求标题和需求概述做语义匹配。
+- 没有 QY 编号但命中了需求编号或需求概述时，允许只引用 `requirement`，`matched.noteIds` 返回空数组。
+- 只有编号和概述都匹配不到的原型批注，才进入 `noteOnly` 或 `ambiguous`。
+
+**理由**：需求编号是最稳定的对账锚点，需求概述是编号缺失时的业务语义兜底。把匹配证据先送进上下文，再用 prompt 明确优先级，比只依赖模型从截断文本里自由联想更稳定。
+
+## 32. 测试用例类型细分，AI 拆解按测试点而不是大流程输出
+
+**问题**：测试用例原先只有功能/API/异常/兼容性四类，AI 容易把多个交互、接口、数据状态和边界场景合并成一条“大用例”，导致测试范围不够细。
+
+**决策**：
+- 在测试分组增加细分类：UI 交互、表单校验、数据一致性、权限、边界值、状态流转、回归测试。
+- AI tool schema、shared 类型和前端任务类型字典同步允许这些 `categoryCode`。
+- Prompt 明确要求 TestCase 按功能点、交互、接口、数据、权限、异常、边界、状态流转和回归点拆细。
+- 一条 QY 如果同时涉及 UI、接口、数据、异常和状态变化，通常应拆出 3-8 条 TestCase，不允许用单条“完整流程验证”兜住。
+
+**理由**：测试用例的分类粒度会反过来影响 AI 输出粒度。更细的稳定语义码能让模型把测试范围拆开，也让后续统计、筛选和负责人评估更准确。
+
+## 33. AI 可推荐负责人，但必须由用户确认后才写入
+
+**问题**：版本成员已经维护完成后，AI 拆解任务时完全不看成员会浪费上下文；但如果 AI 直接分配负责人，容易把模型建议误认为团队承诺，也可能编造成员姓名造成脏数据。
+
+**决策**：
+- AI 草案允许输出 `recommendedAssigneeName` 和 `recommendedAssigneeReason`，但姓名只能来自当前版本成员 `members[].name`。
+- 前端用规则 helper 再校验推荐姓名是否属于当前版本成员，非成员姓名直接丢弃。
+- 采纳弹窗默认不写入负责人；用户勾选“采纳推荐负责人”后，才把已校验推荐写入 DevTask/TestCase 的 `assigneeId`。
+- 没有明确角色匹配或成员匹配时，AI 不输出推荐字段，任务保持未分配，供成员后续领取或手动分配。
+
+**理由**：负责人推荐能减少项目经理初次分配成本，但分配本身是团队执行承诺，必须由人确认。把推荐和写入分开，可以复用版本成员上下文，又避免模型幻觉姓名或越权自动派单。