AI 把 RTL 修对了，它用过原代码吗？

AI 把一段坏掉的 RTL 改到测试通过，能说明它会修芯片代码吗？工程团队还需要追问：测试从什么时候开始比较，复位怎样施加，以及模型究竟利用了多少原有代码。

2026 年 10 月 20 日提交的预印本《What Do RTL Repair Benchmarks Actually Measure?》把这些问题放到了同一套评测中。作者 Yeyin Eva Zhu 和 Rishabh Ranawat 发现，调整复位和首周期比较规则，可以让“提供规格有没有帮助”的表面结论发生反转。加入只给规格、不提供故障 RTL 的对照后，修复得分的解释也变得复杂。

修复成功率需要附上验收条件。一次输出通过测试，只覆盖了最终结果的一部分证据；从结果追溯到修复能力，还要审计判题方法和输入对照。

先把两类错误分开算

论文构建的 RTLRepairBench，即 RTL 修复评测集，包含 459 个留出用例，其中 374 个属于语法或工具诊断类变异，85 个属于行为变异。训练资源 RTLRepairDataset 则提供故障代码与修复代码配对，服务于修复任务训练。

两类题的难度来源不同。缺少结束符、声明与使用不匹配等问题，工具可以提供直接线索；代码通过检查却做错运算、选错条件分支，则需要进一步理解目标行为。把它们合成一个正确率，会遮住模型在行为修复上的短板。

这里的分类按论文的工具门禁划分，不能把全部 374 个用例都理解为无法编译的语法错误。其中还包含时序块中阻塞赋值等工具诊断类问题。工具接受与功能正确，是两道不同的检查。

作者用不同源设计构建训练集和评测集，并检查标准化后的源设计标识没有重叠。这能降低同源设计直接跨集合的风险，但还不足以证明模型预训练阶段从未见过相关材料。

训练集数字也需要分清口径：正文和变异清单报告 5,784 对，附录 C 披露实际发布文件包含 5,775 对，少了 6 对声明改名样本和 3 对位宽样本。引用资源规模时，应同时说明构建统计与发布快照的区别。

首个比较周期，足以改变结论方向

论文设置了两类判题器，也就是判断候选 RTL 是否正确的 oracle。Tier S 使用仿真，让候选模块和 golden reference 在相同抽样激励下运行 200 个周期，再比较输出。Tier F 使用形式等价检查，但按设计分别采用组合检查、复位序列或指定前导序列，并声明初始化和未知值语义。

仿真找到输出不一致，可以给出该轨迹、该比较规则下的反例；抽样轨迹全部一致，则不能据此证明所有允许输入下等价。形式结果同样依赖约束：证明所覆盖的行为范围，需要连同环境假设一起解释。

在论文标记为 GPT-5.5 的历史输出快照中，作者比较了“提供诊断”与“诊断加规格”两组候选。在两组都取得明确形式判定的 79 个行为用例上，从周期 0 比到 199 时，前一组通过 60 个，后一组通过 51 个。加入规格的通过率反而低了 11.4 个百分点。

保持候选输出不变，仅跳过第一次比较，结果变成 72 个对 78 个，规格组领先 7.6 个百分点。采用论文的复位感知初始化规则后，结果为 71 个对 78 个，领先 8.9 个百分点，与这批用例的形式判定相同。

模型并没有因为改评分脚本而学会更多知识。变化来自测试起点和状态解释。对于有状态设计，复位前后的寄存器状态、输出何时有定义，会影响两份实现是否在某个时刻被判成不一致。若判题契约没有写清，能力判断就可能混入初始化差异。

这也不能推出“以后把第一拍都跳过”。首拍可能承载规格要求的有效行为，复位也可能本身就是待修错误。正确做法是先确认设计契约，再确定比较窗口。为提高分数而统一屏蔽一个周期，可能漏掉真实缺陷。

这组结果还排除了 85 个行为用例中没有明确形式判定的 6 个；每个输入条件保留一次贪心生成，多个用例共享源设计。因此，方向反转是这批样本上的描述性发现，不能升级为所有模型、所有设计上的普遍效应。

修好了，也可能是重新写对了

