---
name: blueprint-planner
description: "SOP蓝图预规划 — Phase -1 确定性锚定技能。基于岗位职能手册和服务类目手册，生成锁定的SOP蓝图清单、模板蓝图清单和RACI矩阵草案。核心：内在内容深度标准（不依赖外部参考）、自主规划模式（无参考时仍生成完整蓝图）、全面参数化、数据一致性校验。"
version: 2.0.0
author: MG-01 SOP编排专家
category: 蓝图规划

internal: true
triggers:
 - 蓝图规划
 - blueprint planner
 - SOP蓝图
 - Phase -1
 - 蓝图谱写
keywords:
 - blueprint
 - plan
 - lock
 - 蓝图
 - 规划
 - 锁定
 - 参数化
 - 内容深度
---

# blueprint-planner — SOP蓝图预规划（Phase -1）

## 触发条件

Phase 0 完成且 C1-C6 门禁通过后，在 Phase 1 内循环开始前自动触发。

也可由用户手动触发（如"重新生成蓝图"）。

## 核心使命

基于岗位职能手册和服务类目手册，生成**锁定的**SOP蓝图清单和模板蓝图清单，作为后续所有轮次Q1生成的**唯一依据**。
蓝图一旦写入知识库，后续轮次不允许LLM自行增减SOP/模板。

### 核心增强

1. **全面参数化**：流程阶段、角色代码、业务线代码、服务类别等均从输入材料动态提取，禁止硬编码
2. **内在内容深度标准（Step 0-5）**：定义不依赖外部参考的内容深度下限，确保任何流程的SOP均达到基本业务完整性
3. **自主规划模式**：无参考标准时仍能通过D1-D7规则 + T7深度分析 + 内在深度标准自主生成完整蓝图
4. **模板深度推导**：逐SOP逐环节扫描模板需求（三层分析：可填写文档→业务线变体→上下游衍射）
5. **数据一致性校验（G7）**：蓝图JSON的元数据字段必须与列表实际条目数一致
6. **标准参考增强（可选）**：当standardRefPath有效时，在内在标准之上进一步提取参考深度基准

## 运营参数配置引用

本文件的**业务规则**（蓝图规划算法/G1-G7门禁/B1-B5锁定/D1-D7识别规则等）为权威定义。
**引擎级运营参数**（超时/重试/蓝图校验重试次数等）集中定义在 `sop-system-config` SKILL 中。

### 输入参数

| 参数 | 类型 | 必填 | 说明 |
|:-----|:-----|:----:|:-----|
| processName | string | 是 | 流程名称（如"LTC流程"），从用户输入获取 |
| processCode | string | 是 | 流程代码（如"LTC"），从用户输入或流程名称中提取，用于文件命名前缀 |
| roleHandbookPath | string | 是 | 岗位职能手册路径 |
| serviceCatalogPath | string | 是 | 服务类目手册路径 |
| standardRefPath | string | 否 | 标准参考文件路径（如有），用于内容深度对齐 |
| knowledgeBasePath | string | 是 | 知识库路径（蓝图输出位置） |

### 参数化约束（🚫 禁止硬编码）

```
以下要素必须从输入材料动态提取，禁止在指令/规则中写死具体值：
- 流程阶段名称和数量 → 从岗位职能手册/标准参考中提取
- 角色代码和名称 → 从岗位职能手册中提取
- 业务线代码和名称 → 从服务类目手册中提取
- 部门名称和编码 → 从岗位职能手册中提取
- 服务类别分类 → 从服务类目手册中提取
- 流程代码 → 从processCode参数注入
- 版本号 → 从标准参考或版本继承规则推导
```

## 执行流程（5步）

### Step 0: 标准参考对齐（最高优先级 · 确定性保障）

