案例：ASPICE 工程闭环——从断链定位到测试派生

ASPICE 4.0 要求 SYS.1 ↔ SWE.6 双向可追溯。现实中工程团队不是做不出来，是对不上——需求 → 设计 → 代码 → 测试 → 验证之间的对应关系，手工维护成本极高，一旦断链审计就过不去。这一篇用一个真实 ECU 项目把闭环串一遍。

项目背景

一个 ECU 量产前项目（ABZ-Lightcontrol）：

初始痛点：

• 手工追溯覆盖率 < 60%，离 ASPICE 4.0 要求差距明显
• 每次变更过会全员拉通，遗漏是常态
• 测试覆盖率"画出来"的，BP 评估问到细节就崩
• 离评估还有 8 周，按传统方式至少需要 4 名工程师全脱产补两个月

S1 · 追溯重建（Traceability Rebuild）

对应 SYS.2 → SYS.4 → SWE.1 → SWE.2 → SWE.3 → SWE.4 → SWE.5

第一步：把现状摸清楚。

Agent 把 4 个系统（DOORS / GitLab / Polarion / 本地 Excel 台账）里的工件全部拉过来，做跨工具配对。

操作命令（在 Agent 会话里输入）：

把 ABZ-Lightcontrol 的所有文档入库，文档类型按文件名前缀识别。
然后按 Stakeholder → Feature → Component 的顺序建立追溯链，
输出追溯矩阵并高亮断链。

Agent 自动识别的节点类型：

• stkh_req__ Stakeholder Requirement
• feat_req__ Feature Requirement
• comp_req__ Component Requirement
• feat_arc_sta__ Feature Architecture (Static)
• comp_arc_sta__ Component Architecture (Static)

输出三份东西：

无结构化 ID 时怎么办

部分模块是早期外包代码，没有结构化 ID。这时跑：

这个项目没有追溯 ID。请对文档、接口定义、源码、测试做语义分析，
在"设计 → 接口 → 实现 → 测试"之间建立候选追溯，每条给出置信度。

Agent 抽取候选节点（设计文档章节、*.proto / *.idl / *.h 接口、函数签名、测试用例名）→ 跨文档语义匹配 → 每条候选链接给置信度评分（0-1）。工程师确认环节：

• ≥ 0.9：系统自动接受，标记为"自动追溯"
• 0.6–0.9：人工确认
• < 0.6：列入"需人工补充"清单

S2 · 变更影响分析（Change Impact）

对应 SUP.10 配置管理、SWE.5 / SWE.6 回归测试策略

S1 跑完一周后，新一版需求 baseline 进来。传统做法：开评审会拉通。Agent 做法：

把基线 B23_01 和 B23_02 做一次智能 diff，沿追溯链广播到下游，
给回归测试优先级。

这一轮 Agent 跑了 8 分钟，差出 178 条变更，分类为：

整个分析在追溯链上沿正向广播，每条变更精确告诉团队"这一行需求改完，下游 5 个设计文档、12 个代码模块、8 条测试用例可能受影响"。

Graft 跨会话嫁接

变更影响会话不是从零开始的——它直接 graft 之前的追溯会话：

把之前那个 ASPICE 追溯会话 graft 过来，在这里做变更影响分析。

后一个会话直接复用前一个会话沉淀的追溯链数据，不重新跑一遍。详见 Graft 技能。

S3 · 测试用例派生（Test Generation）

对应 SWE.4 单元测试、SWE.5 集成测试

S2 标出 23 条"P1：无测试"需求。Agent 直接派生测试用例。

输入：一条结构化需求

REQ-COMM-203：CAN 报文 0x123 若 100ms 未收到，则触发超时处理并写入 DTC 0x9210

输出（Agent 自动产出）：

// @req: REQ-COMM-203
// @signal: 0x123
// @timeout: 100ms
// @dtc: 0x9210
testcase req_comm_203_timeout_normal()
{
  setTimer(disconnect_timer, 150);
  on timer disconnect_timer {
    checkSignalGroupTimeout(0x123);
    checkDTC(0x9210, kActive);
  }
}
 
testcase req_comm_203_boundary_99ms()  { /* 99ms 不应触发 */ }
testcase req_comm_203_boundary_100ms() { /* 100ms 边界 */ }
testcase req_comm_203_boundary_101ms() { /* 101ms 必须触发 */ }
testcase req_comm_203_fault_injection_burst() { /* 报文抖动注入 */ }
testcase req_comm_203_recovery_after_500ms() { /* 恢复路径 */ }

Agent 派生的用例特征：

• 按需求 ID 命名：testcase_<req_id>_<scenario>
• 注释里写源需求 ID / 信号 / 期望 / 超时
• body 分五段：setup / stimulate / wait / check / log
• 正常 + 边界 + 异常 + 恢复：每条需求至少 3 个用例

同一份需求，Agent 还可以同时产出：

• CANoe CAPL 用例
• dSPACE M-Script 用例
• NI TestStand Sequence

详见 汽车测试自动化方案 和 canoe-test-automation 技能。

S4 · 双向覆盖审计（Coverage Audit）

对应 ASPICE 评估 BP（Base Practice）清单

S1–S3 跑完，离评估还剩 4 周。Agent 出一份审计级覆盖报告：

输出双向覆盖率矩阵，按需求类型、ASIL 等级、业务域分组。
按 ASPICE BP 清单逐项核对。

输出三层维度：

输出格式：Markdown 报告 + html-report 交互看板 + 可提交的 Excel 矩阵（评估老师常要求"按 BP 清单一一对应"，这部分有模板直接出）。

这个案例里 Agent 真正干了什么

实际收益

常见问题

Q：追溯语义可以自定义吗（我们用 :verifies_partially:）？ A：可以。在"集成 → ALM 适配"里配置 Link Type 映射，平台会用你的命名。

Q：自动追溯的置信度阈值能调吗？ A：可以。默认 0.9 / 0.6，项目初期可以调低（多让 Agent 建议），成熟后可调高（少打扰人工）。

Q：覆盖率矩阵能直接塞进 ASPICE 评估报告吗？ A：能。矩阵可导出 Excel / 嵌入 Word 合规报告。评估老师常要求"按 BP 清单一一对应"，这部分 Agent 有模板直接出。

Q：项目跨多个 ALM 工具，能搞吗？ A：能。DOORS / Polarion / Jama / Jira / 飞书项目都有适配器，不要求客户换工具。详见 ALM 平台对接。

汽车工程没有银弹，Agent 的价值不是替代工程师做判断，而是把工程师从机械对齐里解放出来。完整工程闭环细节看 docs/cases/aspice-engineering-loop，方案能力清单看 docs/solutions/automotive/aspice。