3.2 KiB
3.2 KiB
Round 3 — 工作量评估（demand-assessor 七步，禁止跳步）
输入：01_input/requirements.md + 02_acceptance/acceptance.md v2（MVP：全生命周期数据模型落地）
============================== 需求工作量评估结果
【功能单元】（第一步：仅统计数量，不评复杂度）
- 新表数据模型单元（DDL+实体+Mapper+Service）：zt_ai_code_review ×1、zt_ai_work_log ×1
- 老表字段扩展单元：zt_story_extend +AI参与率 ×1、任务侧 +AI工作量指数 ×1 总数 S = 4
【业务复杂度】（第二步：仅评单个单元，以 zt_ai_work_log 为典型）
| 项 | 分 | 依据 |
|---|---|---|
| 1 业务规则数量 | 2 | 8 类日志枚举 + 字段映射，规则少 |
| 2 状态流转复杂度 | 1 | 存储型表，无状态机 |
| 3 异常处理复杂度 | 1 | 无回滚/补偿/降级路径 |
| 4 边界场景复杂度 | 2 | 枚举校验、时间/关联边界 |
| 5 需求不确定性 | 2 | 8 类日志已列明，但各类内容结构未细化 |
| B = (2+1+1+2+2)/5 = 1.6 |
【技术复杂度】（第三步） T = 4（涉及 DB 变更：2 新表 + 2 老表加列）→ F(T) = 1 + 0.2×(4-1) = 1.6 风险说明：无迁移工具、手工 DDL，需可重入与备份；实体无注解驼峰映射须与库表严格一致；有 zt_story_expand 同模式先例可参照。
【AI效率系数】（第四步） P = 17（需求清晰度4 / 规则明确度4 / 可验证性5 / 代码结构清晰度4） N1 = 0（dynamic-datasource 依赖存在但本变更不涉及多数据源切换） N2 = 2（数据库老表变更 +1；低测试覆盖区域 +1） N3 = 1（测试覆盖率 <30% +1：src/test 仅 1 个空壳 context-load 测试） A = P - N = 14
【安全门】（第五步）
- 核心结算/分布式事务/权限鉴权/影响范围不清：均否
- 单测覆盖率 <20%：是（全项目仅 ZentaoApplicationTests 1 个空壳测试）→ ⚠️ 高风险变更标记，G(A) 强制 = 1.0
【G(A)】（第六步） A=14 映射值 0.55，被安全门覆盖 → G(A) = 1.00 是否高风险变更：是（触发项：单测覆盖率 <20%）
【最终工作量】（第七步） W = B × S × F(T) × G(A) = 1.6 × 4 × 1.6 × 1.00 = 10.2
【综合风险等级】中（安全门由测试欠账触发，非业务核心性；变更本身机械、同构、可控）
【是否建议拆分】否（4 个单元同构且量小，一次交付；拆分只增管理成本）
【AI建议参与方式】 规则档位 G(A)=1.0 →「人类主导」。偏离建议并留痕：本变更高度机械（DDL+代码生成），实际风险点是项目无测试网导致回归不可验证 → 建议「AI 主导实现 + 人类把控 DDL 评审与字段映射核对 + AC-4 单测强制补齐作为安全网」（等效 0.75 档执行），由人类在 DDL 落库前逐项确认。
提交禅道（待办）
- story-id：输入文档无需求ID → 需用户手动提供
- status / 人员信息：待用户确认
- 提交命令：
python .claude/skills/demand-assessor/submit_assessment.py --story-id <ID> --number-units 4 --b 1.6 --ft 1.6 --ga 1.0 --status <状态> --w 10.2 [--product-person ..] [--develop-person ..] [--test-person ..]