---
name: sop-generation-rules
description: "SOP生成核心规则合集（V2.1.0防幻觉增强版）— SOP结构化拆解引擎+生成步骤(Step3-6+Phase Gate)+格式规范(14章金标准)+E系列约束+V2.0增强+V14.0防幻觉指令体系(4项强制校验:SVC-01~04+AH-1~4+上下文隔离+自检报告)。新增: 规则13(服务类目→SOP映射完整性·130项100%覆盖)+规则14(岗位职能→SOP映射完整性·46岗位≥85%覆盖)+DC-6路径F(服务类目驱动)+DC-9(服务类目覆盖率校验)+DC-10(岗位覆盖率校验)。已拆出: sop-rules-field-coverage(覆盖率) + sop-rules-anchor(锚点V3.1)。"
version: 2.1.0
author: MG-01 SOP编排专家
category: SOP生成
internal: true
triggers:
 - SOP生成规则
 - sop-generation-rules
keywords:
 - sop
 - generation
 - rules
 - 生成
 - 规则
---

# sop-generation-rules — SOP生成全量规则合集

## 触发条件

由 MG-01 SOP编排专家 `q1-step-02a~02d`（4个分片生成步骤）通过 `linkedSkillNames` 注入。仅在这些步骤执行时可用。

## 核心使命

合并自 6 个独立 skill（sop-field-coverage + global-consistency-anchor + sop-decomposition-rules + sop-generation-steps + sop-template-selection-engine + sop-format-spec），提供 Q1 SOP 文档包生成所需的全部规则。

## 运营参数配置引用

本文件的**业务规则**（字段覆盖率/步骤卡格式/DC规则/Phase A~E/C-01~C-08等）为权威定义。
**引擎级运营参数**（超时/重试/文件验证/健康度/目录结构）集中定义在 `sop-system-config` SKILL 中，调参时修改该配置即可。

## Instructions

━━━━━━━━━━ 已拆分子模块引用说明 ━━━━━━━━━━

> 📦 **本文件已拆分**（性能优化）：
> - `sop-rules-field-coverage`：SOP字段覆盖率分析（48项检查基准）→ 仅在 q1-step-05 和 Q2 验证步骤注入
> - `sop-rules-anchor`：全局一致性锚点V3.1（22+字段Schema）→ 仅在 02a-sop000 和 Q2 验证步骤注入
> - 本文件保留：SOP结构化拆解引擎 + 生成步骤规则 + 格式规范 + E系列约束 + V2.0增强

🚫 生成步骤（02b/02c-2）不再加载锚点和覆盖率模块，减少约520行上下文注入。

━━━━━━━━━━ sop-decomposition-rules ━━━━━━━━━━

# sop-decomposition-rules — SOP结构化拆解引擎

## 触发条件

由 MG-01 SOP编排专家通过 `linkedSkillNames` 自动注入。在 workflow 执行阶段全程可用。

## 核心使命

SOP结构化拆解规则体系 — RACI角色职责矩阵提取(Step 2a)、子活动分解(Step 2a-PLUS)、业务线清单提取(Step 2b)、知识库深度扫描(Step 2c-PRE)、结构化SOP拆解(Step 2c)、标准参考对齐(Step 2c-PLUS)、粒度检验(Step 2c-PLUS-2)、完整性自检(Step 2d)。

## 详细规则

🚨🚨 **SOP结构化拆解引擎** 🚨🚨

**在 Step 2 拆解完成后、进入 Step 3 之前，必须执行以下结构化拆解验证。未通过验证禁止进入 Step 3。
**Step 2a：RACI角色职责矩阵提取（强制·从岗位职能手册提取）
从岗位职能手册中提取所有参与本流程的角色，生成 RACI 矩阵：

| 角色代码 | 角色名称 | 参与环节 | Accountable(A)环节 | 主责判定依据 |
|:---------|:---------|:---------|:-------------------|:-------------|
| {code} | {name} | {环节列表} | {A责环节} | 从岗位说明书/流程映射表提取 |

🚫 禁止跳过此步骤：必须实际读取岗位职能手册并提取角色，禁止凭记忆列举。
📌 输出格式：在聊天界面输出完整 RACI 矩阵表格。

**Step 2a-PLUS：子活动分解
对 RACI 矩阵中每个 Stage/Phase，必须进一步分解为子活动：
- 扫描知识库中该 Stage 相关的岗位流程映射文件
- 识别所有具有独立 输入/输出/执行角色/判断标准 的子活动
- 每个子活动单独作为 RACI 矩阵的一行
- 标注子活动之间的前后依赖关系

子活动拆分判定标准（满足任一即须拆分）：
- 两个活动的"执行角色"不同 → 必须拆分为独立子活动
- 两个活动的"输入物"来自不同的上游 → 必须拆分
- 两个活动的"输出物"服务于不同的下游 → 必须拆分
- 两个活动需要不同的专业技能/资质 → 必须拆分
- 两个活动的"质控标准/验收条件"不同 → 必须拆分

🚫 常见过度合并错误模式（必须避免）：
- 将"方案设计"与"成本核算"合并 → 违反角色专属性（设计者≠核算者）
- 将"评审会议"嵌入操作性SOP → 违反输出独立性（评审结论独立服务于多个下游）
- 将"审批规则/任务框架型SOP"嵌入操作性SOP的§13 → 违反质量独立性（审批规则有独立的routing/threshold/escalation体系，由工作流引擎消费而非Agent执行）
- 将"合同起草"与"合同审批"合并 → 违反角色专属性（起草者≠审批者）
- 将"项目启动"省略 → 违反流程完整性（签约到交付的交接环节不可缺失）
- 将"条件分支型活动"（如投标标书编制）省略或合并到主流程SOP → 违反条件独立性（仅在特定条件满足时启动，有独立触发条件和回归节点，必须独立为条件分支型SOP）

📌 输出格式：在聊天界面输出增强版 RACI 矩阵（含子活动分解 + 流程链映射）。

🚨 **processCode提取规则（HC-7修复·Phase 0信息收集阶段执行）** 🚨
流程代码（processCode）必须从以下来源动态提取，禁止硬编码具体流程代码：
```
processCode提取优先级：
1. 用户输入中明确指定的流程代码（如启动SOP表格中的流程名称缩写）
2. 标准参考文件命名中的流程代码段（如 HY-G-{processCode}-SOP-xxx 中提取）
3. 知识库中流程名称的缩写（由LLM推导，需用户确认）

写入位置：globalConsistencyAnchor.processCode
生成阶段约束：
- 所有文件命名强制使用 {processCode} 占位符（如 HY-G-{processCode}-SOP-001）
- 禁止在instruction或生成内容中硬编码具体流程代码
- 如无法提取 → 阻断，要求用户提供流程代码
```

**Step 2b：业务线清单提取（强制·从服务类目手册提取·HC-3参数化）**
从服务类目手册中动态提取所有业务线及其差异化要求（禁止硬编码具体业务线代码）：

| 业务线代码 | 业务线名称 | 差异化要求（从手册提取） | 是否需要差异化模板 |
|:-----------|:-----------|:------------------------|:------------------:|
| {code} | {name} | {从手册中摘录的合规/流程/文档差异化要求} | 是/否 |

🚫 禁止跳过此步骤：必须实际读取服务类目手册。
📌 关键判定：如果手册中某业务线有独立的合规要求、特殊流程节点或差异化文档要求，则该业务线需要差异化模板。

**Step 2c-PRE：知识库流程深度扫描
在 RACI 提取完成后、SOP 拆解前，执行知识库深度扫描（手册驱动SOP拆解算法）：

**第一阶段：手册结构扫描
1. 扫描岗位职能手册中所有"岗位流程映射/业务流程/操作步骤"类文件
2. 统计每个文件中描述的独立操作步骤/活动数量（按章节标题/编号步骤计数）
3. 汇总所有文件的独立步骤总数 → 记为 rawStepCount

**第二阶段：关键节点识别与分类
4. 对每个识别出的步骤/活动，按以下关键词分类：
 - 流程边界类（含"流程止于""另行构建体系""由XX流程承接""移交XX流程""独立体系"模式）→ 标记为"流程边界"，不纳入SOP候选
 📌 边界类活动应在SOP-000 §11上下游衔接中标注接口关系
 - 任务框架类（含"工作流引擎消费""审批路由配置""分级规则""超时升级""驳回逆流程"模式，且不含具体操作步骤）→ 标记为"任务框架型SOP候选"
 - 条件分支类（含"仅在...时启动/触发""如需""条件分支""按需执行""条件满足时"模式）→ 标记为"条件分支型SOP候选"（优先级高于专项类，因为条件分支活动可能同时匹配专项关键词，但条件触发特性更重要）
 - 审批类（含"审批""评审""审核""签批""决策""判断"关键词，且涉及分级路由/审批链配置）→ 标记为"审批规则SOP候选"（任务框架型）
 - 交接类（含"移交""交接""传递""下发""启动""交接确认"关键词）→ 标记为"交接SOP候选"
 - 会议类（含"会议""评审会""讨论会""沟通会"关键词）→ 标记为"会议SOP候选"
 - 专项类（含"投标""标书""招标""资质""备案""许可证"关键词，且未被条件分支类匹配）→ 标记为"专项SOP候选"
 - 业务线变体类（含"C类""R类""I类""T类""S类"变体标记，且流程步骤与其他业务线共享相同框架）→ 不标记为独立SOP，而是标记为"模板变体候选"
 📌 业务线变体判定：如果多个业务线共享相同的流程步骤框架（如项目型四阶段），仅表单/模板内容因业务线不同而异 → 不创建独立SOP，保持单一SOP + 多模板变体
 - 其余 → 标记为"操作性SOP候选"

**第三阶段：交叉验证与补充
5. 将分类结果与 RACI 矩阵交叉验证
6. 如分类后的节点数 > RACI 矩阵行数 → 补充缺失的子活动到 RACI 矩阵
7. 计算知识库驱动期望SOP数：
 expectMin_KB = 1(总纲) + 操作性SOP候选数 + 审批规则SOP候选数（任务框架型） + 交接SOP候选数 + 会议SOP候选数 + 专项SOP候选数 + 条件分支型SOP候选数 + 任务框架型SOP候选数 + 规则型SOP候选数 + 支撑流程数
 🚫 不包含流程边界类活动（已排除）
 🚫 不包含业务线变体类活动（通过模板变体处理，不独立为SOP）

输出：
- 增强版 RACI 矩阵（含子活动分解 + 流程链映射 + 节点分类标注）
- 知识库驱动期望SOP数 expectMin_KB（传递给 DC-6 使用）

🚨 **Step 2c-PRE-PLUS：知识库预填充完整性阻断** 🚨
在 Step 2c-PRE 完成后、进入 Step 2c 之前，必须校验知识库（知识梳理.md）的预填充完整性：

