Nox-Lumen AutoASPICE 全链追溯
方案定位
面向需要通过 Automotive SPICE 4.0 评估的研发团队，把追溯工作从"评估前加班补表"变成"开发过程中自然沉淀"。覆盖 V-Model 左侧（需求 → 架构 → 设计 → 实现）与右侧（单元测试 → 集成测试 → 系统测试）全链路。
参考实际演示：📋 ASPICE 能力演示（四场景案例）
行业痛点
ASPICE 4.0 要求 SYS.1 → SYS.5 与 SWE.1 → SWE.6 全过程域双向可追溯。现实中：
| 痛点 | 代价 |
|---|---|
| 需求文档 / 架构 / 设计 / 测试分散在 Word、Excel、DOORS、Polarion、工具链本地，追溯靠人工 | 项目中期开始补链，评估前一个月通宵补表 |
| 每个版本变更都要重新评估下游影响 | 影响分析靠会议拉通，遗漏是常态 |
| 测试用例和需求 ID 不匹配 | 项目交付时测试覆盖率假性达标 |
| 覆盖率矩阵是"画出来"的，不是"算出来"的 | 评估老师一句话问崩 |
四大能力（对应 V-Model 四种场景）
场景 1：追溯重建（Traceability Rebuild）
对应 SYS.2 → SYS.4 → SWE.1 → SWE.2 → SWE.3 → SWE.4 → SWE.5
从异构历史文档（Word 需求文档、Excel 架构台账、老项目遗留代码）出发，Agent 读全文 → 抽节点 → 建链接 → 出审计报告。
- 自动识别
stkh_req__/feat_req__/comp_req__/feat_arc_sta__/comp_arc_sta__等节点类型 - 对 无结构化 ID 的项目做语义追溯发现
- 输出追溯审计看板 + 断链清单 + 按问题类型分布
详见 追溯重建场景。
场景 2：变更影响分析（Change Impact）
对应 SUP.10 配置管理、SWE.5 / SWE.6 回归测试策略
当需求 / 架构版本升级：
- 差分基线 A → B 的 178+ 条变更
- 沿追溯链广播到下游节点（详细设计、代码模块、测试用例）
- 生成回归测试推荐清单（按 P0/P1/P2 优先级）
这是 Graft 跨会话嫁接的关键应用——变更会话从追溯会话引用全链数据。详见 变更影响场景。
场景 3：测试用例生成（Test Generation）
对应 SWE.4 单元测试、SWE.5 集成测试
从结构化需求出发，自动生成 CAPL / M-Script / TCL 测试用例，支持 FMEA 故障注入与边界场景。
场景 4：双向覆盖审计（Coverage Audit）
对应 ASPICE 评估 BP（Base Practice）清单
把传统"手工画的覆盖率矩阵"变成系统算出来的可信矩阵：
- 需求 → 测试的正向覆盖
- 测试 → 需求的反向覆盖
- 按需求类型、业务域、ASIL 等级多维分组
- 按评估 BP 清单按项核对
详见 覆盖审计场景。
支持的追溯语义
| 语义 | 含义 | 使用场景 |
|---|---|---|
:satisfies: | A 需求满足 B 需求 | Stakeholder → Feature → System → Component |
:fulfils: | 架构 / 实现履行需求 | Component Req → Architecture / Code |
# req-Id: | 源码注释绑定需求 | Implementation → Requirement |
fully_verifies: / partially_verifies: | 测试完全 / 部分验证某需求 | Test → Requirement |
| CAN 信号绑定 | 集成测试 → DBC 报文 | 信号一致性追溯 |
操作步骤
操作场景 A：结构化项目追溯建立
前提
需求 / 架构 / 测试条目都带 ID（例如 stkh_req__ABZ_001、feat_req__ABZ_010、comp_arc_sta__ABZ_20 等）。
步骤
-
把项目的所有文档录入知识库：
-
触发追溯建立：
-
确认矩阵：Agent 输出追溯矩阵 + 缺口清单，工程师在清单上逐条确认 / 补全。
-
回写到 ALM：
操作场景 B：非结构化项目（自动追溯发现）
前提
历史项目 / 开源模块，没有结构化 ID，追溯关系不存在。
步骤
Agent 会抽取候选节点（设计文档章节、*.proto / *.idl / *.h 接口、函数签名、测试用例名）→ 做跨文档语义匹配 → 对每条候选链接给置信度评分（0–1）。
工程师确认环节：
- ≥ 0.9：系统自动接受，标记为"自动追溯"
- 0.6–0.9：人工确认
- < 0.6：列入"需人工补充"清单
操作场景 C：需求变更影响分析
前提
有两份需求基线（A vs B），例如版本冻结前 vs 现在。
步骤
Agent 会做：
- 文本 diff + 语义 diff（区分"只是改措辞"和"实质性变更"）
- 按追溯链广播：每条变更 → 哪些架构条目 / 设计条目 / 代码 / 测试受影响
- 回归测试优先级：
- P0：实质变更 + 有测试覆盖 → 必须回归
- P1：实质变更 + 无直接测试 → 需补测试
- P2：措辞变更 → 冒烟即可
利用 Graft 跨会话
变更影响分析会话可以直接 Graft 之前的追溯会话，复用追溯链数据：
详见 Graft 技能。
操作场景 D：双向覆盖审计
前提
项目快到评估前，需要一份可信的覆盖矩阵。
步骤
Agent 会：
- 正向覆盖率：每条需求有多少测试用例覆盖（0 的是漏洞）
- 反向覆盖率：每个测试用例对应多少需求（孤立测试是噪声）
- ASPICE BP 逐项核对：按评估检查表项对照现状
输出格式：Markdown 报告 + html-report 交互看板 + 可提交的 Excel 矩阵。
与演示案例的映射
以下 4 个演示案例直接对应本章 4 个操作场景：
合规参考
| 标准 | 覆盖过程域 |
|---|---|
| ASPICE 4.0 | SYS.1 – SYS.5、SWE.1 – SWE.6、SUP.9 – SUP.10 |
| ISO 26262 | Part 6 软件开发、Part 8 支持过程 |
| ISO/SAE 21434 | 网络安全开发过程 |
客户价值
| 维度 | 传统方式 | combo agent |
|---|---|---|
| 追溯矩阵准备 | 评估前 4–6 周集中补 | 开发过程中自然沉淀 |
| 变更影响分析 | 会议 + 邮件拉通 | 3–5 分钟自动广播 |
| 测试覆盖率 | 人工统计，易美化 | 系统算出，可审计 |
| 评估"灵魂拷问" | 答不上来 | 有据可查 |
常见问题
Q：追溯语义可以自定义吗（我们用 :verifies_partially:）？
A：可以。在"集成 → ALM 适配"里配置 Link Type 映射，平台会用你的命名。
Q：自动追溯的置信度阈值能调吗？ A：可以。默认 0.9 / 0.6，项目初期可以调低（多让 Agent 建议），成熟后可调高（少打扰人工）。
Q：覆盖率矩阵能直接塞进 ASPICE 评估报告吗？ A：能。矩阵可导出 Excel / 嵌入 Word 合规报告。评估老师常要求"按 BP 清单一一对应"，这部分 Agent 有模板直接出。
相关文档
- 🎯 案例演示：ASPICE 四场景完整案例
- 📖 方案组合：AI 需求管理 · AI 代码审查 · 汽车测试自动化
- 🛠️ 相关技能：automotive-process-analyzer · graft（跨会话嫁接）
- 🔌 系统对接：ALM 平台对接
- 🏠 场景总览：汽车场景