```
🚨 本步骤在所有其他步骤之前执行，确保相同输入产生相同输出。

Step 0-1: 检查标准参考文件是否存在
 IF standardRefPath 非空且文件存在:
 → 读取标准参考文件，提取完整的SOP清单和模板清单
 → 将标准参考的SOP清单作为蓝图的「唯一基准」
 → 蓝图中的SOP数量、编号、名称必须与标准参考完全一致
 → 禁止增加、删除或合并标准参考中的SOP条目
 → 输出：🔒 蓝图已对齐标准参考 — {N}个SOP + {M}个模板

Step 0-2: 标准参考不存在时的确定性规则
 IF standardRefPath 为空或文件不存在:
 → 从岗位职能手册中提取角色-流程映射表
 → 按以下确定性规则识别SOP需求（减少LLM解释差异）：
 Rule D1: 每个独立的流程阶段（从手册/服务类目动态提取）至少对应1个SOP
 Rule D2: 如果某阶段在手册中有独立的「操作流程」章节 → 该阶段独立为1个SOP
 Rule D3: 如果某阶段在手册中被拆分为多个子流程（各有独立步骤）→ 每个子流程1个SOP
 子流程识别条件（满足≥2个即独立）：
 a. 有独立的执行角色（不同于同阶段其他子活动）
 b. 有独立的可交付输出物（文档/表单/报告等）
 c. 涉及独立的审批/决策节点
 d. 存在跨部门/跨角色交接点
 Rule D4: 审批规则如果独立成文（不依附于具体操作性SOP，由工作流引擎消费）→ 独立为任务框架型SOP
 Rule D5: 上游流程（如市场活动→线索生成）如果与主流程有明确的交接点 → 独立为SOP
 Rule D6: 以下特征的活动必须独立为SOP（从手册/知识库中按特征模式自动识别）：
 a. 有独立评审/会议纪要交付物的活动 → 会议SOP
 b. 涉及跨部门/跨角色交接的活动（如销售→交付、合同→项目启动）→ 交接SOP
 c. 有独立审批流程/分级审批逻辑的活动 → 审批规则SOP
 d. 有独立投标/标书/资质/备案交付物的活动 → 专项SOP
 e. 有独立成本核算/报价交付物的活动 → 操作性SOP
 f. 仅在特定条件满足时启动的活动（含"仅在...时启动/触发""条件分支""按需执行""如需"等模式）→ 条件分支型SOP
 g. 定义合规审查/业务合规/质量合规等独立规则清单的活动（含"合规""审查规则""业务规则"关键词，有独立判定标准和审查流程）→ 规则型SOP
 📌 规则型SOP与任务框架型SOP的区别：规则型SOP有具体操作步骤（由角色执行），任务框架型SOP仅有规则配置（由引擎消费）
 Rule D7: 任务框架型SOP自动识别（从手册/知识库中按特征模式自动识别）：
 满足以下≥2个特征的活动 → 独立为任务框架型SOP（由工作流引擎消费，非Agent执行）：
 a. 定义审批路由/分级规则/审批链配置（不含具体业务操作步骤）
 b. 由系统工作流引擎消费（而非由角色手动执行）
 c. 包含超时升级/驳回逆流程/会签规则等工作流配置
 d. 被多个操作性SOP引用（作为公共规则而非独立操作步骤）
 📌 任务框架型SOP不包含操作步骤，仅定义规则和配置
 → 输出SOP识别依据：每个SOP对应的手册章节 + 触发规则（D1~D7）
 → 🚫 禁止凭主观判断增加或减少SOP数量

Step 0-2-PLUS: 流程边界识别与范围排除
 在应用D1~D7规则后，必须执行流程边界校验，排除不属于当前流程的活动：

 Rule B-EX1: 流程终点检测
 从手册/知识库中识别流程终点标记：
 - 含"流程止于""流程结束""LTC终止"等标记 → 终点之后的活动不纳入SOP
 - 含"由XX流程承接""转移至XX流程""移交XX流程"等标记 → 下游活动属于其他流程
 - 含"另行构建体系""另行构建""独立体系"等标记 → 该业务不属于当前流程体系

 Rule B-EX2: 上游流程排除
 如果某活动的上游来源明确标注为其他流程（如"来自MM流程""来自市场管理"），
 且该活动本身属于上游流程的核心环节 → 不为本活动创建独立SOP
 📌 但应在SOP-000的§11上下游衔接中标注接口关系

 Rule B-EX3: 下游流程排除
 如果某活动的输出明确标注"由XX流程承接"（如"回款关闭后→CS流程承接售后服务"），
 该承接活动不属于当前流程 → 不创建独立SOP

 Rule B-EX4: 业务线独立体系排除
 如果手册中某业务线明确标注"另行构建体系"或"独立体系"（如"S类另行构建体系"），
 该业务线的独立交付流程不作为当前流程的业务SOP
 📌 但应在SOP-000中声明该业务线的存在和排除原因
 📌 该业务线仍参与当前流程的共享环节（如方案设计/成本核算/报价等），
 其差异化通过模板变体处理（见Step 2-4的T-VAR规则）

 Rule B-EX5: 交付类活动归属判定
 如果手册中"项目交付/项目执行/临床执行"等活动的描述明确标注：
 - "移交OTD流程""由OTD流程承接" → 交付执行属于OTD，不创建独立SOP
 - "移交项目团队执行""进入项目执行阶段" → 交付执行属于其他流程，不创建独立SOP
 📌 但"项目启动"（合同→交付的交接环节）属于当前流程，应创建独立交接SOP

 输出：排除清单（被排除的活动 + 排除原因 + 归属流程）
 🚫 禁止将已排除的活动纳入SOP蓝图
 🚫 禁止为“另行构建体系”的业务线创建独立业务SOP

Step 0-2-RULE: 参考标准废弃/占位SOP检测（当standardRefPath有效时执行）
 在应用D1~D7规则前，必须先过滤参考标准中的非活跃SOP条目：

 Rule D8: 废弃/占位SOP识别
 对参考标准中的每个SOP文件，检查以下废弃特征（满足≥1个即标记为废弃）：
 a. 文件名含“迁移说明”“编号说明”“占位说明”“已作废”“deprecated”等标记
 b. 文件内容以“迁移记录”“编号变更”“作废说明”为主要内容（无操作步骤/业务规则）
 c. §1文档信息中“当前状态”含“已作废”“已迁移”“待建”“编号已作废”等标记
 d. 文件总行数 < 100行且无实质性业务规则内容
 废弃SOP处理：
 - 标记为“已废弃占位”，不纳入蓝图SOP清单
 - 记录废弃原因，写入排除清单
 - 保留其编号位置（不重编号，维持编号连续性）
 - 该编号位置在蓝图中可标记为 deprecatedPlaceholder: true
 🚫 禁止为废弃编号创建新类型的SOP（如将“编号迁移说明”误创建为“合规审查规则SOP”）
 🚫 禁止将废弃SOP计入totalSOPs和breakdown统计

Step 0-3: 模板数量确定性规则
 模板数量不再使用固定比例，改为逐SOP分析驱动：

 Rule T1: 每个操作性/审批/会议/交接/专项SOP至少有1个配套模板
 Rule T2: 如果SOP中有「填写表单」「记录表」「申请表」「确认单」等可填写文档 → 每个独立为1个模板
 Rule T3: 审批类SOP额外增加「审批表」「审批规则配置表」模板
 Rule T4: 当同一业务环节存在多种业务线变体时（如不同业务线使用不同合同/方案模板），每种变体独立为1个模板
 Rule T5: 通用配置类模板（如规则配置表、基准价库等）独立计数
 Rule T6: 从标准参考动态推导模板范围（当standardRefPath有效时）：
 - templateMin = count(标准参考中的模板文件数)
 - templateMax = templateMin × 1.1（允许少量新增）
 Rule T7: 当standardRefPath无效时，逐SOP深度分析驱动：
 - 对每个SOP，按T1-T5规则计算其配套模板数
 - 额外深度分析（确保不遗漏）：
 a. 扫描SOP描述中的每个业务环节，识别所有可填写文档
 b. 对每个审批节点，识别是否需要独立审批表
 c. 对每个业务线变体环节，按T4展开为独立模板
 d. 对每个配置类需求（规则配置/基准价/权限矩阵），识别为独立模板
 e. 对每个交付物/确认单/交接清单，识别为独立模板
 f. 对每个会议/评审环节，识别会议纪要+评审结论模板
 - templateMin = ∑ 各SOP配套模板数（含深度分析结果）
 - templateMax = templateMin × 1.2（允许额外通用模板）
 → 🚫 禁止使用固定比例（如SOP数×0.8~1.2）约束模板数量
 → 🚫 禁止凭主观判断增加或减少模板数量
 → 🚫 禁止仅给每个SOP分配1个模板就停止分析（必须逐环节深入）

Step 0-5: 内在内容深度最低标准（无论standardRefPath是否有效均执行）
 🚨 本步骤定义不依赖外部参考的内容深度下限，确保任何流程的SOP均达到基本业务完整性。

 按SOP类型定义内在深度最低标准：

 总纲类SOP（SOP-000，sopType="总纲"）：
 - 章节数 ≥ 14（标准14章结构）
 - 必须包含：流程架构全景图、SOP完整清单、RACI矩阵、上下游衍接、度量指标
 - 必须包含：公共业务规则体系（从手册中推导）
 - 必须包含：例外处理（≥10条，四要素格式）
 - 必须包含：质控节点（KCP）清单
 - estimatedLines ≥ 800
 📌 注意：当参考标准中SOP-000的类型标注为"任务框架型"时，蓝图中sopType仍使用"总纲"，
 因为"总纲"是蓝图分类维度的特殊类型，与操作步骤层面的"任务框架型"不冲突。

 操作性SOP：
 - 章节数 ≥ 9（基础结构）；当参考标准对应SOP章节数>9时，取 max(9, 参考章节数×0.8)
 - 标准14章结构为理想上限，实际章节数取决于业务复杂度
 - 必须包含的最低章节：目的与范围、术语、角色职责、操作步骤、质控标准、输出物与模板、度量指标、例外处理、版本审批
 - 操作步骤数 ≥ 5（每个步骤含完整的节点类型字段）
 - 例外处理 ≥ 3条（四要素格式）
 - 质控节点 ≥ 2个
 - 必须包含：服务类型差异化说明、跨SOP引用、关联模板索引
 - estimatedLines ≥ 300

 规则型SOP：
 - 章节数 ≥ 7（规则清单+审查流程+判定标准）
 - 必须包含：规则清单（编号化）、审查流程、判定标准、例外与升级
 - 操作步骤数 ≥ 3（聚焦规则执行和审查判定）
 - estimatedLines ≥ 200
 - 📌 规则型SOP不需要配套模板（templateCount可为0），因为规则清单本身即为交付物

 任务框架型SOP：
 - 章节数 ≥ 12（无§7操作步骤）
 - 必须包含：审批分级规则、审批时限、超时升级、驳回逆流程
 - 必须包含：规则配置表模板引用
 - estimatedLines ≥ 250

 条件分支型SOP：
 - 章节数 ≥ 14（同操作性SOP）
 - 必须包含：触发条件定义、条件判断逻辑、分支路径说明
 - 操作步骤数 ≥ 5
 - estimatedLines ≥ 300

 模板文件：
 - 字段数 ≥ 15（基础表单）或 ≥ 25（复杂方案/合同类）
 - 区块数 ≥ 3
 - 必须包含：字段类型、字段约束、填写说明
 - 业务线变体模板必须包含差异化字段（禁止仅改标题）

 将内在深度标准写入蓝图的contentDepthBaseline字段：
 - 当standardRefPath有效时：取 max(内在标准, 参考标准×0.8)
 - 当standardRefPath无效时：使用内在标准作为唯一基准
 🚫 禁止生成低于内在深度标准的SOP/模板（无论是否有参考）

Step 0-4: 标准参考深度解析（仅当standardRefPath有效时执行，否则跳过）
 本步骤在内在标准之上，进一步提取参考标准的内容深度基准。
 🚨 前置过滤：跳过所有被 Rule D8 标记为废弃的SOP文件，不纳入深度解析
 FOR EACH refSOP IN 标准参考SOP文件（排除废弃条目）:
  提取章节结构清单（§1~§14 + 子章节）
  提取每个章节的核心内容类型（角色定义/业务规则/操作步骤/例外处理/质控标准等）
  记录章节行数（作为内容深度基准）
  输出：refSOP.sectionProfile = { 章节编号: {内容类型, 行数, 核心规则数} }

 Step 0-4-2: 业务规则提取
 FOR EACH refSOP IN 标准参考SOP文件:
  提取公共规则清单（如成本模型、信用评级、审批规则、回款规则等）
  提取例外处理清单（触发条件 + 审批路径 + 执行操作 + 后续流转）
  提取质控节点清单（KCP/QC编号 + 检查内容 + 强制级别）
  提取跨SOP一致性声明（统一术语/统一公式/统一枚举值）
  输出：refSOP.businessRules = { 公共规则[], 例外处理[], 质控节点[], 一致性声明[] }

 Step 0-4-3: 模板深度提取
 FOR EACH refTMP IN 标准参考模板文件:
  提取字段清单（字段名 + 类型 + 约束）
  提取区块结构（区块名 + 包含字段数）
  提取业务线变体标记（哪些模板有业务线差异化）
  输出：refTMP.fieldProfile = { 字段数, 区块数, 业务线变体标记 }

 Step 0-4-4: 内容深度基准写入知识库
 将提取结果写入 {knowledgeBasePath}/标准参考深度基准.json
 该文件作为后续 Q1 生成时的内容深度下限约束：
 - 每个SOP的章节数 ≥ refSOP.sectionProfile的章节数 × 0.8
 - 每个SOP的业务规则数 ≥ refSOP.businessRules的规则数 × 0.8
 - 每个模板的字段数 ≥ refTMP.fieldProfile.字段数 × 0.8
 🚫 禁止生成内容深度低于参考标准80%的SOP/模板
```

