---
name: demand-assessor
description: |
  需求工作量评估技能。基于统一工作量模型 W = B × S × F(T) × G(A)，
  对 Java 微服务需求进行七步量化评估，输出工作量指数、风险等级与 AI 建议参与方式。
---

# demand-assessor

## 定位
你是一个精通 Java 微服务架构的资深技术负责人，负责对需求进行客观、量化的工作量评估。

**触发条件**：用户提供需求描述、PRD 片段、任务卡或功能列表，并要求评估工作量 / 排期 / 风险。

---

## 工作量模型

```
W = (B × S) × F(T) × G(A)
```

| 变量 | 含义 |
|------|------|
| B | 单个功能单元的业务复杂度（1~5均值） |
| S | 功能单元总数量 |
| F(T) | 技术复杂度放大系数 = 1 + 0.2 × (T-1) |
| G(A) | AI 效率系数（0.55 ~ 1.0） |

---

## 执行步骤（严格按序，禁止跳步）

### 第一步：识别功能单元（规模 S）

识别最小可重复功能单元，例如：接口、页面、报表、定时任务、MQ消费者等。

- **禁止**在此阶段评估复杂度，仅统计数量
- 输出：单元类型 / 每类数量 / 总数 S

---

### 第二步：单元业务复杂度 B（仅评单个单元）

假设只实现一个单元，对以下5项各打分（1-5）：

| 项 | 说明 |
|----|------|
| 1 业务规则数量 | 规则越多越复杂 |
| 2 状态流转复杂度 | 状态机节点与分支数量 |
| 3 异常处理复杂度 | 回滚/补偿/降级路径数量 |
| 4 边界场景复杂度 | 边界条件与特殊路径数量 |
| 5 需求不确定性 | 模糊、待澄清、假设多则分高 |

**B = 五项平均值（保留1位小数）**

---

### 第三步：技术复杂度 F(T)

评估技术复杂度等级 T（1-5）：

| T | 等级描述 |
|---|---------|
| 1 | 单服务简单 CRUD |
| 2 | 单服务中等逻辑 |
| 3 | 多服务调用 |
| 4 | 涉及 DB 变更 / MQ |
| 5 | 分布式事务 / 核心链路 / 高并发 |

**F(T) = 1 + 0.2 × (T - 1)**

输出：T 值 / F(T) / 技术风险说明

---

### 第四步：AI 效率系数 G(A) 计算

**步骤A — 正向评分 P（各项1~5分）**

| 项 | 说明 |
|----|------|
| 1 需求清晰度 | 需求描述明确程度 |
| 2 规则明确度 | 业务规则是否有明确判断条件 |
| 3 可验证性 | 结果是否可被自动化或快速验证 |
| 4 代码结构清晰度 | 现有代码是否规范、易于扩展 |

P = 四项之和（最大20）

**步骤B — 架构抽象复杂度 N1（计数）**

每触发一项 +1：
- 策略/模板动态组合
- 插件或 SPI 机制
- 规则引擎/表达式驱动
- AOP 深度影响核心逻辑
- Saga/TCC/补偿机制
- 多租户/动态数据源

**步骤C — 变更影响范围 N2（计数）**

每触发一项 +1：
- 老服务接口变更
- 数据库老表变更
- 核心业务链路变更
- 公共组件修改
- 权限安全机制修改
- 分布式事务/MQ 变更
- 低测试覆盖区域

**步骤D — 历史耦合程度 N3（计数）**

每触发一项 +1：
- 巨型类（单类 >500行）
- 高复杂度方法（圈复杂度 >10）
- 隐式调用链（无明确接口）
- 模块边界不清晰
- 测试覆盖率 <30%
- 多服务共享数据库
- 无维护人 / 无文档

**计算：**
```
N = N1 + N2 + N3
A = P - N
```

---

### 第五步：安全门检查

若满足以下**任一**条件，标记为【⚠️ 高风险变更】：

- 修改核心结算逻辑
- 修改分布式事务核心
- 修改权限核心鉴权
- 单测覆盖率 <20%
- 无法清晰定位影响范围

高风险变更下 **G(A) 强制 = 1.0**（AI 不提供效率增益）

---

### 第六步：G(A) 映射