另一个实验把问题落到了模型输入上。作者从模型生成结果中收集 274 个能够编译、但未通过任务 testbench 的失败样本，分别给模型三种材料：仅故障 RTL、故障 RTL 加规格、仅规格。

只给规格这一组，提供了必要的对照。它完全不接触故障 RTL，如果仍能得到正确实现，就提供了一条独立于修复原代码的成功路径。评测因此能追问：把坏代码交给模型，究竟带来了多少额外收益？

在规避初始化前比较影响、仅保留三组都有可评分候选的分析中，六个模型的“仅规格”相对于“故障 RTL 加规格”的恢复率差，介于负 8.5 到正 18.3 个百分点；三个模型更低，三个更高。不同模型实际纳入数量为 260 至 274，不能把每列都当作完整的 274 例比较。

这个结果支持一个有限但有用的判断：只报告最后代码的正确率，无法把修复与重新生成的贡献拆开。它没有证明任何模型在内部忽略了故障代码，也没有证明重新生成总是更好。总体分数相近，更不能反推两个模型采用了相同推理过程。

作者还披露，跨模型实验保留了输出和评分汇总，但缺少精确不可变的提供方版本、调用时间及部分请求元数据。模型名称在这里代表历史端点输出快照。把这张表改写成当前产品排行榜，会超出材料支持范围。

工程任务中的“修复”通常还带着保留既有接口、时序关系与实现约束的要求。这是本文的工程延伸判断：即使重新生成的小模块通过给定功能测试，也需要另外验收修改范围和集成影响，才能判断它是否适合替换项目中的原实现。

团队验收可以追三张清单

沿着论文的证据链，研发团队可以把验收分成任务清单、判题清单和归因清单。三张清单分别回答：修什么、怎样算对、成功与哪些输入有关。

任务清单先拆开工具诊断类错误和行为错误，记录源设计如何划分、变异怎样构造、训练中是否见过同类操作。对于主要由人工变异构成的集合，再用模型自然产生的失败样本补充观察。两类来源各有偏差，混在一起也应保留标签。

判题清单要写出初始化状态、复位极性和持续方式、首个比较时刻、未知值处理、激励长度，以及形式检查的假设。还要保留无法判定、超时、缺失候选等状态，避免只展示容易得到明确答案的子集。

归因清单至少加入仅规格对照，配合故障 RTL 加规格的主实验。若要进一步研究是否利用了原实现，可以设计局部补丁限制、代码上下文消融等实验；这些属于后续实验建议，并非本文论文已完成的验证。

对于设计工程师，最有用的交付是可审阅的改动及其理由；对于验证工程师，是可重跑的激励、比较规则和反例；流程负责人则需要追踪候选、工具版本、判定状态与人工接管记录。模型分数只有进入这些交付物，才方便在项目里使用。 面向 AI+EDA 的流程建设，也应把专业知识、工具编排与审阅节点接起来，让每次修改都能追溯到输入、判定规则和责任人。

项目收益还要另算。正确率没有直接给出人工审阅工时、回归次数、集成代价或缺陷重开情况。论文没有报告客户生产收益，也没有给出芯片项目周期缩短比例，不能替它补上一笔效率账。

拿到一个 RTL 修复通过率，团队到底能据此放行什么？这篇论文给出的推进方向，是把错误类别、判题契约、输入对照与未决结果一并公开，让读者能够复查分数的含义。

下一次看到 AI 修复 RTL 的高分，可以先看三件事：行为错误是否单列，复位与首周期是否写明，仅规格对照是否存在。再检查无法判定的样本去了哪里。材料越完整，团队越容易判断分数能否迁移到自己的任务。

模型给出候选修改后，独立仿真、适用条件下的形式分析以及人工设计 review 仍要继续。能解释、能重跑、能接管的修复结果，才有条件成为工程流程的一部分。

作者：麒芯

本文基于公开论文与附录作技术解读，实验结果归属于原作者；工程建议不构成客户效果或生产签核结论。

参考资料：

Yeyin Eva Zhu、Rishabh Ranawat：《What Do RTL Repair Benchmarks Actually Measure?》，arXiv:2610.28595v1，2026-10-20。