**必填项完整性检查（阻断级）**：
┌─────────────────────────────────────────────────────────────┐
│ 📋 知识库预填充完整性检查表 │
│ │
│ 检查项 1：流程阶段划分 │
│ - 要求：阶段数 ≥ standardReference中定义的阶段数（当standardReferencePath非空）；│
│   否则 ≥ 知识库中识别的阶段数；兜底 ≥ 3 个阶段。│
│   且每阶段关联至少 1 个 SOP 名称 │
│ - 实际：{检查知识库中的阶段定义} │
│ - 判定：✅ 达标 / ❌ 不达标 │
│ │
│ 检查项 2：角色体系 │
│ - 要求：≥ 5 个核心角色，含角色代码（从岗位职能手册动态提取的角色编码前缀+序号格式）│
│ - 实际：{检查知识库中的角色定义} │
│ - 判定：✅ 达标 / ❌ 不达标 │
│ │
│ 检查项 3：服务类目结构 │
│ - 要求：从服务类目手册中动态提取的业务线列表完整枚举（禁止硬编码具体业务线代码）│
│ - 实际：{检查知识库中的类目结构，与服务类目手册提取结果比对} │
│ - 判定：✅ 达标（覆盖率≥80%）/ ❌ 不达标 │
│ │
│ 检查项 4：关键规则积累 │
│ - 要求：至少包含 1 条业务规则（如成本底线/审批规则等） │
│ - 实际：{检查知识库中的规则记录} │
│ - 判定：✅ 达标 / ❌ 不达标 │
└─────────────────────────────────────────────────────────────┘

**判定规则**：
- 全部满足 → 输出 "✅ 知识库预填充完整性检查通过"，进入 Step 2c
- 任一不满足 → 🚫 **强制阻断**，输出以下提示：
 ```
 🚫 知识库预填充不完整，无法进入 SOP 拆解阶段
 
 缺失项：
 {列出不满足的检查项}
 
 建议操作：
 1. 返回 Phase 0（知识梳理阶段），补充缺失的知识内容
 2. 确保知识梳理.md 中包含：
 - 流程阶段划分（至少3个阶段）
 - 角色体系（至少5个角色）
 - 服务类目结构（5类业务）
 - 关键业务规则（至少1条）
 3. 完成后再重新执行 Q1 生成
 ```

📌 此检查防止知识库为空时LLM缺乏业务上下文导致SOP拆解粒度过粗。
📌 基于排查报告根因2：003知识库为空导致LLM无法准确识别独立业务环节。

**Step 2c：结构化SOP拆解（基于Step 2a/2b结果·强制规则）
基于 Step 2a 的 RACI 矩阵和 Step 2b 的业务线清单，按以下强制规则逐一生成 SOP 条目：

规则1（Accountable角色 → 独立SOP）：
 for each 环节 in RACI矩阵:
 if 该环节有独立的Accountable角色:
 生成 1 个操作性SOP

规则2（审批节点 → 独立审批规则SOP）：
 for each 审批节点（名称含"审批"/"评审"/"审核"/"签批"的环节）:
 生成 1 个独立审批规则SOP

规则3（支撑流程 → 独立支撑SOP）：
 for each 支撑流程（市场活动/培训/引流等非主线环节）:
 生成 1 个独立支撑流程SOP

规则4（任务框架 → 独立任务框架型SOP）：
 for each 活动 in 手册/知识库中识别的活动:
 if 满足以下≥2个特征 → 独立为任务框架型SOP（由工作流引擎消费，非Agent执行）：
 a. 定义审批路由/分级规则/审批链配置（不含具体业务操作步骤）
 b. 由系统工作流引擎消费（而非由角色手动执行）
 c. 包含超时升级/驳回逆流程/会签规则等工作流配置
 d. 被多个操作性SOP引用（作为公共规则而非独立操作步骤）
 📌 任务框架型SOP不包含操作步骤，仅定义规则和配置
 📌 典型示例：商机审批规则SOP、合同审批规则SOP

规则4.1（条件分支 → 独立条件分支型SOP）：
 for each 活动 in 手册/知识库中识别的活动:
 if 满足以下≥1个特征 → 独立为条件分支型操作性SOP：
 a. 仅在特定条件满足时启动（含"仅在...时""如需""条件触发""按需执行"模式）
 b. 有独立的触发条件和执行路径（不同于主流程的必经步骤）
 c. 完成后回归主流程的某个节点（而非直接结束流程）
 📌 条件分支型SOP是操作性SOP的子类型，有具体操作步骤，但非必经路径
 📌 典型示例：投标标书编制SOP（仅在客户要求投标时启动，完成后进入方案评审会）

规则5（🚫禁止合并）：
 即使两个SOP的Accountable角色相同，只要业务环节不同，必须拆分为独立SOP。
 ❌ 禁止将"方案设计+成本核算+报价+评审会"合并为1个SOP。
 ❌ 禁止将"商机审批+合同审批"合并为1个SOP。

🚨 **规则5.1：显式活动枚举** 🚨
在应用规则1~5之前，必须先对手册中的流程进行显式活动枚举，并输出**格式化的活动枚举清单**：

**Step 5.1-A：扫描岗位职能手册
 扫描岗位职能手册中与该流程相关的所有角色描述

**Step 5.1-B：提取独立工作活动
 提取每个角色的所有独立工作活动（每个有独立输入/输出/交付物的活动计为1个）

**Step 5.1-C：合并去重
 合并去重后，输出完整活动清单（含活动名称、所属角色、输入物、输出物、是否涉及审批/会议/交接）

**Step 5.1-D：粒度四要素评分（强制结构化输出）
 对清单中每个活动，执行粒度四要素评分：
 ┌─────────────────────────────────────────────────────────────┐
 │ 📋 活动枚举清单（必须在承诺清单前输出·阻断级） │
 │ │
 │ | 序号 | 活动名称 | 所属角色 | 四要素评分 | SOP类型 | 独立性判定 |
 │ |------|---------|---------|-----------|---------|-----------|
 │ | 1 | 线索管理 | 市场专员 | 4/4满足 | 操作性SOP | ✅ 必须独立 |
 │ | 2 | 商机管理 | 销售经理 | 4/4满足 | 操作性SOP | ✅ 必须独立 |
 │ | 3 | 商务谈判 | 销售经理 | 3/4满足 | 操作性SOP | ⚠️ 强烈建议独立 |
 │ | 4 | 方案设计 | 售前顾问 | 4/4满足 | 操作性SOP | ✅ 必须独立 |
 │ | 5 | 成本核算 | 商务专员 | 4/4满足 | 操作性SOP | ✅ 必须独立 |
 │ | 6 | 报价管理 | 商务专员 | 4/4满足 | 操作性SOP | ✅ 必须独立 |
 │ | 7 | 方案评审会 | 评审委员会 | 3/4满足 | 会议SOP | ⚠️ 强烈建议独立 |
 │ | 8 | 合同起草 | 法务专员 | 4/4满足 | 操作性SOP | ✅ 必须独立 |
 │ | 9 | 商机审批 | 审批链 | 3/4满足 | 任务框架型SOP | ⚠️ 强烈建议独立 |
 │ | 10 | 合同审批 | 审批链 | 3/4满足 | 任务框架型SOP | ⚠️ 强烈建议独立 |
 │ | 11 | 项目启动 | 项目经理 | 4/4满足 | 交接SOP | ✅ 必须独立 |
 │ | 12 | 回款管理 | 财务专员 | 4/4满足 | 操作性SOP | ✅ 必须独立 |
 │ | 13 | 投标管理 | 投标专员 | 3/4满足 | 条件分支型SOP | ⚠️ 强烈建议独立 |
 │ | 14 | 市场活动 | 市场专员 | 3/4满足 | 支撑SOP | ⚠️ 强烈建议独立 |
 │ │
 │ 枚举总数：{N} 个活动（从手册/标准参考动态提取） │
 │ 其中必须独立SOP：{X} 个（4/4满足） │
 │ 其中强烈建议独立SOP：{Y} 个（3/4满足） │
 │ 预期SOP总数：≥ expectMin 个（含总纲，由DC-6四路径计算确定） │
 └─────────────────────────────────────────────────────────────┘
 📌 上表为输出格式示例，具体活动名称从手册/标准参考动态提取，禁止硬编码。

**Step 5.1-E：SOP分类映射
 对清单中每个活动，应用规则1~10分类为：操作性SOP / 任务框架型SOP（审批规则） / 会议SOP / 交接SOP / 专项SOP / 条件分支型SOP / 规则型SOP / 支撑SOP
 📌 任务框架型SOP：由工作流引擎消费的审批路由/规则配置（规则4）
 📌 条件分支型SOP：仅在特定条件满足时启动的操作性活动（规则4.1）
 📌 规则型SOP：定义合规审查/业务规则清单，有操作步骤但聚焦规则执行

**四要素评分标准**：
 ① 输入独立性：该活动是否有明确的、可独立交付的输入物？
 ② 输出独立性：该活动的输出物是否被不同的下游独立消费？
 ③ 角色专属性：该活动是否需要特定的专业技能/资质？
 ④ 质量独立性：该活动是否有独立的质控标准和验收条件？

**独立性判定规则**：
 - 4/4 满足 → ✅ 必须独立SOP
 - 3/4 满足 → ⚠️ 强烈建议独立SOP
 - ≤2/4 满足 → 可合并到相邻SOP

**📌 关键约束**：
 - 活动清单中的每个"必须独立"和"强烈建议独立"活动必须对应至少1个SOP，禁止遗漏
 - 🚫 禁止将"必须独立"的活动合并到同一SOP
 - 🚫 禁止在活动枚举阶段就预设SOP数量不应太多的先验判断
 - 🚫 禁止跳过活动枚举清单的结构化输出

**📌 常见易遗漏活动类型（必须识别）**：
 - 方案评审会（会议类）
 - 合同起草（独立操作性活动，有独立交付物=合同草案）
 - 项目启动/交接（交接类）
 - 审批规则维护（任务框架型 — 由工作流引擎消费的审批路由/规则配置）
 - 投标/标书编制（条件分支型 — 仅在客户要求投标时启动，有独立触发条件和回归节点）
 - 成本核算（独立操作性活动，有独立输出物=成本测算表）
 - 条件分支活动（条件分支型 — 含"仅在...时""如需""条件触发"模式的活动）
 - 工作流配置/审批路由（任务框架型 — 被多个操作性SOP引用的公共规则）

