1. 从“AI-native 芯片设计”这个说法说起“AI-native 芯片设计”这个词最近被讨论得很多起因是某头部研究机构发布了一篇关于用 AI 辅助芯片设计流程的研究。消息传开之后圈子里讨论的方向基本分成两派一派觉得芯片设计要被 AI 彻底重构了另一派觉得不过是把已有的 EDA 工具套了个大模型的壳。我前后翻了不少相关的讨论也结合自己这几年在数字后端和验证流程里折腾自动化工具的经验有一些不太一样的看法。先把话说在前面这篇内容不是翻译那篇研究也不是复述它的结论。我想聊的是当“AI-native”这个前缀被加到芯片设计前面的时候真正稀缺的能力到底是什么。这个问题比“AI 能不能做芯片设计”要有意思得多因为它直接关系到你接下来几年该往哪个方向积累。芯片设计这个行当有个特点它的流程链条极长从架构探索、RTL 编写、功能验证、综合、布局布线一直到签核和流片中间任何一个环节出问题代价都是按周甚至按月计算的。一颗中等复杂度的 SoC整个设计周期动辄一年以上人力成本占大头。所以任何声称能“加速芯片设计”的技术都会被反复审视——不是大家不欢迎新工具而是这个领域的容错率太低了。我自己的判断是AI 在芯片设计里真正能发挥价值的地方不在于替代某个环节的工程师而在于它能不能把那些高度依赖经验、难以形式化描述的“隐性知识”变成可复用、可检索、可验证的东西。而这件事的难点恰恰不在 AI 本身。2. 我对“AI-native 芯片设计”的三点不同看法2.1 第一点稀缺的不是模型能力是“可被学习的结构化数据”现在讨论 AI 做芯片设计大部分注意力都放在模型架构、推理能力、上下文长度这些维度上。但你如果真正在芯片设计流程里待过就会发现这个行业最缺的从来不是聪明的模型而是干净、结构化、带标注的设计数据。我举个具体的例子。一个经验丰富的验证工程师看到一段 RTL 代码能很快判断出哪些 corner case 容易被漏掉、哪些断言写得不够紧、哪些时序路径在特定模式下会出问题。这种判断力是怎么来的是他在过去几年里踩过几十个 bug、做过十几个项目之后积累出来的。但这些经验大部分停留在他的脑子里或者散落在各种邮件、评审记录、bug 跟踪系统里格式五花八门根本没有被结构化地沉淀下来。你拿这样的数据去训练模型效果可想而知。模型看到的是一堆非结构化的文本而不是“输入特征—判断依据—结论”这样的三元组。所以我的第一个看法是在芯片设计领域谁能把隐性经验转化成结构化数据谁就掌握了 AI-native 的真正入口。这件事听起来不性感但它是所有上层应用的地基。那具体怎么做我自己的做法是从小处着手。比如在验证环节我会要求团队在关闭每个 bug 的时候除了写清楚修复方案还要额外记录三条信息这个 bug 是在什么激励条件下触发的、当时哪个断言没有覆盖到、如果重新设计这块逻辑会怎么改。这三条信息看起来简单但坚持记录半年之后你就有了一个几百条规模的结构化数据集。这个数据集的价值远比你去网上爬一堆公开的 RTL 代码要高得多。注意结构化数据的采集一定要在流程里固化下来不能靠自觉。我试过让团队“有空就记”结果三个月下来只攒了十几条。后来改成在 bug 关闭流程里加了一个必填字段数据量立刻就上来了。2.2 第二点AI 擅长的不是“设计”是“检查”和“搜索”第二点看法可能有点反直觉我认为在当前阶段AI 在芯片设计里最现实的价值场景不是“生成设计”而是“检查设计”和“搜索方案”。为什么这么说因为芯片设计对正确性的要求是极高的。你让模型去生成一段 RTL它可能语法上没问题功能上看起来也对但里面藏着一个跨时钟域的握手问题或者一个复位释放顺序的隐患。这种问题在仿真阶段可能跑几千个周期都不报错但到了硅上就是致命的。所以“生成”这件事在这个领域天然地被不信任。但“检查”和“搜索”就不一样了。检查是给模型一个已有的设计让它去找出可能的问题点。这时候模型的角色是辅助审查而不是最终决策者。工程师可以对它提出的每一条疑点进行人工确认确认错了就反馈回去确认对了就采纳。这个闭环是安全的因为最终判断权还在人手里。搜索也是类似的逻辑。芯片设计里有大量的“参数调优”工作比如综合时的各种选项、布局布线时的约束设置、电源网络的设计参数。这些参数空间很大靠人工试错效率很低。让模型去搜索一个合理的参数组合然后由工程师来验证和微调这个模式在实际项目里是跑得通的。我去年在一个模块的时序收敛上试过这个思路。那个模块有大概二十几个可调的综合选项之前是靠一位资深工程师凭经验设的。我让模型基于历史项目的数据去搜索一组候选参数然后我们拿三组去实际跑。结果其中一组比原方案在关键路径上好了大概百分之七。这个提升不算惊人但考虑到几乎没有额外的人力投入性价比是可以接受的。应用场景AI 的角色人工的角色风险等级RTL 生成生成候选代码逐行审查、仿真验证高设计检查标记可疑点确认或否决低参数搜索搜索候选组合实际跑验证、微调中文档生成起草初稿审核、补充细节低测试激励生成生成激励模板补充 corner case中这张表是我自己根据实际使用情况整理的不一定全面但能说明一个问题越是靠近最终决策的环节AI 的介入风险越高越是靠近辅助分析的环节AI 的价值越容易落地。2.3 第三点真正的瓶颈在“验证闭环”不在“设计生成”第三点看法是关于瓶颈位置的。很多人默认 AI 做芯片设计的瓶颈在“怎么让模型生成更好的设计”但我觉得真正的瓶颈在“怎么快速验证一个设计是不是对的”。你想想看就算模型能在一秒钟内生成一百个 RTL 版本你怎么知道哪个是对的你还是得跑仿真、跑形式验证、跑综合和时序分析。这些步骤每一个都耗时很长而且很多是需要 license 的。所以设计生成的速度再快验证跟不上整体效率还是提不上去。这就引出一个很关键的判断在 AI-native 芯片设计这个方向上谁能把验证闭环做得更快、更便宜、更自动化谁就掌握了真正的杠杆点。模型能力本身会随着时间推移逐渐商品化但验证基础设施的建设和积累是需要时间和工程投入的这才是壁垒。我观察到的一个趋势是现在有一些团队在尝试用 AI 来加速验证本身。比如用模型去预测哪些测试用例最有可能触发 bug然后优先跑这些用例或者用模型去分析覆盖率数据找出覆盖盲区并自动生成补充激励。这些方向我觉得比“AI 生成 RTL”要务实得多。提示如果你现在想在这个方向积累我的建议是把精力放在验证流程的自动化上而不是去追最新的模型。验证流程的痛点你只要在项目里待过就能感受到而解决这些痛点的经验是可以跨项目复用的。3. 芯片设计流程中 AI 介入的实操拆解3.1 从哪个环节切入最稳妥如果你是一个团队的技术负责人想在实际项目里引入 AI 辅助我的建议是从代码审查和文档生成这两个环节切入。原因很简单这两个环节的容错率高即使模型输出有问题人工审核也能兜住同时这两个环节的人力消耗大改善之后收益明显。具体来说代码审查可以这样做每次有 RTL 提交先让模型跑一遍让它标出它认为可能有问题的行比如未初始化的寄存器、不完整的 case 语句、潜在的锁存器推断、跨时钟域信号没有同步处理等。然后人工审查的时候重点看这些被标记的地方。我实测下来模型能标出大概六成到七成的人工审查会关注的问题虽然它也会标错一些但整体上减少了审查的遗漏率。文档生成就更直接了。芯片设计里有大量的文档工作寄存器手册、接口说明、测试计划、评审记录。这些文档的初稿完全可以让模型来起草工程师只需要审核和补充细节。我试过让模型根据一段 RTL 和对应的验证计划去生成寄存器手册的初稿大概能省掉百分之六十到七十的撰写时间。当然生成的初稿里会有一些不准确的地方比如位域描述和实际代码不一致但这些在审核阶段很容易发现。3.2 数据准备的具体步骤前面说了结构化数据的重要性这里展开讲一下我自己的数据准备流程。整个流程分四步第一步是确定数据采集的粒度。不要一上来就想采集所有环节的数据那样工作量太大而且大部分数据你短期内用不上。我的做法是先选一个具体的痛点场景比如“验证环境搭建”然后只采集这个场景相关的数据。第二步是设计数据记录的模板。模板要足够简单让工程师在忙碌的项目节奏里愿意填。我用的模板只有四个字段场景描述、输入条件、采取的行动、结果。每个字段限制在一两句话以内。太复杂的模板没人会认真填。第三步是把记录动作嵌入现有流程。比如在代码提交的 checklist 里加一项“是否记录了本次修改的经验数据”在 bug 关闭的流程里加一个必填的经验总结字段。这样数据采集就不是额外负担而是流程的一部分。第四步是定期整理和标注。我一般每两周花一个小时把这两周积累的数据过一遍去掉重复的、补充缺失的、给每条数据打上标签。这个整理过程本身也是对自己经验的梳理一举两得。# 一个简单的数据记录模板示例用 Python 字典表示 record { scene: 跨时钟域握手验证, input_condition: 两个异步时钟域之间通过握手信号传输数据, action: 在握手信号上添加了双触发器同步并补充了亚稳态注入测试, result: 发现了一个在特定时钟相位关系下握手丢失的问题, tags: [CDC, 握手协议, 亚稳态, 验证] }这个模板看起来很简单但坚持用下来半年就能攒出几百条高质量的经验数据。这些数据拿去微调一个小模型或者作为检索增强生成的语料库效果都比用公开数据好得多。3.3 工具选型的考量因素在工具选型上我的原则是优先选可本地部署、可定制、数据不出内网的方案。芯片设计的数据敏感度很高很多设计细节是不能外传的。所以那些需要把代码上传到外部服务的工具在正式项目里基本没法用。具体来说我会关注这几个维度部署方式能不能在内网环境里跑有没有离线模式可定制性能不能用自己的数据做微调能不能接入自己的知识库集成能力能不能和现有的版本管理、bug 跟踪、CI 流程对接成本结构是一次性买断还是按量计费长期使用的成本是否可控输出可解释性模型给出的建议能不能追溯到具体的依据这几个维度里我觉得集成能力是最容易被低估的。一个工具再好如果它不能嵌入工程师现有的工作流使用率就会很低。我见过太多团队买了好工具结果因为用起来麻烦最后只有一两个人偶尔用一下。注意不要追求“功能最全”的工具要追求“最容易嵌入现有流程”的工具。功能可以慢慢加但流程一旦定型就很难改。4. 实际项目中的问题排查与经验总结4.1 模型输出不稳定的应对方法在实际使用中最常见的问题就是模型输出不稳定。同一个问题你今天问和明天问得到的答案可能不一样。这在芯片设计场景里是很让人头疼的因为你需要的是确定性的、可复现的结果。我的应对方法有三个。第一个是固定输入格式。把你要问的问题模板化每次都用同样的结构去问。比如“请检查以下 RTL 代码中是否存在跨时钟域问题如果有请指出具体行号和问题类型”。模板化的输入能显著降低输出的随机性。第二个是要求模型给出推理过程。不要只让它给结论让它把判断依据也写出来。这样即使结论有偏差你也能从推理过程里看出它是在哪一步跑偏的方便你调整提问方式。第三个是多次采样取交集。对于关键问题我会让模型跑三次然后取三次都提到的那些问题点。实测下来三次都提到的点准确率能到八成以上。只提到一次的点准确率大概只有三成左右。4.2 常见问题速查表下面这张表是我在实际使用中整理出来的列了一些典型问题和对应的处理方式问题现象可能原因处理方式模型漏报明显问题输入上下文不足补充相关模块的接口定义和约束文件模型误报率高提问过于宽泛缩小问题范围指定具体的检查类型输出格式混乱没有指定输出结构在提问中明确要求用表格或列表输出对特定工艺不熟悉训练数据覆盖不足在提问中附上工艺相关的约束说明长代码处理效果差上下文长度限制分段处理每次只送一个模块建议不可落地缺少项目背景在提问中补充项目阶段和约束条件这张表里的每一条都是我实际踩过的坑。比如“对特定工艺不熟悉”这一条我一开始以为模型应该什么都知道后来发现它对一些比较新的工艺节点确实了解有限。解决办法就是在提问的时候把相关的设计规则和约束条件一起附上让它基于你给的信息来判断而不是依赖它自己的先验知识。4.3 团队协作中的经验沉淀机制最后聊一下团队层面的经验沉淀。AI 工具在个人手里能发挥的作用是有限的真正大的收益来自团队层面的知识共享。我的做法是建一个内部的“经验库”每个人在使用 AI 辅助工具时发现的好用的提问模板、有效的检查清单、典型的误报案例都往里面丢。这个经验库不需要什么复杂的系统一个共享文档就够了。关键是要有人定期整理把零散的记录归类、去重、提炼成可复用的模板。我一般每个月花半天时间做这件事整理出来的模板会同步给团队所有人。这个机制运行了大概半年之后效果很明显。新加入的工程师不需要从头摸索怎么用这些工具直接拿现成的模板就能上手。团队整体的审查遗漏率下降了文档撰写的平均时间也缩短了。更重要的是大家在用 AI 工具的时候有了一个共同的参考框架讨论问题的时候效率高了很多。提示经验库的内容要定期清理。过时的模板、被验证无效的方法要及时删掉或标记。不然经验库会越来越臃肿大家就不愿意看了。5. 关于能力积累方向的一些个人判断如果你问我接下来几年在芯片设计领域什么能力最值得积累我的答案可能和很多人不一样。我觉得不是学最新的模型架构也不是追最新的 EDA 工具而是把设计意图和验证意图形式化表达出来的能力。为什么这么说因为 AI 工具再强它也需要一个明确的输入。你告诉它“帮我检查这段代码”它只能做一些通用的检查。但如果你能告诉它“这段代码实现的是一个带优先级仲裁的轮询调度器仲裁粒度是四个周期优先级可以动态配置我需要你重点检查在优先级切换的时候会不会出现仲裁丢失”它就能给出更有针对性的分析。这种把设计意图精确表达出来的能力本质上是一种“翻译”能力——把人类脑子里的模糊想法翻译成机器能理解的精确描述。这个能力在 AI 时代不是变得不重要了而是变得更重要了。因为以前你只需要把想法翻译给同事听同事能靠经验补全你没说清楚的部分。现在你要翻译给模型听模型可不会帮你补全你说不清楚它就真的理解不了。所以我的建议是在日常工作中有意识地训练自己把设计决策的理由写清楚。不要只写“我把这个寄存器改成双触发器了”要写“我把这个寄存器改成双触发器了因为它的输入来自一个异步时钟域单触发器有亚稳态风险双触发器能把 MTBF 提升到可接受的范围”。这种记录做多了你自然就知道怎么把意图表达清楚了。这个能力还有一个好处它不依赖于任何特定的工具或平台。不管以后流行什么模型、什么框架能把问题说清楚的人永远是有优势的。工具会变但这个底层能力不会过时。我在实际项目里带过几个新人那些进步最快的往往不是代码写得最快的而是最愿意把“为什么这么做”想清楚、写清楚的。这个习惯短期看是增加了工作量长期看是在给自己积累真正的壁垒。