Arteris 的 AI 实践：先把失败定义清楚

让 AI 找 Bug，最容易展示的是它生成了多少测试。工程团队更需要知道：这些测试里，哪些真的暴露了缺陷，确认它们又花了多少时间？

近日，Arteris 工程博客介绍了内部 C++ 约束激励库的 AI 开发实践。作者先定义可检查的失败，让模型搜索触发场景，再由程序检查、工程师调查。这项实践围绕验证团队使用的软件库展开。

对 AI+EDA，这个切入口很具体：先把“什么算错”写清楚，再决定模型可以探索多远。搜索速度、检查质量与人工处置成本，要放在同一张账单上。

失败判据决定搜索能走多远

按博客描述，该库从数据模型与字段约束生成合法激励。作者围绕段错误、内存泄漏和生成样本违反约束展开搜索，并把生成后的合法性检查纳入库的默认行为；不合法的样本会触发定义好的异常。

这套分工可以拆成四步：工程师规定有效输入和失败条件，模型提出候选场景，执行环境运行并留下证据，工程师判断缺陷及修复方式。模型的说法在第二步结束，后面的判断必须接到可运行的程序上。

一个能在有效使用条件下稳定复现的崩溃，比一段“这里可能有问题”的解释更容易进入缺陷处理流程。它给工程师留下了输入、运行结果和调查入口。不过，崩溃本身还不能说明问题出在库、调用代码还是测试环境；这些责任仍需拆开。

约束检查又把搜索目标推进了一层。多个字段之间的关系可能很难同时满足，但样本生成后，可以逐项检查关系是否成立。这里利用的是特定任务中“构造难、检查相对容易”的差异，不能泛化为所有验证问题都便宜。

这也是值得借鉴的架构选择：让重要失败能够被程序明确报告。只给模型更多提示，无法补上一个缺失的判据。判据写得含糊，模型即使找到异常，团队也可能争论很久才知道它有没有价值。

检查器也需要被检查

客观判据能减少争论，却不会自动保证判据正确。若激励生成器与检查器沿用同一处错误解释，二者可能一起接受错误结果；只检查字段范围，也可能漏掉字段间关系。因此，采用这类方法时，还要审查检查器对规格的理解。

所以，要区分三件事：测试能否运行，结果是否满足已编码约束，约束是否忠实表达规格。第一件事是执行问题，第二件事是检查器问题，第三件事需要规格理解和人工 review。通过前两项，不能替代第三项。

工具能让部分失败更容易观察。LLVM 官方文档说明，AddressSanitizer 能检测越界访问、释放后使用等内存错误，LeakSanitizer 用于内存泄漏检测。这类工具可以为内存错误提供可执行的检查入口。

检查器的导入也应有验收。可以准备一组已知正确样本和人工植入错误的样本，确认它能接受前者、拒绝后者；再检查边界输入、异常路径和报告是否足够定位问题。这一步能帮助团队在扩大搜索前，先校验检查器。

还要保护检查器本身。若让同一个代理既生成候选、又随时修改通过条件，它可能通过放松条件让报错消失。试点时宜固定判据版本，候选生成与规则修改分别 review，并保留修改记录。否则一次“通过”究竟意味着修复了缺陷还是改宽了门槛，就说不清。

搜索便宜以后，检查可能变贵

作者提出按搜索与验证所需时间的关系判断 AI 适用性。研发负责人还得把验证成本拆细。单次运行便宜，乘上大量候选后可能占满队列；自动报错容易，人来理解每份报错未必容易。

我们建议用一张完整成本账：判据建设和维护，加上候选生成、执行检查、去重分诊、根因分析以及修复回归。采用这套核算框架，可以把模型搜索收益与后续处置负担一起衡量。

“测试数量”是活动指标。“可复现、去重后的有效缺陷数量”更接近质量指标。最后还要看，在相同预算和任务范围内，团队多解决了哪些问题，或者减少了多少确认与处置工时。三个指标不能互相代替。

重复报错尤其容易放大成绩。同一个根因可能被不同输入反复触发。对一线工程师，十份相似日志未必比一份最小复现更有用；对模型评测，如果把每份日志都记作独立发现，数字会掩盖人工负担。

