芯片"体检报告"的自动翻译员：首尔国立大学如何让AI读懂设计规则手册

这项由首尔国立大学计算机科学与工程系、神经处理研究中心以及三星电子联合推进的研究，发表于2026年第43届国际机器学习大会（ICML 2026），论文编号为arXiv:2605.15669。有兴趣深入探索的读者可通过该编号查阅完整原文。

每一颗芯片在出厂前，都要经历一场严苛的"体检"。这场体检不是用听诊器，而是用一套密密麻麻的几何规则——芯片上哪条线能有多细、两个图案之间至少要留多大间距、某个结构必须完全被另一个结构包裹……这些规则少则数百条，多则数千条，统称为"设计规则"。而负责执行这场体检的程序，叫做设计规则检查（Design Rule Checking，DRC）脚本。

问题在于，这份"体检程序"是人写的。每当芯片工厂推出一种新的生产工艺，工程师们就得重新把厚厚的规则手册——用自然语言写成的文字描述——一条一条手工翻译成计算机能执行的代码。这项工作枯燥、耗时，还极度依赖专家经验。随着芯片越做越小，到了7纳米、5纳米这样的尺度，规则条数和复杂程度都急剧膨胀，翻译工作的难度和成本也随之水涨船高。

于是，一个自然而然的问题出现了：能不能让AI来做这件事？

这个问题并不新鲜，已经有研究团队探索过用机器学习辅助DRC脚本生成。但现有工作存在三个让人头疼的缺陷：测试集规模太小，很多不超过200条规则；评估方式靠"对比代码长相"而非"运行看结果"；数据集又因为涉及商业机密大多不公开。更重要的是，现有方法要么完全不用执行反馈来改进生成效果，要么虽然用了执行反馈，却要求事先提供带标注的测试芯片版图——这在现实中往往意味着你得先有一个正确答案，才能去检验另一个答案，逻辑上相当别扭。

首尔国立大学的研究团队决定从根本上解决这些问题。他们做了两件事：一是建了一个叫做Rule2DRC的大规模公开基准数据集；二是设计了一种叫做SplitTester的AI测试代理。这两件事合在一起，构成了一套完整的"AI翻译员训练与考核体系"。

一、一本有1000道考题的练习册

要理解Rule2DRC的价值，先得理解"评估"这件事有多难。

把一条自然语言规则翻译成DRC脚本，结果可能五花八门。同一条规则，可以用A方法写，也可以用B方法写，两段代码长得完全不一样，但运行起来效果完全相同。如果用"代码相似度"来打分，这两段代码会得到很低的分数，但它们实际上都是正确答案。这就好比同一道数学题，一个学生用加法算，另一个用乘法算，答案一样，过程不同——用"笔迹是否相似"来判卷显然是荒谬的。正确的方式，是把两份答案都代入题目，看结果对不对。

Rule2DRC就是这样一本练习册。它包含1000道题，每道题都是"一条自然语言规则+一段参考脚本+一批测试版图+每个版图的标准答案"。AI生成的脚本会被真正运行在这批测试版图上，把它报告出来的违规结果和标准答案逐一对比，完全一致才算答对。这才是真正的"运行看结果"式评估。

这1000道题的来源分三个部分，覆盖了从简单到复杂、从常见到罕见的广泛场景。第一批310道题来自真实的SkyWater130工艺设计套件，这是谷歌和SkyWater Technology联合开源的一套芯片制造规则，是目前最广泛使用的开源工艺之一。研究团队从中提取了自然语言规则，亲手实现了对应的KLayout DRC脚本，并精心设计了测试版图。这批版图特别注重"刁钻"——比如一条规则要求两个图案之间至少间距5微米，测试版图里会专门包含间距4.999微米（违规）、5.000微米（刚好合格）和5.001微米（安全合格）这三种情况，以及图案部分重叠、完全包含、完全不相交等各种空间关系。这批数据花费了研究团队约两个月的手工标注时间。