### Step 1: 读取输入材料

```
Step 1-1: 读取岗位职能手册
 ├── glob_search(roleHandbookPath + "/**/*") → 获取全部文件列表
 ├── 提取角色清单（角色编码 + 角色名称 + 部门 + 流程参与阶段）
 ├── 提取流程参与矩阵（角色 × 流程阶段 的RACI分配）
 └── 🚫 角色编码/部门名称必须原文提取，禁止缩写或改写

Step 1-2: 读取服务类目手册
 ├── glob_search(serviceCatalogPath + "/**/*") → 获取全部文件列表
 ├── 提取业务线清单（业务线代码 + 业务名称 + 业务性质 + 阶段划分）
 ├── 提取服务项清单（服务编码 + 服务名称 + 阶段 + 类型（主/辅））
 └── 🚫 业务线名称必须原文提取（如"注册临床业务"而非"咨询类"），禁止自行编造描述

Step 1-3: 读取标准参考文件（如有）
 ├── 如果 standardRefPath 非空且存在
 ├── 提取参考SOP清单（文件名解析：编号 + 名称 + 版本号）
 ├── 提取参考模板清单（文件名解析：编号 + 名称 + 版本号）
 └── 提取参考SOP的内容结构（章节数 + 行数 + 规则数）

Step 1-4: 服务类型原文校验
 从服务类目手册中提取的业务线信息必须与手册原文完全一致：
 - 业务线代码（如C/R/I/T/S）← 手册第二章表格
 - 业务名称（如"注册临床业务""真实世界研究"）← 手册原文
 - 业务性质（项目型/平台型）← 手册原文
 - 阶段划分（启动→准备→执行→收尾 / 商机与转化→入驻与启用→运营与支持→续约与增值）← 手册原文
 🚫 禁止用其他描述替代手册原文（如用"咨询类"替代"注册临床业务"）
 🚫 禁止合并或拆分手册中的业务线定义
```

### Step 2: 执行蓝图规划算法

