夜雨聆风最近这篇 Rule2DRC，不是那种一眼就能刷屏的 AI 论文。
它没有去讲“AI 自动设计一颗芯片”，也没有把目标放在 RTL、版图布线或者模拟电路参数优化这些更容易被传播的方向。它盯上的是一个很窄、很硬、也很容易被外行忽略的环节：设计规则检查，DRC。
具体说，就是让 AI Agent 把自然语言里的工艺设计规则，翻译成可以在 KLayout 里执行的 DRC 脚本。
这事听起来有点小。但越往里看，越能看出它为什么值得写。因为 DRC 脚本生成刚好卡在 AI for EDA 最难糊弄的地方：你懂不懂专业语义，能不能接工具，跑出来的结果到底对不对。
Rule2DRC 真正的问题意识，不是“大模型会不会写 KLayout Ruby”。这个问题太浅了。它问的是：当一个 Agent 生成 DRC runset 时，我们到底拿什么判断它写对了？
论文给出的答案很朴素，也很工程：别只看代码长得像不像，拿去执行，看违规结果对不对。
DRC 是个很诚实的考场
在芯片设计流程里，DRC 是制造可行性的底线检查。金属线宽够不够，间距有没有违反规则，某个层是否被另一个层正确包围，过孔、扩散区、栅极之间的几何关系是否满足 foundry 要求，最后都要落到设计规则和 DRC 脚本上。
规则文本有时看起来不复杂。真正写成脚本，完全是另一回事。
工程师要先理解规则语义，再找对版图层，组合几何操作，处理边界条件，最后把违规对象输出给 DRC engine。KLayout 的 DRC 文档里能看到，它支持 width、space、overlap、enclosure、inside/outside、edge objects、cell filtering、tiling、多核执行等能力。说白了，DRC 脚本不是几行普通代码，而是一段小型几何程序。
这就很适合检验 AI Agent。
因为它不能只会复述规则，也不能只会生成语法看起来没错的代码。它必须把工艺语义翻译成可运行逻辑，还要能借助工具反馈判断自己错在哪里。
很多通用代码生成 benchmark 的问题，在 DRC 场景里会被放大。代码相似度可能会误判：两段脚本写法完全不同，但执行结果一致；也可能漏掉危险错误：脚本长得像标准答案，但在某个边界版图上少报了一类 violation。
芯片设计不太吃这一套。工具一跑，结果就摆在那里。
Rule2DRC 做对了一件事：用执行结果说话
论文构建了一个包含 1,000 个 rule-to-script 任务、13,921 个 evaluation layouts 的 benchmark。输入是自然语言规则，输出是 KLayout DRC 脚本，版图用 GDSII 表示。评估时，不是比较生成代码和参考代码的文本相似度，而是执行生成脚本，再比较它的 violation output 和 ground-truth script 是否一致。
这一步很关键。
第一，规模上去了。过去一些相关 benchmark 任务数量和测试样例都偏小，很难判断模型是真懂，还是刚好撞上了少数样例。1,000 条规则和接近 1.4 万个测试版图，至少把投机空间压小了不少。
第二，评估口径变了。EDA 工具链里的正确性，本来就不是由“看起来像不像”决定的，而是由工具跑出来的结果决定的。DRC 脚本只要漏报或误报，后续设计闭环就会被污染。
第三，论文没有把 evaluation layouts 直接交给 Agent。这一点很现实。真实工作里，工程师不会把完整隐藏测试集喂给模型。模型能拿到的，通常是规则文本、工具文档、少量可构造测试和执行反馈。
所以 Rule2DRC 测的不是“模型看完答案之后能不能解释答案”，而是“模型在有限信息下能不能生成可靠程序”。
这也是这篇论文比普通代码生成任务更有 EDA 味道的地方。
半导体公司真正关心的不是模型会不会聊天，而是它能不能进入一个受控的、可验证的研发流程。规则、日志、设计约束和版图数据都很敏感，AI Agent 如果要落地，知识库、工具协同和验证过程就不能飘在外部公有云上。
中科麒芯做智语芯、FlowBuilder 和相关 Agent 能力时，底层判断也是这个：半导体 AI 不能只做通用助手，要围绕 Design Flow、工具链和企业知识库组织起来，并且支持私有化部署。否则越靠近 DRC、LVS、仿真和 signoff，越难被真正接入。
SplitTester：不是让模型自信一点，而是让测试更刁钻一点
Rule2DRC 里另一个有意思的设计，是 SplitTester。
它解决的是 Best-of-N 里一个很真实的问题：同一个规则，模型可以生成很多候选脚本。它们看起来都像那么回事，普通 judge 也不一定能分出谁真的对。怎么办？
SplitTester 的思路是主动构造更有区分度的测试样例，把候选脚本之间的差异逼出来。
这很像软件工程里的差分测试。不是问模型“你觉得哪个更好”，而是问：“有没有一个版图，能让 A 脚本和 B 脚本跑出不同结果？”
这个思路放在 DRC 里尤其合理。很多错误不会出现在普通样例上，而是藏在边界条件里。比如 enclosure 刚好等于阈值，略小于阈值，多层对象重叠，某个层为空，或者规则文本里有一个容易被误解的方向性约束。候选脚本在大多数简单版图上都能过，但一到这种地方就露馅。
论文评述整理的实验结果显示，SplitTester 在多个模型和 Best-of-N 设置下都优于 LLM-as-a-judge、Generated Tests、S*、CodeMonkey 等基线。一个例子是 GPT-OSS-20B 的 BoN-20 设置中，SplitTester 相比 CodeMonkey 把成功率从 41.1% 提到 44.4%，错误率从 14.1% 降到 12.6%。
这不是一个夸张到能拿来喊口号的数字。但它很有价值，因为它说明执行反馈不是装饰品。对这种专业任务来说，测试生成和程序选择本身就是 Agent 能力的一部分。
对 AI for EDA 来说，真正的门槛在“可验证工件”
Rule2DRC 最值得行业关注的地方，是它把 AI for EDA 从“生成内容”往“生成可验证工件”推了一步。
EDA 不是办公软件。芯片设计里的 AI 如果只会写建议、画流程图、解释报错，很难进入主流程。它必须能调用工具、读懂日志、修正脚本、生成测试、记录中间过程，并且让工程师可以追溯每一步为什么这么做。
DRC 只是一个切口。类似逻辑会出现在 LVS、STA 约束、形式验证、仿真脚本、PDK migration、rule deck 维护、回归测试和 signoff checklist 里。越接近真实研发流程，越需要可执行、可检查、可回滚。
这也解释了为什么 DRC 代码生成虽然冷门，却很有代表性。
它足够窄，窄到可以构造 benchmark；又足够硬，硬到模型没法只靠通用编程能力蒙混过关。KLayout 的 DRC DSL、GDSII 版图、工艺规则文本、几何运算语义，这些东西放在一起，就是一个典型的半导体长尾知识场景。
很多国内芯片公司面对 AI 的真实需求，其实也在这里。大家不缺一个会聊天的大模型，缺的是一个能在私有环境里理解规则、接入工具链、围绕本公司 Design Flow 形成闭环的 Agent 系统。模型能力只是第一层。工具协同、知识库、验证沙箱、权限边界和私有化部署，才决定它能不能进研发流程。
这也是 IC Agent Hub 这类平台要解决的问题：Agent 技能不只是“下载一个脚本”，还要经过格式校验、安全扫描、依赖校验和物理机运行验证。先解决敢不敢用、能不能跑、出了问题能不能查，后面才谈效率提升。
但别把它读成“AI 已经接管 rule deck”
这里也要保持克制。
Rule2DRC 还不能说明 AI 已经能接管真实 foundry rule deck 开发。论文使用的是 KLayout 和可构造数据集，真实商业 rule deck 的复杂度、保密要求、历史包袱都要重得多。很多规则里有大量例外、层派生、特殊器件处理和长期维护逻辑，不是一个 benchmark 能完整覆盖的。
第二，GitHub 仓库虽然已经公开，但目前 README 仍然写着 code and benchmark data will be updated soon。对产业界来说，真正有价值的验证，要等完整数据、脚本和复现实验放出来。
第三，成功率本身仍然有限。即使 SplitTester 能改善 Best-of-N 选择，距离“工程师可以放心让它自动合入 rule deck”还有很长距离。EDA 的门槛不是 60 分能不能过，而是错误成本太高。
不过，这些限制并不削弱论文价值。相反，它把方向讲得更清楚了：AI for EDA 需要少一点泛泛的“智能设计”叙事，多一点能跑、能测、能复现、能比较的硬任务。
写在最后
Rule2DRC 给行业提了一个更清楚的问题：AI Agent 在芯片设计里到底应该怎样被评估？
如果答案只是“生成得像不像”，AI for EDA 很容易停留在演示层。如果答案变成“能不能跑、能不能测、能不能在边界条件下暴露错误”，事情就开始接近真实工程。
DRC 脚本生成不是最热闹的方向，但它可能是很诚实的方向之一。
因为在这里，模型说得再漂亮也没用。工具一跑，结果就出来了。
作者：麒芯
参考资料：arXiv 2605.15669、Rule2DRC GitHub、KLayout DRC 文档、SkyWater SKY130 PDK、NVIDIA DRC-Coder 论文介绍。
本文为产业分析，不构成任何投资建议；论文数据以作者正式版本和后续开源仓库为准。
💬 加入 IC Agent 技术交流群
群里聚集了芯片设计工程师、IT/CAD 负责人和 AI+EDA 从业者，聊技术、聊工具、聊行业趋势。
👉 关注回复「加群」，拉你进群一起聊
👉 关注回复「合作」，如果你在做 AI+ 芯片/EDA 相关，欢迎来聊
后续会持续更新这个系列，关注不迷路。