第二批490道题是合成的多层约束规则。现代先进工艺的设计规则往往要同时涉及多个图层、多个几何操作的串联。研究团队用GPT-5.2-high这个强力语言模型草拟了初稿，再由人类专家逐条审核、修正和补充，最终确保每道题都是有意义的、正确的。这批题目的难度比第一批高得多——平均每道题需要9.2次DRC方法调用，而第一批只需2.6次。

第三批200道题专门用来覆盖那些在前800道题中出现不足5次的"冷僻语法"。KLayout的DRC脚本语言有184种不同的方法，如果只靠前两批题目，很多罕见但重要的语法点会被完全忽视。这批题目的设计目标，正是让练习册里的知识点分布尽可能全面。

整个数据集最终包含13921个测试版图，平均每道题约14个，其中合成多层规则那批平均高达20.7个，是覆盖最密集的部分。与之形成对比的是，此前最接近的公开工作DRC-Coder只有7道题和29个版图，Rule2DRC的规模大了将近两个数量级。

二、"考官"的困境：如何从一堆答案里挑出最好的那个

有了练习册，下一个问题是：AI怎么用它来提升表现？

一种常见思路叫做"Best-of-N"——让AI生成N份答案，然后挑出最好的那一份。如果N=20，AI有20次机会，只要其中一次答对了，那次就是最终答案。问题在于，在没有标准答案的情况下，怎么判断哪份答案最好？

这就需要一个"考官"。考官的职责是：自己出几道测试题，让所有候选答案都做一遍，根据做题结果来判断哪份答案最靠谱。

在DRC脚本这个场景里，考官出的"测试题"是芯片版图。考官先预测这个版图应该报违规还是不报违规，然后让所有候选脚本都跑一遍，看谁的结果和预测一致。和预测一致越多的脚本，得分越高。

现有的考官方法存在明显短板。CodeMonkey这个方法会先把候选答案剪裁到只剩前三名，然后针对这三人出题区分，但这样很容易在剪裁时就把真正的正确答案误伤掉。S*这个方法会聚焦在那些已经被区分开的候选者身上继续出题，但对于那些彼此无法区分的候选者，它几乎无能为力——而这恰恰是最关键的问题所在。

研究团队把这个核心困境描述得很形象：你面前有二十份考卷，很多份在你出过的所有题目上答案都完全相同，你根本看不出它们之间的区别。但它们不可能真的一模一样，只是你还没找到能区分它们的那道题。你需要一种策略，专门去找这类"无法区分的"卷子，并专门为它们设计一道能把它们区分开来的新题。

三、SplitTester：专门对付"无法区分"的考官

SplitTester的核心设计思想，就是把精力集中在最难区分的那一批候选者身上。

它的工作流程可以用一个故事来描述。假设你是一位侦探，手边有二十名嫌疑人（候选脚本）。你先做了几个初步测试（初始版图），把嫌疑人按照"对这些测试的反应是否完全相同"分成若干个小组（簇）。同一个小组里的嫌疑人，在所有已知测试中表现一模一样，你目前完全无法区分他们。

接下来，你要决定把有限的调查精力投入到哪个小组。SplitTester的策略是：挑那个既人数多（包含更多嫌疑人）、又平均得分高（成员整体表现较好、更可能包含真正的"正确答案"）的小组。这两个指标的乘积就是这个小组的优先级分数。优先级最高的小组，就是下一轮调查的目标。

锁定目标小组之后，SplitTester从这个小组里随机抽取三名代表（三份候选脚本），让AI看着这三份脚本，专门设计一个能把它们区分开来的新版图——就像侦探设计一个圈套，专门针对这三个嫌疑人。新版图出来后，让所有二十名嫌疑人都"参加测试"，重新按照新的测试结果分组，然后重复这个过程，直到用完预算。

这里有一个小细节值得注意：AI预测的"这个版图应该报违规还是不报"并不总是对的，可能有15%到37%的错误率，取决于用的是哪个模型。错误率越高的模型，靠自己预测的得分来选最终答案就越不可靠。所以SplitTester在走完所有分裂步骤之后，还有一个"最终裁判"环节——把得分最高的前三名候选脚本，连同所有区分过它们的版图和各自的实际运行结果，一起交给一个更有经验的"判官AI"来最终拍板。这个判官看的不是预测是否正确，而是直接看这三份脚本在争议性测试上的实际行为差异，然后判断谁最符合规则的描述。

