「汽车行业AI Coding最佳实践」系列·第7讲:AI代码要有据可查——需求-代码-测试双向追溯与ASPICE审计

一、痛点：代码越快，审计越慌

很多团队对 AI 代码助手又爱又怕。爱的是速度——单个会话里能生成过去一周的量；怕的是交付节点前那一周：质量负责人开始补追溯矩阵，把需求、代码、测试用例一张张对表，对着对着发现某段 AI 生成的函数「找不到爹」——不知道它实现的是哪条需求，自然也没人敢说它被哪条用例覆盖过。

这正是 ASPICE 想治的病。它是汽车软件的过程改进与能力评定标准，由 VDA QMC 维护，OEM 在 ECU 软件项目里普遍要求供应商达到 CL2（能力等级 2）以上。CL2 的核心不是「代码写得好」，而是过程可管理：开发可文档化、可审计、可重复。双向可追溯性是其中最常被挑刺的一环——需求必须连到代码，代码必须连到测试，测试结果必须回归需求。一个函数找不到需求出处，在评审里就是一条扣分项。

二、概念：双向追溯到底要什么

双向追溯不是一张表那么简单，它是一条完整证据链：

• 前向追溯
  每条需求 → 对应设计与代码 → 对应测试用例，回答「这条需求落实了没有、用什么验证」；
• 后向追溯
  每段代码、每条测试 → 回指需求 ID，回答「这段代码为什么存在、改它会影响谁」。

在评估里，SWE.1.BP6 的双向追溯是实战中失败率最高的基础实践——部分覆盖、口头链接都不算数；SWE.3 则要求详细设计与代码并存。换句话说：文档与代码缺一不可，链接要机器可查，不能靠「我记得」。

把 ASPICE 的过程域摊开看，追溯贯穿软件开发的每一级：SWE.1 系统需求分析、SWE.2 软件需求分析、SWE.3 软件架构设计、SWE.4 软件详细设计与单元实现、SWE.5 单元验证、SWE.6 软件集成与集成测试。每一级之间都有明确的追溯要求，上一级的产出是下一级的输入，测试反过来逐级验证。这也解释了为什么「只让 AI 写代码」在车规语境下走不通——代码只是 SWE.4 那一层的产物，前后每一层的链接都要补上。

三、最佳实践：让 AI 生成的每一行都有出处

1. 把需求 ID 写进 Prompt

最直接的开关在生成那一刻。项目规范里统一编号，比如 SW-REQ-0421：ACC 目标车跟随距离误差 ≤ 0.5m。让 AI 生成前先回显它要落实的需求 ID，代码文件头、函数注释、提交信息里都带上这个 ID。没有链接需求 ID 的代码不允许生成——把这条写进团队规则，AI 助手在生成时就带上「身份证」。

2. 让追溯工具链开源化、自动化

手工对表撑不住 AI 的产出速度，追溯必须交给工具。两个开源思路值得参考：

• doorstop
  把文本需求直接存进版本控制，每条需求是一个 YAML 文件，代码提交和需求变更进同一个仓库，工具自动校验需求树有没有断链、有没有孤儿需求，还能发布成多种格式的追溯文档；
• flashtrace
  从 Markdown 写的规格说明出发，追踪到引用这些需求的源代码，一条命令输出追溯关系，适合「规格在仓库里、代码在仓库里」的团队。

它们的共同点：追溯是持续跑出来的，不是审计前突击拼的。需求、代码、测试在同一次提交里变化，追溯图同步更新，审计时导出即可。

3. 测试用例与需求 ID 绑定

AI 生成的单元测试、集成测试，每条用例的标题或注释里回链需求 ID。CI 里跑完，测试报告按需求 ID 聚合——哪些需求有覆盖、哪些没有，一眼可见。这就把「测试回归需求」从口号变成了机器可核验的输出。

4. AI 辅助产物本身也要留痕

审计不只查代码，还查「过程」。AI 用的什么工具、什么模型版本、当时给了什么 Prompt、中间改过几轮——这些都应该随变更记录存档。证据链里包含「这段代码是怎么来的」，比只留下代码本身更经得起问。Git 提交信息里写明「由 AI 生成初稿、工程师修改」这类来源标记，半年后做变更影响分析时，一眼就能分清哪段可以直接信任、哪段要重点复核。

5. 需求变更时，让 AI 帮你更新追溯

车规项目的需求是活的。某条需求从「跟随距离误差 ≤0.5m」改成「≤0.3m」时，受影响的代码函数、测试用例、标定参数散落各处，人工找容易漏。这时可以反向用 AI：把变更后的需求 ID 和旧代码给 AI，让它列出所有引用过这条需求 ID 的位置，输出一份「待更新清单」，工程师按清单逐一确认。追溯链一旦建好，AI 就成了链条上的导航员——顺着链接找影响面，而不是靠记忆猜。

四、汽车行业落地建议

先想清楚追溯矩阵长什么样：一张表，行是需求 ID 与需求描述，列是设计文档、代码文件、测试用例、验证结果，每个交叉格要么是链接要么是「未覆盖」标记。这张表不是 Excel 手拉出来的，是从版本控制与 CI 里自动聚合出来的。

建议一：从一条需求线跑通闭环。选一个非安全相关的信号处理需求，从需求 ID → AI 生成 → 单元测试 → 追溯导出，整条链在两周内跑通，作为团队样板。

建议二：追溯矩阵随 CI 自动生成。把 doorstop 或 flashtrace 挂进流水线，每次提交后自动校验并导出追溯报告，失败即阻断合入，让「缺追溯」和「编译错误」一样不可接受。

建议三：把审计证据前置到日常。把「证据随时可导出」当成验收标准，而不是交付前突击补。这样 ASPICE CL2 评审准备时间可以从数周缩到数小时——因为证据一直在。

收束

AI 把写代码的成本压到了地板，追溯把证明「代码为什么对」的成本顶了上来。写得多快不重要，说得清才重要。让需求 ID 进 Prompt、让追溯工具进 CI、让证据随提交持续累积——AI 越快，这套「有据可查」的底子越要提前打好。

读到这里如果觉得有帮助，欢迎点赞、点「在看」，并关注「AI 虾忙活」。下一讲我们聊测试与验证，看 AI 生成的代码怎么过单元、集成与 HIL 的关。