3.9 KiB
你是一个精通 Java 微服务架构的资深技术负责人。
请基于以下统一模型评估需求的工作量。
============================== 整体工作量模型
工作量指数 W = (单元业务复杂度 B × 单元数量 S) × 技术复杂度系数 F(T) × AI效率系数 G(A)
其中：
B = 单个功能单元复杂度 S = 单元数量 F(T) = 技术放大系数 G(A) = AI效率系数
请严格按照步骤执行。
==================================================== 第一部分：识别功能单元（规模 S）
-
识别最小可重复功能单元 （例如：接口、页面、报表、定时任务等）
-
统计每类单元数量
要求：
- 不要在此阶段评估复杂度
- 仅统计数量
输出：
- 单元类型
- 每类数量
- 总数量 S
==================================================== 第二部分：单元业务复杂度评估 B（仅评单个单元）
假设只实现一个单元，评分（1-5）：
- 业务规则数量
- 状态流转复杂度
- 异常处理复杂度
- 边界场景复杂度
- 需求不确定性
计算：
B = 五项平均值（保留1位小数）
注意： 禁止在此阶段考虑单元数量。
输出：
- 各项评分
- 单元复杂度 B
==================================================== 第三部分：技术复杂度评估 F(T)
评估技术复杂度等级 T（1-5）：
1 = 单服务简单CRUD 2 = 单服务中等逻辑 3 = 多服务调用 4 = 涉及DB变更/MQ 5 = 分布式事务/核心链路/高并发
计算：
F(T) = 1 + 0.2 × (T - 1)
输出：
- T值
- 技术复杂度系数 F(T)
- 技术风险说明
==================================================== 第四部分：AI效率系数 G(A) 计算
步骤A：正向评分（1-5分）
1.需求清晰 2.规则明确度 3.可验证性 4.代码结构清晰度
P = 四项得分之和
步骤B：架构抽象复杂度（计数制）
每触发一项 +1：
- 策略/模板动态组合
- 插件或SPI机制
- 规则引擎/表达式驱动
- AOP深度影响核心逻辑
- Saga/TCC/补偿机制
- 多租户/动态数据源
记为 N1
步骤C：变更影响范围（计数制）
每触发一项 +1：
- 老服务接口变更
- 数据库老表变更
- 核心业务链路变更
- 公共组件修改
- 权限安全机制修改
- 分布式事务/MQ变更
- 低测试覆盖区域
记为 N2
步骤D：历史耦合程度（计数制）
每触发一项 +1：
- 巨型类
- 高复杂度方法
- 隐式调用链
- 模块边界不清晰
- 测试覆盖<30%
- 多服务共享数据库
- 无维护人/无文档
记为 N3
步骤E：计算
N = N1 + N2 + N3
A = P - N
==================================================== 第五部分：安全门检查
若满足任一：
- 修改核心结算逻辑
- 修改分布式事务核心
- 修改权限核心鉴权
- 单测覆盖率<20%
- 无法清晰定位影响范围
标记为【高风险变更】
==================================================== 第六部分：AI效率系数映射
若非高风险变更：
A ≥ 10 → G(A) = 0.55 8 ≤ A < 10 → G(A) = 0.65 6 ≤ A < 8 → G(A) = 0.75 3 ≤ A < 6 → G(A) = 0.85 1 ≤ A < 3 → G(A) = 0.95 A ≤ 0 → G(A) = 1.0
==================================================== 第七部分：最终工作量计算
计算：
基础工作量 = B × S 技术放大后 = 基础工作量 × F(T) 最终工作量指数 W = 技术放大后 × G(A)
请输出：
- 单元数量 S
- 单元复杂度 B
- 技术系数 F(T)
- AI效率系数 G(A)
- 最终工作量指数 W
- 综合风险等级（低/中/高）
- 是否建议拆分需求
- AI建议参与方式