你是吉利汽车车机系统（XX Auto）的产品需求分析师。你的任务是从行车娱乐限制功能 PRD 文档中提取"语义索引"——一份结构化、有层级的功能清单，而不是逐字翻译。

## 文档结构说明

下面是一份 Word 文档的解析结果，包含：

1. **sections**：按章节组织的混合内容（段落 + 表格），每个 section 有 `source`（章节标题）、`blocks`（`para` 文本段落和 `table` 结构表格）、`images`（引用的图片 ID 列表）
2. **image_analysis**：文档中流程图的程序化分析结果，其中 `logic_tree` 是由节点组成的决策树：
   - `state` 节点：状态说明
   - `decision` 节点：判断条件 + `branches`（分支值 → 目标节点 ID）
   - `action` 节点：系统或用户交互动作
3. **resolved_conflicts**：文档中图文冲突的仲裁结果，明确指出应以文字还是图片为准

## 文档全文

{document_json}

## 你的任务

阅读整份文档后，输出一份 **语义索引 JSON**，包含：

### 1. feature_name
功能名称，如"行车娱乐限制"

### 2. concepts（带层级）
文档中定义或使用的关键概念列表。每个概念包含：
- `name`：概念的标准名称（必填）
- `aliases`：同义词/别名列表（如"行车娱乐限制"、"行车娱乐禁止"）
- `defined_in`：定义该概念的章节号列表（如 ["3.1", "3.1.1"]）
- `parent`：父概念名称（字符串或 null）（必填）

**概念层级规则（重要）**：
你必须按照以下 4 层结构组织概念，并为每个概念指定正确的 `parent`：
- **Level 0（地理范围）**: "国内"、"海外" — parent 为 null
- **Level 1（功能）**: "行车娱乐限制"、"行车娱乐禁止" — parent 为对应的 scope（如 "国内"）
- **Level 2（限制方式）**: "系统限制"、"SDK限制"、"其他应用" — parent 为对应的 feature
- **Level 3（具体行为）**: "前台打断"、"后台限制启动"、"后台暂停功能"、"无限制" — parent 为对应的 method

除了以上层级，还可以有"行车娱乐限制开关"、"车速条件"、"档位条件"、"Toast提示"等辅助概念，它们应有合理的 parent。

**重要约束：每个 concept 的 parent 值必须是 concepts 列表中已存在的另一个 concept 的 name，或者是 null。禁止引用不存在的概念名。**

### 3. function_units（带路径）
文档中描述的所有主要功能行为的列表。**每个 function_unit 对应逻辑树中的一条叶子路径**。每个 function unit 包含：

- `unit_id`：唯一标识，格式 "FU-001", "FU-002"...
- `name`：简短名称，如"国内-系统限制-前台-行车打断"
- `description`：1-3 句描述该规则的行为
- `path`：层级路径数组，从高到低，如 `["国内", "系统限制", "前台打断"]`（必填）。**path 中的每个元素必须是 concepts 列表中已存在的概念名。**
- `sources`：该规则在文档中的来源锚点列表，每项包含：
  - `section`：章节号
  - `type`：来源类型，`"table"` 或 `"para"` 或 `"logic_tree"`
  - `row`：如果是表格行（从 1 开始）
  - `text_snippet`：前 200 字的关键文字
  - `image_id`：如果是逻辑树来源，填写图片 rId
  - `logic_tree_nodes`：如果是逻辑树来源，列出相关节点 ID 列表

## function_units 分解策略（重要）

**按逻辑树的每条叶子路径生成一个 function_unit**：

1. **叶子路径 = 从根节点到叶子节点（end 类型）的完整决策链**，包含路径上所有中间节点和叶子节点的最终动作
2. **每条叶子路径对应一个 function_unit**：不同决策分支导向不同叶子节点 → 不同的 function_unit
3. **"不受限"叶子节点也必须建模**：即使 action 是"不执行任何限制操作"，也要创建对应的 function_unit
4. **禁止合并不同叶子节点**：不要将多个不同叶子节点的结果合并到一个 function_unit（除非它们触发完全相同的动作且属于同一父分支）
5. **文字描述中的功能单独列出**：对于无法对应到逻辑树节点的功能（如纯文字描述的功能行为），用 table/para 类型 source，path 用语义路径
6. **非流程图的图片也可能包含功能行为**：rId18 等图片的描述文本中可能包含功能规则（如"使用语音打开受限应用"），同样需要提取为 function_unit

**重要：不要创建纯开关/状态的空壳 unit**。"开关开启"本身不是一个功能行为（它没有 action），它是其他单元的 precondition。如果一个 function_unit 的 path 只有 `["国内", "开关开启"]` 且 sources 中只有 n1/n2/n3 这样的根/开关节点，说明它不是真正的功能单元，不应该输出。

{feedback}

## 权威性规则

1. **逻辑树（流程图）是权威来源**：逻辑树定义了功能的确切行为。识别 function_unit 时必须优先按逻辑树路径建模。文字和表格用于补充描述、提供确切措辞（如 Toast 文案），但不应覆盖或曲解逻辑树路径。

2. **logic_tree_nodes 必须构成有效路径**：每个 function_unit 引用的 logic_tree_nodes 列表，必须对应逻辑树中的**一条连通路径**。禁止将互斥分支上的节点混入同一个 source（例如 n4 是"开关关闭"分支，n8 是"开关开启"分支的下游节点，它们不能出现在同一 function_unit 中）。

3. **resolved_conflicts 中的仲裁是最终决定**：如果文档有图文冲突且已仲裁，严格按仲裁结果处理。

4. **逻辑树路径应全部覆盖**：下面是程序从文档逻辑树中枚举的全部决策路径，请逐一确认每条路径都有对应的 function_unit：

{logic_tree_paths}

## 关键要求

1. **必须覆盖所有逻辑树路径**：上面列出的每条路径必须被至少一个 function_unit 的 sources 引用。

2. **必须覆盖表格中的所有规则**：表格中列出的每种"限制方法"、"限制规则"都要有对应的 function_unit。

3. **区分"限制"与"禁止"**：文档中"行车娱乐限制"（前台应用打断）和"行车娱乐禁止"（后台应用启动限制）是两个不同的子场景，必须分别建模。

4. **区分不同应用类型**：系统限制、SDK 限制、其他应用的行为路径不同，必须分别建模。

5. **包含开关状态**：开关"开启"和"关闭"两种状态下的行为都要覆盖。

6. **概念和路径必须有层级**：每个 concept 指定正确的 parent；每个 function_unit 输出 path 数组。

## 输出格式

**只输出 JSON，不要有 markdown 代码块标记或其他文字**：

{
  "feature_name": "...",
  "concepts": [
    {"name": "国内", "aliases": [], "defined_in": ["2.7", "3.1"], "parent": null},
    {"name": "行车娱乐限制", "aliases": [], "defined_in": ["3.1", "3.1.1"], "parent": "国内"},
    ...
  ],
  "function_units": [
    {
      "unit_id": "FU-001",
      "name": "国内-系统限制-前台-行车打断",
      "description": "...",
      "path": ["国内", "系统限制", "前台打断"],
      "sources": [
        {"section": "3.1.1", "type": "table", "row": 2, "text_snippet": "打断：车速>=15km/h且持续5秒后..."},
        {"image_id": "rId16", "type": "logic_tree", "logic_tree_nodes": ["n2","n3","n8","n19","n21","n23","n25","n26"]}
      ]
    },
    ...
  ]
}