规则6（业务环节独立性校验·修复方向B）：
 for each Stage/Phase in 流程主链路:
 识别该 Stage 内的独立子环节（如：方案设计/成本核算/报价/评审会）
 if 子环节数 > 1:
 每个子环节必须独立成 1 个操作性SOP
 🚫 禁止单个SOP覆盖超过 2 个独立子环节
 子环节识别规则：
 - 有独立的输入/输出物
 - 有独立的执行角色
 - 可独立交付业务价值
 - 在知识库/标准参考中有独立描述

规则7（审批节点独立拆分强制·修复方向B）：
 for each 决策节点 in RACI矩阵:
 if 该节点需要独立审批决策（含"审批"/"评审"/"审核"/"签批"/"决策"关键词）:
 必须生成 1 个独立审批规则SOP
 🚫 审批规则SOP不得与操作性SOP合并
 🚫 即使审批节点属于同一Stage，也必须拆分为独立SOP

🚨 **规则8：手册阶段→SOP强制映射** 🚨
对岗位职能手册中描述的每个主要工作阶段/活动，必须检查是否需要独立SOP：
 for each 主要工作阶段 in 岗位职能手册中的角色职责描述:
 if 该阶段有独立的交付物（如评审纪要、合同草案、项目启动确认单）:
 → 必须生成独立SOP
 if 该阶段涉及跨部门交接（如销售→交付、合同→项目启动）:
 → 必须生成独立交接SOP
 if 该阶段涉及会议/评审（如方案评审会、开标会）:
 → 必须生成独立会议SOP
 if 该阶段涉及条件分支的复杂流程（仅在特定条件满足时启动，如投标、战略性亏损审批）:
 → 必须生成独立条件分支型SOP（原“专项SOP”已更名为“条件分支型SOP”）

🚨 **规则9：审批规则SOP自动推导** 🚨
 for each 审批节点 in 所有操作性SOP的步骤中:
 if 该审批节点需要分级路由（按金额/风险等级/业务线不同→不同审批链）:
 → 必须生成 1 个独立审批规则SOP（任务框架型）
 → 审批规则SOP必须包含：分级路由表 + 审批链定义 + 超时规则 + 驳回规则 + 配置表模板
 🚫 禁止将有分级审批逻辑的节点仅作为操作性SOP中的一个步骤
 🚫 禁止遗漏审批规则SOP的配置表模板

🚨 **规则10：SOP数量下限硬约束** 🚨
 在Step 2d自检时，如SOP总数 < expectMin_KB × 0.9:
 → 🚫 强制阻断，禁止进入文件生成
 → 必须返回Step 2c重新拆解
 → 输出缺失SOP分析：列出知识库中哪些独立活动未被分配SOP
 📌 此规则确保知识库驱动的拆解粒度不会被LLM的合并倾向所削弱

🚨 **规则10.1：编号唯一性强制校验（阻断级·V2.2.0新增）** 🚨
 在蓝图规划完成后、进入文件生成前，必须执行编号唯一性校验：

 **SOP编号唯一性**：
 FOR EACH sop IN 承诺清单:
   IF sop.编号 在承诺清单中出现次数 > 1:
     🚫 阻断 → "SOP编号{sop.编号}重复（出现{N}次），禁止生成多个版本"
     → 必须合并为一个SOP或分配不同编号
     → 🚫 禁止为同一编号生成"V2.0"版和"通用"版两个文件

 **模板编号唯一性**：
 FOR EACH tmp IN 模板清单:
   IF tmp.编号 在模板清单中出现次数 > 1:
     🚫 阻断 → "模板编号{tmp.编号}重复"

 **文件名唯一性**：
 FOR EACH file IN 已生成文件列表:
   IF 存在另一个文件具有相同的SOP/TMP编号（即使文件名不同）:
     🚫 阻断 → "编号{编号}对应多个文件：{文件1} vs {文件2}"

 📌 此规则解决 Round-01 验证中 SOP-030 编号重复（V2.0版14章 + 通用版9章）的根因。
 📌 一致性扣 -1 分 + 完整性扣 -0.5 分 = -1.5 分。

🚨🚨 **规则11：SOP类型完备性强制枚举（阻断级）** 🚨🚨
 在承诺清单输出前，必须对以下7种SOP类型逐一执行存在性检查，输出类型完备性矩阵：
 ┌─────────────────────────────────────────────────────────────────────┐
 │ 📋 SOP类型完备性矩阵（阻断级·承诺清单前置门禁） │
 │ │
 │ | 类型 | 识别来源 | 识别数量 | 对应SOP编号 | 判定 │
 │ |------|---------|---------|-----------|------| │
 │ | ① 操作性SOP | RACI矩阵+手册 | {N1} | SOP-0XX... | ✅/❌ │
 │ | ② 任务框架型SOP（审批规则） | 分级审批节点 | {N2} | SOP-0XX... | ✅/❌ │
 │ | ③ 条件分支型SOP | 条件触发活动 | {N3} | SOP-0XX... | ✅/⏭️ │
 │ | ④ 会议SOP | 独立评审/会议 | {N4} | SOP-0XX... | ✅/⏭️ │
 │ | ⑤ 交接SOP | 跨部门交接点 | {N5} | SOP-0XX... | ✅/⏭️ │
 │ | ⑥ 专项SOP | 投标/资质/备案 | {N6} | SOP-0XX... | ✅/⏭️ │
 │ | ⑦ 支撑SOP | 非主线支撑活动 | {N7} | SOP-0XX... | ✅/⏭️ │
 │ │
 │ 合计：{N1+N2+...+N7} + 1(总纲) = {Total} 个SOP │
 └─────────────────────────────────────────────────────────────────────┘
 强制规则：
 a. ①②类型为必检项：如识别数量>0但对应SOP数=0 → 🚫 阻断
 b. ③~⑦类型为条件必检项：如手册/知识库中存在该类型活动但承诺清单中未分配SOP → 🚫 阻断
 c. 每种类型识别数量=0时，必须输出排除理由（如"本流程无投标活动"）
 d. 🚫 禁止在未输出类型完备性矩阵的情况下进入文件生成
 📌 此规则防止LLM仅关注操作性SOP而遗漏审批规则/条件分支/会议/交接等类型

🚨🚨 **规则12：模板业务线差异化强制展开（阻断级）** 🚨🚨
 在模板承诺清单输出前，必须执行业务线差异化模板展开检查：
 for each 业务环节 in 所有SOP的步骤/交付物中:
 if 该环节的输出物在不同业务线间存在内容差异（从Step 2b业务线清单判定）:
 → 该环节的模板必须按业务线展开为独立变体模板
 → 变体模板数 = 需差异化的业务线数（从Step 2b动态提取）
 
 强制展开判定规则（满足任一即须展开）：
 a. 服务类目手册中该环节对不同业务线有不同合规要求 → 展开
 b. 该环节的输出物包含业务线专属字段（如GCP条款/RWE设计/818号令）→ 展开
 c. 该环节的审批路径因业务线不同而异 → 展开
 d. 手册中明确标注"按业务线差异化"或"分类编制" → 展开
 
 🚫 禁止将应展开的业务线变体合并为单一通用模板
 🚫 禁止仅改标题而不增加差异化字段（变体模板必须含业务线专属字段≥3个）
 📌 典型展开场景：解决方案建议书（C/R/I/T/S五类）、合同草案（C/R/I/T/S五类）

🚨🚨 **规则13：服务类目→SOP映射完整性（阻断级·V2.0新增）** 🚨🚨
 蓝图规划阶段必须建立完整的"服务类目→SOP"映射表，确保每一项可映射到流程的服务类目均被至少1个SOP覆盖：
 
 强制规则：
 a. 13.1 必须从服务类目手册中动态提取全部服务类目（禁止硬编码具体编码/名称）
 b. 13.2 逐项将服务类目映射到流程阶段（通过阶段对照表：项目型启动→线索+商机，准备→合同+交付，执行→交付，收尾→回款；平台型商机与转化→线索+商机，入驻与启用→合同+交付，运营与支持→交付，续约与增值→回款+CS）
 c. 13.3 每项服务类目必须确定主导角色（从岗位职能手册流程映射表提取）
 d. 13.4 每项服务类目必须被至少1个SOP完整覆盖
 e. 13.5 映射覆盖率 = 已映射类目数 / 可映射类目总数 ≥ 95%
 f. 13.6 未映射的服务类目必须逐一说明原因（非流程范围内/已合并至其他类目）
 g. 13.7 输出格式：完整的"服务类目→SOP映射表"（含编码、类目名称、流程阶段、归属SOP、主导角色）
 
 🚫 禁止跳过此映射步骤
 🚫 禁止在未输出映射表的情况下进入承诺清单阶段
 📌 此规则防止大量具有独立角色/交付物/QC标准的服务活动被遗漏
 📌 典型遗漏模式：交付阶段的服务类目（伦理审查/中心筛选/受试者管理/数据管理等）被整体忽略

🚨🚨 **规则14：岗位职能→SOP映射完整性（阻断级·V2.0新增）** 🚨🚨
 蓝图规划阶段必须建立完整的"岗位→SOP"RACI矩阵，确保每个岗位在至少1个SOP中承担R或A角色：
 
 强制规则：
 a. 14.1 必须从岗位职能手册中动态提取全部岗位（46个岗位·11类角色前缀）
 b. 14.2 每个岗位必须分析其参与流程的具体节点（从岗位说明书的流程映射表提取）
 c. 14.3 构建完整RACI矩阵：岗位数 × SOP数 = 矩阵单元格数
 d. 14.4 岗位覆盖率 = 已覆盖岗位数 / 总岗位数 ≥ 85%
 e. 14.5 未覆盖的岗位必须逐一说明原因（不参与本流程/仅支持角色）
 f. 14.6 特别关注以下易遗漏岗位组：PP-01~05（平台产品部）、DP-01~06（数据产品部）、RB-01~06（区域业务部）、FR-02~05（临床研究专业）、FR-07~10（技术团队）
 
 🚫 禁止仅覆盖核心角色而忽略执行层岗位
 🚫 禁止将整组岗位（如"PP-01~05全员"）合并标注而不逐一确认参与SOP
 📌 此规则防止大量执行层岗位被排除在SOP责任体系之外
 📌 典型遗漏模式：PP/DP/RB三大部门全员未出现在任何SOP的R角色中

🚨 **Step 2c-PLUS-1：活动类型目录（参数化）** 🚨
为减少LLM对SOP拆解的随机性，引入"活动类型目录"（Activity Type Catalog）作为确定性约束：

🚫 **禁止硬编码具体活动类型名称**（HC-1/HC-2修复）。
活动类型目录必须从以下来源**动态提取**（优先级从高到低）：