此外，如果连续多次尝试都无法把目标小组进一步分裂，SplitTester会主动停下来，不再浪费预算在死胡同里。这个"耐心参数"默认设为1，也就是失败一次就放弃该目标，转向下一轮。研究团队发现，把这个参数调高到2或3，可以进一步提升准确率，代价是消耗更多时间，用户可以根据需要自行权衡。

四、考试结果：SplitTester确实更好

研究团队用三个不同的语言模型评估了所有方法的表现：Qwen3-30B（一个开源指令模型）、GPT-OSS-20B（一个中等规模推理模型）和GPT-OSS-120B（一个大规模推理模型）。每个模型都在"生成N份候选脚本、用考官选出最好一份"的框架下测试，N分别取10、15和20。

先说最重要的一个发现：把API文档放进提示词里，比不放进去，性能提升极为显著。GPT-OSS-120B在单次生成（不做任何选择优化）的情况下，有了文档之后pass@1（即第一次就答对的概率）提升超过20个百分点，pass@20提升超过40个百分点。这说明DRC脚本语言实在太专业了，连最强的模型如果没有参考资料，表现也会大打折扣。因此后续所有实验都把API文档放进了上下文。

在考官方法的比较上，SplitTester在三个模型、三个N值的组合下，几乎全面超越了对比方法。以GPT-OSS-20B配合N=20为例，CodeMonkey的成功率是41.1%，SplitTester提升到了44.4%，同时把错误率（脚本无法运行的比例）从14.1%降到了12.6%。在Qwen3-30B上，成功率从17.2%提升到18.0%，错误率从38.6%降到35.1%。在最强的GPT-OSS-120B上，成功率从62.7%提升到63.8%，错误率基本不变——因为此时错误率已经非常低，几乎没有改善空间了。

这些数字缩短了与"理论上限"（Oracle@N，即N份答案里只要有一份对就算赢的完美选择者）之间的差距，说明SplitTester确实在更可靠地找到候选集里那份正确的答案。

从运行时间和计算成本的角度看，SplitTester和CodeMonkey消耗的总时间几乎相同，远低于S*，但成功率更高。这意味着SplitTester不是靠堆算力取胜，而是靠更聪明的策略把每一次测试机会用在刀刃上。

五、拆解SplitTester的每个齿轮

研究团队还做了一系列消融实验，逐一拆除SplitTester的各个部件，观察性能如何变化，以此确认每个设计决策是否真的有用。

去掉"最终裁判"环节，成功率从58.0%降到55.5%。这说明AI自己预测的标签噪声太大，不足以单独作为最终判断依据，需要一个更高层次的决策者来综合考量。去掉AI预测标签（改用轮流从最大簇里各抽一个候选者的方式），成功率降到57.1%。预测标签有噪声，但仍然提供了有用的信号，比完全不用要好。把候选池从一开始就强制剪裁到只剩前三名（模仿CodeMonkey的做法），成功率降到57.4%。这证明过早剪裁会误伤一些"慢热型"的正确答案。这三个消融实验合在一起，说明SplitTester的三个核心机制——预测标签评分、保持完整候选池、最终裁判——是相互补充的，缺一不可。

关于簇选择的优先级策略，研究团队也做了验证。用"最大簇"（忽略得分只看人数）或"得分最高簇"（忽略人数只看得分）替代默认的"得分乘以人数"策略，三种方式的结果差异都在一个标准差以内。这说明SplitTester的优势来自于"把测试集中在无法区分的候选者上"这个核心思想本身，而不是依赖于某一个特定的簇选择公式。

研究团队还把测试预算砍半（从16个版图减到8个），结果发现SplitTester依然是所有方法里最好的。比如GPT-OSS-20B配N=20时，缩减预算后SplitTester达到44.5%，仍然超过CodeMonkey的41.8%，说明这种策略对资源约束有良好的适应性。

在不同规则类别的分类表现上，SkyWater真实规则（第一类）相对容易，单次生成成功率就有39.2%；合成多层规则（第二类）最难，单次生成只有5.0%；语法覆盖规则（第三类）居中，11.7%。SplitTester在三个类别上都取得了最好的成绩，BoN-20时分别比CodeMonkey高出4.5、2.6和3.0个百分点。

