---
name: baseline
version: "1.0.0"
category: workflow
description: "当用户需要扫描原始业务文件并提取结构化业务基线数据时使用。不要用于需求分析、PRD编写、功能设计。Use when user needs to scan raw business documents and extract structured business baseline data. Do NOT use for requirement analysis, PRD writing, or feature design."
triggers:
  zh: ["基线提取", "业务梳理", "条款提取", "制度分析", "组织架构梳理", "业务流程挖掘"]
  en: ["baseline", "extract", "business constraints mining", "document set analysis"]
license: MIT
compatibility: Node.js >= 18, Java 11+
config: 
  - workflow-config.yaml
dependencies: 
  - textutil
  - openpyxl
  - xlrd
metadata: 
author: "neuqik@hotmail.com"
created: "2026-06-16"
updated: "2026-06-16"
status: "stable"
---

# 基线提取 / Baseline Extraction

## Changelog / 版本履历
| 日期 | 版本 | 变更摘要 |
|------|------|---------|
| 2026-06-16 | 1.0.0 | 规范化调整 |

## Description / 描述
Before formal PRD analysis, scans ALL raw business documents provided by the user (policies, org charts, process descriptions, management rules, meeting minutes, system screenshots, business ledgers, etc.), systematically extracts implicit business elements, and outputs a structured "Business Baseline Document" that provides a solid factual foundation for downstream analysis. 在正式进行PRD需求分析之前，扫描用户提供的全部原始业务文件（制度文件、组织架构表、流程说明、管理办法、会议纪要、系统截图、业务台账等），系统化提取其中隐含的业务要素，输出结构化的「业务基线文档」，为后续分析提供坚实的事实基础。

## Triggers / 触发词
- English: 'baseline', 'extract', 'business constraints mining', 'document set analysis'
- 中文: '基线提取', '业务梳理', '条款提取', '制度分析', '组织架构梳理', '业务流程挖掘'

## Capabilities / 能力
- 12类业务要素提取 - 从条款约束、人员角色部门、机构、规范标准等12个维度提取业务要素
- 二进制文件处理 - 支持docx/xlsx/pdf等格式的文本提取
- 多源文件扫描 - 全面扫描用户提供的所有文件，不遗漏任何信息源
- 矛盾检测与标注 - 识别不同文件间的矛盾描述并标记待确认
- 增量更新机制 - 支持在已有基线基础上进行增量提取和更新
- Auto-Review机制 - 自动执行覆盖率、完整性、一致性、矛盾检查

## Dependencies / 依赖
- textutil - 处理docx文件格式转换
- openpyxl - 处理xlsx文件格式
- xlrd - 处理xls文件格式
- workflow-config.yaml - 配置文件处理策略和提取规则

## Usage / 使用方式

### Invocation / 调用方式
This skill is typically invoked via the workflow router when trigger keywords are detected, or directly via expert invocation for business baseline extraction tasks.

### Parameters / 参数
| 参数 | 类型 | 必填 | 说明 |
|------|------|------|------|
| document_set | array | ✅ | 原始业务文件集（docx/xlsx/pdf/md/图片文字描述） |
| incremental | boolean | ❌ | 是否为增量更新模式（默认false） |

### Example / 示例
```
/baseline document_set=["制度.pdf", "组织架构.xlsx", "流程.docx"]
```

## Output Format / 输出格式
Business baseline document in Markdown format containing: file inventory, organizations & personnel, clause constraints, business processes, key nodes, institutional requirements, expected goals, existing problems, system constraints, business boundaries, audit & construction requirements, standards & norms, pending confirmation items, and file processing log.

## Configuration / 配置
The skill reads workflow-config.yaml for baseline extraction settings:
- binary_file_handling: object with strategies for different file formats
- extraction_timeout: number (default 60000ms)
- contradiction_detection_enabled: boolean (default true)