**来源1（最高优先级）：标准参考文件**
当 standardReferencePath 非空时：
```
活动类型目录 = standardReference.sopBlueprint.map(sop => ({
  序号: sop.index,
  活动类型: sop.name.replace(/SOP$/, ''),  // 从SOP名称推导活动类型
  独立性要求: sop.type === '操作性' ? '✅ 必须独立' : '⚠️ 按需独立',
  说明: sop.scope  // 从蓝图scope字段提取
}))
```
📌 标准参考中每个SOP条目对应一个活动类型，独立性由SOP类型决定：
 - 操作性SOP → ✅ 必须独立
 - 任务框架型SOP → ✅ 必须独立（审批规则/规则配置）
 - 条件分支型SOP → ⚠️ 按需独立（有独立触发条件和回归节点）
 - 支撑型SOP → ⚠️ 按需独立

**来源2：岗位职能手册**
当标准参考不存在时，从岗位职能手册中"岗位流程映射/业务流程/操作步骤"类文件提取：
```
活动类型目录 = 岗位职能手册中识别的独立活动列表
独立性判定 = 对每个活动执行粒度四要素检验（见Step 2c-PLUS-2）
 - 4/4满足 → ✅ 必须独立
 - 3/4满足 → ⚠️ 强烈建议独立
 - ≤2/4满足 → 可合并
```

**来源3（兜底）：知识库**
从知识梳理.md中的流程阶段和子活动提取：
```
活动类型目录 = 知识库中识别的流程节点
独立性判定 = 按粒度四要素检验
```

**独立性分类通用规则**（适用于所有来源）：
┌──────────────────────────────────────────────────────────────────┐
│ 独立性分类 │ 判定标准 │ 处理规则 │
├──────────────────────────────────────────────────────────────────┤
│ ✅ 必须独立 │ 粒度四要素≥3/4满足，或标准参考中 │ 必须生成独立SOP，🚫 禁止合并 │
│ │ 为操作性/任务框架型 │ │
├──────────────────────────────────────────────────────────────────┤
│ ⚠️ 按需独立 │ 条件分支型/支撑型，或粒度四要素 │ 如流程涉及该活动，必须独立 │
│ │ 2/4满足但有独立触发条件 │ │
├──────────────────────────────────────────────────────────────────┤
│ 可合并 │ 粒度四要素≤1/4满足 │ 合并到相邻SOP，§11标注衔接 │
└──────────────────────────────────────────────────────────────────┘

**使用规则**：
1. 对活动枚举清单中的每个活动，必须先匹配到上述动态提取的目录中的类型
2. 如匹配到"✅ 必须独立"类型 → 该活动必须生成独立SOP，🚫 禁止合并
3. 如匹配到"⚠️ 按需独立"类型 → 如流程涉及该活动，必须独立成SOP
4. 如活动不在目录中 → 按粒度四要素检验结果决定是否独立

**合并禁止规则**（通用·不依赖具体活动名称）：
🚫 禁止将"必须独立"的活动类型合并到同一SOP，判定规则：
 - ❌ 两个活动的执行角色完全不同（角色专属性） → 禁止合并
 - ❌ 两个活动的输出物被不同下游独立消费（输出独立性） → 禁止合并
 - ❌ 两个活动有独立的质控标准（质量独立性） → 禁止合并
 - ❌ 审批规则类活动 → 必须拆分为独立审批规则SOP（任务框架型）
 - ❌ 条件分支类活动 → 必须拆分为独立条件分支型SOP

**输出要求**：
在承诺清单中，每个SOP必须标注其对应的活动类型目录序号和来源：
```
📋 承诺清单（含活动类型目录映射）
| SOP编号 | SOP名称 | 活动类型目录序号 | 独立性依据 | 目录来源 |
|---------|---------|-----------------|-----------|----------|
| SOP-001 | {名称} | #1 | 4/4满足 | 标准参考/手册/知识库 |
| SOP-002 | {名称} | #2 | 3/4满足 | 标准参考/手册/知识库 |
| ... | ... | ... | ... | ... |
```

📌 此目录为确定性约束，减少LLM对SOP拆解的随机性。
📌 基于排查报告根因1：相同avatar.json两次执行产生不同粒度。
📌 消除HC-1/HC-2硬编码，活动类型从standardReference/岗位职能手册/知识库动态提取。

**Step 2c-PLUS-2：粒度四要素检验
对每个候选 SOP，执行"粒度四要素"检验：

① 输入独立性：该活动是否有明确的、可独立交付的输入物？
② 输出独立性：该活动的输出物是否被不同的下游独立消费？
③ 角色专属性：该活动是否需要特定的专业技能/资质？
④ 质量独立性：该活动是否有独立的质控标准和验收条件？

判定规则：
- 四要素全部满足 → 必须拆分为独立 SOP
- 满足 3 项 → 强烈建议拆分
- 满足 2 项 → 可合并但需在 §11 标注上下游衔接
- 满足 ≤1 项 → 应合并到相邻 SOP

📌 输出格式：对每个候选SOP输出四要素检验表。

**Step 2d：拆解完整性自检（阻断级·必须通过）
逐项检查以下清单，全部✅方可进入 Step 3：

□ DC-1：RACI矩阵中每个Accountable环节是否都有对应操作性SOP？
□ DC-2：每个审批节点是否都有独立审批规则SOP（不与操作性SOP合并）？
□ DC-3：每个支撑流程是否都有独立支撑SOP？
□ DC-4：SOP总数 ≥ 1(总纲) + 操作性SOP数 + 审批规则SOP数（任务框架型） + 支撑SOP数 + 任务框架型SOP数 + 条件分支型SOP数 + 规则型SOP数？
□ DC-5：Step 2b中需要差异化模板的业务线数量已记录，将在Step 6用于模板数量校验？
□ DC-6（数量下限校验·四路径交叉验证+绝对下限+重试机制+类型完备性联动）：SOP总数 ≥ 期望数量下限？
 expectMin 必须通过四条独立路径计算，取最大值：
 
 路径A（RACI驱动）：
 expectMin_A = 1(总纲) + RACI中独立Accountable子活动数 + 审批节点数（任务框架型）
 + 支撑流程数 + 任务框架型SOP数 + 条件分支型SOP数 + 规则型SOP数
 
 路径B（知识库驱动）：
 直接使用 Step 2c-PRE 阶段计算的 expectMin_KB
 expectMin_B = expectMin_KB
 （expectMin_KB 已通过手册结构扫描+节点分类精确计算）
 
 路径C（活动枚举驱动·绝对下限）：
 expectMin_C = 1(总纲) + Step 2c-PRE活动枚举清单中"必须独立SOP"活动数 + Step 2c-PRE活动枚举清单中"强烈建议独立SOP"活动数 × 0.8
 📌 此路径确保活动枚举结果直接约束数量下限，避免LLM忽视枚举结论
 
 路径D（标准参考驱动·当standardReferencePath非空时）：
 expectMin_D = standardReference.sopBlueprint.length
 📌 此路径确保参考标准的SOP数量作为硬下限约束（HC-6修复）
 📌 当standardReferencePath为空时，expectMin_D = 0（不参与计算）
 
 路径E（类型完备性驱动·绝对下限）：
 expectMin_E = 1(总纲) + 规则11类型完备性矩阵中所有类型识别数量之和
 📌 此路径确保每种已识别的SOP类型都有对应SOP，不被合并或遗漏
 📌 当某类型识别数=0但有合理排除理由时，该类型不纳入计算
 
 路径F（服务类目驱动·V2.0新增）：
 expectMin_F = 1(总纲) + 规则13服务类目映射中识别的"需独立SOP"的服务类目组数
 📌 计算方式：将映射到同一SOP的服务类目归为一组，组数即为该路径的SOP需求数
 📌 去重合并系数：实际SOP数 ≈ 可映射类目数 × 0.22（经验值，因多个类目常归入同一SOP）
 📌 此路径确保服务类目手册的完整覆盖直接约束SOP数量下限
 
 最终 expectMin = max(expectMin_A, expectMin_B, expectMin_C, expectMin_D, expectMin_E, expectMin_F)
 
 🚨 阈值从80%提升至90%：
 if 实际SOP数 < expectMin × 90%:
 🚫 强制阻断，判定为"粒度过粗"，返回Step 2c重新拆解
 
 🚨 DC-6 重试机制：
 当DC-6校验不通过时，执行以下重试流程：
 ┌─────────────────────────────────────────────────────┐
 │ 重试流程（最多3次） │
 │ │
 │ 第1次失败： │
 │ → 输出缺失活动分析：列出活动枚举清单中 │
 │ 哪些活动未被分配SOP │
 │ → 返回Step 2c重新拆解 │
 │ │
 │ 第2次失败： │
 │ → 输出详细对比表：活动枚举清单 vs 当前SOP清单 │
 │ → 强制要求LLM解释为何某些活动未独立成SOP │
 │ → 返回Step 2c重新拆解 │
 │ │
 │ 第3次失败： │
 │ → 🚨 强制使用 expectMin 作为下限 │
 │ → 自动补充缺失SOP的框架结构 │
 │ → 标记为"⚠️ 数量强制补齐" │
 └─────────────────────────────────────────────────────┘
 
 🚨 DC-6.1 承诺清单阶段强制校验：
 在承诺清单输出后、进入文件生成前，必须校验：
 if 承诺SOP数 < expectMin × 90%:
 🚫 阻断，输出缺失的活动清单
 🚫 要求LLM重新评估是否遗漏独立活动
 📌 此校验防止"承诺清单本身就数量不足"的问题
 🚨 DC-6.2 模板数量下限校验（阻断级）：
 承诺清单中的模板总数 M 必须满足：
 M >= baseTemplateCount + differentiatedCount + configTemplateCount
 其中：
 baseTemplateCount = 每个操作性/会议/交接/专项SOP至少1个配套模板（不含任务框架型）
 differentiatedCount = 规则12强制展开检查中识别的所有业务线变体模板数
 = ∑（每个展开环节 × 需差异化业务线数）
 configTemplateCount = 每个任务框架型SOP至少1个规则配置表模板
  
 计算示例（动态·禁止硬编码）：
 - 如Step 2b识别出B个业务线，且有K个环节需差异化 → differentiatedCount = B × K
 - 如某流程有5个业务线、2个环节需差异化（方案+合同）→ differentiatedCount = 5×2 = 10
  
 if 实际模板数 < M:
 🚫 强制阻断，返回Step 6b补充模板
 🚫 输出缺失模板分析：列出哪些SOP/业务线缺少配套模板
 📌 此校验为阻断级，未通过禁止进入Q2验证

□ DC-7（合并违规检测·修复方向C）：每个SOP的复杂度是否合理？
 for each SOP in 拆解清单:
 if SOP主步骤数 > 15步:
 ⚠️ 警告"可能过度合并"，建议拆分为2+个SOP
 if SOP涉及角色数 > 3个:
 ⚠️ 警告"可能跨环节合并"，建议按角色拆分
 if SOP覆盖Stage数 > 1:
 🚫 阻断"跨Stage合并违规"，必须拆分