```
Step 2-1: 按流程阶段分组角色（参数化，禁止硬编码阶段名）
 // 阶段列表从岗位职能手册/标准参考中动态提取，禁止写死具体阶段名称
 stages = 从岗位职能手册中提取流程阶段列表
       ∪ 从标准参考中提取阶段列表（当standardRefPath有效时）
 stageGroups = {}
 FOR EACH stage IN stages:
   stageGroups[stage.name] = roles.filter(r => r.participatedStages.includes(stage.name))
 📌 阶段名称、数量、顺序均从输入材料动态获取
 🚫 禁止在代码/指令中硬编码具体阶段名称（如"Lead""Opportunity"等）
 🚫 禁止假设固定阶段数量（不同流程的阶段数可能不同）

Step 2-2: 按业务节点识别SOP需求
 ├── 每个流程阶段至少1个SOP覆盖
 ├── 如果一个阶段有≥2个独立子活动（满足以下≥2个条件即独立）→ 拆分为多个SOP：
 │ a. 不同执行角色（角色代码不同）→ 必须拆分
 │ b. 不同独立交付物（输出文档/表单/报告类型不同）→ 必须拆分
 │ c. 涉及独立审批/决策节点（含审批/评审/签批关键词）→ 必须拆分
 │ d. 存在跨部门/跨角色交接点 → 必须拆分
 │ e. 有独立的质控标准和验收条件 → 强烈建议拆分
 ├── 🚫 禁止单个SOP覆盖超过2个独立子环节（即使执行角色相同）
 ├── 🚫 禁止将不同执行角色的子活动合并到同一SOP（如：方案设计SR-01 + 成本核算PM → 必须拆分）
 ├── 审批类活动如果涉及分级审批逻辑 → 独立审批规则SOP（任务框架型）
 ├── 会议/评审类活动（有独立会议纪要/评审结论交付物）→ 独立会议SOP（操作性）
 ├── 交接类活动（涉及跨部门/角色交接，有独立交接确认单）→ 独立交接SOP（操作性）
 ├── 专项类活动（投标/标书/资质/备案等，有独立交付物）→ 独立专项SOP
 ├── 条件分支类活动（仅在特定条件满足时启动，含“仅在...时”“如需”“条件触发”模式）→ 条件分支型SOP
 ├── 任务框架类活动（定义审批路由/分级规则/工作流配置，由引擎消费而非Agent执行）→ 任务框架型SOP
 └── 🚨 反合并保护规则（MERGE-PROTECT，强制执行）：
 以下模式绝对禁止合并，违反即触发阻断：
 MP-1: 角色不同 → 禁止合并
 如果两个活动的执行角色(R)不同（如SR-01做方案设计、FR-01/PM做成本核算），
 即使它们属于同一流程阶段，也必须为独立SOP。
 “同一阶段”不是合并的理由，“同一执行角色”才是合并的必要条件。
 MP-2: 交付物不同 → 禁止合并
 如果两个活动的核心交付物类型不同（如“方案建议书” vs “成本测算表” vs “报价单”），
 每个交付物对应独立SOP。
 MP-3: 评审/会议类活动 → 必须独立
 任何有“评审会”“方案评审”“技术评审”“商务评审”关键词的活动，
 且有独立会议纪要/评审结论交付物 → 必须为独立SOP，禁止作为其他SOP的一个步骤。
 MP-4: 投标/标书/资质类活动 → 必须独立
 任何有“投标”“标书”“资质”“备案”“招标文件”关键词的活动，
 且有独立交付物 → 必须为独立SOP（条件分支型）。
 MP-5: 成本核算/报价类活动 → 必须独立
 任何有“成本核算”“成本测算”“报价编制”“A~L成本树”关键词的活动，
 且有独立计算模型/公式体系 → 必须为独立SOP。

Step 2-2-AUDIT: 合并违规审计（SOP识别完成后强制执行）
 在生成sopList后，必须执行以下审计：
 FOR EACH sop IN sopList:
   // 审计1：检查是否合并了不同角色的活动
   IF sop.coreActivities中存在不同执行角色的活动:
     → 🚨 违规！必须拆分为独立SOP
   // 审计2：检查是否合并了不同交付物类型
   IF sop.deliverables中存在≥ 3种不同类型的交付物:
     → 🚨 警告！强烈建议拆分
   // 审计3：检查是否遗漏了评审/会议类SOP
   IF 手册中存在"评审会/方案评审/技术评审"活动但sopList中无对应SOP:
     → 🚨 违规！必须补充独立会议SOP
   // 审计4：检查是否遗漏了投标/标书类SOP
   IF 手册中存在"投标/标书/招标"活动但sopList中无对应SOP:
     → 🚨 违规！必须补充独立专项SOP
   // 审计5：检查是否遗漏了成本核算类SOP
   IF 手册中存在"成本核算/成本模型/报价编制"活动但sopList中无对应SOP:
     → 🚨 违规！必须补充独立操作性SOP
 审计不通过 → 返回Step 2-2重新识别（≤ 2次）
 🚫 禁止跳过审计步骤
 └── Step 2-2-PLUS: 业务线变体处理
 对同一流程环节中存在多业务线变体的情况，区分SOP级拆分 vs 模板级变体：
 Rule T-VAR1: 共享流程框架判定
 如果多个业务线（如C/R/I/T/S）共享相同的流程步骤框架（如项目型四阶段：启动→准备→执行→收尾），
 仅表单/模板内容因业务线不同而异 → 不拆分为独立业务SOP，保持单一SOP + 多模板变体
 Rule T-VAR2: 差异化模板标记
 对以下环节类型，按业务线数(B)生成差异化模板：
 - 方案建议书/解决方案书 → B个模板（每业务线1个）
 - 合同草案/协议模板 → B个模板（每业务线1个）
 - 评估报告/评估表 → 条件B个（如不同业务线评估标准不同）
 📌 差异化模板归属同一SOP，在SOP §9.2模板清单中逐项列出
 Rule T-VAR3: 独立流程变体判定
 仅当某业务线需要完全不同的流程步骤（不满足T-VAR1的共享框架条件）时，
 才考虑拆分为独立SOP
 📌 判定标准：该业务线的流程步骤数与其他业务线差异>50%，或有完全不同的执行角色链

Step 2-3: 生成SOP蓝图清单
 每个SOP条目必须包含：
 {
 "sopId": "HY-G-{processCode}-SOP-{NNN}",  // processCode从参数注入
 "sopName": "{SOP名称}",
 "sopType": "操作性SOP | 任务框架型SOP | 条件分支型SOP | 规则型SOP | 总纲",
 // 📌 sopType说明：
 // - "总纲"：仅用于SOP-000，定义流程全局架构和SOP衔接关系
 // - "操作性SOP"：含具体操作步骤，由角色手动执行
 // - "任务框架型SOP"：仅定义规则/配置，由工作流引擎消费（D7识别）
 // - "条件分支型SOP"：仅在特定条件满足时启动（D6.f识别）
 // - "规则型SOP"：定义合规审查/业务规则清单，有操作步骤但聚焦规则执行（D6.g识别）
 "version": "{版本号}",  // 从标准参考继承或按版本规则推导
 "description": "{SOP描述}",
 "coveredStages": ["动态提取的阶段名"],
 "primaryRoles": ["动态提取的角色代码"],
 "relatedDepartments": ["从岗位手册提取的部门名称"],
 "serviceTypeCoverage": ["从服务类目手册提取的业务线代码"],
 "inputServices": ["动态提取的服务编码"],
 "outputTemplates": ["HY-G-{processCode}-TMP-{NNN}"],
 "upstream": ["上游SOP的sopId"],
 "downstream": ["下游SOP的sopId"],
 "estimatedLines": 300,
 "contentDepthBaseline": {  // 内容深度基准（当标准参考存在时填充）
 "refSectionCount": 14,  // 参考标准章节数
 "refBusinessRuleCount": 10,  // 参考标准业务规则数
 "refExceptionCount": 18,  // 参考标准例外处理数
 "refKCPCount": 10  // 参考标准质控节点数
 },
 "priority": "P0 | P1 | P2"
 }
 🚫 sopId中的流程代码必须使用processCode参数，禁止硬编码
 🚫 sopId必须使用完整格式 HY-G-{processCode}-SOP-{NNN}，禁止省略前缀
 🚫 primaryRoles中的角色代码必须从岗位职能手册提取，禁止编造
 🚫 version必须从标准参考继承（当standardRefPath有效时），禁止统一写V1.0
 🚫 所有必填字段（description/upstream/downstream/contentDepthBaseline/priority）不得省略

Step 2-4: 生成模板蓝图清单
 每个模板条目必须包含：
 {
 "tmpId": "HY-G-{processCode}-TMP-{NNN}",  // processCode从参数注入
 "tmpName": "{模板名称}",  // 从标准参考继承或按命名规则推导
 "version": "{版本号}",  // 从标准参考继承
 "relatedSop": "HY-G-{processCode}-SOP-{NNN}",
 "fieldCount": 12,  // 从标准参考提取或按T1-T5推导
 "sectionCount": 3,
 "serviceTypeVariant": null | "{serviceTypeCode}",  // 业务线变体标记
 "contentDepthBaseline": {
 "refFieldCount": 25,  // 参考标准字段数
 "refSectionCount": 5  // 参考标准区块数
 }
 }
 🚫 tmpId中的流程代码必须使用processCode参数
 🚫 tmpName优先从标准参考继承（去掉前缀和版本号后的核心名称）
 🚫 fieldCount当标准参考存在时，必须≥参考模板字段数×0.8

 Step 2-4-PLUS: 模板变体展开
 在生成模板清单时，必须对需要业务线差异化的模板进行展开：

 Rule T-EXP1: 变体识别
 对每个SOP的配套模板，检查是否存在业务线差异化需求：
 - 从Step 2b获取业务线清单（如C/R/I/T/S共5类）
 - 对以下环节类型的模板，按业务线数展开：
 a. 方案建议书/解决方案书类 → 展开为B个独立模板
 b. 合同草案/协议类 → 展开为B个独立模板
 c. 评估表/报告类 → 条件展开（如不同业务线评估标准不同）
 d. 配置表/基准价库类 → 不展开（通用）
 e. 表单/记录表/确认单类 → 不展开（通用）

 Rule T-EXP2: 变体命名规范
 展开的模板命名格式：{模板名称}（{业务线代码}类）
 示例：解决方案建议书模板（C类）、合同草案模板（R类）

 Rule T-EXP3: 变体数量校验
 模板总数 = 基础模板数 + ∑(各差异化环节的变体数)
 其中：基础模板数 = 每个非总纲SOP至少1个配套模板
 差异化环节的变体数 = 业务线数B × 差异化环节类型数
 🚫 禁止将多个变体合并为1个"通用版"模板

Step 2-5: 生成RACI矩阵草案
 角色 × SOP 矩阵，每格标注 R/A/C/I/—
```