除了全有或全无的"成功率"指标，研究团队还引入了F1分数来衡量部分正确的情况。F1分数把预测正确的违规版图和预测正确的合规版图都纳入考量，能够体现出一个脚本"虽然不完全正确，但已经答对了大部分"的程度。在这个更细粒度的指标上，SplitTester同样全面领先。GPT-OSS-120B配BoN-20时，SplitTester的F1达到85.6，已经非常接近理论上限87.4。

最后，研究团队还探索了一个"选完再改"的延伸应用：用考官选出最佳候选脚本之后，让AI继续根据测试结果反复修改这份脚本，每次只接受能提升得分的修改。经过三轮修改，SplitTester的成功率从62.3%进一步提升到63.4%，错误率从4.2%降到2.7%。贯穿全程，SplitTester始终保持比普通"生成测试"方法高出约6个百分点的领先优势，说明分裂策略带来的收益在后续修改阶段依然保持。

说到底，这项研究的核心价值在于两点。其一，Rule2DRC这个数据集填补了一个真实存在的空白——此前整个领域缺乏一个公开、大规模、基于执行结果评估的基准，导致不同研究之间难以客观比较，新方法也缺乏可靠的检验手段。现在有了这个基准，未来的研究都有了一把共同的尺子。其二，SplitTester揭示了一个朴素但有效的道理：当你有一批候选答案需要从中挑选，测试的价值不在于数量多少，而在于针对性。把测试资源集中在那些你最难区分的候选者上，比漫无目的地多出题要有效得多。

这对芯片行业以外的软件工程领域同样有参考意义。任何时候你需要从AI生成的多份代码里挑出最好的那份，类似的思路都可能派上用场。当然，DRC这个场景有其特殊性——测试版图的设计本身就需要领域知识，AI预测的标签噪声也比一般编程题大得多，这些挑战在其他场景下未必存在，也未必可以直接迁移。

至于未来，芯片工艺还在继续向前推进，规则复杂度还在上升，手工翻译的成本和风险也还在积累。能否有一天让AI完全接手这份翻译工作，目前还不好说，但Rule2DRC和SplitTester给出了一个清晰的前进方向——更大的数据集、更真实的评估方式、更聪明的测试策略，这三者缺一不可。有兴趣进一步探索的读者，可以通过arXiv编号2605.15669找到完整论文，对应的代码和数据集也已在GitHub公开。

Q&A

Q1：Rule2DRC基准数据集和之前的DRC脚本评估数据集相比，最大的区别是什么？

A：Rule2DRC最大的区别在于规模和评估方式。它包含1000道规则翻译任务和13921个测试芯片版图，比此前最大的公开数据集大了将近两个数量级。更重要的是，它通过真正运行脚本并比较执行结果来评分，而不是靠代码相似度来打分，因为同一条规则可以用完全不同的代码实现，外观不像不代表功能不同。

Q2：SplitTester和CodeMonkey都是用来选最佳DRC脚本的，它们的根本区别在哪里？

A：根本区别在于候选集的处理方式。CodeMonkey会先把候选脚本剪裁到只剩前三名，再出题区分，这样做容易把一些"暂时得分不高但其实正确"的答案提前淘汰。SplitTester则全程保留所有候选脚本，把出题精力专门集中在那些在已有测试上表现完全相同、无法区分的候选者上，然后专门设计能区分这个群体的新测试，避免了过早剪裁导致的误伤。

Q3：AI预测测试版图的"预期结果"错误率那么高，SplitTester如何保证最终选择的准确性？

A：SplitTester用两个机制来对冲预测标签的噪声。首先，它在整个分裂过程中只用预测标签来做相对排序和分组，不把它当作绝对真理。其次，在最终决策阶段，SplitTester会把得分最高的前三名候选脚本，连同所有真实运行结果一起交给一个单独的"裁判AI"，裁判直接看各脚本在争议测试上的实际行为，而非依赖可能出错的预测，从而弥补了噪声带来的误差。