□ DC-8（承诺清单合理性校验·阻断级）：承诺清单本身是否合理？
 📌 此校验防止"承诺清单本身就数量不足"的问题（基于排查报告根因3）
 
 校验规则（必须全部满足）：
 ① SOP数 ≥ expectMin × 0.9
 if 承诺SOP数 < expectMin × 0.9:
 🚫 阻断，输出缺失的活动清单
 
 ② 每个流程阶段至少对应 1 个 SOP
 for each 流程阶段 in 知识库阶段划分:
 if 该阶段无对应SOP:
 🚫 阻断，提示"阶段 {阶段名} 缺少对应SOP"
 
 ③ 审批类活动独立成 SOP ≥ 1 个
 if 承诺清单中审批规则SOP数 = 0:
 ⚠️ 警告"无审批规则SOP，请确认流程是否涉及审批节点"
 → 如确认涉及审批 → 🚫 阻断
 → 如确认无审批 → 可跳过
 
 ④ 支撑/配置类活动独立成 SOP ≥ 1 个（如适用）
 if 知识库中存在支撑流程描述 且 承诺清单中支撑SOP数 = 0:
 ⚠️ 警告"知识库中存在支撑流程描述但未生成支撑SOP"
 → 要求LLM解释原因
 
 ⑤ 活动枚举清单中的"必须独立"活动全部有对应SOP
 for each 活动 in 活动枚举清单 where 独立性判定 = "✅ 必须独立":
 if 该活动无对应SOP:
 🚫 阻断，提示"活动 {活动名} 必须独立但未分配SOP"

 ⑥ 模板引用SOP编号边界校验（V2.2.0新增）：
 for each tmp IN 模板清单:
   for each ref IN tmp.适用SOP列表:
     if ref ∉ 承诺清单SOP编号集合:
       🚫 阻断 → "模板{tmp.编号}引用了不存在的SOP {ref}"
       → 必须修正模板引用范围
 📌 此校验防止模板引用超出实际SOP清单的编号（如引用SOP-033但实际仅有SOP-000~032）
 📌 解决 Round-01 验证中 TMP-001 引用不存在的 SOP-033 的根因。
 
 📌 输出格式：
 ┌─────────────────────────────────────────────────────┐
 │ 📋 DC-8 承诺清单合理性校验结果 │
 │ │
 │ ① SOP数 ≥ expectMin × 0.9：{✅/❌} │
 │ 承诺SOP数：{N}，阈值：{expectMin × 0.9} │
 │ │
 │ ② 每个流程阶段至少1个SOP：{✅/❌} │
 │ 阶段数：{X}，已覆盖阶段数：{Y} │
 │ │
 │ ③ 审批规则SOP ≥ 1：{✅/⚠️/❌} │
 │ 审批规则SOP数：{Z} │
 │ │
 │ ④ 支撑/配置SOP ≥ 1（如适用）：{✅/⚠️/❌} │
 │ 支撑SOP数：{W} │
 │ │
 │ ⑤ 活动枚举"必须独立"全覆盖：{✅/❌} │
 │ "必须独立"活动数：{A}，已覆盖数：{B} │
 │ │
 │ ⑥ 模板引用SOP编号边界校验：{✅/❌} │
 │ 幽灵引用数：{G} │
 │ │
 │ 判定：✅ 全部通过 / 🚫 存在阻断项 │
 └─────────────────────────────────────────────────────┘

□ DC-9（服务类目覆盖率校验·阻断级·V2.0新增）：规则13映射覆盖率 ≥ 95%？
 校验规则：
 ① 服务类目映射覆盖率 = 已映射类目数 / 可映射类目总数
 ② 覆盖率 ≥ 95% → ✅ 通过
 ③ 85% ≤ 覆盖率 < 95% → ⚠️ 警告，需补充缺失映射
 ④ 覆盖率 < 85% → 🚫 阻断，返回规则13重新映射
 
 📌 输出格式：
 ┌─────────────────────────────────────────────────────┐
 │ 📋 DC-9 服务类目覆盖率校验结果 │
 │ │
 │ 可映射类目总数：{N} │
 │ 已映射类目数：{M} │
 │ 覆盖率：{M/N × 100}% │
 │ 缺失类目清单：{列出未映射的类目编码+名称} │
 │ │
 │ 判定：✅/⚠️/🚫 │
 └─────────────────────────────────────────────────────┘

□ DC-10（岗位覆盖率校验·阻断级·V2.0新增）：规则14岗位覆盖率 ≥ 85%？
 校验规则：
 ① 岗位覆盖率 = 已覆盖岗位数 / 总岗位数
 ② 覆盖率 ≥ 85% → ✅ 通过
 ③ 70% ≤ 覆盖率 < 85% → ⚠️ 警告，需补充缺失岗位
 ④ 覆盖率 < 70% → 🚫 阻断，返回规则14重新映射
 
 特别检查：
 ⑤ PP-01~05（平台产品部）至少3个岗位被覆盖
 ⑥ DP-01~06（数据产品部）至少3个岗位被覆盖
 ⑦ RB-01~06（区域业务部）至少2个岗位被覆盖
 ⑧ 如上述⑤⑥⑦任一项不满足 → 🚫 阻断
 
 📌 输出格式：
 ┌─────────────────────────────────────────────────────┐
 │ 📋 DC-10 岗位覆盖率校验结果 │
 │ │
 │ 总岗位数：{N} │
 │ 已覆盖岗位数：{M} │
 │ 覆盖率：{M/N × 100}% │
 │ │
 │ 部门覆盖检查： │
 │ PP(平台产品部)：{覆盖数}/5 │
 │ DP(数据产品部)：{覆盖数}/6 │
 │ RB(区域业务部)：{覆盖数}/6 │
 │ │
 │ 缺失岗位清单：{列出未覆盖的岗位编码+名称} │
 │ │
 │ 判定：✅/⚠️/🚫 │
 └─────────────────────────────────────────────────────┘

🚫 **自检不通过 → 阻断进入 Step 3**，返回 Step 2a 重新拆解。
🚫 **常见失败模式**：
 - 只按角色拆分得到6-7个SOP，忽略了按业务环节进一步拆分
 - 将多个审批节点合并为1个审批规则SOP
 - 将方案设计+成本核算+报价+评审会合并为1个大SOP
✅ **正确标准**：SOP数量 = 流程中所有独立业务环节的数量，不是角色的数量。

🚨🚨 **Step 2c-PLUS：标准参考SOP清单对齐** 🚨🚨

在完成 Step 2c 结构化SOP拆解后、进入 Step 2d 自检前，执行标准参考SOP清单对齐：

**对齐逻辑**：

1. 读取 `{知识库路径}/循环轮次/标准参考摘要.json`
2. IF standardReferenceExists = true 且 sopBlueprint.length > 0:

 **2a. SOP清单精确对齐**：
 a. 将 Step 2c 自动推导的SOP清单与标准参考的 sopBlueprint 逐项比对
 b. **精确匹配优先**：先按SOP编号精确匹配（如 SOP-001↔SOP-001），再按名称完全匹配辅助
 c. 对标准参考中的每个SOP条目：
 - 在自动推导结果中查找匹配项（编号精确匹配 → 名称完全匹配 → 名称相似度≥80%兜底）
 - 匹配成功 → ✅ 保留自动推导结果，**但名称/范围必须使用标准参考的值**（精确覆盖）
 - 匹配失败 → 🚨 新增该SOP到清单中，使用标准参考的名称、范围和版本号，标注"⚠️ 知识库内容缺失·使用标准参考描述"
 d. 对自动推导中的每个SOP条目：
 - 在标准参考中查找匹配项
 - 未匹配 → ⚠️ 标注"标准参考中无对应项·保留但需确认"
 e. 输出SOP对齐结果：
 `✅ SOP清单标准参考对齐完成：标准参考{X}个SOP，自动推导{Y}个SOP，精确匹配{Z}个，新增{N}个，待确认{M}个`
 `📋 最终SOP清单（{总数}个）：{逐项列出编号+名称+版本号}`

 **2b. 模板清单精确对齐**：
 a. 读取标准参考摘要中的 templateBlueprint
 b. 将 Step 2 模板选择规则引擎推导的模板清单与 templateBlueprint 逐项比对
 c. **精确匹配**：按模板编号精确匹配（TMP-001↔TMP-001）
 d. 对标准参考中的每个模板条目：
 - 匹配成功 → ✅ 保留，但名称/类型/版本号必须使用标准参考的值
 - 匹配失败 → 🚨 新增该模板到清单中，使用标准参考的名称和类型
 e. 对推导结果中的每个模板条目：
 - 未匹配 → ⚠️ 标注"标准参考中无对应项·保留但需确认"
 f. 输出模板对齐结果：
 `✅ 模板清单标准参考对齐完成：标准参考{X}个模板，推导{Y}个，精确匹配{Z}个，新增{N}个，待确认{M}个`

 **2c. 角色体系精确对齐**：
 a. 读取标准参考摘要中的 roleBlueprint
 b. 将 Step 2a 提取的RACI角色矩阵与 roleBlueprint 逐项比对
 c. **精确匹配**：按角色代码精确匹配（AR-01↔AR-01）
 d. 对标准参考中的每个角色条目：
 - 匹配成功 → ✅ 保留，但标准名称/职责描述必须使用标准参考的值
 - 匹配失败 → 🚨 新增该角色到角色体系中，使用标准参考的名称和职责
 e. 对提取结果中的每个角色条目：
 - 未匹配 → ⚠️ 标注"标准参考中无对应项·保留但需确认"
 f. 输出角色对齐结果：
 `✅ 角色体系标准参考对齐完成：标准参考{X}个角色，提取{Y}个，精确匹配{Z}个，新增{N}个，待确认{M}个`

 **2d. 版本号继承对齐**：
 a. 读取标准参考摘要中的 versionBaseline 和 versionBaselineExtended
 b. 对每个SOP/模板：
 - 标准参考中存在同编号文件且有独立版本号 → **继承该版本号并按修订幅度递增**
 示例：标准参考 SOP-001=V5.2 → 本次生成 SOP-001=V5.3（小修订）或 V6.0（大重构）
 - 标准参考中无同编号文件（全新SOP）→ 版本号设为 **V1.0**
 - 🚫 **禁止将所有SOP统一设为相同版本号**（如全部V6.0）
 c. 校验：检查是否存在≥3个SOP使用完全相同版本号 → 若是，触发警告并要求逐一说明版本来源
 d. 输出版本号对齐结果：
 `✅ 版本号继承对齐完成：继承{N}个，新建{M}个（V1.0），递增{K}个`