### Step 3: 蓝图校验门禁（Phase Gate -1）

```
G1: SOP数量 ≥ expectMin × 0.9
 expectMin 计算规则（按优先级）：
 P0: 当 standardRefPath 有效时
 expectMin = max(count(标准参考SOP文件数), expectMin_KB)
 📌 标准参考SOP数量为绝对下限，不可被知识库推导值覆盖
 P1: 当 standardRefPath 无效时
 expectMin = expectMin_KB（从知识库内容推导）
 expectMin_KB 计算公式：
 = 1(总纲)
 + ∑(每个流程阶段的独立执行角色数)  // 🚨 关键：每阶段按角色数计数，不是固定1
 + 审批规则SOP候选数（任务框架型）
 + 会议/评审SOP候选数
 + 专项SOP候选数（投标/标书/资质）
 + 条件分支型SOP候选数
 + 交接SOP候选数
 📌 核心原则：每个流程阶段的SOP数 ≥ 该阶段独立执行角色数
 例如：某阶段有SR-01(方案设计)+PM(成本核算)+AR-01(报价)三个角色 → 该阶段至少3个SOP
 🚫 禁止在标准参考有效时使用小于标准参考SOP数的expectMin
 🚫 禁止将“每阶段至少1个SOP”理解为“每阶段只需1个SOP”
G2: 每个流程阶段至少有1个SOP覆盖
G3: 每个角色至少在1个SOP中出现（R或A角色）
G4: 模板数量动态校验
 按以下优先级计算模板合理范围：
 P0: 当 standardRefPath 有效时
 templateMin = count(标准参考模板文件数)
 templateMax = templateMin × 1.15（允许少量新增模板）
 P1: 当 standardRefPath 无效时，逐SOP分析驱动
 对每个非总纲类型SOP（含操作性/任务框架型/条件分支型/规则型SOP），计算其配套模板数：
 baseCount = 1（至少1个核心模板）；规则型SOP的baseCount可为0（规则清单本身即交付物）
 + 可填写文档数（表单/记录表/申请表/确认单）
 + 审批表数（审批类SOP）
 + 业务线变体数（同一环节不同业务线的差异化模板）
 + 配置表数（规则配置类模板）
 templateMin = ∑ 各SOP配套模板数
 templateMax = templateMin × 1.2（允许额外通用模板）
 校验：templateMin ≤ 实际模板数 ≤ templateMax
 🚫 禁止使用固定比例（如SOP数×0.8~1.2）约束模板数量
 📌 不同流程的模板/SOP比例差异很大（如LTC约2.1，简单流程可能0.8），必须动态推导
G5: RACI矩阵无空白列（每个角色至少有一个R/A）
G6: 内容深度基准校验（始终强制执行）
 校验规则：
 当standardRefPath有效时：
 a. 每个SOP的estimatedLines ≥ 对应参考SOP行数 × 0.6
 b. 每个SOP的contentDepthBaseline必须已填充（refSectionCount > 0）
 c. 模板总数 ≥ 参考标准模板数 × 0.95
 d. 每个模板的fieldCount ≥ 参考模板字段数 × 0.8
 e. 参考标准中的每个业务线变体模板必须在蓝图中有对应条目
 当standardRefPath无效时（使用内在深度标准）：
 a. 总纲类SOP: estimatedLines ≥ 800, 章节数 ≥ 14
 b. 操作性SOP: estimatedLines ≥ 300, 步骤数 ≥ 5
 c. 任务框架型SOP: estimatedLines ≥ 250
 d. 条件分支型SOP: estimatedLines ≥ 300
 e. 规则型SOP: estimatedLines ≥ 200, 章节数 ≥ 7
 f. 每个模板: fieldCount ≥ 15（基础）或 ≥ 25（复杂类）
 g. 每个非总纲/非规则型SOP至少有1个配套模板（禁止空模板SOP）；规则型SOP允许templateCount=0
 不通过处理：补充缺失的SOP/模板条目或调整estimatedLines → 重新校验
G7: 数据一致性校验
 校验规则：
 a. totalCount字段 == sopList/templateList的实际条目数
 b. breakdown各类型数量之和 == totalCount
 c. 每个SOP的outputTemplates必须在templateList中存在
 d. 每个模板的relatedSop必须在sopList中存在
 e. generationOrder中的SOP编号必须与sopList完全一致（不多不少）
 不通过处理：修正元数据字段 → 重新校验
G8: SOP类型完备性校验（阻断级）
 校验规则：
 a. 从岗位职能手册中扫描以下关键词模式，统计各类型候选数：
 - 审批/评审/审核/签批 + 分级路由 → 任务框架型SOP候选
 - "仅在...时"/"如需"/"条件触发"/"按需执行" → 条件分支型SOP候选
 - 合规/审查规则/业务规则/质量合规 + 独立判定标准 → 规则型SOP候选
 - 评审会/讨论会/沟通会 + 独立会议纪要 → 会议SOP候选
 - 移交/交接/传递 + 跨部门 → 交接SOP候选
 - 投标/标书/招标/资质/备案 → 专项SOP候选
 b. 对每种类型：如候选数>0但蓝图中该类型SOP数=0 → 🚫 阻断
 c. 输出类型完备性报告：
 「✅ 操作性SOP: {N1}个 | 任务框架型: {N2}个 | 条件分支型: {N3}个 | 规则型: {NR}个 | 会议: {N4}个 | 交接: {N5}个 | 专项: {N6}个」
 d. 当某类型候选数=0时，必须输出排除理由
 不通过处理：补充缺失类型的SOP → 重新校验
 📌 此门禁防止蓝图规划仅关注操作性SOP而遗漏审批规则/条件分支/会议/交接等类型
G9: 模板业务线差异化完备性校验（阻断级）
 校验规则：
 a. 从Step 1-2提取的业务线清单中，识别需差异化模板的业务线数B
 b. 从Step 2-2识别的SOP中，扫描所有“方案/合同/评估/报告”类交付物环节
 c. 对每个差异化环节，检查模板蓝图中是否存在B个业务线变体模板
 d. 如某环节应有B个变体但实际仅有1个通用模板 → 🚫 阻断
 e. 输出差异化模板展开报告：
 「✅ 差异化环节数: {K} | 业务线数: {B} | 应展开变体模板数: {K×B} | 实际变体模板数: {V}」
 不通过处理：按业务线展开缺失的变体模板 → 重新校验
 📌 此门禁防止将应差异化的业务线模板合并为单一通用模板

通过条件：G1~G9 全部 ✅
不通过处理：调整蓝图 → 重新校验（≤3次）
```

