262 lines
7.2 KiB
Markdown
262 lines
7.2 KiB
Markdown
---
|
||
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 仅辅助文档/测试 |
|
||
|
||
---
|
||
|
||
## 禁止行为
|
||
- 禁止跳步（必须按第一步到第七步顺序执行）
|
||
- 禁止在第一步评估复杂度
|
||
- 禁止在第二步考虑单元数量
|
||
- 禁止在未触发安全门时擅自标记高风险
|
||
- 禁止省略任何计算中间过程
|