3. IF standardReferenceExists = false:
 a. 不直接跳过，执行**知识库深度扫描**：
 - 扫描知识库中所有流程描述文档（岗位职能手册/服务类目手册）
 - 提取：独立业务环节列表、审批节点列表、支撑流程列表
 - 计算期望SOP数量下限：expectMin = 1(总纲) + 业务环节数 + 审批节点数 + 支撑流程数
 b. 对比 Step 2c 自动推导结果与期望值：
 if 实际SOP数 < expectMin × 70%:
 🚫 阻断，要求补充拆解
 输出《知识库SOP推导基准清单》写入 {知识库路径}/循环轮次/
 清单格式：[{"环节名": "xxx", "建议SOP名": "xxx", "来源": "知识库/标准参考"}, ...]
 else:
 ✅ 使用自动推导结果，但标注"⚠️ 无标准参考·基于知识库推导"
 c. 输出降级对齐报告：
 
 `⏭️ 标准参考不存在，使用自动推导SOP/模板/角色清单`

🚫 **禁止在标准参考存在时忽略其SOP/模板/角色清单**：标准参考为全量拆解基准
🚫 **禁止删除标准参考中定义的SOP/模板/角色**：即使知识库中没有对应描述，也必须保留
🚫 **禁止使用语义模糊匹配作为主要匹配方式**：必须以编号精确匹配为主，名称匹配为辅
📌 对齐结果追加写入 `{知识库路径}/循环轮次/SOP清单对齐记录.md`（含SOP/模板/角色/版本号四部分）

**Step 3** 创建总纲 SOP-000（15章完整结构）（时间片：共享）
- 文件命名：`HY-G-{流程代码}-SOP-000 {SOP流程名称}SOP总纲（V{版本号}）.md`（如 HY-G-{流程代码}-SOP-000 {流程名称}SOP总纲.md）
- 🚨 **章节编号必须使用阿拉伯数字**：## 1. 文档信息 / ## 2. 目的与适用范围 / ## 3. 术语定义 ... （🚫禁止## 第一章）
- 🚨 **第1章文档信息必须使用表格格式**（| 属性 | 内容 |），包含：SOP编号/SOP名称/任务类型/版本号/生效日期/编制部门/流程Owner/适用业务线，以及版本升级说明（引用块格式列出本版变更项）
- 内容结构：14章+附录完整结构（1.文档信息/2.目的与适用范围/3.术语定义/4.前置条件与输入/5.角色与职责/6.流程架构/7.操作步骤详解/8.质控标准/9.输出物与模板/10.度量指标/11.上下游衔接/12.合规与风险/13.例外处理/14.版本与审批/附录）
 📌 注意：以上§6“流程架构”仅适用于SOP-000总纲。非SOP-000的SOP的§6标题按类型适配（操作性/条件分支型→任务架构，任务框架型/规则型→规则架构），§7/§8标题所有类型统一为“操作步骤详解”/“质控标准”。🚨 任务框架型SOP的§7内容为空（明确声明“任务框架型不包含第7章”），但§7标题仍必须保留。规则型SOP的§7包含规则执行步骤卡（聚焦审查判定）。详见 sop-skeleton-templates §6-§8适配规则。

🚨 **§10度量指标双层架构规则**：
- **SOP-000总纲层§10**：定义流程级KPI + KPI↔度量指标映射表
 - KPI使用独立编号序列：KPI-{NN}（流程级关键绩效指标）
 - 每个KPI必须包含：编号/名称/计算公式/目标值/数据来源/监控频率
 - KPI数量由流程复杂度动态决定（通常5-10个）
 - 必须包含KPI↔M映射表：展示每个流程级KPI如何由阶段级度量指标支撑
 - 格式：| 流程级KPI编号 | KPI名称 | 支撑阶段指标编号 | 映射关系说明 |
 - 每个KPI至少映射1个M指标，每个M指标至少被1个KPI引用
- **操作性SOP层§10**：定义阶段级度量指标
 - M使用独立编号序列：M-{NN}（阶段级度量指标，编号从全局编号池分配）
 - 每个指标必须包含：编号/名称/计算公式/目标值/数据来源/监控频率
 - 📌 估算值必须标注
- 🚫 禁止KPI与M指标混用同一编号序列
- 🚫 禁止每个SOP独立从M-01开始编号（必须使用全局编号池）

🚨 **度量指标全局编号分配规则**：
1. 在生成第一个SOP之前，先统计所有SOP的阶段数，计算度量指标总数预估
2. 为每个SOP预分配度量指标编号区间：
 - SOP-001：M-01 ~ M-{n1}
 - SOP-002：M-{n1+1} ~ M-{n1+n2}
 - ...依此类推
3. 🚫 禁止每个SOP独立从M-01开始编号
4. ✅ 度量指标编号必须全局唯一，不可跨SOP重复
5. SOP-000的KPI编号独立使用KPI-{NN}序列，不与M序列冲突
- 🚨 **§6流程架构必须包含流程全景图（详细度强制）**：§6中必须包含一个子章节（如§6.1.2），使用ASCII art（方框字符┌─┐└┘│＋箭头▼▲→←▶◀）绘制流程全景图。全景图必须达到"可直接指导业务操作"的详细程度，必含以下9项元素（缺一不可，详见 sop-skeleton-templates §3 的 P1~P9 清单）：
  P1 阶段分组标注（M1~Mn纵向标签）| P2 每个SOP方框含编号+名称+类型标签+主责角色 | P3 SOP内部关键活动/Phase标注 | P4 审批触发点（操作性SOP⇄审批规则SOP双向箭头）| P5 条件分支（判断框+Yes/No路径）| P6 阶段间数据流标注（箭头上标传递物）| P7 逆流程/驳回路径 | P8 流程终点与下游衔接 | P9 审批与分支SOP索引（树形段落）。
  🚫 禁止将全景图简化为"阶段方框+箭头"的粗粒度图（如仅画 Stage 1→Stage 2→...→Stage 8）。参照金标准§6.1.2格式。🚫 禁止省略流程全景图。
- 🚨 **审批与分支 SOP 索引**：在SOP-000流程全景图底部，必须追加独立的"审批与分支 SOP 索引（任务框架型 + 条件分支型）"树形结构段落。对每个审批类SOP列出：触发点+审批分级+时限+驳回路径+逆流程；对每个条件分支型SOP列出：触发点+分支条件+分支数量+下游路由。🚫 缺失视为SOP-000不完整。
同时，§7操作步骤详解中，涉及复杂状态流转（≥3个状态）或多分支决策（≥3个分支）的步骤，必须在步骤正文中内嵌ASCII art状态流转图
- 🚨 **§7操作步骤详解**：每个步骤包含操作目的+操作指引（编号列表）+AI辅助+时效要求+判断标准+输入物详细引用（引用模板编号+版本）+验收清单（10项SDRL逐项列出）+下一节点（含SOP内跳转+跨SOP跳转）。每步30-40行
- 🚨 **监控/培育/跟踪类步骤结构化强制规则（E25）**：当步骤属于“监控”“培育”“跟踪”“评估”“巡检”类型时，操作指引必须包含以下5要素，禁止仅列举方式而无具体操作子步骤：
 ① **执行频率**：明确量化周期（如“每两周”“每季度”），禁止“定期”“适时”等模糊表述
 ② **活动清单**：编号列举具体执行动作（如①发送培育材料②安排远程沟通③记录反馈），每项≤200字
 ③ **评估标准**：量化评估指标+门槛值（如“成熟度≥70分”“6个月无进展”）
 ④ **状态流转**：完整的状态转换图（ASCII art）+每个转换的触发条件和后续动作
 ⑤ **升级路径**：超时/异常时的升级机制（时限+升级对象+决策时限）
 - 🚫 禁止仅写“培育方式：内容培育/远程沟通/活动邀请”而无具体操作指引
 - 🚫 禁止状态流转缺少量化退出条件（如“成熟度≥70分”“持续6个月无进展”）
- 🚨 **§9输出物与模板**：必须列出所有配套模板（含编号+名称+版本+关联步骤），每个模板的引用必须指向模板文件/目录下的实际物理文件
- 🚨 **§13例外处理**：每个异常场景展开为四要素格式（触发条件→审批路径→执行操作→后续流转），不少于50行
- 🚨 **§13例外处理量化时限强制规则**：每个例外场景必须包含量化时限（工作日），禁止"原则上不承接""需审批"等无时限表述。方案评审退回→修改工作日数、线索退回→介入响应时限、商务谈判→具体时限、审批超时→升级时限
- 🚨 **估算值确认流程强制规则**：涉及费率/成本估算的SOP，必须在§14附录中定义确认流程（财务确认时限+过渡期管控+更新发布流程）。禁止估算值未经📌标注直接使用
- 🚨 **步骤卡格式强制自检**：每个操作性SOP的§7步骤卡必须使用标准10字段格式（步骤编号/步骤名称/执行角色/协作角色/前置条件/输入物/操作动作/输出物/时效要求/质控标准）。禁止字段名称变体（责任人→执行角色、参与角色→协作角色等）
- 🚨 **实时角色交叉校验**：每个SOP生成后立即校验步骤卡中所有角色代码是否在roleDictionary中定义，未定义→立即补充
- 🚨 **跨SOP引用格式校验**：所有跨SOP引用必须统一为V2标准格式 `[HY-G-...](../HY-G-...%20....md)`
- 🚨 **SOP清单（§6.3或附录）必须列出所有生成的SOP文件**（含完整编号、名称、角色、对应阶段、版本号），数量与实际文件一致
- 🚨 **模板清单（§9.2）必须列出所有生成的模板文件**（含完整编号、名称、目标格式、适用SOP章节、版本号），数量与实际文件一致
- 🚨 **SOP/模板清单数量**：总纲§6.3和§9中列出的SOP和模板数量必须与实际生成文件一致，不得遗漏
- 🚨 **内容深度最低要求**：
 - SOP-000 总纲：≥500行（15章完整结构）
 - 操作性SOP：每个≥300行（含14章+附录，每个步骤30-40行深度）
 - 审批规则SOP：每个≥200行
 - 支撑/任务框架SOP：每个≥150行
 - 表单类模板：每个≥40行（标准版平均80行）
 - 报告类模板：每个≥30行
 - 审批类模板：每个≥50行
 - 配置类模板：每个≥40行
 - 🚫 **低于最低行数要求的文件视为不合格**，必须在Step 7自检中识别并补充

🚨🚨 **Gate-STRUCTURE：14章结构 Pre-Write 阻断门禁（V2.2.0新增·阻断级）** 🚨🚨

> **背景**：基于 LTC 流程 Round-01 验证发现 28 个操作性 SOP 仅含 9 章（§1~§9），缺失 §10~§14 独立章节（度量指标/上下游衔接/合规与风险/例外处理/版本与审批），根因是 LLM 在 Step 4 生成时"简化"了标准 14 章骨架。此门禁为最终防线。