### Step 4: 蓝图谱写与锁定

```
写入以下文件到知识库：
 ├── {knowledgeBasePath}/SOP蓝图清单.json ← 核心锁定文件
 ├── {knowledgeBasePath}/模板蓝图清单.json ← 核心锁定文件
 ├── {knowledgeBasePath}/RACI矩阵草案.md ← 参考文件
 └── {knowledgeBasePath}/标准参考深度基准.json （当standardRefPath有效时）

写入前强制执行数据一致性校验（G7）：
 ✅ totalCount == sopList.length
 ✅ breakdown各类型之和 == totalCount
 ✅ generationOrder.length == sopList.length
 ✅ 所有outputTemplates引用在templateList中存在
 ✅ 所有relatedSop引用在sopList中存在

写入后立即锁定：
 🚫 后续所有轮次的Q1生成均以蓝图为唯一依据
 🚫 不允许LLM自行增减SOP/模板
 🚫 任何新增/删除SOP的操作必须通过“蓝图变更请求”（需人工审批）
 🚫 内容深度基准文件锁定后，后续轮次不得降低内容深度要求
```

### Step 5: Phase Gate -1 确认

```
输出蓝图谱写确认卡片：

📋 Phase -1 蓝图预规划完成
 SOP蓝图：{N}个（操作性SOP {B}个 + 任务框架型SOP {R}个 + 条件分支型SOP {C}个 + 规则型SOP {RB}个 + 总纲 {F}个）
 模板蓝图：{M}个（基础模板 {BM}个 + 业务线变体 {VM}个）
 RACI矩阵：{角色数}角色 × {SOP数}SOP
 内容深度基准：{refSOPCount}个参考SOP + {refTMPCount}个参考模板已解析
 Phase Gate -1：✅ G1~G9 全部通过
 锁定状态：🔒 已锁定（后续轮次不可修改）

自动流转 → Phase 1 Q1
```

## 蓝图锁定规则（B1~B5）

```
规则 B1：蓝图不可变性
 一旦 SOP蓝图清单.json 写入知识库，其内容在后续所有轮次中不可修改。
 任何新增/删除SOP的操作必须通过“蓝图变更请求”（需人工审批）。

规则 B2：SOP数量下限约束
 实际生成的SOP数量 ≥ 蓝图中的SOP数量。
 如果实际数量 < 蓝图数量 → 触发阻断 → 返回Q1补全。

规则 B3：模板数量绑定
 实际生成的模板数量 = 蓝图中的模板数量。
 不等 → 触发阻断 → 返回Q1补全。

规则 B4：编号一致性
 实际生成的SOP/模板编号必须与蓝图中的编号完全一致。
 编号不一致 → 触发阻断 → 返回Q1重命名。

规则 B5：内容深度下限约束
 实际生成的SOP/模板内容深度 ≥ 蓝图中的contentDepthBaseline × 0.8。
 包括：章节数、业务规则数、例外处理数、质控节点数、模板字段数。
 低于下限 → 触发阻断 → 返回Q1补充内容。
```

## 蓝图文件格式

### SOP蓝图清单.json

