OA/zentao-flow
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
zentao-flow/.agents/skills/demand-assessor/SKILL.md
T

7.2 KiB
Raw Permalink Blame History

name, description
name description
demand-assessor 需求工作量评估技能。基于统一工作量模型 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）：
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 <测试人员>]
  1. 输出 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 仅辅助文档/测试

禁止行为

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