## Workflow / 工作流程
1. Step 0: File Inventory Scan - List all user-provided files and determine extraction strategy
2. Step 1: Organization & Personnel Extraction - Extract org hierarchy and personnel information
3. Step 2: Clause Constraints & Policy Requirements Extraction - Extract numbered clauses and rules
4. Step 3: Business Process & Key Node Extraction - Extract step sequences and decision points
5. Step 4: Goals & Problems Extraction - Extract business targets and known issues
6. Step 5: System Constraints & Business Boundaries Extraction - Extract technical and scope constraints
7. Step 6: Integrated Baseline Output - Organize all results into structured baseline document

## Auto-Review / 自检清单
| # | 检查项 |
|---|--------|
| 1 | 输入文件是否全部被扫描处理 |
| 2 | 提取结果是否标注了完整的来源引用 |
| 3 | 推断项是否标记为[待确认] |
| 4 | 是否检测并处理了文件间的矛盾描述 |
| 5 | 基线文档是否包含所有12类业务要素 |
| 6 | 文件处理日志是否完整记录 |
| 7 | 组织架构信息是否与源文件完全一致 |

# PDD-Business Baseline Extraction / 业务基线提取技能

## Core Concept / 核心概念

### 🇨🇳
在正式进行 PRD 需求分析之前，扫描用户提供的全部原始业务文件（制度文件、组织架构表、流程说明、管理办法、会议纪要、系统截图、业务台账等），系统化提取其中隐含的业务要素，输出结构化的「业务基线文档」，为后续 pdd-ba 的需求分析提供坚实的事实基础。

**输入**: 原始业务文件集（docx/xlsx/pdf/md/图片文字描述） | **输出**: 业务基线文档（条款约束/角色部门/机构/业务流程/制度要求/期望目标/存在问题/系统约束/业务边界） | **不负责**: 需求分析、PRD编写、功能设计

### 🇺🇸
Before formal PRD analysis, scans ALL raw business documents provided by the user (policies, org charts, process descriptions, management rules, meeting minutes, system screenshots, business ledgers, etc.), systematically extracts implicit business elements, and outputs a structured "Business Baseline Document" that provides a solid factual foundation for downstream pdd-ba analysis.

**Input**: Raw business document set (docx/xlsx/pdf/md/image-text) | **Output**: Business Baseline Document (clauses/roles&departments/orgs/processes/policy requirements/goals/problems/system constraints/boundaries) | **NOT responsible for**: Requirement analysis, PRD writing, feature design

***

## 定位：pdd-baseline 在 PDD 体系中的位置

```
pdd-baseline（本文档）
    ↓ 输出：业务基线文档
pdd-ba（业务分析）
    ↓ 输出：需求分析报告
pdd-extract-features（功能点提取）
    ↓ 输出：功能点矩阵
pdd-generate-spec（开发规格生成）
    ↓ 输出：开发规格文档
```

pdd-baseline 是 PDD 体系的**上游入口**。它不替代 pdd-ba——pdd-ba 需要的是 PRD 或需求描述，而 pdd-baseline 产出的是从原始文件中挖掘出的**业务要素结构化清单**，这份清单可以直接作为 pdd-ba 的输入材料。

***

## 方法论工具箱 / Methodology Toolbox

### 🇨🇳
### 12 类业务要素提取框架

对每份输入文件，从以下 12 个维度扫描并提取：