```json
{
 "blueprintVersion": "2.0",
 "processName": "{processName参数值}",
 "processCode": "{processCode参数值}",
 "createDate": "{YYYY-MM-DD}",
 "locked": true,
 "totalSOPs": "必须等于sopList.length",
 "blueprintBasis": {
 "orgHandbook": "{岗位职能手册文件名}",
 "serviceHandbook": "{服务类目手册文件名}",
 "standardReference": "{standardRefPath文件名或null}",
 "businessCycle": "{从手册提取的业务闭环描述}",
 "serviceTypes": ["从服务类目手册动态提取的业务线列表"]
 },
 "sopList": [
 {
 "sopId": "HY-G-{processCode}-SOP-{NNN}",
 "sopName": "{SOP名称}",
 "version": "{从标准参考继承的版本号}",
 "type": "操作性SOP | 任务框架型SOP | 条件分支型SOP | 规则型SOP | 总纲",
 "description": "{SOP描述}",
 "primaryRoles": ["从岗位手册提取的角色代码"],
 "relatedDepartments": ["从岗位手册提取的部门名称"],
 "serviceTypeCoverage": ["从服务类目手册提取的业务线代码"],
 "upstream": ["{sopId}"] ,
 "downstream": ["{sopId}"],
 "contentDepthBaseline": {
 "refSectionCount": 14,
 "refBusinessRuleCount": 10,
 "refExceptionCount": 18,
 "refKCPCount": 10
 },
 "priority": "P0 | P1 | P2"
 }
 ],
 "sopDependencyGraph": {},
 "roleCoverage": {},
 "departmentCoverage": [],
 "generationOrder": ["按依赖关系排序的sopId列表"],
 "breakdown": {
 "operational": "操作性SOP数量",
 "taskFramework": "任务框架型SOP数量",
 "conditionalBranch": "条件分支型SOP数量",
 "ruleBased": "规则型SOP数量",
 "master": "总纲数量（通常为1）"
 }
 // 📌 breakdown各字段之和必须等于totalSOPs
 // 📌 当无规则型SOP时，ruleBased=0（字段仍需保留）
}
```

> 🚫 **数据一致性强制要求**：`totalSOPs` 必须等于 `sopList.length`，`breakdown` 各字段之和必须等于 `totalSOPs`，`generationOrder.length` 必须等于 `sopList.length`。

### 模板蓝图清单.json

```json
{
 "blueprintVersion": "2.0",
 "processName": "{processName参数值}",
 "processCode": "{processCode参数值}",
 "createDate": "{YYYY-MM-DD}",
 "locked": true,
 "totalTemplates": "必须等于templateList.length",
 "templateList": [
 {
 "templateId": "HY-G-{processCode}-TMP-{NNN}",
 "templateName": "{模板名称，优先继承标准参考}",
 "version": "{从标准参考继承的版本号}",
 "relatedSOP": "HY-G-{processCode}-SOP-{NNN}",
 "description": "{模板描述}",
 "primaryUsers": ["从岗位手册提取的角色代码"],
 "serviceType": null | "{serviceTypeCode}",
 "fieldCount": "从标准参考提取或按T1-T5推导",
 "contentDepthBaseline": {
 "refFieldCount": 25,
 "refSectionCount": 5
 }
 }
 ],
 "templateSOPMapping": {}
}
```

> 🚫 **数据一致性强制要求**：`totalTemplates` 必须等于 `templateList.length`。每个 `relatedSOP` 必须在SOP蓝图清单中存在。

## 输出路径

1. `{knowledgeBasePath}/SOP蓝图清单.json`
2. `{knowledgeBasePath}/模板蓝图清单.json`
3. `{knowledgeBasePath}/RACI矩阵草案.md`
4. `{knowledgeBasePath}/标准参考深度基准.json`（当standardRefPath有效时）

## 与其他技能的协作

| 技能 | 协作方式 |
|:-----|:---------|
| sop-generation-rules | Q1 Step 5读取蓝图清单，生成指令中引用蓝图；读取标准参考深度基准为内容深度下限 |
| sop-generation-reference | Q1 Step 6按蓝图生成SOP，前置校验PV-1比对蓝图；内容覆盖度对比Gate-20引用深度基准 |
| quality-scoring | Q1 Step 8评分时，一致性维度检查§9.2↔蓝图对齐；内容深度维度引用深度基准 |
| evaluation-steps | Q2 Step 13验证时，A3检查索引↔蓝图一致性；A5检查内容深度≥基准80% |
| sop-template-generator | 模板生成时引用模板蓝图清单中的fieldCount和contentDepthBaseline |

## 参数化检查清单（🚫 硬编码禁止）

| # | 检查项 | 正确做法 | 错误做法 |
|:-:|:---------|:---------|:---------|
| HC-1 | 流程阶段 | 从岗位手册/标准参考动态提取 | 硬编码"Lead/Opportunity/Solution..." |
| HC-2 | 角色代码 | 从岗位职能手册提取 | 硬编码"AR-01/MG-03..." |
| HC-3 | 业务线代码 | 从服务类目手册提取 | 硬编码"C/R/I/T/S" |
| HC-4 | 流程代码 | 从processCode参数注入 | 硬编码"LTC" |
| HC-5 | 版本号 | 从标准参考继承 | 统一写"V1.0" |
| HC-6 | 部门名称 | 从岗位职能手册提取 | 硬编码具体部门名 |
| HC-7 | 服务类别描述 | 从服务类目手册提取 | 自行编造类别描述 |
| HC-8 | SOP数量 | 从标准参考/手册动态推导 | 硬编码"≥10个" |
| HC-9 | 阶段数量 | 从输入材料动态确定 | 硬编码"≥3个" |

## 规范依据

- SOP编排专家优化方案 第二部分 §2.3
- 第三部分 §3.1 Phase -1 流程定义
- 第六部分 §6.1 蓝图约束规则 B1~B5
- SOP-TMP内容差异分析及Skill优化方案
- SOP生成规范 §18（业务完整性生成约束）、§19（跨SOP一致性约束）
- SOP验证规范 §H-§J（字段完整性检查项标准）

## 文件命名规范

```
SOP文件命名格式：
 HY-G-{processCode}-SOP-{NNN} {SOP名称}（V{version}）.md
 示例：HY-G-LTC-SOP-001 线索管理SOP（V6.0）.md

模板文件命名格式：
 HY-G-{processCode}-TMP-{NNN} {模板名称}（V{version}）.md
 示例：HY-G-LTC-TMP-006 解决方案建议书模板（C类）（V2.0）.md

命名规则：
 - 前缀 HY-G-{processCode}- 为强制前缀，禁止省略
 - 版本号使用中文括号（V{version}）
 - 编号三位数补零（000, 001, 011, 013）
 - 子编号使用连字符（如TMP-023-01）
 🚫 禁止使用无前缀命名（如"SOP-001 线索管理.md"）
 🚫 禁止省略版本号
```

## 版本继承规则

