把零散的业务诉求（一句话需求、会议纪要、聊天记录、工单描述、口头转述）转换成符合 IT 需求管理规范的《需求规格说明书（L2）》。
本 Skill 固化的是文档格式与写作约束，不是某个具体项目。核心目标：
-
格式对齐------输出结构与公司既有需求单完全一致，可直接提交评审。
-
口径补全------强制暴露统计窗口、折算规则、异常处理、责任人等易漏项。
-
可验证------验收标准必须可观测、可判定，杜绝"运行正常"式空话。
与相邻 Skill 的边界：
| Skill | 职责 | 何时用 |
|---|---|---|
| 本 Skill | 业务需求 → L2 需求规格说明书 | 需求还没写清楚时 |
mes-design-doc-generator |
DDL / 存储过程 → 设计文档（ER图、概要/详细设计、用例图） | 需求已定，进入技术设计 |
mes-sp-analyzer |
存储过程 → 业务逻辑解读 | 需要理解既有代码逻辑 |
mes-test-generator |
需求 / 存储过程 → 测试用例 | 需求已定，进入测试设计 |
触发条件
出现以下任一意图即加载本 Skill：
-
需求规格说明书 / 需求文档 / L2 需求 / 需求单 / 功能需求文档
-
写需求 / 提需求 / 报需求 / 整理成需求 / 把这段写成需求
-
需求评审 / 需求补充 / 需求澄清 / 需求改写
-
MES 需求 / PRD / requirement spec / requirement document
工作流程
Step 0 --- 需求定级（决定用哪套模板）
| 等级 | 判定标准（满足任意 2 条即归该级） | 交付物 |
|---|---|---|
| L1（简单） | 单一部门；单点配置或参数调整；≤5 人日；不新增逻辑分支 | 简版需求单（本模板第 1--3、6、7 章） |
| L2（中等） | 跨 2 个及以上部门；含配置维护 + 业务规则 + 推送/报表；5--20 人日；需口径标准化 | 完整 L2 规格说明书（本模板全 7 章） |
| L3（大型） | 跨系统/跨工厂；流程重构；>20 人日；需立项评审 | L2 规格说明书 + 概要设计（转 mes-design-doc-generator） |
默认按 L2 生成；明显更小或更大时在文档标题中标注等级并告知用户。
Step 1 --- 信息补全（先问全，再动笔）
逐项核对以下必填项 。缺失的不要编造、不要跳过 ，一律写成 [待确认：需向 XX 确认的具体问题]。
| 类别 | 必填项 | 常见获取对象 |
|---|---|---|
| 归属 | 适用公司及代码、需求范围等级、涉及系统、是否 SAP、涉及部门 | 需求提出人 / IT 接口人 |
| 角色 | 目标用户或角色（至少 2 类） | 需求提出人 |
| 业务 | 当前耗时、出错频次、涉及人数等业务现状数字 | 现场业务人员 |
| 规则 | 统计口径、计算公式、系数来源、缺省值、取整规则 | IE / 工艺 / 业务负责人 |
| 报表 | 字段清单、排序、分组与合并、特殊样式（标红等） | 报表使用方 |
| 推送 | 触发时点、目标群/收件人（含工号）、内容、失败兜底与责任人 | 需求提出人 |
| 验收 | 可观测的判定方式（比对样本数、连续验证天数、成功率阈值） | IT + 业务共同确认 |
禁止编造清单 （命中即写 [待确认]）：人名、工号、公司代码、表名、字段名、存储过程名、群名与机器人地址、IP、URL、系数数值、线体编号归属。
Step 2 --- 生成首部三栏
按 references/l2-template.md 的表格输出「痛点背景 / 项目价值 / 影响范围」。写作要求：
-
痛点背景：3 条左右，每条必须带可核对的事实（耗时、人数、频次、口径不一致的具体表现），不写"效率低"这类抽象词。
-
项目价值：与痛点一一对应，写"替代/实现/支撑"什么，输出的是结果不是功能。
-
影响范围：固定 4 项------适用范围（公司 + 范围等级）、涉及系统、涉及部门、目标用户/角色。
Step 3 --- 生成正文 7 章
严格按 references/l2-template.md 的章节与字段顺序，逐章按 references/writing-rules.md 的规范填写。
章节编号固定为 1--7，不得增删、不得改序。某章暂无内容时保留标题并写「待补充：缺什么，向谁确认」。
Step 4 --- 质量自检（输出前逐条过）
- 第 1 章 12 个字段全部有值，无空白（未知者为
[待确认]） - 第 2 章 四问（问题/现状/痛点/期望）齐全，且至少含 1 个量化现状数字
- 第 3 章 有「项目边界（不包含）」；成功标准含有数字阈值
- 第 4 章 每个计算写全了公式、系数来源、缺省值、取整规则、异常标识
- 第 4 章 每个报表写全了字段清单、排序、分组合并、特殊样式
- 第 4 章 每个自动/定时动作写全了失败兜底与责任人
- 第 5 章 统计时间窗口写明边界取值（含/不含）与节假日行为
- 第 6 章 每条验收标准可观测可判定，无"正常/稳定/及时/友好"等形容词
- 第 7 章 三类（待确认事项 / 依赖项 / 待定方案）均已覆盖
- 全文无编造的人名、工号、对象名
Step 5 --- 交付
-
默认 ：输出 Markdown 文件，文件名格式
<需求名称>-需求规格说明书L2.md。 -
需要 Word ：先按模板产出 Markdown，再调用
tencent-docx插件的full_pipeline生成.docx，并用present_files打开预览。 -
交付后追加一段「待确认事项汇总」，把所有
[待确认：xxx]集中列出，便于需求提出人一次性补齐。
字段取值字典
生成第 1 章时从下表取值，不要自创枚举：
| 字段 | 可选值 |
|---|---|
| 需求形态 | 功能增强（新功能开发）· 功能优化（现有功能改进）· 缺陷修复 · 接口对接 · 报表开发 · 数据治理 |
| 需求类型 | 新增 · 变更 · 优化 · 缺陷 |
| 需求类型标签 | 数据治理 · 管理升级 · 效率提升 · 质量管控 · 成本优化 · 合规风控 · 系统集成 · 自动化（可多选） |
| 需求范围等级 | 集团级 · 工厂级 · 部门级 · 车间级 |
| 涉及系统清单 | MES系统（深圳）· WMS系统（深圳）· SAP · SRM · QMS · EAP · 其它（注明） |
| 是否 SAP | 是 · 否 |
| 需求等级 | L1（简单）· L2（中等）· L3（大型） |
硬规则（违反即返工）
-
不编造 ：任何无法从输入或已知上下文确证的实体（人、工号、表、字段、群、地址），一律
[待确认]。 -
验收标准可判定：每条必须能回答"谁、在什么时点、看什么、看到什么算通过"。禁用：正常、稳定、及时、友好、高效、满足需求、运行良好。
-
自动化必配兜底：凡出现"自动/定时/每日/每月"，必须同时写清失败检测方式、通知对象、处理责任人。
-
计算必配全要素：凡出现折算/换算/比率，必须写清公式、系数来源（谁在哪维护）、缺省值、取整或精度规则、异常标识方式。
-
报表必配结构：凡出现报表，必须写清字段清单、排序规则、分组与单元格合并规则、特殊样式规则。
-
口径必配边界：凡出现统计区间，必须写清起止时点的含/不含、跨天处理方式、节假日行为、无数据时的表现。
-
边界必显式：必须写出"不包含"什么，避免范围蔓延。