NESMA 工作量拆分工作流

基于 NESMA 标准，将需求文档拆解为功能点明细。通过多步骤工作流（工作区准备 → 模块摸底 → 用户确认 → 执行拆解 → CSV 导出）完成自动化拆分。

何时调用

• 用户要求根据需求文档进行 NESMA 工作量拆分
• 用户要求进行功能点分析
• 用户提到 NESMA 拆分、工作量拆解等关键词

前置条件

• 用户提供需求文档路径（支持 .md 或 .docx 格式）
• 项目根目录下存在 results/ 文件夹

工作流概览

本工作流包含 6 个步骤，通过 TodoWrite 工具追踪进度：

1. 工作区准备 — 创建产出文件夹、转换文档格式（Task 子代理）
2. 模块与功能摸底 — 梳理模块结构、按五类分组识别功能点、生成扩展建议候选（Task 子代理）
3. 摸底结果确认 — 与用户沟通确认模块清单与扩展建议的采纳情况（主 Skill 处理）
4. 执行 NESMA 拆解 — 逐模块拆分功能点，含变更类型与折算系数（Task 子代理）
5. 拆解结果审查 — 独立子代理做二次审查，修正硬伤并报告建议项（Task 子代理）
6. 审阅、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 回复 中提供可点击的文件访问超链接。

规则如下：

1. 链接只出现在 AI 回复里，不要写入 需求摸底说明与拆分计划.md、拆解明细.md、拆解明细.csv 等产出文件正文。
2. 链接格式优先使用 Markdown 链接 + file:/// 绝对路径 URI。
3. 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)

1. 如果平台对本地文件链接支持有限，仍应优先输出上述链接格式，必要时可同时附上绝对路径文本作为兜底。

子代理调度方式

重要：本工作流通过 Task 工具调度子代理，提示词模板存放在 prompts/ 目录下。调度步骤：

1. 使用 Read 工具读取对应的提示词模板文件
2. 在提示词前面拼接本次任务的具体参数（文件路径、运行模式等）
3. 通过 Task 工具（subagent_type: general-purpose）发起子代理执行

硬性执行约束

以下约束是强制要求，优先级高于“主 agent 自己把事情做完”的一般倾向：