```
🚨 核心原则：版本号独立性 🚨
- 每个SOP/模板的版本号必须基于其自身的修订历史独立确定
- 禁止跨SOP统一版本号（如将所有SOP统一设为V6.0）
- 版本号反映的是文件自身的迭代演进，不是全局统一基准

版本号确定优先级（从高到低）：

1. **最高优先级**：`anchor.versionBaselineExtended` 中各文件的独立版本号
 - 当 versionBaselineExtended 中存在对应文件的版本号时 → 继承该版本号并按修订幅度递增
 - 示例：versionBaselineExtended.sopVersions["SOP-001"] = "V5.2" → 本次生成用 V5.3 或 V6.0

2. **回退优先级**：标准参考文件继承（当standardRefPath有效但versionBaselineExtended无对应条目时）：
 - 从参考文件名中解析版本号（如"（V10.0）"→ version="10.0"）
 - 每个SOP必须从标准参考中继承其同编号文件的版本号并递增
 - 示例：标准参考 SOP-001=V5.2 → 本次生成 SOP-001=V5.3或V6.0
 - 示例：标准参考中无SOP-013 → 本次生成 SOP-013=V1.0（新建）

3. **无标准参考时**（当standardRefPath无效且versionBaselineExtended无记录时）：
 - 每个SOP/模板均为全新创建，初始版本号为 **V1.0**
 - 总纲（SOP-000）若无参考，初始版本号为 V1.0
 - 📌 禁止在无参考时将业务SOP默认设为V6.0或其他高版本号
 - 🚫 已废除：~~"业务SOP版本 = 6.0（初始版本）"~~ — 此规则导致所有SOP统一V6.0

4. 版本一致性约束：
 - 同一SOP在蓝图、生成指令、实际文件中的版本号必须一致
 - 禁止在生成过程中自行变更版本号
 - 版本号必须在文件名和§1文档信息中保持一致

5. 版本号递增规则：
 - 基于已有SOP迭代生成时，继承原SOP最新版本号并按修订幅度递增
 - 小幅修订（文字修正、字段调整）→ 次版本号+1（如V5.2→V5.3）
 - 重大重构（章节调整、流程变更）→ 主版本号+1（如V5.x→V6.0）
 - 全新创建（标准参考中无对应SOP）→ V1.0

6. 版本号校验：
 - 🚨 蓝图规划完成后检查：是否有≥3个SOP使用完全相同版本号 → 若是，逐一说明版本来源
 - 🚨 新建SOP检查：标准参考中无对应的SOP是否使用了V1.0 → 若不是，强制修正
```

## 自主规划模式（当standardRefPath无效时）

```
🚨 核心原则：无参考标准 ≠ 降低质量。大多数流程没有“完整版”参考，
系统必须在无参考时也能自主生成完整、高质量的蓝图。

自主规划执行路径：

1. SOP识别：D1~D7规则 + B-EX1~B-EX5排除规则（与有参考时相同）
2. 模板推导：T1~T5 + T7深度分析（逐SOP逐环节扫描，禁止浅层分析）
3. 内容深度：使用Step 0-5内在深度标准（不依赖外部参考）
4. 版本号：所有SOP/模板均为新建，初始版本号为V1.0（总纲SOP-000亦为V1.0）
 🚫 已废除：~~"总纲V10.0 / SOP V6.0 / TMP V2.0"~~ — 此规则导致跨SOP版本统一
5. G6门禁：使用内在深度标准替代参考对比（仍然强制执行）
6. G7门禁：强制执行（数据一致性始终保证）

模板深度分析强化规则（无参考时的关键补偿机制）：
 FOR EACH sop IN sopList:
   // 第一层：从SOP描述中识别所有可填写文档
   扫描sop.description中的关键词：
   - "表""单""记录""报告""确认""申请""清单""台账" → 每个=1个模板
   - "方案""建议书""草案""文本" → 每个=1个模板（可能需业务线变体）
   - "审批""审查""评审" → 额外+1个审批表/配置表
   - "会议""评审会" → 额外+1个会议纪要+1个评审结论表
   - "基准价""配置""规则" → 额外+1个配置类模板
   // 第二层：业务线变体展开
   IF 模板属于"方案/合同/协议/评估"类:
     按业务线数(B)展开为B个独立模板
   // 第三层：上下游衍射
   IF SOP有downstream且衍射SOP需要交接确认:
     额外+1个交接清单/确认单模板

📌 重要提示：即使用户声称“无标准参考”，仍应检查以下路径是否存在参考文件：
 - 知识库同级目录中是否有“完整版”“参考”“标准”等关键词的文件夹
 - 用户提供的岗位手册/服务手册中是否引用了已发布的SOP文件
 如发现潜在参考文件，应提示用户确认是否作为standardRefPath使用
```

## 常见错误与防御

| # | 常见错误 | 根因 | 防御措施 |
|:-:|:---------|:-----|:---------|
| E-1 | totalSOPs与实际列表不一致 | 元数据手动填写后未同步 | G7门禁强制校验 |
| E-2 | 服务类型描述与手册不符 | LLM自行编造而非原文提取 | Step 1-4原文校验 |
| E-3 | 模板数量严重不足 | 未逐SOP逐章节分析模板需求 | T1-T7规则 + G4校验 |
| E-4 | 版本号全部V1.0 | 未从standardRef继承 | 版本继承规则 + HC-5检查 |
| E-5 | 流程Owner角色错位 | LLM推测而非从手册提取 | 强制从岗位手册提取流程Owner |
| E-6 | S类业务处理错误 | 未识别"另行构建体系"标记 | B-EX4排除规则 |
| E-7 | SOP内容仅有框架无业务规则 | 无内容深度约束 | G6门禁（内在深度标准）+ B5锁定规则 |
| E-8 | 业务线变体模板被合并 | 为省事合并为"通用版" | T-EXP3变体数量校验 |
| E-9 | 阶段名称硬编码 | 复制LTC示例未修改 | Step 2-1参数化 + HC-1检查 |
| E-10 | 缺失SOP无模板配套 | 未逐SOP分析模板需求 | G7-c outputTemplates引用校验（规则型SOP除外） |
| E-11 | 不同角色活动被合并为1个SOP | “同阶段=同SOP”的错误等式 | MP-1反合并规则 + Step 2-2-AUDIT审计 |
| E-12 | 评审会/投标/成本核算SOP被遗漏 | 未执行D6特征模式匹配 | MP-3/MP-4/MP-5 + 审计3/4/5 |
| E-13 | 每阶段仅生成1个SOP | G1公式误解为“每阶段=1” | G1新公式：每阶段SOP数≥角色数 |
| E-14 | 废弃SOP被误创建为新类型 | 未检测参考标准中的废弃/占位条目 | Rule D8废弃检测 + 前置过滤 |