| 维度 | 英文 | 提取目标 | 示例 |
|------|------|---------|------|
| **条款约束** | Clause Constraints | 制度文件中带编号的条款、硬性/软性规则、表决比例、金额阈值 | 「4/5投决会委员同意通过」「直投>300万须报集团」 |
| **人员角色部门** | Personnel / Roles / Departments | 组织架构表中的真实姓名、岗位名称、部门归属、兼任关系 | 厉赟(创投总经理)、王红枚(恒信董事长兼担保集团董事长) |
| **机构** | Organizations | 公司/子公司/部门/委员会/外部机构的层级关系 | 盛京金控→创投/科技风投/农投/拓源/… |
| **规范标准** | Standards & Norms | 命名规范、编码规则、分类标准、行业术语 | 「立项报告」(非「预审报告」)、snake_case 编码 |
| **业务流程** | Business Processes | 步骤序列、泳道归属、前置条件、产出物、时限 | 股权投资13步、科技风投T+110日尽调时限 |
| **关键节点** | Key Nodes | 审批节点、决策点、一票否决权、会签/或签 | 投委会表决(4/5)、总经理一票否决、集团评审会 |
| **审计和建设要求** | Audit & Construction Req. | 合规检查项、审计追踪要求、档案管理规范 | 「双人复核填报制度」、投前投中投后档案分类 |
| **制度要求** | Institutional Requirements | 制度文件明确规定的必须/禁止/建议事项 | 「未纳入年度计划不得投资」「禁止类清单」 |
| **期望目标** | Expected Goals | 业务目标、KPI、成功标准、年度计划 | 年度投资计划完成率、退出计划达成率 |
| **存在问题** | Existing Problems | 系统内测反馈、用户痛点、制度执行中的困难 | 「直投立项无提报集团审批端口」「合同审批流暂无」 |
| **系统约束** | System Constraints | 技术环境限制、数据源约束、性能要求、安全要求 | T+1更新、不直连业务库、数据隔离 |
| **业务边界** | Business Boundaries | 范围边界（做什么/不做什么）、不做事项清单 | 驾驶舱不做审批、不替代财务系统 |

### 🇺🇸
### 12-Category Business Element Extraction Framework

