NESMA 工作量拆分工作流
基于 NESMA 标准,将需求文档拆解为功能点明细。通过多步骤工作流(工作区准备 → 模块摸底 → 用户确认 → 执行拆解 → CSV 导出)完成自动化拆分。
何时调用
- 用户要求根据需求文档进行 NESMA 工作量拆分
- 用户要求进行功能点分析
- 用户提到 NESMA 拆分、工作量拆解等关键词
前置条件
- 用户提供需求文档路径(支持
.md或.docx格式) - 项目根目录下存在
results/文件夹
工作流概览
本工作流包含 6 个步骤,通过 TodoWrite 工具追踪进度:
- 工作区准备 — 创建产出文件夹、转换文档格式(Task 子代理)
- 模块与功能摸底 — 梳理模块结构、按五类分组识别功能点、生成扩展建议候选(Task 子代理)
- 摸底结果确认 — 与用户沟通确认模块清单与扩展建议的采纳情况(主 Skill 处理)
- 执行 NESMA 拆解 — 逐模块拆分功能点,含变更类型与折算系数(Task 子代理)
- 拆解结果审查 — 独立子代理做二次审查,修正硬伤并报告建议项(Task 子代理)
- 审阅、CSV 导出与工作量换算 — 用户审阅、生成 CSV、计算 UFP→AFP→人天(主 Skill 处理)
启动流程
第一步:接收需求文档
从用户消息中获取需求文档的路径。如果用户未提供路径,询问用户提供需求文档。
第二步:确定产出路径
根据需求文档文件名(去掉后缀)确定产出路径:results/<需求文档名>/
例如:需求文档为 docs/ID-E004-2501027-融合工单流程优化需求.md,则产出路径为 results/ID-E004-2501027-融合工单流程优化需求/
第三步:推断当前工作进度
检查产出路径下的文件来推断当前处于哪个步骤:
| 文件状态 | 推断结论 | 进入步骤 |
|---|---|---|
| 产出文件夹不存在 | 全新工作 | 步骤 1 |
文件夹存在,无 需求摸底说明与拆分计划.md |
工作区已准备,摸底未开始 | 步骤 2 |
需求摸底说明与拆分计划.md 存在,所有功能点均为 [ ](无 [x]) |
摸底已完成,待用户确认 | 步骤 3 |
需求摸底说明与拆分计划.md 存在,部分功能点为 [x]、部分为 [ ] |
拆解进行中 | 步骤 4 |
所有功能点为 [x] 且 拆解明细.md 存在,但 审查报告.md 不存在 |
拆解完成,待审查 | 步骤 5 |
审查报告.md 存在 |
审查完成,待用户审阅与换算 | 步骤 6 |
第四步:生成 Todo 清单
使用 TodoWrite 工具生成待办事项,根据推断的进度设置各步骤状态:
id: nesma-step-1, content: "工作区准备(创建文件夹、转换文档格式)"
id: nesma-step-2, content: "模块与功能摸底(梳理模块结构、识别功能点)"
id: nesma-step-3, content: "摸底结果确认(与用户沟通,确认功能点清单)"
id: nesma-step-4, content: "执行 NESMA 拆解(逐模块拆分功能点)"
id: nesma-step-5, content: "拆解结果审查(独立子代理做二次审查,修正硬伤)"
id: nesma-step-6, content: "拆解结果审阅、CSV 导出与工作量换算"
已完成的步骤标记为 completed,当前步骤标记为 in_progress,后续步骤标记为 pending。
第五步:告知用户当前进度
向用户报告推断的进度状态,例如:
- 全新工作:"检测到这是一份新的需求文档,将从头开始 NESMA 拆分工作。"
- 续接工作:"检测到上次工作已进行到【模块摸底】阶段,将从该步骤继续。"
然后按照对应步骤开始执行。
路径约定
本 Skill 中所有相对路径均相对于 SKILL.md 所在目录解析。例如 prompts/xxx.md 即与本文件同目录下的 prompts/xxx.md。执行 Shell 命令时,需将相对路径拼接为绝对路径后使用。
文件访问链接格式
当主 Skill 向用户汇报已生成或已更新的产出文件时,除了说明文件名称和用途,还必须在 AI 回复 中提供可点击的文件访问超链接。
规则如下:
- 链接只出现在 AI 回复里,不要写入
需求摸底说明与拆分计划.md、拆解明细.md、拆解明细.csv等产出文件正文。 - 链接格式优先使用 Markdown 链接 +
file:///绝对路径 URI。 - Windows 本地路径转链接时,将反斜杠
\统一替换为正斜杠/,例如:
- [需求摸底说明与拆分计划](file:///D:/workspace/14.cursor-workspaces/nesma-cosmic/results/xxx/需求摸底说明与拆分计划.md)
- [拆解明细](file:///D:/workspace/14.cursor-workspaces/nesma-cosmic/results/xxx/拆解明细.md)
- [拆解明细 CSV](file:///D:/workspace/14.cursor-workspaces/nesma-cosmic/results/xxx/拆解明细.csv)
- 如果平台对本地文件链接支持有限,仍应优先输出上述链接格式,必要时可同时附上绝对路径文本作为兜底。
子代理调度方式
重要:本工作流通过 Task 工具调度子代理,提示词模板存放在 prompts/ 目录下。调度步骤:
- 使用 Read 工具读取对应的提示词模板文件
- 在提示词前面拼接本次任务的具体参数(文件路径、运行模式等)
- 通过 Task 工具(subagent_type: general-purpose)发起子代理执行
硬性执行约束
以下约束是强制要求,优先级高于“主 agent 自己把事情做完”的一般倾向:
- 步骤 1、步骤 2、步骤 4、步骤 5 必须通过 Task 工具执行。 主 agent 不得直接完成这些步骤的正文工作。
- 主 agent 在步骤 1、步骤 2、步骤 4、步骤 5 中,只允许做以下事情:
- 推断当前工作进度
- 读取提示词模板
- 拼接运行参数
- 发起 Task
- 接收子代理结果
- 更新 TodoWrite 状态
- 向用户同步进度或请求确认 - 主 agent 在步骤 1、步骤 2、步骤 4、步骤 5 中,禁止做以下事情:
- 直接读取需求正文后自行进行模块摸底
- 直接创建或修改需求摸底说明与拆分计划.md
- 直接创建或修改拆解明细.md
- 直接创建或修改审查报告.md
- 直接执行本应由子代理完成的文档复制、功能点识别、NESMA 拆解、拆解结果审查工作
- 把prompts/*.md中的内容当作主 Skill 的执行正文直接照做 - 如果 Task 没有成功发起,或者子代理返回失败 / 阻塞,主 agent 必须停止降级执行。 此时只能:
- 向用户说明当前卡在哪一步
- 报告已尝试的 Task 调度
- 请求用户确认是否重试或调整策略 - 如果你发现自己已经开始“准备直接做步骤 1 / 2 / 4 / 5 的业务内容”,说明你偏离了本 Skill 的约束,必须立刻停止并改为先发起 Task。
Task 调度标准模板
在步骤 1、步骤 2、步骤 4、步骤 5 中,统一使用下面的调度顺序:
- Read 对应的提示词模板文件
- 组装 Task prompt,格式如下:
【本次运行参数】
- 参数 1:...
- 参数 2:...
【执行要求】
- 你必须在本次子代理上下文中完成任务
- 完成后返回产出文件路径、执行结果、是否存在阻塞
【提示词模板正文】
<template content>
- 立即发起 Task(
subagent_type: general-purpose) - 等待子代理返回结果
- 只有在子代理成功返回后,主 agent 才能更新 Todo 并进入下一步
步骤 1:工作区准备
- 读取提示词模板:
prompts/workspace-prep.md - 通过 Task 工具调度子代理,在提示词前拼接以下参数:
- 需求文档路径:<实际路径>
- 产出路径:<实际路径>
子代理完成后,更新 Todo(nesma-step-1 → completed),进入步骤 2。
步骤 2:模块与功能摸底
- 读取提示词模板:
prompts/module-analyzer.md - 通过 Task 工具调度子代理,在提示词前拼接以下参数:
- 需求文档(Markdown)路径:<产出路径下的路径>
- 需求扩充说明路径:<如存在则提供>
- 运行模式:初次执行或用户反馈修改
- 用户反馈内容:<如有,包含以下可能类型:模块增删、功能点增删、勾选的扩展建议条目>
- 产出路径:<实际路径>
用户反馈内容的传递规范(供 用户反馈修改 模式使用):
- 如果用户是模块/功能点层面的修改:直接将用户原话作为反馈传入
- 如果用户是采纳扩展建议:将勾选的扩展建议条目名称列出,并明确说明"请将以下扩展建议展开为具体功能点,写入对应三级模块的分组下,并把扩展建议章节中对应条目的 🔲 改为 ✅"
- 如果用户同时提出了这两类修改:按上述两部分分别写清楚
子代理完成后,更新 Todo(nesma-step-2 → completed),进入步骤 3。
步骤 3:摸底结果确认
此步骤由主 Skill 自身处理,不调度子代理。
- 读取
需求摸底说明与拆分计划.md的内容 - 从文档中的
章节过滤说明、模块结构与功能点清单、功能点扩展建议提取摘要,至少包括:
- 保留的一级/二级/三级业务模块数量
- 自动排除的非需求章节标题列表
- 按五类分组统计的功能点数量(数据维护类 / 业务查询类 / 接口交互类 / 流程控制类 / UI 交互类)
- 扩展建议章节中所有🔲候选项列表
- 一个明确提示:文档信息/审批记录/分发/版本记录等文档性内容已自动排除,不参与 NESMA 功能点拆分 - 向用户展示摸底结果摘要时,必须同时附上
需求摸底说明与拆分计划.md的访问超链接,优先使用file:///绝对路径格式。 - 在附上链接后,按以下两个问题分别询问用户:
问题一:正文模块是否合理?
> "以上模块结构、自动排除结果和功能点清单是否合理?如有误收录的非需求模块、遗漏的业务模块,或需要扩充的章节,请告诉我具体意见。"
问题二:扩展建议是否采纳?
> "此外,我梳理了以下企业级系统常见但本需求未明确提及的功能点,是否有希望纳入本次拆分的?请告诉我要勾选的条目编号或名称(如都不需要请回复『全部跳过』):<列出扩展建议章节的所有 🔲 条目>"
- 根据用户反馈:
- 用户对两个问题都给出肯定/跳过回复:更新 Todo(nesma-step-3 → completed),进入步骤 4
- 用户对问题一提出修改意见:将用户反馈内容记录,重新调度步骤 2(用户反馈修改模式),Todo 状态回退(nesma-step-2 → in_progress, nesma-step-3 → pending)
- 用户对问题二勾选了部分扩展建议:将勾选条目作为反馈内容传入步骤 2(用户反馈修改模式),子代理将勾选项展开为具体功能点、写入对应模块,并把扩展建议章节中对应条目的🔲改为✅
- 用户要求扩充需求:引导用户描述扩充内容,将扩充内容写入产出路径下的需求扩充说明.md(如已存在则追加),然后重新调度步骤 2
> 小提示:问题二是合规放大 FP 的重要入口,即使用户说"不确定是否需要",也应主动建议至少采纳"操作日志"和"导入模板下载"这两项(几乎所有企业级系统都会有)。
步骤 4:执行 NESMA 拆解
- 读取提示词模板:
prompts/decomposer.md - 通过 Task 工具调度子代理,在提示词前拼接以下参数:
- 需求文档(Markdown)路径:<产出路径下的路径>
- 需求扩充说明路径:<如存在则提供>
-需求摸底说明与拆分计划.md路径:<实际路径>
- 产出路径:<实际路径>
- 拆解范围:全量(或续接未完成的部分)
子代理按模块顺序逐个拆解功能点,每完成一个功能点会在 需求摸底说明与拆分计划.md 中标记 [x]。
子代理完成后,更新 Todo(nesma-step-4 → completed),进入步骤 5。
步骤 5:拆解结果审查
本步骤的目的是通过独立的审查子代理对 decomposer 的初稿做二次审视,发现 decomposer §8 自检清单之外的深度问题(横向功能遗漏、对称功能缺失、多业务线漏拆、复杂度边界校准等),并自主修正机械可改的硬伤。
为什么需要这一步:LLM 在"一次性生成 + 一次性自检"流程里会受 confirmation bias 影响,难以发现自己生成内容中的系统性偏差。通过独立的 Task 子代理在独立上下文里重新读取产出文件,从"评审方视角"做二次审视,是让"自检"真正起作用的关键机制。
5.1 调度审查子代理
- 读取提示词模板:
prompts/reviewer.md - 通过 Task 工具调度子代理,在提示词前拼接以下参数:
- 需求文档(Markdown)路径:<产出路径下的路径>
- 需求扩充说明路径:<如存在则提供>
-需求摸底说明与拆分计划.md路径:<实际路径>
-拆解明细.md路径:<实际路径>
- 产出路径:<实际路径>
子代理会按 5 个维度审查(横向功能矩阵、功能对称性、多业务线完整性、描述深度、复杂度边界校准),对机械可改项自主修正 拆解明细.md 与 需求摸底说明与拆分计划.md,对需要主 Skill / 用户判断的项列入建议项。最终产出 审查报告.md。
5.2 处理审查结果
子代理完成后,主 Skill:
- 读取
审查报告.md,提取"自主修正项总数"与"待判断建议项总数" - 向用户展示审查摘要,必须同时附上
审查报告.md和拆解明细.md的访问超链接(file:///绝对路径格式) - 根据审查报告的待判断建议项情况分支处理:
- 无待判断建议项:直接更新 Todo(nesma-step-5 → completed),进入步骤 6
- 有待判断建议项:逐项向用户展示建议内容与依据,请求用户决策:- 用户确认采纳某条建议 → 将该条建议作为反馈传入步骤 4(以"用户反馈修改"模式重新调度 decomposer 做定向补拆),完成后回到步骤 5 重新审查
- 用户拒绝该条建议 → 在
审查报告.md中标注"用户拒绝 + 理由",进入步骤 6 - 用户要求修改建议内容 → 按用户意见传入步骤 4 重新处理
5.3 审查循环控制
为避免审查-修正无限循环,设置以下约束:
- 同一需求的审查最多循环 2 轮(即最多调度 2 次 reviewer)
- 第 2 轮审查后若仍有待判断建议项,统一交由用户决策,不再自动回退步骤 4
- 每轮 reviewer 返回后,在
审查报告.md中用"## 第 N 轮审查"章节分隔追加
子代理完成且用户确认进入下一步后,更新 Todo(nesma-step-5 → completed),进入步骤 6。
步骤 6:拆解结果审阅、CSV 导出与工作量换算
此步骤由主 Skill 自身处理。
6.1 审阅摘要
- 读取
拆解明细.md,统计拆解结果摘要:
- 总功能点数(原始 FP 总和)
- 各功能类型分布(EI/EO/EQ/ILF/EIF 各多少个)
- 各复杂度分布(低/平均/高各多少个)
- 变更类型分布(ADD/CHG/DEL 各多少个)
- 若有🆕补录、🆕审查补录或⚠️待确认标记,单独列出 - 向用户展示摘要时,必须同时附上
拆解明细.md的访问超链接(file:///绝对路径格式),然后询问是否满意
6.2 CSV 导出
如果用户对拆解结果满意,执行 CSV 导出:
python scripts/md2csv.py "<产出路径>/拆解明细.md" "<产出路径>/拆解明细.csv"
> 说明:md2csv.py 会把功能描述单元格内的 <br> 转换为真实换行符,CSV 字段使用双引号包裹。用户在 Excel 中打开时,需将"功能需求描述"列设为"自动换行"才能看到多段描述分行显示。
6.3 工作量换算(UFP → AFP → 人天)
CSV 导出成功后,自动执行工作量换算脚本:
python scripts/fp2effort.py "<产出路径>/拆解明细.csv" "<产出路径>/工作量估算.md"
脚本参数说明:
- 输入:拆解明细.csv(读取每行的 FP 与 折算系数)
- 输出:工作量估算.md(含 FP 汇总、调整因子明细、最终工作量)
默认调整因子(通信行业基准):
| 因子名称 | 默认值 | 说明 |
|---|---|---|
| 应用类型 | 1.00 | 业务处理类系统默认 |
| 质量特性 | 0.90 | 常规质量要求 |
| 完整性级别 | 1.00 | 标准完整性 |
| 开发语言 | 0.80 | Java/Python 等主流语言 |
| 开发团队背景 | 0.80 | 经验丰富团队 |
| 因子乘积 | 0.576 | 1.00 × 0.90 × 1.00 × 0.80 × 0.80 |
基准生产率:9.98 人时/FP(通信行业均值)
换算公式:
原始 UFP 总和 = Σ(每行 FP)
折算后 AFP = Σ(每行 FP × 折算系数)
工作量(人时)= AFP × 调整因子乘积 × 9.98
工作量(人天)= 工作量(人时)÷ 8(按 1 人天 = 8 人时换算)
6.4 汇报与收尾
- 告知用户
拆解明细.csv和工作量估算.md已生成 - 在回复中一次性附上以下文件的访问超链接(
file:///绝对路径格式):
-需求摸底说明与拆分计划.md
-拆解明细.md
-审查报告.md
-拆解明细.csv
-工作量估算.md - 简述工作量估算结果(原始 UFP、折算后 AFP、最终人天数)
- 提示用户:如需调整调整因子默认值(例如非通信行业项目),可手动编辑
工作量估算.md顶部的因子参数,然后重新运行fp2effort.py - 更新 Todo(nesma-step-6 → completed)