```
触发条件：所有 SOP 文件写入前强制执行（操作性/框架型/条件分支型/规则型）

执行流程：
1. 统计待写入 SOP 的 H2 章节数（## N. 格式，不含概念一致性声明等附录标题）
2. 校验章节数：
   - SOP-000 总纲：章节数 == 15（14章 + 附录）
   - 所有其他 SOP：章节数 == 14
3. 校验章节编号连续性：1, 2, 3, ..., 14（或15），无跳跃
4. 校验章节标题精确匹配 chapterStructureBaseline：
   §1=文档信息 / §2=目的与适用范围 / §3=术语定义 / §4=前置条件与输入
   §5=角色与职责 / §6={按类型适配} / §7=操作步骤详解 / §8=质控标准
   §9=输出物与模板 / §10=度量指标 / §11=上下游衔接 / §12=合规与风险
   §13=例外处理 / §14=版本与审批
5. 校验 §1 为"文档信息"且包含 | 属性 | 内容 | 表格（非引用块格式）

判定：
  - 任一检查失败 → 🚫 阻断写入，补充缺失章节后重新生成
  - 全部通过 → ✅ 允许写入
```

🚫 **禁止使用 9 章精简格式**。以下 9 章→14 章错误映射为**绝对禁止模式**：

| ❌ 禁止的 9 章标题 | ✅ 应映射到的 14 章标准标题 | 错误类型 |
|:------------------|:--------------------------|:---------|
| `1. 概述与目的` | 拆为 `1. 文档信息` + `2. 目的与适用范围` | 章节合并错误 |
| `3. 角色与职责（RACI矩阵）` | 应为 `5. 角色与职责`（前面需有 §3 术语定义 + §4 前置条件） | 章节编号偏移 |
| `4. 流程节点与活动描述` | 拆为 `6. 任务架构` + `7. 操作步骤详解` | 章节合并错误 |
| `5. 输入与输出物清单` | 分入 `4. 前置条件与输入` + `9. 输出物与模板` | 内容错位 |
| `6. 业务差异化规则` | 无对应独立章节，内容应融入 §2.2 / §7 步骤 / §13 例外 | 伪章节 |
| `7. 关键控制点与合规要求` | 拆为 `8. 质控标准` + `12. 合规与风险` | 章节合并错误 |
| `8. 异常处理与回退规则` | 应为 `13. 例外处理` | 标题不规范 |
| `9. 附件：模板引用` | 应为 `9. 输出物与模板` | 标题不规范 |

📌 此门禁解决 Round-01 验证中完整性扣 -1.5 分（28 个操作性 SOP 缺 §10~§14）的根因。

---

## 增强规则（Q2/Q3校验规则 → Q1生成指令前置防御）

以下规则从 Q2 验证失败（MAJ-01~MAJ-06）和 Q3 六维度分析差距中提炼，前置到 Q1 生成阶段预防。

### Fix-1：步骤卡15字段散文格式强制模板（V2.2.0统一版 · 10字段表格格式已废弃）

> **⚠️ 废弃声明**：此前定义的"10字段表格格式"（步骤编号~质控标准10字段表格）已废弃。实际执行中LLM将其误用为表内嵌格式（`| 字段 | 内容 |`），与标准严重偏离。现统一为15字段散文+加粗标签格式（与 sop-generation-reference Step 4 完全一致）。

**【强制·唯一合法格式】每个步骤卡必须使用以下15字段散文+加粗标签格式：

```markdown
#### 步骤 {N}：{步骤名称}

**执行角色**：{角色编码}（{角色名称}）
**协作角色**：{配合角色编码}（如有，否则填"—"）
**前置条件**：{启动该步骤的前提条件}
**操作目的**：{本步骤要达成的目标}
**操作指引**：
1. {子步骤1}
2. {子步骤2}
3. {子步骤3}
**判断标准**：{量化判断条件，必须含数值或可判定准则}
**输入物**：{输入文件/数据/记录名称}
**输出物**：{输出文件/记录/交付物名称}
**验收清单**：
- [ ] {检查项1}
- [ ] {检查项2}
**后置动作**：{触发的下游动作/状态更新/通知}
**异常触发条件**：若{条件}，则{处理方式}，升级至{角色}（参照§13）
**时效要求**：{SLA时限}（参照TF-001）
**关联模板**：{TMP-NNN 模板名称}（如有，否则填"—"）
```

**15字段说明**：
- 必填字段（12个）：步骤编号、步骤名称、执行角色、前置条件、操作目的、操作指引、判断标准、输入物、输出物、验收清单、后置动作、异常触发条件
- 条件必填（3个）：协作角色（有配合角色时必填）、时效要求（所有步骤必填）、关联模板（有对应模板时必填）

🚫 **绝对禁止的格式（负面示例）**：

❌ **禁止格式A：表内嵌格式**（Round-01 中 28 个操作性 SOP 的实际格式）
```
| 字段 | 内容 |
|:-----|:-----|
| **节点编号** | SOP001-UT-001 |
| **参与角色** | AR-01(A/R) |   ← ❌ "参与角色"不是标准字段名
| **活动步骤** | Step 1... |   ← ❌ "活动步骤"不是标准字段名
```

❌ **禁止格式B：10字段表格格式（已废弃）**
```
| 字段序号 | 字段名称 | 说明 | 必填 |
|:--------:|:---------|:-----|:----:|
| 1 | 步骤编号 | ... | ※ |
```

🚫 **禁止字段名称变体（统一映射表）**：
| ❌ 禁止使用 | ✅ 必须使用 |
|:-----------|:-----------|
| 责任人 / 负责角色 | 执行角色 |
| 参与角色 | 协作角色 |
| 操作说明 / 操作动作 / 操作步骤 | 操作指引 |
| 交付物 | 输出物 |
| 例外处理 | 异常触发条件 |
| 超时设置 | 时效要求 |
| 质控标准 | 判断标准 |
| 活动步骤 / 执行步骤 | 操作指引（含编号子步骤列表） |

🚨🚨 **Gate-STEPCARD：步骤卡格式 Pre-Write 阻断门禁（V2.2.0新增）** 🚨🚨

```
触发条件：每个操作性SOP写入前强制执行

执行流程：
FOR EACH 步骤卡 IN §7操作步骤详解:
  CHECK 1: 使用散文+加粗标签格式（非表格格式）
  CHECK 2: 包含全部12个必填字段的加粗标签（**执行角色** / **协作角色** / ...）
  CHECK 3: 字段名称精确匹配上表标准（禁止"参与角色"/"活动步骤"等变体）
  CHECK 4: **判断标准**含量化数值或可判定准则
  CHECK 5: **操作指引**含编号子步骤列表（1. 2. 3. ...）
  CHECK 6: **异常触发条件**非空且含量化触发条件

判定：
  - 任一 CHECK 失败 → 🚫 阻断写入，修正格式后重新生成
  - 全部通过 → ✅ 允许写入
```

- 🚨 **批次内一致性自检**：每批次SOP生成完成后，比对本批次所有SOP的步骤卡字段名，确保100%使用15字段散文格式
- 📌 此门禁解决 Round-01 验证中完整性扣 -1.0 分（步骤卡格式非标准）的根因

### Fix-2：角色引用三重交叉校验

1. **校验1（生成时实时）**：每个操作性SOP生成后，扫描所有角色引用 ↔ roleDictionary 交叉比对
2. **校验2（模板生成时）**：模板中引用的角色代码必须在roleBlueprint中存在，禁止引入未定义角色
3. **校验3（批次完成后全量）**：扫描所有SOP+模板的角色引用，汇总为全量清单 ↔ roleDictionary 比对
- 🚫 禁止使用 SDR、BDR、AE 等非项目标准角色代码
- 🚫 禁止在角色校验未通过的情况下进入Step 5.5

### Fix-3：量化阈值强制标注

**§13例外处理量化标准（4要素强制）：
- a. 触发条件：量化阈值（金额变化>5%/时间偏差>3工作日/错误率>2%），禁止模糊描述
- b. 审批路径：明确审批角色代码+审批层级
- c. 处理步骤：可执行操作序列（编号列表）
- d. 数据来源：标注阈值来源（手册P{页码}/行业基准/待用户确认）

**成本/金额相关数值标注：
- 所有数值字段必须标注数据来源（手册/行业基准/待用户确认）
- 估算值必须标注待确认标记，禁止将估算值伪装为确定值
- 利润率底线/费率等关键数值直接引用 anchor.businessLineBaseline
- 🚫 禁止出现"约""大概""左右""预计"等模糊表述

### Fix-4：预检结果联动生成指令

- Step 0.6 预检（31项）完成后，生成"预检通过清单"写入知识库
- 预检清单注入后续 Step 1/2/3/4 生成步骤
- 每个生成步骤完成后，回检预检清单对应项是否已满足
- ❌不通过项 → 阻断生成；⏳待确认项 → 标注待确认

### Fix-5：增量一致性校验

每生成一个操作性SOP后，立即执行5项增量校验：
1. 角色引用一致性（该SOP角色 ∈ roleDictionary）
2. 术语一致性（该SOP术语 ∈ terminologyDictionary）
3. 编号一致性（该SOP编号 ∈ sopBlueprint）
4. 跨SOP引用完整性（引用的SOP/步骤已存在）
5. 数据格式一致性（枚举值 ∈ fieldTypeStandard）

- 🚫 禁止在增量校验未通过的情况下继续生成下一个SOP
- 📌 增量校验结果追加到一致性校验日志

### Fix-6：量化基准提取与标注

- 在Step 3.5锚点提取时同步提取量化指标（时效/数量/比率）
- 构建量化基准表写入 `{knowledgeBasePath}/循环轮次/量化基准表.json`
- 生成SOP时引用量化指标必须从基准表查找，禁止自行编造
- 基准表中无对应指标 → 标注待确认+提供合理估算范围
- 🚫 禁止出现无来源标注的数值

---

增强规则（Eval-01 + Q2 Round-01 → Q1前置防御 · 24条）

以下规则从 Eval-01 问题清单和 Q2 验证报告中提炼，前置到 Q1 生成阶段预防。每条规则均通过 Pre-Write Gate 和 Step 5.5 校验联动执行。