| Dimension | Extraction Target |
|-----------|------------------|
| **Clause Constraints** | Numbered clauses, hard/soft rules, voting ratios, amount thresholds |
| **Personnel / Roles / Depts** | Real names, job titles, department affiliations, dual appointments |
| **Organizations** | Company/subsidiary/department/committee hierarchy relationships |
| **Standards & Norms** | Naming conventions, coding rules, classification standards, terminology |
| **Business Processes** | Step sequences, swimlane ownership, preconditions, deliverables, timelines |
| **Key Nodes** | Approval gates, decision points, veto powers, countersign/or-sign |
| **Audit & Construction Req.** | Compliance checklists, audit trail requirements, archival standards |
| **Institutional Requirements** | Mandatory/prohibited/recommended items in policy documents |
| **Expected Goals** | Business targets, KPIs, success criteria, annual plans |
| **Existing Problems** | System test feedback, user pain points, policy execution difficulties |
| **System Constraints** | Technical constraints, data source limitations, performance/security requirements |
| **Business Boundaries** | Scope boundaries (do/don't do), exclusion lists |

***

## 分析流程 / Analysis Flow

### 🇨🇳
### Step 0: 文件清单扫描（前置步骤）

列出用户提供的所有文件，建立文件清单表：

| 文件代码 | 文件名 | 类型 | 提取策略 |
|---------|--------|------|---------|
| F001 | XX制度.pdf | pdf | 需用户提供文字版或OCR |
| F002 | XX组织架构.xlsx | xlsx | openpyxl提取 |
| F003 | XX流程.docx | docx | textutil提取 |

**二元文件处理策略**：docx → `textutil -convert txt`；xlsx → `openpyxl`；xls → `xlrd`；pdf/图片 → 提示用户提供文字版或 OCR 转换。

**中断检查**：如果超过 50% 的文件无法提取文本 → 🔴 CRITICAL → 终止并提示用户。

### Step 1: 机构与人员提取

从组织架构表和制度文件中提取：

- **机构层级树**：集团→子公司→部门→岗位 的完整层级
- **人员清单**：真实姓名、登录名、岗位、部门、职级、兼任关系
- **委员会/虚拟组织**：投委会、风险评审委员会、立项会、评审会的组成规则

**输出格式**：
```
盛京金控(集团)
├── [O01] 创投集团
│   ├── 领导班子: 厉赟(总经理)/张剑(副总)/李霖(副总)
│   ├── 投资业务部: 杨大勇(负责人)/吕鹏(副职兼项目经理)/张萨仁/…
│   ├── 合规风控部: 田婧(负责人)/陈鹏旭
│   └── …
```

**中断检查**：如果组织架构表中存在「另属于」字段但未提取 → 🟡 WARN → 提示兼任关系可能遗漏。

### Step 2: 条款约束与制度要求提取

逐文件扫描制度文档，提取：

- **硬性规则**（带编号条款）：如「第16条：4/5及以上投决会委员同意通过」→ 标注 [来源: 文件名 §条款号]
- **软性规则**（建议/推荐）：如「原则上退出期管理费低于投资期」
- **金额阈值**：如「直投>300万」「基金出资>1000万或>40%」
- **负面清单**：禁止类和特别监管类清单

**输出格式**：
| 规则ID | 规则原文摘要 | 约束类型 | 条款来源 |
|--------|-----------|---------|---------|
| C01-§16 | 项目立项:4/5投决会委员同意通过 | 硬性 | 创投股权投资管理细则 §16 |
| C01-§21 | 投资决策:4/5通过;总经理一票否决 | 硬性 | 创投股权投资管理细则 §21 |

**中断检查**：如果某制度文件全文未提取到任何带编号的条款 → 🟡 WARN → 标注"可能为框架性文件，条款不够具体"。

### Step 3: 业务流程与关键节点提取

从流程文档中提取：

- **流程步骤序列**：按编号排列，每步骤标注执行角色、输入、输出、时限
- **决策节点**：投票/审批/一票否决的发生位置和规则
- **泳道归属**：每步骤的执行部门

**输出格式**：
```
股权投资流程13步（来源: C01 §12）
1. 项目开发筛选 [投资经理] → 储备项目库
2. 初步尽调 [项目组≥2人] → 初步尽调报告 [签保密协议后]
3. 项目初审 [分管副总+部门全员 投票 2/3通过] → 初审表决表
4. 项目立项 [投委会 投票 4/5通过, 总经理一票否决] → 立项报告 [重大报集团]
...
```

**中断检查**：如果流程文档缺少时限标注 → 🟡 WARN → 提示「流程步骤缺少时间约束」。

### Step 4: 期望目标与存在问题提取

- **期望目标**：从制度文件的"总则""目标"章节、年度计划模板中提取
- **存在问题**：从系统内测反馈、用户邮件、会议纪要中提取

**中断检查**：如果未发现任何"存在问题"类输入 → 🔵 INFO → 标注「用户未提供问题反馈文档」。

### Step 5: 系统约束与业务边界提取

- **系统约束**：从技术文档或用户说明中提取（数据源、更新频率、安全要求）
- **业务边界**：从制度文件中提取"不适用范围""不做事项"

### Step 6: 整合输出基线文档

将以上 6 步的提取结果按 12 类业务要素组织为「业务基线文档」。该文档作为 pdd-ba 的输入材料。

***

### 🇺🇸
### Step 0: File Inventory Scan (Pre-step)

List all user-provided files with extraction strategy.

**Binary File Strategy**: docx → `textutil -convert txt`; xlsx → `openpyxl`; xls → `xlrd`; PDF/images → prompt user for text version or OCR.

**Interruption Check**: If >50% of files cannot extract text → 🔴 CRITICAL → Terminate and prompt user.

### Step 1: Organization & Personnel Extraction

Extract from org charts and policy docs: org hierarchy tree, personnel list (real names, login names, positions, departments, dual appointments), committees/virtual orgs.

**Interruption Check**: If org chart contains "另属于" field but not extracted → 🟡 WARN.

### Step 2: Clause Constraints & Policy Requirements Extraction

Scan policy docs for: hard rules (numbered clauses), soft rules (recommendations), amount thresholds, negative lists.

**Interruption Check**: If a policy doc yields zero numbered clauses → 🟡 WARN → "May be framework document, clauses not specific enough."

### Step 3: Business Process & Key Node Extraction

Extract from process docs: step sequences with roles/inputs/outputs/timelines, decision nodes, swimlane ownership.

**Interruption Check**: If process doc lacks time constraints → 🟡 WARN.

### Step 4: Goals & Problems Extraction

Extract from policy preambles, annual plan templates, user feedback docs.

**Interruption Check**: If no problem feedback found → 🔵 INFO.

### Step 5: System Constraints & Business Boundaries Extraction

Extract from technical docs or user specifications.

### Step 6: Integrated Baseline Output

Organize all extraction results into the "Business Baseline Document" structured by 12 categories.

***

## 输出规范 / Output Specification

### 🇨🇳
### 业务基线文档结构

1. **文件清单**: 所有输入文件的索引表(代码/名称/类型/提取状态)
2. **机构与人员**: 机构层级树 + 人员清单(姓名/岗位/部门/兼任) + 委员会组成
3. **条款约束**: 所有硬性/软性规则清单(含来源标注)
4. **业务流程**: 每项业务的步骤序列+泳道+时限+决策节点
5. **关键节点**: 审批节点/决策点/一票否决权的完整列表
6. **制度要求**: 必须/禁止/建议事项汇总
7. **期望目标**: 业务目标和KPI清单
8. **存在问题**: 已知问题和痛点清单(含来源)
9. **系统约束**: 技术/数据/安全约束清单
10. **业务边界**: 范围边界(做什么/不做什么)
11. **审计和建设要求**: 合规检查/档案/审计要求
12. **规范标准**: 术语表/命名规范/编码规则
13. **待确认事项**: 推断标记为[待确认]的事项清单（供用户二次确认）
14. **文件处理日志**: 哪些文件成功提取、哪些失败、失败原因

### 🇺🇸
### Business Baseline Document Structure

1. **File Inventory**: Index of all input files
2. **Organizations & Personnel**: Org hierarchy + personnel list + committees
3. **Clause Constraints**: All hard/soft rules with source annotations
4. **Business Processes**: Step sequences per business with swimlane/timeline/decision nodes
5. **Key Nodes**: Approval gates, decision points, veto powers
6. **Institutional Requirements**: Mandatory/prohibited/recommended items
7. **Expected Goals**: Business targets and KPI list
8. **Existing Problems**: Known issues and pain points with sources
9. **System Constraints**: Technical/data/security constraints
10. **Business Boundaries**: Scope boundaries (do/don't do)
11. **Audit & Construction Req.**: Compliance/archival/audit requirements
12. **Standards & Norms**: Glossary, naming conventions, coding rules
13. **Pending Confirmation**: Items marked [待确认] for user verification
14. **File Processing Log**: Success/failure per file with reasons

***

## Guardrails / 安全护栏

### 🇨🇳
**必须遵守**:
- 每个提取项必须标注来源文件代码和条款号
- 推断项必须标记 [待确认] 而非作为确定结论
- 不编造不存在于源文件中的条款
- 组织架构表中的人员姓名、岗位必须原样保留
- 同一信息在多处出现时，以制度文件原文为准，交叉验证

**避免事项**:
- ❌ 对业务流程进行"优化建议"（只提取，不评价）
- ❌ 根据常识补充业务规则（只提取文件中明确写出的）
- ❌ 合并不同来源的相似条款而不标注各自来源
- ❌ 跳过"看起来不重要"的文件

### 🇺🇸
**MUST comply**:
- Every extracted item MUST be annotated with source file code and clause number
- Inferred items MUST be marked [待确认/TBC] rather than as confirmed conclusions
- NEVER fabricate clauses not present in source files
- Personnel names and positions from org charts MUST be preserved verbatim
- When same info appears in multiple places, prioritize policy document text; cross-validate

**Avoid**:
- ❌ Making "optimization suggestions" for business processes
- ❌ Supplementing rules based on common sense
- ❌ Merging similar clauses from different sources without annotating each

***

## 与其他技能协作 / Skill Collaboration

### 🇨🇳
| 协作技能 | 协作方式 | 传入数据 | 期望输出 |
|---------|---------|---------|---------|
| **pdd-ba** | Sequential（下游） | 业务基线文档 | 需求分析报告 |
| **pdd-extract-features** | Sequential（下游） | 需求分析报告 | 功能点矩阵 |
| **pdd-generate-spec** | Sequential（下游） | 需求分析报告 | 开发规格 |
| **pdd-main** | 流程调度 | 分析请求 | 调度各skill执行 |

### 🇺🇸
| Collaborating Skill | Mode | Input | Output |
|--------------------|------|-------|--------|
| **pdd-ba** | Sequential (downstream) | Business Baseline Document | Requirements analysis report |
| **pdd-extract-features** | Sequential (downstream) | Requirements analysis report | Feature matrix |
| **pdd-generate-spec** | Sequential (downstream) | Requirements analysis report | Development spec |
| **pdd-main** | Flow scheduling | Analysis request | Skill orchestration |

***

## Iron Law / 核心铁律

### 🇨🇳
1. **只提取，不分析**: 业务基线提取的产出是"文件中写了什么"，不是"这意味着什么"——后者是 pdd-ba 的职责。
2. **全覆盖扫描**: 用户提供的每一份文件都必须被扫描，无论看起来是否相关。不得凭直觉跳过文件。
3. **源标注强制**: 每条提取结果必须标注 `[来源: 文件代码 §条款号/行号]`。无源标注的提取视为无效。
4. **推断透明化**: 所有基于上下文的推断必须标记 `[待确认]`，并与确定结论明确区分。
5. **原文优先**: 提取时优先保留原文表述，不做润色和改写。术语按原文记录（即使不统一），统一工作留给 pdd-ba。
6. **疑问即时输出**: 遇到以下情形立即输出疑问并等待用户确认: ①两份文件对同一事项有矛盾表述; ②关键信息缺失(如流程缺少步骤); ③文件内容与文件标题明显不符。

**违规示例**: ❌ 在某流程步骤旁加注"建议此处增加审批节点" | ❌ 看到组织架构表中有风控部就推断"应该有风控制度" | ❌ 提取条款时不标注来源 | ❌ 跳过"看起来不重要"的截图文件

**合规示例**: ✅ 提取「4/5投决会委员同意通过 [来源: C01 §21]」| ✅ 发现制度A和制度B对同一流程描述不同时，并列提取并标记 [矛盾待确认] | ✅ 在组织架构表中提取到"另属于担保集团"时标注 [兼任关系]

### 🇺🇸
1. **Extract Only, No Analysis**: Baseline output is "what the document says," not "what it means" — the latter is pdd-ba's job.
2. **Full Coverage Scan**: Every user-provided file MUST be scanned. Never skip files based on intuition.
3. **Mandatory Source Annotation**: Every extraction MUST be annotated `[Source: FileCode §Clause/Line]`. Unannotated extractions are invalid.
4. **Transparent Inference**: All context-based inferences MUST be marked [待确认/TBC] and clearly separated from confirmed conclusions.
5. **Original Text Priority**: Preserve original phrasing during extraction. No polishing or rewriting. Record terms as-is even if inconsistent; unification is pdd-ba's job.
6. **Immediate Question Output**: Immediately output questions and wait for user confirmation when: ①Two documents contradict on the same matter; ②Critical info missing (e.g., process missing steps); ③File content clearly doesn't match file title.

***

## Rationalization Table / 合理化防御表

| # | Trap / 陷阱 | Question / 请问自己 | Action / 应该怎么做 |
|---|-------------|------------------|------------------|
| 1 | "这个文件看起来跟主题无关,跳过吧" | 文件标题可能不反映内容,内部可能包含跨领域条款 | 至少快速扫描文件内容再判断 |
| 2 | "这个条款太细节了,不需要提取" | 细节条款可能是后续需求分析的关键约束 | 只要带编号的条款,全部提取 |
| 3 | "这里没有明确写,但我根据上下文推断应该是这样" | 推断会引入错误 | 标记 [待确认] 而非作为确定结论 |
| 4 | "两份文件的描述差不多,合并成一条吧" | 细微差异可能是不同视角的重要信息 | 分别保留,标注各自来源 |
| 5 | "这个术语在另一份文件里有不同叫法,我统一一下" | 术语不统一本身就是重要发现 | 原样记录,差异留到 pdd-ba 处理 |
| 6 | "用户没提需求文档,我就只从非制度文件中找" | 制度文件是最权威的事实来源 | 优先扫描制度文件,其次才是非正式文档 |

***

## Red Flags / 红旗警告

### Layer 1: Input Guards / 输入防护
- **INPUT-BL-001**: 用户未提供任何文件或文件列表为空 → 🔴 CRITICAL → 终止，提示用户提供至少一份业务文件
- **INPUT-BL-002**: 超过 50% 文件无法提取文本（非文本格式且无法转换）→ 🔴 CRITICAL → 列出失败文件清单，提示用户提供文字版本
- **INPUT-BL-003**: 提供的文件中不包含任何可识别的制度条款或组织信息 → 🟡 WARN → 提示"当前文件可能不包含结构化业务信息，是否继续？"

### Layer 2: Execution Guards / 执行防护
- **EXEC-BL-001**: 某文件全文扫描后未找到任何可提取的 12 类业务要素 → 🟡 WARN → 标注该文件为"无有效提取内容"
- **EXEC-BL-002**: 两份文件对同一业务要素的描述存在矛盾 → 🔴 CRITICAL → 并列展示矛盾双方，标记 [矛盾待确认]，等待用户指示
- **EXEC-BL-003**: 组织架构表缺少关键字段（如缺少「另属于」字段但存在兼任情况）→ 🟡 WARN → 提示用户补充兼任关系
- **EXEC-BL-004**: 流程文档缺少时限标注 → 🟡 WARN → 标注「该流程未在源文件中找到时限约束」

### Layer 3: Output Guards / 输出防护
- **OUTPUT-BL-001**: 基线文档缺少「待确认事项」章节 → 🔴 CRITICAL → 补充所有标记为 [待确认] 的事项汇总
- **OUTPUT-BL-002**: 提取的条款超过 20% 未标注来源 → 🔴 CRITICAL → 逐条补标注
- **OUTPUT-BL-003**: 基线文档缺少「文件处理日志」→ 🟡 WARN → 补充每份文件的处理结果日志
- **OUTPUT-BL-004**: 组织架构提取结果中人名/岗位名与源文件不一致 → 🔴 CRITICAL → 逐条核对修正

### Layer 4: Iteration Guards / 迭代防护
- **ITER-BL-001**: 用户在上次基线提取后提供了新文件 → 自动触发增量提取，仅处理新增/变更文件，输出「增量变更摘要」
- **ITER-BL-002**: 用户在上次基线提取后修改了源文件 → 自动对比新旧版本，标注变更部分
- **ITER-BL-003**: 连续 3 次提取同一批文件但基线文档无实质变化 → 🔵 INFO → 提示「文件内容未变化，无需重新提取」

**Trigger Handling / 触发处理流程:**
🔴 CRITICAL → 立即停止，输出疑问详情，等待用户指示 | Stop immediately, output question details, wait for instructions
🟡 WARN → 记录警告到处理日志，继续处理但标注不确定性 | Log warning, continue but mark uncertainty
🔵 INFO → 记录信息，正常继续 | Log info, continue normally

***

## 迭代记忆与 Auto-Review / Iterative Memory & Auto-Review

### 🇨🇳
### 增量更新机制

当用户在上次基线提取后追加新文件时：
1. 对比新旧文件清单，识别新增/修改/删除的文件
2. 仅对新增和修改的文件执行提取流程
3. 将新提取结果融合入已有基线文档，标注「[新增 日期]」或「[更新 日期]」
4. 输出「增量变更摘要」：新增条款数 / 修改条款数 / 新增人员数 / 新增流程数

### Auto-Review 机制

每次基线提取完成后，自动执行以下检查：
1. **覆盖率检查**：输入文件总数 vs 有有效提取内容的文件数
2. **完整性检查**：12 类业务要素中哪些类别有提取结果、哪些为空
3. **一致性检查**：同一实体的名称/编码在不同文件中是否一致
4. **矛盾检查**：是否存在对同一业务要素的矛盾描述
5. **输出 Auto-Review 报告**，标注 PASS/FAIL/WARN

> 🇺🇸 English version: see [references/iterative-memory-en.md](references/iterative-memory-en.md)