性能问题还会提高判据成本。认定一次生成“太慢”，需要先限定模型复杂度、输入规模、机器环境与合理基线。否则模型可能只是在制造更重的任务。功能失败常能给出明确结果，性能退化则往往需要可比较的实验条件。

因此，给搜索设置运行时间、候选数量和人工分诊预算很有必要。预算用完仍没有有效发现，是一次有边界的试验结果；它既不能证明软件没有缺陷，也不应被包装为“模型成功完成验证”。

迁移到芯片验证，要换验收对象

内部 C++ 激励库和 RTL DUT 是不同的被测对象。前者生成合法样本，只说明生成结果通过了相应检查；这些样本送进芯片设计之后，设计是否正确，还要由 testbench、断言、参考模型等对应手段判断。

一个约束也可能限制了探索范围。若合法性规则排除了规格要求验证的边界状态，搜索过程再积极，也无法触及那部分问题。迁移方法时，先审查输入空间是否合理，比增加候选数量更有意义。

可以用一条示意流程理解这种迁移：工程师指定一项协议属性和允许的输入空间，模型提出激励序列，仿真环境执行，checker 报告违例。团队随后固定版本与随机种子、缩小复现、核对规格，再决定是否修复 DUT 或测试环境。这条示意流程把候选生成、失败确认和修复责任连接起来。

这里要分清：找到反例可以推翻某项具体判断，没有找到反例通常只说明在当前条件和预算下没有观察到失败。仿真搜索不能凭一次无报错结果就宣称覆盖所有行为。形式验证的结论也依赖属性、环境假设和证明范围，不能把两类证据混写。

芯片研发团队采用 AI 搜索时，首先要接好已有验证体系：失败如何归档，规格版本如何锁定，修复如何回归，未关闭问题由谁负责。脱离这些交接，模型输出越多，现场可能越忙。把专业知识、工具执行与问题记录接入同一条研发流程，也是 AI+EDA 工程化落地的实际入口；可追溯的结果，比孤立的问答更便于团队接手。

试点先问三件事

第一，失败是否说得清。必须明确被测对象、有效输入、失败条件和例外情况。若一开始就需要模型判断“设计架构是否优秀”，试点已经跨入高度依赖上下文的领域，不能沿用崩溃检查的成本预期。

第二，判据是否可信。能否用已知样本校验检查器，能否追溯规格与规则版本，失败能否独立复现？如果答案不清楚，先补检查能力。模型找得更快，只会让这个缺口更快显露。

第三，收益是否扣除了处置成本。对工程师，验收证据是可复现输入与有效定位信息；对流程负责人，是版本、工具执行和回归记录；对研发负责人，是去重后的缺陷价值与总工时。各方需要的证据不同，单一“生成量”无法交差。

试点可以先选择执行快、判据明确、失败可复现的局部任务，并与现有人工或自动化方法保持相同范围和预算做比较。我们建议同时记录无效候选比例、重复发现比例和人工确认时间。它们有助于判断下一步该升级模型、补检查器，还是缩小搜索目标。

Arteris 这篇博客值得讨论的地方，是它把 AI 的使用问题落到了工程流程的接口：谁定义失败，什么程序检查失败，谁解释证据。对团队而言，这种分工有助于把模型探索接到可执行、可复查的工程流程上。

对准备试点的团队，我们更建议从一张验收单开始：写出被测对象、输入边界、检查器、复现材料和人工预算。五项能落地，就有条件让模型多搜索；五项仍含糊，先建设验证能力。搜索自由度应随证据质量扩大，工程责任则要一直有人接住。

作者：麒芯

免责声明：本文依据公开资料作工程方法分析，试点建议和迁移示意供团队结合项目条件评估。实际设计与验证结论由相应工程流程确认。

参考资料：

Arteris 工程博客：《From Bug Hunting to Engineering Methodology: Lessons from AI-Driven Development》

LLVM/Clang 官方文档：《AddressSanitizer》

LLVM/Clang 官方文档：《LeakSanitizer》