feat(ai): 优化拆解目标和负责人推荐
This commit is contained in:
Script Generator
@@ -34,7 +34,13 @@
|
||||
- `estimateHours` 留给负责人/执行人确认后填写
|
||||
- AI 不输出预计开始/截止时间，排期由负责人后续维护
|
||||
|
||||
4. **历史版本不强制存储**
|
||||
5. **AI 可推荐负责人，但不自动分配**
|
||||
- AI 只能从当前版本成员 `members[].name` 中输出可选的 `recommendedAssigneeName`
|
||||
- 推荐只作为采纳弹窗里的辅助信息，默认不写入 `assigneeId`
|
||||
- 用户勾选“采纳推荐负责人”后，前端再次校验推荐姓名属于当前版本成员，才写入 DevTask/TestCase
|
||||
- 没有明确匹配成员时不输出推荐字段
|
||||
|
||||
6. **历史版本不强制存储**
|
||||
- 系统不要求历史原型 URL 作为基准
|
||||
- 拆偏问题靠"对账报告"暴露给用户，由人工补救
|
||||
- 这条决定见 decisions.md #17
|
||||
@@ -58,16 +64,30 @@
|
||||
|
||||
**输出**：
|
||||
- 对账报告（结构化文本，含"完美对应/单边/含糊"三段）
|
||||
- DevTask 草案数组（每条带 `aiDraft: true` + `references[]` + `aiEstimateHours`）
|
||||
- TestCase 草案数组（每条带 `aiDraft: true` + `references[]` + `aiEstimateHours`）
|
||||
- DevTask 草案数组（每条带 `aiDraft: true` + `references[]` + `aiEstimateHours`，可选 `recommendedAssigneeName` / `recommendedAssigneeReason`）
|
||||
- TestCase 草案数组（每条带 `aiDraft: true` + `references[]` + `aiEstimateHours`，可选 `recommendedAssigneeName` / `recommendedAssigneeReason`）
|
||||
- `target = dev_tasks` 时 `testCaseDrafts` 必须为空数组；`target = test_cases` 时 `devTaskDrafts` 必须为空数组
|
||||
|
||||
**原型与需求匹配规则**：
|
||||
- 优先按需求编号匹配：原型批注或文本出现 `requirement.id` / `requirement.code` 时，必须优先判定为该需求命中。
|
||||
- 编号未出现时，再按需求标题和需求概述（`title` / `description`）做语义匹配。
|
||||
- 有 QY 编号时，`prototype_note` 引用只能使用真实存在的 QY 编号。
|
||||
- 没有 QY 编号但原型文本已命中需求编号或需求概述时，不应丢弃；可只引用 `requirement`，并在 `matched.noteIds` 返回空数组。
|
||||
- 只有既匹配不到需求编号，也匹配不到需求概述语义的原型批注，才进入 `noteOnly` 或 `ambiguous`。
|
||||
|
||||
**测试用例拆解粒度**：
|
||||
- TestCase 要按功能点、UI 交互、表单校验、接口、数据一致性、权限、异常、边界、状态流转、兼容性和回归点拆细。
|
||||
- 不允许用一条“验证 XX 完整流程”覆盖多个交互、多个接口或多个规则。
|
||||
- 一条 QY 若同时涉及 UI、接口、数据、异常和状态变化，通常应拆出 3-8 条 TestCase。
|
||||
- 测试用例 `categoryCode` 可使用：`test_functional`、`test_ui_interaction`、`test_form_validation`、`test_api`、`test_data_consistency`、`test_permission`、`test_exception`、`test_boundary`、`test_state_flow`、`test_compatibility`、`test_regression`。
|
||||
|
||||
**写入**：
|
||||
- 用户确认后，调用 `useDevTaskStore.createTask` 和 `useTestCaseStore.createTestCase`
|
||||
- 打开采纳弹窗前，前端先过滤当前版本已采纳过的重复 DevTask/TestCase 草案
|
||||
- 写入字段中 `aiDraft: true`、`aiDraftAt: ISO时间戳`
|
||||
- 写入 `aiEstimateHours`，不写入执行人预估 `estimateHours`
|
||||
- DevTask 草案不写预计开始/截止时间，负责人后续排期时再填写
|
||||
- 只有用户在采纳弹窗勾选“采纳推荐负责人”时，才把已校验的 `recommendedAssigneeName` 写入 `assigneeId`
|
||||
|
||||
**权限**：
|
||||
- 读：Version, Requirement, VersionPlan, Member
|
||||
@@ -82,7 +102,7 @@
|
||||
|
||||
**MVP 阶段限制**（V3.1）：
|
||||
- 只生成 DevTask 和 TestCase 草案
|
||||
- 不自动分配 assignee（assignee 留给用户从草案编辑时手填）
|
||||
- 不自动分配 assignee；AI 只提供可选推荐，用户确认采纳后才写入
|
||||
- 不做"上一版基准 diff"
|
||||
|
||||
### Agent 2：Risk Watch Agent（风险预警）— 待规划
|
||||
@@ -208,8 +228,8 @@ interface DecomposeOutput {
|
||||
noteOnly: string[]; // 原型注释 ID 列表
|
||||
ambiguous: Array<{ noteId: string; reason: string }>;
|
||||
};
|
||||
devTaskDrafts: Array<{ title: string; description?: string; categoryCode: string; priority: Priority; aiEstimateHours: number; references: Reference[] }>;
|
||||
testCaseDrafts: Array<{ title: string; description: string; categoryCode: string; priority: Priority; aiEstimateHours: number; references: Reference[] }>;
|
||||
devTaskDrafts: Array<{ title: string; description?: string; categoryCode: string; priority: Priority; aiEstimateHours: number; recommendedAssigneeName?: string; recommendedAssigneeReason?: string; references: Reference[] }>;
|
||||
testCaseDrafts: Array<{ title: string; description: string; categoryCode: string; priority: Priority; aiEstimateHours: number; recommendedAssigneeName?: string; recommendedAssigneeReason?: string; references: Reference[] }>;
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@@ -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 不输出推荐字段，任务保持未分配，供成员后续领取或手动分配。
|
||||
|
||||
**理由**：负责人推荐能减少项目经理初次分配成本，但分配本身是团队执行承诺，必须由人确认。把推荐和写入分开，可以复用版本成员上下文，又避免模型幻觉姓名或越权自动派单。
|
||||
|
||||
Reference in New Issue
Block a user