doc_parser_skill: - New: verify_flowchart.py (flowchart validation) - Updated: LLM.py (multi-provider: DeepSeek + DashScope) - Updated: image_parser.py (logic tree support, external prompts) - Updated: SKILL.md, prompts/image_prompt.md conflict_detection_skill: - Updated: LLM.py (multi-provider sync) - Updated: detect_conflicts.py (logic tree text conversion) ir_generation_skill: - Replaced old scripts/LLM.py + ir_generator.py with standalone project - New: main.py, config.py, step1-3_*.py, ensemble_merge.py - New: prompts/, tests/ subdirectories tests: - New: acceptance/ test suite with schema validation - Fixed: conftest no longer globally skips non-acceptance tests - Updated: test_sample.py for new ir_generation structure Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,46 @@
|
||||
## 上一轮遗漏分析
|
||||
|
||||
上一轮生成的语义索引经过自动校验，发现以下问题需要修正：
|
||||
|
||||
### 遗漏的逻辑树路径
|
||||
以下逻辑树决策路径未被任何 function_unit 覆盖，请为每条路径生成对应的 function_unit：
|
||||
{missing_paths}
|
||||
|
||||
### 遗漏的概念
|
||||
以下关键概念未在 concepts 列表中出现，请补充：
|
||||
{missing_concepts}
|
||||
|
||||
### 格式问题
|
||||
以下 function_unit 或 concept 的格式不符合要求：
|
||||
{format_issues}
|
||||
|
||||
### concept parent 问题
|
||||
以下概念的 parent 引用有问题（悬空引用或缺少 parent）：
|
||||
{parent_issues}
|
||||
|
||||
---
|
||||
|
||||
请在本次生成中针对以上问题进行修正。注意：
|
||||
1. 你不需要从头生成完整的语义索引，只需要输出**补充和修正**的部分
|
||||
2. function_units 的输出应只包含本次新增或修正的单元（已有的正确单元不需要重复）
|
||||
3. concepts 的输出应只包含本次新增或修正的概念
|
||||
4. 如果格式问题中提到"空壳单元"：删除该 unit，或将其合并到包含实际 action 的 unit 中。纯开关状态不是独立的功能行为
|
||||
5. 如果格式问题中提到"不构成有效路径"：说明你引用了互斥分支上的节点。检查 logic_tree_nodes，确保它们都落在逻辑树的**同一条分支路径**上（例如 n4 是关闭分支，n8 是开启分支，不能共存）
|
||||
6. 如果格式问题提到"缺少 path"或"缺少 sources"：补充对应字段
|
||||
|
||||
## 输出格式
|
||||
|
||||
只输出 JSON：
|
||||
|
||||
{
|
||||
"feature_name": "（与之前相同）",
|
||||
"supplemental_function_units": [
|
||||
// 只放新增的或修正的 function_unit
|
||||
],
|
||||
"supplemental_concepts": [
|
||||
// 只放新增的或修正的 concept
|
||||
],
|
||||
"corrections": {
|
||||
// 需要修正的已有项: { "unit_id或concept_name": { 修正后的字段 }, ... }
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,123 @@
|
||||
你是吉利汽车车机系统（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"]}
|
||||
]
|
||||
},
|
||||
...
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,200 @@
|
||||
你是吉利汽车车机系统的需求分析专家。你的任务是基于给定的精准上下文包，为单个功能单元（Function Unit）提取详细的 **IR 规则（Intermediate Representation Rule）**。
|
||||
|
||||
## 上下文
|
||||
|
||||
下面是一个功能单元的精准上下文包，包含了从原始需求文档中提取的相关文字、表格和逻辑树：
|
||||
|
||||
### 功能单元概要
|
||||
- **unit_id**: {unit_id}
|
||||
- **unit_name**: {unit_name}
|
||||
- **unit_description**: {unit_description}
|
||||
|
||||
### 相关文字段落
|
||||
{texts}
|
||||
|
||||
### 相关表格
|
||||
{tables}
|
||||
|
||||
### 相关逻辑树
|
||||
{logic_trees}
|
||||
|
||||
### 图文冲突仲裁（如有）
|
||||
{resolved_conflicts}
|
||||
|
||||
## IR Schema
|
||||
|
||||
你需要为这个功能单元输出一个 **规则数组（rules）**。每条规则遵循以下 schema：
|
||||
|
||||
```json
|
||||
{{
|
||||
"rule_id": "{unit_id}-DOMESTIC-SYS-FG-INTERRUPT-01",
|
||||
"path": ["国内", "系统限制", "前台打断"],
|
||||
"description": "国内车型，开关开启，系统限制类应用在前台，车速>=15km/h且持续>5秒且非P档时，系统打断应用前台进程、将应用调入后台，显示Toast'在行车状态下无法使用该应用'",
|
||||
"priority": "P0",
|
||||
"sources": [
|
||||
{{"type": "table", "section": "3.1.1", "row": 2, "text_snippet": "打断：车速>=15km/h且持续5秒后..."}},
|
||||
{{"type": "logic_tree", "image_id": "rId16", "node_ids": ["n2","n3","n8","n19","n21","n23","n25","n26"], "priority": "primary_source"}}
|
||||
],
|
||||
"precondition": {{
|
||||
"geographic_scope": "国内",
|
||||
"screen_type": "any",
|
||||
"switch": "开启",
|
||||
"app_type": "系统限制",
|
||||
"app_state": "前台"
|
||||
}},
|
||||
"trigger": {{
|
||||
"operator": "AND",
|
||||
"conditions": [
|
||||
{{"signal": "车速", "operator": ">=", "value": 15, "unit": "km/h"}},
|
||||
{{"signal": "车速_持续时间", "operator": ">", "value": 5, "unit": "秒"}},
|
||||
{{"signal": "档位", "operator": "!=", "value": "P"}}
|
||||
]
|
||||
}},
|
||||
"actions": [
|
||||
{{"type": "system", "description": "打断应用前台进程"}},
|
||||
{{"type": "system", "description": "将应用调入后台"}},
|
||||
{{"type": "user_interaction", "description": "显示Toast", "content": "在行车状态下无法使用该应用"}}
|
||||
]
|
||||
}}
|
||||
```
|
||||
|
||||
## 字段说明（必读）
|
||||
|
||||
1. **rule_id**: 格式为 `{unit_id}-SCOPE-METHOD-BEHAVIOR-NN`，其中：
|
||||
- SCOPE: DOMESTIC（国内）| OVERSEAS（海外）
|
||||
- METHOD: SYS（系统限制）| SDK（SDK限制）| OTHER（其他应用）
|
||||
- BEHAVIOR: FG-INTERRUPT（前台打断）| BG-BLOCK（后台限制启动）| BG-PAUSE（后台暂停功能）| NO-RESTRICT（无限制）| SWITCH-OFF（开关关闭）
|
||||
- NN: 序号从 01 开始
|
||||
|
||||
2. **path**: 层级路径数组（必填）。从 scope 到 behavior 逐级列出，如 `["国内", "系统限制", "前台打断"]`。此字段用于程序化遍历所有功能点。
|
||||
|
||||
3. **description**: 完整但简洁地描述整个规则，必须包含：地理范围 + 开关状态 + 应用类型 + 前后台状态 + 触发条件 + 所有动作。人读取此字段即可设计测试用例。
|
||||
|
||||
4. **priority**: P0（核心安全规则）、P1（重要规则）、P2（边界情况）。
|
||||
|
||||
5. **sources**: 每条规则必须列出所有数据来源。逻辑树类型的 source 必须标记 `"priority": "primary_source"`。文字/表格类型的 source 标记 `"priority": "supplementary"`。**node_ids 必须列举该规则在逻辑树中经历的所有 decision 和 action 节点。**
|
||||
|
||||
6. **precondition**: 规则生效的前置状态条件。必须包含以下字段：
|
||||
- `geographic_scope`（必填）："国内" | "海外"
|
||||
- `screen_type`（必填）："CSD" | "PSD" | "RFD" | "any"（如文档未区分屏幕类型则填 "any"）
|
||||
- `switch`：开关状态（"开启" | "关闭"）
|
||||
- `app_type`：应用类型
|
||||
- `app_state`：应用前后台状态（"前台" | "后台"）
|
||||
如某字段不适用，可省略。
|
||||
|
||||
7. **trigger**: 触发条件对象：
|
||||
- `operator`: "AND" | "OR"
|
||||
- `conditions`: 条件数组，每个条件必须有 `signal`、`operator`、`value`。有单位加 `unit`。
|
||||
- 如为瞬时事件（用户点击），用 `event` 字段。
|
||||
|
||||
8. **actions**: 每个动作必须有 `type`（"system" | "user_interaction"）和 `description`。
|
||||
- `"user_interaction"` 类型必须有 `content` 字段，填写**确切的提示文案**。
|
||||
- **禁止使用占位符**：content 不能是"文案由业务定义"、"待定"、"自定义"等。如果文档中给出了文案，必须原样填入。如果文档确实未给出文案，填写 `"（文档未指定）"` 并标注。
|
||||
|
||||
## Few-shot 示例
|
||||
|
||||
### 示例 1：行车娱乐限制（前台打断）
|
||||
|
||||
**输入上下文**：国内车型，开关开启，系统限制类应用在前台，车速>=15km/h且持续>5秒且非P档时，打断应用并显示Toast"在行车状态下无法使用该应用"。
|
||||
|
||||
**期望输出**：
|
||||
|
||||
```json
|
||||
{{
|
||||
"rule_id": "FU-001-DOMESTIC-SYS-FG-INTERRUPT-01",
|
||||
"path": ["国内", "系统限制", "前台打断"],
|
||||
"description": "国内车型，开关开启，系统限制类应用在前台，当车速>=15km/h且持续超过5秒且非P档时，系统打断应用前台进程、将应用调入后台，并弹出Toast提示'在行车状态下无法使用该应用'",
|
||||
"priority": "P0",
|
||||
"sources": [
|
||||
{{"type": "table", "section": "3.1.1", "row": 2, "text_snippet": "行车娱乐限制：目标应用/功能处于前台时 ○ 打断：车速>=15km/h且持续5秒后...", "priority": "supplementary"}},
|
||||
{{"type": "logic_tree", "image_id": "rId16", "node_ids": ["n2","n3","n8","n19","n21","n23","n25","n26"], "priority": "primary_source"}}
|
||||
],
|
||||
"precondition": {{
|
||||
"geographic_scope": "国内",
|
||||
"screen_type": "any",
|
||||
"switch": "开启",
|
||||
"app_type": "系统限制",
|
||||
"app_state": "前台"
|
||||
}},
|
||||
"trigger": {{
|
||||
"operator": "AND",
|
||||
"conditions": [
|
||||
{{"signal": "车速", "operator": ">=", "value": 15, "unit": "km/h"}},
|
||||
{{"signal": "车速_持续时间", "operator": ">", "value": 5, "unit": "秒"}},
|
||||
{{"signal": "档位", "operator": "!=", "value": "P"}}
|
||||
]
|
||||
}},
|
||||
"actions": [
|
||||
{{"type": "system", "description": "打断应用前台进程"}},
|
||||
{{"type": "system", "description": "将应用调入后台"}},
|
||||
{{"type": "user_interaction", "description": "显示Toast", "content": "在行车状态下无法使用该应用"}}
|
||||
]
|
||||
}}
|
||||
```
|
||||
|
||||
### 示例 2：行车娱乐禁止（后台启动拦截）
|
||||
|
||||
**输入上下文**：国内车型，开关开启，应用在后台，非P档时阻止应用启动，提示"请在P挡时使用该功能/应用"。
|
||||
|
||||
**期望输出**：
|
||||
|
||||
```json
|
||||
{{
|
||||
"rule_id": "FU-002-DOMESTIC-SYS-BG-BLOCK-01",
|
||||
"path": ["国内", "系统限制", "后台限制启动"],
|
||||
"description": "国内车型，开关开启，目标应用处于后台，当用户尝试启动应用且档位非P档时，系统限制应用/功能启用，并弹出Toast提示'请在P挡时使用该功能/应用'",
|
||||
"priority": "P0",
|
||||
"sources": [
|
||||
{{"type": "table", "section": "3.1.1", "row": 2, "text_snippet": "行车娱乐禁止：目标应用/功能处于后台时 ○ 限制：非P挡时，限制目标应用/功能启用...", "priority": "supplementary"}},
|
||||
{{"type": "logic_tree", "image_id": "rId17", "node_ids": ["n1","n2","n5","n7"], "priority": "primary_source"}}
|
||||
],
|
||||
"precondition": {{
|
||||
"geographic_scope": "国内",
|
||||
"screen_type": "any",
|
||||
"switch": "开启",
|
||||
"app_state": "后台"
|
||||
}},
|
||||
"trigger": {{
|
||||
"operator": "AND",
|
||||
"conditions": [
|
||||
{{"signal": "应用请求启动", "operator": "==", "value": true}},
|
||||
{{"signal": "档位", "operator": "!=", "value": "P"}}
|
||||
]
|
||||
}},
|
||||
"actions": [
|
||||
{{"type": "system", "description": "限制应用/功能启用"}},
|
||||
{{"type": "user_interaction", "description": "显示Toast", "content": "请在P挡时使用该功能/应用"}}
|
||||
]
|
||||
}}
|
||||
```
|
||||
|
||||
## 关键要求
|
||||
|
||||
1. **逻辑树为唯一权威来源**：触发条件和动作序列必须严格按逻辑树路径建模。文字/表格描述仅用于补充确切措辞（如 Toast 文案），不得覆盖或曲解逻辑树路径。在 sources 中，逻辑树类型标记 `"priority": "primary_source"`，文字/表格标记 `"priority": "supplementary"`。
|
||||
|
||||
2. **信号和数值必须精确**：禁止写"车速超过阈值"，必须写 `{{"signal": "车速", "operator": ">=", "value": 15, "unit": "km/h"}}`。
|
||||
|
||||
3. **条件必须完整**：逻辑树中的每个 decision 条件必须对应 trigger.conditions 中的一条。如果文档说"车速>=15km/h 且持续超过5秒 且非P档"，这三个条件必须全部出现。
|
||||
|
||||
4. **每条规则必须自包含**：人仅凭一条 rule JSON 就能设计出对应的测试用例。必须包含：geographic_scope、screen_type、开关状态、应用类型、前后台状态、完整触发条件、所有动作及确切 Toast 文案、来源引用。
|
||||
|
||||
5. **禁止占位符**：`"user_interaction"` 类型的 `content` 不能是"文案由业务定义"、"待定"、"自定义"。如文档确实未给出文案，填 `"（文档未指定）"`。
|
||||
|
||||
6. **逻辑树节点必须追踪**：在 sources 中列出该规则在逻辑树中经历的所有 decision 节点和 action 节点。
|
||||
|
||||
7. **多条规则**：如果一个功能单元包含多个独立行为分支，输出多条规则分别描述。
|
||||
|
||||
8. **开关关闭状态**：开关关闭时所有限制失效，这也必须作为一条规则输出（path: ["...", "开关关闭", "无限制"]）。
|
||||
|
||||
{format_feedback}
|
||||
|
||||
## 输出格式
|
||||
|
||||
**只输出 JSON 数组，不要有任何其他文字或 markdown 标记**：
|
||||
|
||||
[
|
||||
{{ ... }},
|
||||
{{ ... }}
|
||||
]
|
||||
|
||||
注意：即使只有一个规则，也必须用数组格式 `[...]`。
|
||||
Reference in New Issue
Block a user