这两年“AI-native芯片设计”从一个小圈子的黑话慢慢变成了行业大会的必聊话题。尤其是某头部科技巨头把一整套自研的AI驱动芯片设计流程公开之后讨论声量一下子起来了。好消息是大家对AI进芯片设计这事没那么抵触了坏消息是很多讨论都跑偏了。我看到不少人在纠结“数据集多大”“模型多少参数”“验证覆盖率能不能自动拉满”但真正该被反复咀嚼的问题其实是那个研究里无意间暴露出来的能力缺口。我前后也做过几年芯片设计流程里的工具链和验证相关的工作算是半个局内人。老实说那一轮研究公布后我身边好几个团队连夜开会讨论点集中在“AI能不能把RTL寄存器传输级代码写完”“验证工程师会不会失业”“哪些环节可以被Agent接管”。这些当然重要但如果只看到这一层那基本还是用旧地图找新大陆。我读完那篇披露的技术细节之后心里的感受是它给出的不是一套标准答案而是一张关于“稀缺能力在哪里”的重新划分的版图。而版图上的标注和很多人以为的并不一样。这篇文章我不会去复述整个技术方案的具体细节那些官方资料写得比我清楚。我想聊的是在那套AI-native设计流程真正落地之前有哪些能力是远比“会写提示词”更稀缺的。并且我确实有几点不同看法。1. 那项研究真正戳中的痛点设计产能堵在了“中间层”1.1 AI-native设计为什么突然变成绕不开的话题先说说为什么这个方向会在最近两年突然爆发。芯片设计本身是个极度依赖人力的行业前端架构、微架构实现、验证、后端物理实现每一环都需要大量经验丰富的工程师。而先进制程走到今天一颗芯片里塞几亿门、几十个时钟域、上千条关键路径都是家常便饭。传统EDA工具虽然能帮人做逻辑综合、布局布线但“决定做什么电路”这件事依然得靠人肉完成。架构师画PDF框图设计工程师写RTL验证工程师在SystemVerilog/UVM里搭环境这一套流程几十年没什么本质变化。然而随着AI大模型能生成高质量代码大家忽然发现写RTL这件事似乎可以被“低垂果实”化。只要给它足够多高质量的设计示例和约束文档它就能生成一段可综合的Verilog。问题是芯片设计不是一个“生成代码”就能交差的领域。代码旁边还站着覆盖率、断言、时序约束、功耗估算、形式化验证等一系列配套物。生成一个模块容易生成一个能被验证、能被集成、能不出问题的子系统完全是另一个量级的事情。那次研究公开的框架本质上是在打这个“中间层”的仗如何让AI不只写单点代码而是参与整条设计链条的决策。它提出了类似“预注册时间线”的思路让每个AI代理先声明自己打算做什么、怎么验证、需要什么输入再去执行。这听起来像给AI加了一套项目管理规范。但这套东西一旦铺开对组织里人类工程师的能力要求就完全变了。1.2 明面上说“缺高质量数据”实际上缺的是“数据生产机制”我观察到业内对这项研究最普遍的一句评价是他们到底是怎么搞到那么多干净且带验证信息的设计数据确实AI生成RTL的质量上限很大程度上由训练数据决定。通用代码大模型写写Python、JavaScript没问题但让它写一段带复杂流水线交互的Verilog它很容易生成出“看起来很对但根本综合不过”的代码。原因很简单公开可用的、带有完整验证环境和设计规格的高质量RTL数据集太少了。这比自然语言语料还要稀缺。于是大家自然得出一个结论AI-native芯片设计稀缺的是数据。但我恰恰觉得这里被带偏了。缺的并不是“数据”这个静态资产而是“数据生产机制”这个动态能力。什么意思呢假如你今天花钱找几千个工程师手工标注一批高质量RTL工程给模型训练那你得到的是一堆历史快照明天工艺变了、接口标准变了、总线协议升版本了这批数据的价值就会衰减。真正有用的是那一套能够持续把“设计意图、代码实现、验证结果、风险报告”自动沉淀成训练语料的机制。这个机制里最容易被忽略的是数据中蕴含的负样本。一个模型纠正过的bug、一个被覆盖率工具打回来的分支、一条导致时序违例的路径这些才是让AI真正理解设计约束最宝贵的材料。可大多数设计团队根本没有把这些信息存下来。项目结束之后脚本删了、日志清了唯一留存的是最终那版能跑通的代码。这种习惯在人类协作时代勉强够用但在AI时代相当于扔掉了几千TB的“训练燃料”。所以我说的第一点不同看法就是别再问“高质量数据去哪里找”要问“我的设计流程能不能自动长出数据”。前者是买矿后者是种树。1.3 研究里隐含的稀缺能力第一个候选规则抽象能力顺着数据生产机制往下走研究里其实还暗含了另一种稀有能力把设计经验抽象成机器可执行的规则。现在的AI代理之所以能在设计流程里干活不只是靠模型自己聪明更要靠人预先给它设置大量约束和检查点。好比一个刚入职的应届生你再聪明没有公司规范、没有checklist、没有review机制也很难直接交付高质量模块。研究里强调的“显式验证计划”“代理间结构化协作”翻译成人话就是我们得把老师傅脑子里的经验变成AI能查的条文。这件事比想象中难。因为芯片设计里大量经验是“非编码知识”。比如“这块缓冲器要远离时钟门控单元”“跨时钟域的同步器至少要打两拍”“这条路径留15%余量给IR drop”这些往往是写在PPT里、或者干脆只存在于老工程师脑中的模糊判断。如果我们要AI-native化就必须把它们硬编码成可计算、可检查、可自动触发的规则。所以懂得“把RTL设计经验结构化”的人将会变成比“会写RTL的人”更稀缺的物种。这事情AI替代不了人反而需要人做大量前期的规则考古和抽象设计。我接触过的几个尝试AI辅助芯片设计的内部项目最后做成的团队都有一个共通点都投入了大量人月去做规则梳理而不是在调模型。2. 我的第一点不同看法真正稀缺的不是“生成代码”而是“生成正确代码的约束表达”2.1 大模型写出的RTL和“可交付的RTL”之间还隔着什么很多围观AI写芯片代码的人只看了最表面的演示给LLM一段自然语言描述模型哗啦哗啦输出几十行Verilog仿真波形出来了绿灯亮了。于是觉得“设计要被AI取代了”。这种印象极其误导。真实芯片设计团队里一段代码能合入主干要过多少关首先是编译和lint静态检查通过不能有语法歧义、位宽不匹配这些低级问题。然后是仿真功能对拍比如你自己写的RTL和一个参考模型跑同一批case输出要一致。再然后是约束检查时序约束、跨时钟域约束、低功耗约束都得挂上。接着是覆盖率统计看分支、状态机、表达式覆盖够不够。最后还有形式化验证证明你的逻辑在数学上和规格等价。这只是前端部分。大模型生成的代码过第一关都费劲因为它太容易给出“语法正确但风格奔放”的代码了。所谓风格奔放就是它不理解你项目里那些不成文的规定模块命名规则、状态机编码方式、复位策略、接口时序握手的约定。这些规定如果不下沉到提示词里生成的代码就是不可集成的孤岛。所以我一直觉得“AI生成代码”是一个伪命题真正的命题是“AI能否在约束充足的情况下生成满足约束的代码”。这里的约束不是三言两语的自然语言提示而是像UVM环境、时序约束SDC、验证计划、覆盖率目标、设计规范文档这全套东西的机器可读表达。2.2 为什么说“约束表达”比“模型调优”更值得押注模型能力当然重要参数更大的模型对语义理解确实更好。但芯片设计领域有个现实问题高质量领域数据太少不足以支撑无约束的模型继续狂飙。而约束表达则不同它是工程问题可以靠流程优化来解决。你哪怕用同一个开源模型给它的上下文里塞进三种东西它的输出质量就能有质的提升带结构标签的设计规格拆解让模型知道每个模块的参数化边界、时序预算和接口信号列表来自相似模块的参考实现片段让模型在风格上有样可循一组编译器和仿真脚本反馈回路让模型生成之后立即跑lint和冒烟仿真再把报错信息回喂给模型进行自纠错。这三样东西都不需要更大的模型也不需要更多神秘数据需要的是流程设计者把“如何描述约束”这件事做到位。这个能力比单纯堆算力难得多了。一个没有经验的团队往往会走这条路先把最新模型拿来让它自由发挥生成RTL失败了就怪模型不够聪明然后换更大的模型。在我看来这是在错误的层面上花冤枉钱。真正的进阶路径是把约束从人脑搬到文档、从文档搬到机器可解析的Schema再从Schema接到模型的上下文里。2.3 “约束表达能力”具体指什么一个工程师视角的拆解落实到操作层面约束表达又可以拆成三块第一块是结构约束。你得告诉AI这是一个同步FIFO还是一个异步FIFO读端口有没有寄存输出写侧有没有背压。这些信息如果揉在一大段自然语言里模型很容易忽略关键限制。更好的做法是给一个JSON或者YAML格式的接口定义表把每个端口的名称、方向、位宽、时序关系列清楚。模型读结构化数据的能力其实比读散文强很多。第二块是质量约束。告诉AI“代码必须无latency漂移”“关键路径延迟不超过3.2纳秒”“寄存器数不能超过2048个”这些约束可以挂在模型的输出评判阶段让生成的代码不是一次性输出就完事而是经过一轮“差分进化式”的迭代筛选。变异、交叉、筛选这套思路完全可以用在RTL生成上。第三块是验证约束。生成完代码之后模型还得知道自己什么时候算完成任务。如果目标仅仅是“代码能编译”那验证深度就太浅了。我见过比较有效的做法是把一段参考模型的测试向量和覆盖率编译命令直接塞给代理让它以“通过这项测试”为完成信号。这样AI的行为就从“写一段代码”变成“交付一段可验证的代码”完全是两个层次。所以第一点不同看法总结起来就是AI-native设计的瓶颈不在生成侧而在表达侧。谁能在表达约束这件事上做出标准化的框架谁就掌握了下一代设计流程的入口。3. 我的第二点不同看法数据稀缺是表象场景闭环能力才是胜负手3.1 一个简单的思想实验为什么开源模型吃不到芯片设计红利你随手用ChatGPT或者开源模型写一段Verilog它给出的代码往往混合了多种风格一会儿用阻塞赋值一会儿用非阻塞赋值甚至状态机编码方式都很混乱。这在可综合设计里是致命伤。因为可综合风格要求极其严格稍有闪失综合工具就会给你一个“inferred latch”的警告或者综合出和你预期完全不一致的硬件。但如果同样一个模型被接在一个自动化的闭环系统里情况就完全不同。系统拿到模型输出的代码自动丢给仿真器跑一个快速冒烟用例发现断言失败然后把失败波形摘要转换成文本反馈要求模型修改。这个模型相当于多了一个“上膛的教练”每一次犯错都能立刻获得纠正信号。几轮迭代之后输出质量会有肉眼可见的飞跃。这说明一个核心现象大语言模型的初始能力固然重要但场景闭环才是决定它能不能在垂直领域真正站稳脚跟的关键。谁占住了闭环谁就拥有了“正反馈的数据飞轮”。开源模型本身大家都能拿到但有没有调试回路、有没有回归测试集、有没有覆盖率自动反馈才是区别专业工具和玩具demo的分水岭。3.2 闭环的起点是“评标系统”回归测试集的工程化要形成闭环先得有评标系统。放在芯片设计场景里这就是一套稳定可跑的回归测试集。听起来简单其实工程量极大。你需要从历史项目里提取出有代表性的小模块比如各类总线桥、中断控制器、片上网络路由节点、各种位宽的算法加速器每个模块配齐规格、参考向量、覆盖率脚本、代码风格检查规则。这样一个测试集就相当于AI设计时代的“跑分基准”。可问题又来了芯片项目迭代快模块五花八门怎么保证测试集不过时我的经验是不追求全追求小和稳。每次只针对AI最常犯的错误类型设置测试位宽截断、跨时钟域漏同步、状态机死锁、异步复位释放时序。能把这些基础问题兜住AI设计工具就已经有实战价值了。这套测试集不需要一开始就做得很庞大但必须能自动化运行并且报错信息直白。想象一下你给AI系统加了一个新能力怎么知道它退化了没有没有回归测试集你只能靠人工review。有了回归测试集你每次修改提示词、调整数据预处理、换底层模型都能立即看到分数变化。这跟单元测试对软件工程的意义完全相同。3.3 更进阶的闭环把验证计划变成可执行的自动反馈如果说回归测试集是初级闭环那“验证计划驱动代理”就是中级闭环。还是拿人做类比新手工程师拿到设计规格往往闷头就写代码。而有经验的人会先列一个验证计划把要测的功能点、边界情况、错误注入机制写清楚再决定代码怎么组织。这份验证计划如果也能被AI解析作为代理执行过程中的检查清单AI-native设计就从“代码生成”进化到了“意图驱动设计”。具体做法可以是把过去的验证计划文档整理成一套规则模板自动解析出检查项ID再通过脚本把检查项和仿真结果关联。我见过一个内部实验他们把验证计划分解成“信号级断言、事务级断言、覆盖率仓绑定”三层然后把这三层信息作为提示词附加给LLM让它按图索骥地生成代码。结果生成了比直接给自然语言规格高得多的正确率。原因不复杂因为LLM的本质是概率联想你给的线索越结构化它的输出空间就被约束得越准。这背后的工程资产是从无数个项目里沉淀下来的验证意图。那些能把它整理成可执行内容的团队会比拥有更多GPU的团队先享受到AI红利。3.4 所以稀缺的是“把场景做成闭环”的人三种能力维度——回归测试集成、验证计划转译、反馈回路设计——共同构成了我所说的“场景闭环能力”。这在组织里对应的是什么呢不是单一的某个岗位而是一支能同时理解芯片设计和机器学习工程的小团队。这种团队比较难找因为传统芯片工程师大多不熟悉模型的调试技巧而AI工程师又不理解验证覆盖率、时序约束这些硬约束。缺口就摆在这里。所以我说数据稀缺是表象能把场景闭环做起来的人太少才是本质。4. 我的第三点不同看法AI-native的最终竞争是“组织学习速度”的竞争不是模型参数的竞争4.1 从“设计工程师”到“设计系统工程师”岗位边界开始溶解很多讨论都停在“AI会取代谁”这个粗浅层面。但实际观察下来AI-native设计真正改变的不是某个人的岗位而是设计团队之间的接口方式。过去架构师把微架构图定下来设计工程师照着写RTL验证工程师拿到RTL再搭UVM环境。每两个角色之间靠的是文档和会议来传递信息。现在如果AI代理参与进来谁来写RTL的问题就变得模糊了。AI可以直接根据架构师的规范草稿生成RTL然后验证工程师负责审核和补测试但审核的方式不再是一行行看代码而是看约束是否完备、验证计划是否覆盖了AI可能出错的地方。这意味着未来一个团队里最吃香的是那种既看得懂高层规格又理解底层验证边界还能把中间这些流程整理成AI代理工作流的人。这是原来任何一个单一岗位都覆盖不了的。岗位的边界会溶解成一个新的角色设计系统工程师。这类人要做的事情包括设计系统里哪些环节适合交给Agent哪些必须保留人工审批把质量门禁嵌入到AI工作流里建立反馈回路让Agent的失败经验变成下一次执行的提示词。这不是管理岗位而是深度参与具体设计的技术岗位。它的核心产出物不是某一个模块的代码而是整个团队的“设计能力进化速度”。4.2 流程可编程性同一件事传统流程和AI-native流程的差距在哪我拿一个很具体的事情举例ECO工程变更指令处理就是芯片上线后发现bug需要通过修改金属层来修复逻辑。传统流程里ECO工程师收到检查报告手动分析问题路径找到需要改逻辑的门级网表位置然后手工调整连线或插入逻辑这就需要经验非常丰富的人来操作。AI-native流程里理想状态下应该是最小改动自动生成人工审查后一键输出。但真要落地你首先得把ECO的决策过程拆成数据流和判断规则哪里可以动、哪里不能动、有哪些留住的逻辑、修完之后的时序裕度怎么快速评估。这些规则可能散落在几个老工程师脑子里没有文档。谁能先把流程做成可编程的谁就能在这件事上做到组织级AI落地。这已经不是一个AI模型能力问题了而是公司的知识管理、流程梳理、工程文化问题。4.3 小团队怎么培养“组织学习速度”三点可操作的做法如果你想在一个几十人的设计团队里试水AI-native流程我的建议是不要一上来就搞颠覆性创新从三个小改革开始。第一建立“失败案例库”。每个AI代理或脚本出过的错都存成一个大模型可检索的case base。这个库不只要存错误日志还要存人对错误的解释和修正动作。久而久之它可以成为提示词优化的原料库也充当新员工的培训教材。第二每周固定做一次“流程复盘会”。把一个真实的设计任务同时用传统方法和AI辅助方法跑一遍对比质量、时间、人力投入记录下AI在哪个环节表现亮眼在哪个环节陷入无效循环。这比空谈战略有用得多。复盘的产出不是会议纪要而是下一周的提示词模板和工作流改动清单。第三把AI的使用门槛从“个人兴趣”拉到“团队规范”。不要让大家各自用各自的开源框架、各自写提示词。团队里选一个公共基座把提示词模板、结构化约束Schema、回归用例都沉淀在统一仓库里。这样别人踩过的坑其他人不必再踩一遍。这看起来是效率问题本质上是组织学习速度的问题。4.4 为什么这项能力比模型参数更稀缺模型参数排行榜月月刷新开源模型的能力下限在快速抬高。这就意味着任何团队能拿到的模型基座都差不多。你用开源模型能做出的效果别的团队一个月后也能做出来。这种情况下唯一能拉开差距的就是你围绕着模型建立的学习系统。你能多快把一次失败变成全团队的共同经验你能多快把一个成功案例沉淀成可复用的模板。这种速度是模型参数无法替代的。芯片设计这个行业一向保守因为一次流片失败的成本太高。这决定了它对AI的态度不会是激进替换而是稳健融合。在这个过程中最稀缺的一直都不是会调模型的人而是知道“什么值得自动化、什么必须保留人味”的规则设计者和“能把错误快速转化为改进”的组织机制。5. 关于那项研究容易被忽略的两个细节5.1 “预注册时间线”的本质是在给代理建立信任边界那项研究里特别强调了“预注册”让代理在行动前先提交计划。很多搞AI的人可能觉得这太繁琐多此一举。但我恰恰认为这是整个框架里最值得学的部分。芯片设计流程的代价结构非常不对称写错一段代码的代价可能只是一次仿真失败但如果在不明不白的情况下让错误代码进入后续环节代价会指数级放大。AI代理一旦自主性增强就会做出让人意想不到的操作。预注册相当于给代理建立了一个“信任边界”你可以自主探索但要先告诉人类你要去哪、怎么去。这在管理高风险过程里远比事后审计高效。落到企业的AI工具设计上也应该强调“过程透明”。不要只给经理一个最终结果仪表盘要给每个任务流一个过程记录最好详细到每次模型自反馈改了什么。有了这个记录出了问题才能回溯复盘才有材料。5.2 代理间结构化协作“分工”不是效率问题是算力和语义损耗问题研究里把大型设计任务拆给多个代理协同本身也很有意思。很多人会觉得“一个能力超强的单体模型”应该比“一堆能力一般的代理协作”更强。但在芯片设计场景里我不这么认为。原因在于上下文窗口的现实约束。一个超大任务塞进单一模型上下文很快会被无关信息淹没。而多个代理各司其职相当于给每个模型一个更聚焦的上下文窗口。A代理只专注于解析规格和生成结构化约束B代理拿着约束去做代码生成C代理做验证结果分析。每个代理的提示词都短而精犯错概率显著下降。但这种协作设计有个隐性成本就是代理之间传递的信息会有语义损耗。A理解的需求经过转述B可能会理解偏。因此代理之间交互的“接口协议”设计变得重要。这又是一项新的工程能力如何设计代理间的信息格式让一方输出的约束能被另一方无歧义地消费。这些细节在公开报道里往往被一语带过但对真正想落地的人来说它们才是金矿。6. 我自己在实际项目中的三点体会与提醒聊了这么多最后分享几条我在实际推进AI辅助设计时的零散体会。它们不一定适合所有团队但至少能帮你避开几个我踩过的坑。第一提示词工程不像外界说的那么“软”。在一个约束明确的设计流程里提示词的写法直接决定输出代码能不能用。我试过两种方式一种是把设计规格直接复制给模型另一种是花半小时把规格转成结构化约束表再加参考风格片段。前者需要人工删改大量错误代码后者几乎一路绿灯。别听信“提示词工程已死”这类说法那是在应用太浅的领域里的结论。在芯片这种重约束领域提示词本身就是设计的一部分。第二别迷信“全自动”。现阶段AI-native芯片设计的最佳形态是“AI提出参考方案人类专家审核修改反馈数据回流”而非“AI直接交付最终版”。我见过一个团队强行追求零人工干预结果AI生成的设计里出现了一个极其隐蔽的跨时钟域风险问题差点流片翻车。AI可以帮忙把设计空间探索的范围缩得很小但最后那一下“拍板”短期还是得人来做。第三工具链的“可观测性”决定AI引入的成败。有些团队导入AI辅助设计工具之后发现没法用核心原因不是模型不好而是它输出的中间步骤不可追踪。AI生成了一个模块但你不知道它基于哪些假设、考虑过哪些约束、修改过哪些版本。这在大规模项目里是不可接受的。所以选工具的时候别只看演示效果多惊艳要看它导出的过程日志和决策记录是否完整。一直有人问我AI-native芯片设计到底是不是泡沫。我的回答是会有一段泡沫期但方向和逻辑没问题。芯片设计的复杂度已经超越了纯粹靠堆人力的极限AI迟早会成为标配。但标配的意思是它会像编译器和综合工具一样成为基础设施而非竞争力本身。真正的竞争力还是会落在那些能定义约束、能构建闭环、能加速组织学习的团队手里。这三点就是我对那项研究最大的不同看法。