1. 步骤 1、步骤 2、步骤 4、步骤 5 必须通过 Task 工具执行。 主 agent 不得直接完成这些步骤的正文工作。
2. 主 agent 在步骤 1、步骤 2、步骤 4、步骤 5 中，只允许做以下事情：
• 推断当前工作进度
• 读取提示词模板
• 拼接运行参数
• 发起 Task
• 接收子代理结果
• 更新 TodoWrite 状态
• 向用户同步进度或请求确认
3. 主 agent 在步骤 1、步骤 2、步骤 4、步骤 5 中，禁止做以下事情：
• 直接读取需求正文后自行进行模块摸底
• 直接创建或修改 需求摸底说明与拆分计划.md
• 直接创建或修改 拆解明细.md
• 直接创建或修改 审查报告.md
• 直接执行本应由子代理完成的文档复制、功能点识别、NESMA 拆解、拆解结果审查工作
• 把 prompts/*.md 中的内容当作主 Skill 的执行正文直接照做
4. 如果 Task 没有成功发起，或者子代理返回失败 / 阻塞，主 agent 必须停止降级执行。 此时只能：
• 向用户说明当前卡在哪一步
• 报告已尝试的 Task 调度
• 请求用户确认是否重试或调整策略
5. 如果你发现自己已经开始“准备直接做步骤 1 / 2 / 4 / 5 的业务内容”，说明你偏离了本 Skill 的约束，必须立刻停止并改为先发起 Task。

Task 调度标准模板

在步骤 1、步骤 2、步骤 4、步骤 5 中，统一使用下面的调度顺序：

1. Read 对应的提示词模板文件
2. 组装 Task prompt，格式如下：

【本次运行参数】
- 参数 1：...
- 参数 2：...

【执行要求】
- 你必须在本次子代理上下文中完成任务
- 完成后返回产出文件路径、执行结果、是否存在阻塞

【提示词模板正文】
<template content>

1. 立即发起 Task（subagent_type: general-purpose）
2. 等待子代理返回结果
3. 只有在子代理成功返回后，主 agent 才能更新 Todo 并进入下一步

步骤 1：工作区准备

1. 读取提示词模板：prompts/workspace-prep.md
2. 通过 Task 工具调度子代理，在提示词前拼接以下参数：
• 需求文档路径：<实际路径>
• 产出路径：<实际路径>

子代理完成后，更新 Todo（nesma-step-1 → completed），进入步骤 2。

步骤 2：模块与功能摸底

1. 读取提示词模板：prompts/module-analyzer.md
2. 通过 Task 工具调度子代理，在提示词前拼接以下参数：
• 需求文档（Markdown）路径：<产出路径下的路径>
• 需求扩充说明路径：<如存在则提供>
• 运行模式：初次执行 或 用户反馈修改
• 用户反馈内容：<如有，包含以下可能类型：模块增删、功能点增删、勾选的扩展建议条目>
• 产出路径：<实际路径>

用户反馈内容的传递规范（供 用户反馈修改 模式使用）：

• 如果用户是模块/功能点层面的修改：直接将用户原话作为反馈传入
• 如果用户是采纳扩展建议：将勾选的扩展建议条目名称列出，并明确说明"请将以下扩展建议展开为具体功能点，写入对应三级模块的分组下，并把扩展建议章节中对应条目的 🔲 改为 ✅"
• 如果用户同时提出了这两类修改：按上述两部分分别写清楚

子代理完成后，更新 Todo（nesma-step-2 → completed），进入步骤 3。

步骤 3：摸底结果确认

此步骤由主 Skill 自身处理，不调度子代理。

1. 读取 需求摸底说明与拆分计划.md 的内容
2. 从文档中的 章节过滤说明、模块结构与功能点清单、功能点扩展建议 提取摘要，至少包括：
• 保留的一级/二级/三级业务模块数量
• 自动排除的非需求章节标题列表
• 按五类分组统计的功能点数量（数据维护类 / 业务查询类 / 接口交互类 / 流程控制类 / UI 交互类）
• 扩展建议章节中所有 🔲 候选项列表
• 一个明确提示：文档信息/审批记录/分发/版本记录等文档性内容已自动排除，不参与 NESMA 功能点拆分
3. 向用户展示摸底结果摘要时，必须同时附上 需求摸底说明与拆分计划.md 的访问超链接，优先使用 file:/// 绝对路径格式。
4. 在附上链接后，按以下两个问题分别询问用户：

问题一：正文模块是否合理？

> "以上模块结构、自动排除结果和功能点清单是否合理？如有误收录的非需求模块、遗漏的业务模块，或需要扩充的章节，请告诉我具体意见。"

问题二：扩展建议是否采纳？

> "此外，我梳理了以下企业级系统常见但本需求未明确提及的功能点，是否有希望纳入本次拆分的？请告诉我要勾选的条目编号或名称（如都不需要请回复『全部跳过』）：<列出扩展建议章节的所有 🔲 条目>"

1. 根据用户反馈：
• 用户对两个问题都给出肯定/跳过回复：更新 Todo（nesma-step-3 → completed），进入步骤 4
• 用户对问题一提出修改意见：将用户反馈内容记录，重新调度步骤 2（用户反馈修改 模式），Todo 状态回退（nesma-step-2 → in_progress, nesma-step-3 → pending）
• 用户对问题二勾选了部分扩展建议：将勾选条目作为反馈内容传入步骤 2（用户反馈修改 模式），子代理将勾选项展开为具体功能点、写入对应模块，并把扩展建议章节中对应条目的 🔲 改为 ✅
• 用户要求扩充需求：引导用户描述扩充内容，将扩充内容写入产出路径下的 需求扩充说明.md（如已存在则追加），然后重新调度步骤 2

> 小提示：问题二是合规放大 FP 的重要入口，即使用户说"不确定是否需要"，也应主动建议至少采纳"操作日志"和"导入模板下载"这两项（几乎所有企业级系统都会有）。

步骤 4：执行 NESMA 拆解

1. 读取提示词模板：prompts/decomposer.md
2. 通过 Task 工具调度子代理，在提示词前拼接以下参数：
• 需求文档（Markdown）路径：<产出路径下的路径>
• 需求扩充说明路径：<如存在则提供>
• 需求摸底说明与拆分计划.md 路径：<实际路径>
• 产出路径：<实际路径>
• 拆解范围：全量（或续接未完成的部分）

子代理按模块顺序逐个拆解功能点，每完成一个功能点会在 需求摸底说明与拆分计划.md 中标记 [x]。

子代理完成后，更新 Todo（nesma-step-4 → completed），进入步骤 5。

步骤 5：拆解结果审查

本步骤的目的是通过独立的审查子代理对 decomposer 的初稿做二次审视，发现 decomposer §8 自检清单之外的深度问题（横向功能遗漏、对称功能缺失、多业务线漏拆、复杂度边界校准等），并自主修正机械可改的硬伤。

为什么需要这一步：LLM 在"一次性生成 + 一次性自检"流程里会受 confirmation bias 影响，难以发现自己生成内容中的系统性偏差。通过独立的 Task 子代理在独立上下文里重新读取产出文件，从"评审方视角"做二次审视，是让"自检"真正起作用的关键机制。

5.1 调度审查子代理

1. 读取提示词模板：prompts/reviewer.md
2. 通过 Task 工具调度子代理，在提示词前拼接以下参数：
• 需求文档（Markdown）路径：<产出路径下的路径>
• 需求扩充说明路径：<如存在则提供>
• 需求摸底说明与拆分计划.md 路径：<实际路径>
• 拆解明细.md 路径：<实际路径>
• 产出路径：<实际路径>

子代理会按 5 个维度审查（横向功能矩阵、功能对称性、多业务线完整性、描述深度、复杂度边界校准），对机械可改项自主修正 拆解明细.md 与 需求摸底说明与拆分计划.md，对需要主 Skill / 用户判断的项列入建议项。最终产出 审查报告.md。

5.2 处理审查结果

子代理完成后，主 Skill：

1. 读取 审查报告.md，提取"自主修正项总数"与"待判断建议项总数"
2. 向用户展示审查摘要，必须同时附上 审查报告.md 和 拆解明细.md 的访问超链接（file:/// 绝对路径格式）
3. 根据审查报告的待判断建议项情况分支处理：
• 无待判断建议项：直接更新 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 审阅摘要

1. 读取 拆解明细.md，统计拆解结果摘要：
• 总功能点数（原始 FP 总和）
• 各功能类型分布（EI/EO/EQ/ILF/EIF 各多少个）
• 各复杂度分布（低/平均/高各多少个）
• 变更类型分布（ADD/CHG/DEL 各多少个）
• 若有 🆕补录、🆕审查补录 或 ⚠️待确认 标记，单独列出
2. 向用户展示摘要时，必须同时附上 拆解明细.md 的访问超链接（file:/// 绝对路径格式），然后询问是否满意

6.2 CSV 导出

如果用户对拆解结果满意，执行 CSV 导出：

python scripts/md2csv.py "<产出路径>/拆解明细.md" "<产出路径>/拆解明细.csv"

> 说明：md2csv.py 会把功能描述单元格内的
转换为真实换行符，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 汇报与收尾

1. 告知用户 拆解明细.csv 和 工作量估算.md 已生成
2. 在回复中一次性附上以下文件的访问超链接（file:/// 绝对路径格式）：
• 需求摸底说明与拆分计划.md
• 拆解明细.md
• 审查报告.md
• 拆解明细.csv
• 工作量估算.md
3. 简述工作量估算结果（原始 UFP、折算后 AFP、最终人天数）
4. 提示用户：如需调整调整因子默认值（例如非通信行业项目），可手动编辑 工作量估算.md 顶部的因子参数，然后重新运行 fp2effort.py
5. 更新 Todo（nesma-step-6 → completed）