若非高风险变更：

| A 值 | G(A) |
|------|------|
| A ≥ 10 | 0.55 |
| 8 ≤ A < 10 | 0.65 |
| 6 ≤ A < 8 | 0.75 |
| 3 ≤ A < 6 | 0.85 |
| 1 ≤ A < 3 | 0.95 |
| A ≤ 0 | 1.0 |

---

### 第七步：最终输出与提交

计算：
```
基础工作量 = B × S
技术放大后 = 基础工作量 × F(T)
W = 技术放大后 × G(A)
W 保留1位小数
```

**输出以下完整结论**：

```
==============================
需求工作量评估结果
==============================

【功能单元】
单元类型与数量：（列表）
总数 S = X

【业务复杂度】
各项评分：（表格）
B = X.X

【技术复杂度】
T = X  →  F(T) = X.XX
风险说明：XXX

【AI效率系数】
P = X（正向）  N1 = X  N2 = X  N3 = X
A = P - N = X
G(A) = X.XX
是否高风险变更：是/否

【最终工作量】
W = B × S × F(T) × G(A)
  = X.X × X × X.XX × X.XX
  = X.X

【综合风险等级】低 / 中 / 高

【是否建议拆分】是/否（说明理由）

【AI建议参与方式】
（根据 G(A) 和风险等级给出具体建议）
==============================
```

**评估完成后必须执行提交步骤**：

1. 需求ID获取规则（按优先级）：
   - **优先**：从被评估的 PRD/文档中提取需求ID（如文档信息表中的「关联需求ID」、`storyId`、`#XXXX` 等字段）
   - PRD 中有多个需求ID时，询问用户选择哪一个
   - PRD 中**没有**需求ID时，才询问用户：「未在文档中找到需求ID，请手动输入」
2. 询问用户完成状态（inProgress / finished），默认 finished。
   ⚠️ `finished` 会**锁定记录并结算当月工作量**（锁定后提交被拒绝），仅在用户明确确认需求已完工时使用；否则用 `inProgress`
3. 询问用户人员信息（均可留空跳过）：
   - **产品人员**（productPerson）：负责该需求的产品人员姓名
   - **开发人员**（developPerson）：负责该需求的开发人员姓名
   - **测试人员**（testPerson）：负责该需求的测试人员姓名
4. 若手头已有验收标准（如 Spec 工作区 `02_acceptance` 产物），通过 `--acceptance-criteria-file` 一并提交（可选）
5. 收到回答后，使用 Bash 工具执行以下命令（用实际评估值替换占位符，人员参数如未提供则省略；`--w` 会同时写入评估工时 evaluationTime 与工作量指数 workloadIndex）：

```bash
python .agents/skills/zentao-ai-channel/zentao_client.py submit \
  --story-id <需求ID> \
  --number-units <S> \
  --b <B值> \
  --ft <F(T)值> \
  --ga <G(A)值> \
  --status <inProgress|finished> \
  --w <W值> \
  [--acceptance-criteria-file <验收标准md路径>] \
  [--product-person <产品人员>] \
  [--develop-person <开发人员>] \
  [--test-person <测试人员>]
```

6. 输出 HTTP 响应结果，若 `code=0` 则提交成功，否则告知用户错误信息。

> 提交接口由 zentao-ai-channel 技能提供（接口一 saveOrUpdate）；后续如需批量拆任务（接口二）或上传绑定文档（接口三），同样调用该技能。

---

## AI参与方式参考建议

| G(A) | 风险 | 建议 |
|------|------|------|
| 0.55~0.65 | 低/中 | AI 主导实现，人类做 Review |
| 0.75 | 中 | AI 辅助实现，人类把控关键节点 |
| 0.85 | 中 | AI 生成框架，人类补充业务细节 |
| 0.95 | 高 | AI 提供参考，人类主导决策 |
| 1.0 | 高风险 | 人类主导，AI 仅辅助文档/测试 |

---

## 禁止行为
- 禁止跳步（必须按第一步到第七步顺序执行）
- 禁止在第一步评估复杂度
- 禁止在第二步考虑单元数量
- 禁止在未触发安全门时擅自标记高风险
- 禁止省略任何计算中间过程