最近某头部科技公司放出了一份关于AI-native芯片设计的研究报告行业内讨论热度很高。大部分人都把目光聚焦在大模型能不能生成可用的电路或者AI会不会取代芯片设计师这种二选一的争论上但仔细读完整个报告的逻辑我发现它真正想回答的问题其实是另一个当AI开始参与从系统架构到物理实现的芯片设计全流程整个行业最稀缺的能力到底是什么研究报告给出的核心判断有一定道理但结合我自己这几年在不同芯片项目里摸爬滚打的经验我对其中几个关键结论有完全不同的看法。这篇文章不打算复述报告内容而是想认真聊一聊我看完之后的三个分歧点以及如果让我重新组织一条AI-native芯片设计流程我会把资源优先砸到哪里。1. 先搞清楚这份研究到底在说什么AI-native不等于把AI塞进EDA1.1 两种完全不同的设计范式很多人一提AI芯片设计第一反应就是用AI工具辅助做布局布线用强化学习优化时钟树这其实是传统EDA的AI增强属于把AI当作一把更好用的螺丝刀。而研究报告里讨论的AI-native完全是另一回事它主张从设计数据的表示方式开始就为AI而重新设计让流程中的每一个环节——设计意图捕获、参数化空间探索、逻辑综合、物理实现、验证策略——都以AI模型作为不可分割的组成部分。我习惯用一个简单类比来区分这两个层次传统EDA的AI辅助像是你用计算器算账算法帮你按得更快AI-native则是你重新设计整套记账体系从账本数据结构、科目分类到结算规则全部为了自动化计算而重新定义计算器只是其中一环甚至不再是主角。也就是说AI-native不是锦上添花的工具而是整个流程的原生操作系统。1.2 研究报告反复强调的稀缺能力是什么从报告公开讨论的内容看它认为AI-native芯片设计中最稀缺的能力是对电路行为的高质量抽象与跨层次建模能力。为了支撑这个观点报告用了不少篇幅说明一个现象当前生成式模型已经能产出逻辑上看起来正确的代码和网表但一旦进入物理实现阶段结果常常大面积失败因为时序、功耗、可制造性这些跨层次要素根本无法靠生成得更长更完整来解决。这个观点的确抓住了痛点。芯片设计跟写软件有一个本质差异软件可以接受一定程度的模糊发布之后打补丁芯片不行芯片一旦流片所有错误都变成实实在在的成本而且很多电路行为是跨层次的——逻辑综合时的优化决策会直接影响物理设计的收敛性而物理设计中的布局又会反过来推翻逻辑层面的意图。假如没有一种能把跨层信息压缩成统一优化目标的高质量抽象AI生成的电路永远只在仿真器里看起来正确。1.3 我认可的部分不能盲目崇拜模型的规模报告里有一点我非常认同单纯堆参数规模解决不了芯片设计问题。大模型在自然语言、图像这类高冗余领域之所以效果好是因为语义空间有大量冗余可以稀释错误但芯片设计恰恰是高约束、低冗余的领域每一个晶体管都必须满足物理规则任何一点偏差都可能让整个设计失效。所以在这个领域模型的泛化能力不是靠数据量硬堆出来的而是靠在领域约束条件下反复打磨出来的。2. 我的第一点不同看法稀缺的不是建模能力而是问题可判定性的工程化2.1 为什么说不清楚什么算对比建不好模型更致命报告把稀缺能力归结为跨层次建模但我在实际项目里观察到的情况是真正的瓶颈往往在问题本身能不能被形式化地判定。听起来很绕但换句话就很好懂——很多设计环节我们根本说不清楚什么算对。比如在架构探索阶段表面上目标函数是性能、功耗、面积这几个指标但实际评估一个候选方案时你还要考虑可测试性、可布局性、供应链里某个特定IP的可用性、甚至下游封装工艺的限制。这些隐性约束大量存在于资深设计师的脑子里从来没有被写进任何一份需求文档。AI-native流程的第一步需要把设计问题转成模型能优化的目标函数而在这个形式化的过程中大量隐性知识会无可避免地丢失。2.2 一个真实的反面案例逻辑正确但物理失败我之前参与过一个模拟项目X团队花了大力气训练一个寄存器传输级代码生成模型专门用来根据高层规格自动生成模块代码。模型在逻辑仿真阶段的正确率已经做到相当可观团队上下都觉得看到了希望。结果到了物理综合阶段生成结果大面积出现时序违例和拥塞问题很多模块根本没法在目标频率下收敛。这个问题的根源不是模型能力不够而是我们定义正确性时只覆盖了逻辑层。没有人事先把物理约束、时序预算、拥塞预估这些判据接入到模型训练的信号里。也就是说这个模块生成得算不算成功这个问题的判定标准在逻辑层和物理层之间完全是两个世界而我们在启动项目的时候根本没有意识到需要先解决这个可判定性问题。2.3 解法把判定器前置到模型训练信号中吃过那次亏之后我现在做任何AI-native设计流程第一件事就是搭一套多层判定器体系逻辑层用形式验证工具做等价性检查时序层用静态时序分析跑整套约束物理层跑一版快速布局布线拿到面积和拥塞预估。每一层都有明确的通过/不通过标准并且把这些判定器前接到生成模型的奖励信号里让模型在每一次迭代中不仅看到逻辑对不对还看到物理上有没有可能收敛。这个做法的成本不低因为你需要同时维护三套验证环境和三套数据管线。但它的价值远超任何单个模型判定器体系解决了问题可判定性的工程化让AI的输出永远有一个明确、可执行、跨层次的验收标准。我认为这才是真正稀缺的——一个能完整承接设计意图的判定体系而不是某个更聪明的模型。3. 我的第二点不同看法稀缺的不是全流程自动化而是可信可回退的人机协作机制3.1 AI-native并不等于无人化研究报告在讨论AI-native时实际上写了一个倾向似乎流程越自动化就越接近理想的AI-native状态。我和这个观点完全相反。芯片设计是一个容错率极低的领域一次完整流片的成本高得惊人没有任何团队敢把最终签核决策完全交给一个黑箱模型。AI-native真正的形态不应该是AI做决定、人签字而应该是AI做建议、人做判断、系统保底可回退。这就像自动驾驶L4级别在开放道路上可以做到完全无人但在限定场景里大家最终接受的是人机共驾随时接管。AI-native芯片设计也一样我们在设计层面追求的是一个稳定的人机闭环AI负责探索设计空间的大片区域人负责在关键决策点上做确认或否决系统必须保证任何一步被否决之后AI能够理解原因并在下一轮迭代中修正方向。3.2 设计师的认知负担为什么模型准确率高但没人敢用很多项目里出现过一个怪现象某个AI优化模块的测试结果非常好PPA性能、功耗、面积指标全面优于人工基线但设计师就是不敢把它合入主线。我追问过很多次得到的回答出奇一致我不知道它为什么能好也不知道它什么时候会突然变差。这个现象说明模型能力再强如果不能降低使用者的认知负担它在工程落地中的价值就是零。设计师要承担的不仅是理解AI给出的方案建议还要判断该在什么条件下采纳、什么条件下否决。这种判断能力不会因为模型准确率提高而自动获得它需要系统在设计层面显式地提供支持——也就是可解释的接口。3.3 如何建立增量式的信任机制我的做法其实可以类比数据库里的两阶段提交机制。AI在给出优化建议时不是只给一个结论而是同时输出三样东西关键假设清单依赖哪些边界条件、置信区间当前预估的可靠性范围、回退点信息如果采纳这个建议出了问题最坏损失是多少能否回到上一个状态。设计师在评审时不需要理解模型的全部内部逻辑但必须能看到如果它错了我能不能不流血地撤回来。信任从来不是靠模型跑分刷出来的而是靠工程上的可控性一点点积累起来的。最开始你可能只让AI处理一些非关键模块跑几十个项目验证它的回退机制是可靠的之后再把决策权限逐步扩大。这个过程很慢但它是唯一能让AI-native设计在真实流片项目里存活下来的路径。4. 我的第三点不同看法稀缺的不是指标领先而是可迁移的设计资产沉淀4.1 行业最大的误区把benchmark当成一切每次有AI-native芯片设计的研究出来舆论都会盯着某个benchmark上的数字生成正确率提升了多少时序预测精度提升了多少。但以我的观察这种单点指标领先在工程上的真实价值相当有限。真正值钱的、能构成长期壁垒的是流程跑完一遍之后沉淀下来的设计资产——包括数据资产、流程资产、决策资产。数据资产这个词听起来普通但实际上大多数AI-native项目都没有真正积累起来。很多团队确实是跑了海量仿真但保存的基本都是网表、波形这些原料完全没有把验证环境、约束版本、工具版本、甚至一次设计评审的结论记录下来。结果项目一结束AI流程的经验就随着人员流动彻底蒸发。4.2 负样本被忽略的宝藏我发现一个几乎没人提过的现象AI-native的模型训练大家都喜欢堆成功案例——即那些最终通过验证、成功流片的模块设计。但实际上设计流程中最有学习价值的部分恰恰是那些被否决的方案和来回修改的过程。比如一个计算结果通过了所有签核检查但因为可测试性不足被评审会推翻又比如一个模块连续经历了多轮ECO工程变更指令才最终收敛。这些负样本和被反复修改的记录编码了真实世界中大量隐性约束——这种知识是任何教科书都写不进去的。如果你真的想让AI-native流程越用越聪明就应该把数据管线的重心放在回收这些失败与修正上。我甚至觉得设计一个数据回收机制让每次人工否决和修改都能自动沉淀为训练样本比优化模型结构本身更紧迫。4.3 可迁移性从工艺无关到工艺相关我一直提醒身边的同行AI-native设计资产如果不可迁移那它本质上只是每个项目的一次性消耗品。具体来说要把设计资产按抽象层次分层与工艺节点无关的资产比如逻辑设计模式、验证策略模板、决策规则可以跨项目复用与具体工艺强相关的资产比如特定标准单元库下的时序模型、光刻约束下的布局策略则需要单独维护。这里的关键是建立一套资产管理机制让每个项目结束后都能自动完成资产分类入库并在下一个项目启动时能被快速检索和复用。如果做不到这一点每次新项目都从零开始收集数据、训练模型、调参那AI-native的成本就会高到没有任何团队能持续负担。这一点是绝大多数研究在讨论技术可行性时完全忽略掉的。5. 如果让我来落地AI-native芯片设计我真正会优先投入的时刻5.1 从单点闭环开始不做大而全的平台很多团队犯了同一个错误一上来就要搭一个覆盖全流程的AI-native平台从架构探索到物理实现全部AI化。以我的经验这种大而全的平台绝大多数会烂尾因为流程中每一环的成熟度差异太大你根本找不到一个统一的数据接口能把所有环节串起来。我的建议是先挑一个最痛的单点闭环。以我的经验物理综合之前的时序预估和拥塞预判通常是最值得AI下手的环节——因为这一环传统方法误差大、反馈慢而且一旦预估错误后续的PPA性能会全盘崩掉。在这个单点上把数据管线、多层判定器、人机回退接口、负样本回收机制全部做完整形成一个能自我迭代的闭环再逐步向逻辑综合、布局布线等上下游扩展。5.2 工具链选型与团队配置容易被忽略的细节工具链层面纯开源的流程和商业EDA工具之间需要做一个务实的取舍。如果目标是快速验证AI算法开源流程确实方便但如果是冲着流片去的最终签核还是离不开商业工具。我的折中方案是算法探索阶段使用开源流程跑大量数据、训练模型到了关键节点用商业工具做交叉验证保证数据的可信度。数据格式这一环尤其要提前统一——Pin级标注、时序预算、物理约束的命名规范如果不一致后面合并训练集的时候会非常痛苦。团队配置上有一条经验我认为比技术选型更重要AI-native流程项目里除了芯片设计工程师和AI算法工程师一定要有一个专职的流程架构师。这个角色的核心工作不是写模型也不是画版图而是把整条设计流程拆解成AI可以训练和评估的独立任务单元定义每个单元的输入输出接口和判定标准。缺少这个角色算法团队和设计团队往往会互相听不懂对方在说什么项目就会一直在技术翻译里空转。5.3 绕不开的坑几个常见病根与对策走完几个项目之后我整理过一份踩坑清单这里挑最典型的几条坑的表现根因对策模型训练结果不可复现换一台机器就变训练随机性没有管理全流程固定随机种子Diffusion/强化学习还要锁定数据增强和探索策略回归测试时好时坏无法判断模型是否变强验证环境不稳定先用一套冻结的测试集建立基线任何改动必须回归通过才允许合入设计师完全不采纳AI建议人机接口设计太重要求AI输出建议时附带置信区间和回退点采用两阶段提交式评审项目结束之后知识归零没有资产回收机制把负样本、评审意见、修改记录强制纳入数据管线像管理代码一样管理设计数据这五条坑每一条我都真实踩过而且都是那种看似不起眼、但能让整个项目停滞好几个月的类型。如果你正在规划自己的AI-native流程建议先对照这张表自查一遍比急着上模型更有价值。最后的几句实在话过去几年陪不同团队走完好几条AI-native芯片设计的落地路径我最大的感受是不要太迷恋AI自动做设计这个叙事。真正稀缺的能力永远在模型之外——你能不能把一个问题定义到可以判定的程度敢不敢让AI出错并且确认自己随时能回退以及能不能把每一个项目沉淀成下一次可复用的资产。这三件事任何一件都比训练一个更大的模型更难也更重要。最后分享一个我一直在用的评审技巧任何AI-native流程走到阶段评审时先问一句——如果AI今天全面失效你的团队还能不能按原有流程完成任务能说明这套系统是健康的增强不能说明你已经把一个不成熟的系统绑在了整个团队的生产力上。保持这个反问的习惯能帮你避开绝大多数听起来很美的陷阱。