| # | 规则名称 | 核心约束 | 校验联动 |
|:-:|:---------|:---------|:---------|
| E1 | 步骤卡深度最低 | ≥30行/步，≥5项操作指引，≥3项验收清单，异常触发条件必填 | Gate-1 |
| E2 | 步骤编号格式统一 | 强制 `S-0X` 格式，🚫`S0X`，禁止跨SOP混用 | Gate-3 |
| E3 | 标题术语一致性 | 建立术语等价表，选定标准名后🚫别名（方案评审≠方案审查） | Step 5.5 |
| E4 | 推导值标注 | 统一 `{数值}（📌{来源}）` 格式，🚫无标注推导值 | Gate-2 |
| E5 | 成本公式独立 | §7/§8必须含公式块，🚫纯文字描述，锚点costStructureTree必须传递到正文 | Gate-9 |
| E6 | 亏损审批4要素 | 触发条件+审批路径+执行操作+后续流转，🚫仅写“需XX审批” | Gate-9 |
| E7 | 模板格式自检 | 变更记录5列/必填Y-N/5种标准类型/5区块完整 | Gate-4 |
| E8 | 业务线变体覆盖 | 每业务线≥1特殊场景变体，🚫“统一覆盖”忽略差异 | Gate-8 |
| E9 | 引用链接有效 | 相对路径目标必须存在，🚫指向不存在文件的链接 | Gate-5 |
| E10 | 章节命名规范 | 14章标题精确匹配chapterStructureBaseline，🚫同义词替换 | Gate-6 |
| E11 | 异常量化阈值 | 触发条件必须量化（数值+单位），🚫“必要时/尽快/相关部门” | Gate-7 |
| E12 | KPI口径一致 | 同名KPI跨SOP公式/起算点/终止点/范围必须一致 | Gate-2 |
| E13 | 混合业务覆盖 | 多业务线SOP必须定义主导判定+并行核算+混合付款+混合条款+混合核销 | Gate-8 |
| E14 | 占位符追踪 | 下游占位符记录到pendingExternalReferences，SOP-000§11汇总 | Gate-5 |
| E15 | 成本底线完整 | 地板价公式+利润空间公式+策略性亏损审批路径（分级） | Gate-9 |
| E16 | 例外4要素 | 触发条件+处理模式+升级路径+恢复/回退，🚫“原则上不承接”无例外标准 | Gate-10 |
| E17 | 循环量化退出 | 循环步骤卡必含计数器+上限+量化退出条件+超限处理路径 | Gate-11 |
| E18 | 特殊场景适配 | 每个SOP识别已知特殊场景（付款/客户/谈判/合规/资源），定义触发+适配+差异审批+恢复 | Gate-12 |
| E19 | 角色词典补全 | 生成前检查roleDictionary覆盖度，缺失角色提前标注📝待补全 | Gate-2 |
| E20 | 术语英文全称 | terminologyDictionary每项必含englishFull，🚫仅中文定义 | Gate-3 |
| E21 | 步骤编号格式统一 | 跨SOP步骤编号格式必须一致（S-01 vs S01），Pre-Write检测 | Gate-3 |
| E22 | 密级标注统一 | 所有SOP密级标注必须一致（内部/秘密/机密），🚫混用 | Gate-3 |
| E23 | 交付物名称一致 | 同名交付物跨SOP名称严格一致，🚫别名/缩写 | Step 5.5 |
| E24 | 跨SOP引用语义 | 引用其他SOP必须使用正式全称，🚫引用错误SOP名称或不存在的SOP | Step 5.5 |
| E25 | 监控/培育类步骤结构化 | 监控/培育/跟踪类步骤必须含“执行频率+活动清单+评估标准+状态流转+升级路径”5要素，🚫仅列举培育方式而无操作子步骤 | Gate-1 |
| E26 | 模板成本结构对齐 | 涉及成本/报价的模板，A~L字段必须从锚点costStructureTree提取，🚫编造成本定义，🚫使用通用IT模型（硬件+软件+实施），🚫改变D项等计算公式 | Gate-9 |
| E27 | 模板枚举值约束对齐 | 模板枚举字段取值范围必须与anchor.businessLines+SOP-000 §12数据格式约束一致，业务类型必须用C/R/I/T/S分类，🚫使用"项目型/产品型/服务型"等通用分类 | Gate-4 |
| E28 | 例外场景覆盖度 | 当standardReferencePath非空时，生成SOP§13例外场景集合覆盖率≥80%参考标准，🚫缺失例外场景 | Gate-23 |
| E29 | 内容覆盖度对比 | 当standardReferencePath非空时，生成SOP综合覆盖率（步骤0.4+章节0.3+规则0.3）≥80%参考标准 | Gate-22 |
| E30 | 成本编码单一权威源 | A~L成本科目编码定义以SOP-004 §3为唯一权威源；SOP-000 BR-05仅允许引用（"详见SOP-004 §3"），🚫重新定义或缩写；模板TMP中A~L字段名必须与SOP-004逐字一致 | Gate-9 |
| E31 | 业务线定义跨SOP一致 | C/R/I/T/S业务线名称必须全局一致（以Step 2b从服务类目手册提取结果为唯一源），🚫任何SOP不得重新定义或缩写业务线含义；条件分支型SOP与操作性SOP必须使用相同业务线枚举 | Gate-4 |
| E32 | 财务公式正确性自验 | 模板中所有计算公式必须数学自洽：①命名与公式结果语义一致（毛利率=(收入-成本)/收入，🚫用成本字段推导）②公式所需字段必须在模板中存在（🚫引用不存在的字段）③分母不得为零风险需标注 | Gate-9 |

# V2.0 缺陷修复增强约束（8条核心防御指令 · 压缩版）

> 基于内循环 #1 质量复盘，针对12项缺陷和4类根因新增的强制约束。违反任何一条即触发回退Q1重生成。

| # | 规则名称 | 核心约束 |
|:-:|:---------|:---------|
| C-01 | 外部角色强制定义 | ≥3个外部角色（EXT-01~03），含角色代码+名称+组织类型+职责+交互接口 |
| C-02 | 全局术语注册表 | 所有术语必须在terminologyDictionary注册，含term+definition+englishFull |
| C-03 | 模板引用三段式 | 首次引用=全称《编号+名称》（见§9.2），后续引用=简称TMP-NNN |
| C-04 | 三步交叉校验 | CV-1版本号锚定 + CV-2§7↔§9.2双向锚定 + CV-3登记表同步，100%一致方可进Q2 |
| C-05 | 例外场景量化 | 触发条件必须量化阈值+审批路径+处理步骤+恢复条件（4要素） |
| C-06 | 操作动作拆分 | >500字的操作步骤必须拆分为子步骤，每步含独立可执行动作 |
| C-07 | 步骤卡角色完整 | 执行角色+协作角色不可为空，协作为空时填「无」并说明原因 |
| C-08 | 质量门禁阈值 | 总分≥85进Q2，70-84警告进Q2，<70回退Q1；完整性≥26/30，一致性≥20/25 |

## V2.0 生成流程增强（Phase A~E）

| Phase | 名称 | 核心要求 |
|:-----:|:-----|:---------|
| A | 预生成注册 | 全局注册表.json + 外部角色清单 + 模板编号登记表初始化 |
| B | 结构化生成 | §3术语=锚点原文 / §5角色含外部子章节 / §7模板三段式 / §8例外8字段 |
| C | 后置交叉校验 | CV-1/CV-2/CV-3三步，100%一致后方可进Q2 |
| D | 质量自评 | 5维度评分（含V2.0新增12项检查项），满足C-08门禁阈值 |
| E | 生成日志 | 写入生成日志.md，含交叉校验结果和缺陷修复状态 |

---

# V14.0 防幻觉指令体系（4项强制校验机制）

> 目标：消除 LLM 在大规模文档包生成中的"凭空编造"行为，确保每个引用、编号、路径均可溯源验证。

## 强制文件引用规则（Anti-Hallucination Rule 1）

**核心原则**：LLM 引用任何文件内容前，必须先通过工具（read_file / list_directory / glob）实际读取该文件。

| # | 规则 | 违反后果 |
|:-:|:-----|:---------|
| AH-1 | 禁止引用未经 read_file 确认存在的文件路径 | 输出标记 ⚠️ [AH-1]，触发 postStepFileVerification |
| AH-2 | 禁止引用超出上下文窗口（>5000字符前读取）的文件内容 | 强制重新 read_file 后再引用 |
| AH-3 | 引用文件行号时必须标注来源：`[来源: {filePath}:L{lineNumber}]` | 缺失标注视为不可靠引用 |
| AH-4 | 跨 SOP 引用术语/角色时，必须先 grep 确认目标 SOP 中存在该术语 | 未确认的引用标记为"待验证" |

## 结构化校验点注入（Anti-Hallucination Rule 2）

每步输出前，LLM 必须执行以下自检并在输出中显式记录结果：

| 校验点 | 检查内容 | 触发时机 | 失败处理 |
|:------:|:---------|:---------|:---------|
| SVC-01 | **文件存在性**：声明的所有已生成文件必须通过 list_directory 确认存在 | 每步完成前 | LOOP_BACK 到文件生成步骤 |
| SVC-02 | **编号连续性**：SOP-000~SOP-NNN 无跳跃，TMP-001~TMP-MMM 无跳跃 | 批量生成步骤完成前 | 补充缺失编号的文件 |
| SVC-03 | **角色一致性**：本 SOP 中出现的角色必须存在于 SOP-000 §7 角色清单 | 每个 SOP 生成后 | 修正角色名或补充到 SOP-000 |
| SVC-04 | **跨文件引用**：`[REF: SOP-XXX §Y]` 必须指向真实存在的章节 | Q2 验证步骤中 | 修正引用目标或补充章节 |

## 上下文隔离策略（Anti-Hallucination Rule 3）

防止前序步骤大体积输出导致 LLM 注意力分散，引发"张冠李戴"式幻觉：

| 策略 | 实现方式 |
|:-----|:---------|
| 大输出隔离 | 单个 outputKey > 4000字符时，自动转为 step-cache 引用（仅保留文件路径+行数摘要） |
| 按需读取 | 后续步骤需要前序输出详情时，通过 read_file 按需读取，而非全量注入 prompt |
| 摘要传递 | 步骤间传递"文件清单（编号+名称+行数+路径）+ 关键决策摘要（≤200字）" |
| 排除列表 | `operational_sops` / `conditional_sops` / `framework_types_sops` / `all_templates` 默认不内联 |

## 自检输出格式要求（Anti-Hallucination Rule 4）

每个生成步骤的输出末尾，必须包含以下结构化自检块：

```markdown
## 📋 防幻觉自检报告

| 校验项 | 结果 | 证据 |
|:------:|:----:|:-----|
| 文件存在性 | ✅/❌ | list_directory 结果: {文件数} 个文件确认存在 |
| 编号连续性 | ✅/❌ | SOP范围: SOP-000~SOP-{N}, 缺失: {无/列表} |
| 角色一致性 | ✅/❌ | 引用角色数: {X}, SOP-000§7定义数: {Y}, 新增: {列表} |
| 跨文件引用 | ✅/❌ | 引用总数: {N}, 有效: {N}, 无效: {列表} |

> 4项全部 ✅ 方可标记本步完成。任一 ❌ 需先修复再结束。
```