1. 从“AI设计芯片”这个说法说起“AI-native 芯片设计”这个词最近被讨论得很多起因是某头部研究机构发布了一篇关于用 AI 辅助甚至主导芯片设计流程的研究。消息传开之后各种解读铺天盖地有人说“芯片设计师要失业了”有人说“以后芯片设计就是调参”还有人把这件事类比成“AlphaGo 之于围棋”。我在芯片设计和 EDA 工具链这个圈子里待了十多年看到这些讨论的第一反应是方向没错但大部分解读都偏了。偏在哪里偏在把“AI 能做什么”和“AI 真正稀缺的能力是什么”混为一谈。这两件事之间的差距可能比很多人想象的要大得多。这篇文章不打算复述那篇研究的具体内容而是想从一线从业者的角度聊聊我对“AI-native 芯片设计”这件事的三点不同看法。核心关键词就三个AI-native 芯片设计、稀缺能力、工程落地。如果你是从业者或者正在考虑进入这个方向希望这些内容能帮你少走一些弯路。先说结论AI 在芯片设计领域真正稀缺的能力不是算法有多强、模型有多大而是把设计意图准确翻译成约束条件的能力、在巨大搜索空间里做工程折中的能力以及对设计结果做可信验证的能力。这三点目前 AI 都还差得远而这恰恰是人类工程师最值钱的地方。2. 三点不同看法的整体拆解2.1 为什么我要“唱反调”先交代一下我的立场。我不是在否定 AI 在芯片设计中的价值恰恰相反我认为 AI 在这个领域的渗透速度会比大多数人预期的更快。但正因为如此才更需要有人把“能做的事”和“难做的事”分清楚否则整个行业会陷入一种盲目的乐观最后在工程落地的环节摔跟头。我见过太多类似的场景一个新技术出来媒体先吹一波资本跟进一波然后真正做工程的人发现demo 很漂亮但离量产还差十万八千里。芯片设计尤其如此因为它是一个容错率极低的领域。一次流片失败可能就是几百万甚至上千万的损失外加几个月的工期延误。这种场景下“差不多能用”是远远不够的。所以我的三点看法本质上是在回答同一个问题当 AI 进入芯片设计流程之后哪些能力会变得稀缺哪些能力会被重新定价2.2 三点看法的逻辑关系这三点看法不是并列的而是有递进关系的。第一点关于设计意图的翻译这是入口问题。AI 再强如果输入的设计意图本身就是模糊的、不完整的那输出一定不可靠。第二点关于搜索空间里的工程折中这是过程问题。芯片设计本质上是在功耗、面积、性能、成本之间找平衡这个平衡点怎么找AI 目前还很难替代人的判断。第三点关于可信验证这是出口问题。设计出来的东西能不能用、敢不敢用最终要靠验证来说话而验证这件事AI 目前更多是辅助角色。把这三点串起来看你会发现一个有意思的现象AI 在芯片设计中最容易切入的环节恰恰是那些规则明确、反馈及时、搜索空间相对封闭的环节比如布局布线优化、参数调优、版图检查。而最难切入的是那些需要跨领域知识、需要权衡取舍、需要承担决策责任的环节。2.3 对从业者的实际影响聊这些不是为了空谈而是因为它直接关系到从业者的职业选择。如果你是一个刚入行的芯片设计工程师看到“AI 要取代设计师”的新闻可能会焦虑。但如果你理解了上面这个逻辑你就会知道被取代的不是设计师而是设计师工作中那些重复性的、规则明确的部分。真正稀缺的能力反而会因为 AI 的普及而变得更加值钱。举个例子。以前一个工程师可能要花大量时间在手动调参数、跑仿真、看波形上。AI 工具把这些时间压缩之后工程师的时间会释放出来去做更有价值的事理解系统需求、定义设计约束、判断折中方案、做架构决策。这些事AI 目前做不了短期内也看不到能做的迹象。3. 第一点看法设计意图的翻译才是真正的瓶颈3.1 芯片设计不是从代码开始的很多人对芯片设计的理解是从 RTL 代码开始的觉得写 Verilog 就是芯片设计的全部。这是一个巨大的误解。真正的芯片设计是从理解需求开始的。需求可能来自很多地方产品经理说“我要一个低功耗的蓝牙芯片”系统架构师说“这个模块的吞吐量要跑到多少”软件团队说“我需要这个接口支持某种协议”。这些需求都是自然语言的、模糊的、甚至互相矛盾的。芯片设计工程师要做的第一件事就是把这些模糊的需求翻译成精确的、可执行的、可验证的约束条件。这个过程我称之为设计意图的翻译。它包含好几个层次从产品需求到系统架构从系统架构到模块划分从模块划分到接口定义从接口定义到具体的时序、面积、功耗约束。每一层翻译都会丢失信息每一层翻译都可能引入歧义。3.2 AI 在翻译环节的真实表现那 AI 在这个环节表现如何说实话目前还很有限。我试过用一些 AI 工具来辅助做需求分析和约束提取。在结构化程度高的场景下比如从一份格式规范的协议文档里提取接口时序要求AI 做得还不错能省不少时间。但一旦进入非结构化的场景比如从一段产品讨论的会议记录里提炼出关键的设计约束AI 的表现就很不稳定经常抓不住重点或者把次要需求当成核心需求。为什么会这样因为设计意图的翻译不仅仅是语言问题更是领域知识问题。一个资深工程师在听产品经理描述需求的时候脑子里同时在跑很多东西这个需求对应的典型架构是什么有哪些已知的实现方案每种方案的代价是什么哪些约束是硬性的、哪些是可以商量的。这种背景知识的调用AI 目前还很难做到。3.3 一个具体的翻译案例举个具体的例子。假设需求是“这个芯片要支持某种低功耗模式待机电流要小于某个值”。一个资深工程师听到这句话脑子里会立刻浮现出一串问题这个待机电流是在什么温度下测的是典型值还是最大值低功耗模式下哪些模块要断电、哪些要保持供电唤醒时间有要求吗这些问题的答案直接决定了电路架构和电源管理策略。而 AI 拿到这句话大概率会直接开始搜索“低功耗设计技巧”然后给你一堆通用的方法时钟门控、电源门控、多阈值电压等等。这些方法都对但没有针对性。它不知道你的具体场景是什么不知道你的约束边界在哪里所以给出的建议往往是“正确的废话”。这就是我说的稀缺能力把模糊需求翻译成精确约束的能力。这种能力目前主要掌握在资深工程师手里而且很难被结构化、很难被规模化。AI 要在这个环节真正发挥作用需要的不仅仅是更强的语言模型还需要领域知识图谱和设计经验库的支撑。提示如果你正在做 AI 辅助芯片设计的产品建议把重点放在“翻译环节的辅助”上而不是“翻译环节的替代”上。辅助的意思是帮工程师更快地整理需求、更全地列出约束、更早地发现矛盾。这个定位更现实也更有价值。4. 第二点看法搜索空间里的工程折中无法被算法替代4.1 芯片设计本质上是一个优化问题抛开所有的工程细节芯片设计本质上是一个多目标优化问题。你要在功耗、面积、性能、成本、工期这几个维度之间找平衡。这几个维度往往是互相矛盾的性能上去了功耗可能就下来了面积缩小了成本可能反而上升因为良率下降工期压缩了质量可能就出问题。这个优化的搜索空间有多大大到难以想象。一个中等规模的芯片可能有几十亿个晶体管每个晶体管的位置、尺寸、连接方式都有无数种可能。即使把问题简化到布局布线这一个环节搜索空间也是天文数字。AI 擅长什么擅长在巨大的搜索空间里找局部最优解。强化学习、遗传算法、模拟退火这些方法在布局布线优化上已经有实际应用效果也不错。但问题在于芯片设计要的不是局部最优而是全局可接受的折中。4.2 折中背后的“不可言说”知识什么叫“全局可接受的折中”就是综合考虑了各种因素之后选一个“够用就好”的方案。这个“够用就好”的标准往往不在任何文档里而是存在于资深工程师的脑子里。我举个例子。假设你在做一个移动端芯片有两个布局方案方案 A 的性能高 5%但面积大 10%方案 B 的性能低 5%但面积小 10%。选哪个这取决于很多因素产品的定位是什么成本压力大不大散热条件怎么样竞争对手的产品是什么水平甚至公司当前的战略重点是抢市场还是保利润。这些因素很多是商业层面的不是技术层面的。AI 可以告诉你方案 A 和方案 B 的技术指标差异但它很难告诉你“在当前市场环境下应该选哪个”。这个判断需要的是商业敏感度和工程经验的结合而不是算力。4.3 AI 在折中环节的合理定位那 AI 在折中环节能做什么我认为最合理的定位是提供决策支持而不是替人做决策。具体来说AI 可以做的事包括快速生成多个候选方案并给出每个方案的技术指标对候选方案做敏感性分析告诉决策者“如果某个约束放松一点收益有多大”记录历史决策和结果形成可检索的经验库帮助新人快速上手。这些事本质上是在扩大决策者的信息输入而不是替代决策者的判断。我觉得这个定位很重要因为它决定了 AI 工具的设计方向。如果你把 AI 定位成“决策者”那你会追求更高的自动化程度如果你把 AI 定位成“决策支持者”那你会更注重可解释性和交互性。注意在芯片设计这种高风险领域“可解释性”往往比“准确性”更重要。一个准确但无法解释的 AI 建议工程师不敢用一个稍微不那么准确但能说清楚理由的 AI 建议工程师反而更愿意采纳。5. 第三点看法可信验证是 AI 最难跨越的门槛5.1 验证占了芯片设计一半以上的工作量在芯片设计行业有一个不太被外界知道的事实验证工作量通常占整个设计周期的 50% 到 70%。也就是说设计工程师写 RTL 代码可能只花了 30% 的时间剩下 70% 的时间都在验证这个设计对不对。为什么验证这么重要因为芯片一旦流片改不了的。软件有 bug 可以打补丁芯片有 bug 只能重新流片代价是几百万到几千万外加几个月的工期。所以芯片行业对验证的要求极其苛刻追求的是尽可能高的覆盖率和尽可能低的漏检率。5.2 AI 在验证环节的现状AI 在验证环节的应用目前主要集中在几个方向自动生成测试用例、智能分析覆盖率漏洞、辅助定位 bug 根因。这些方向都有实际的产品和案例效果也参差不齐。自动生成测试用例是相对成熟的方向。传统的测试用例靠工程师手写覆盖率和效率都有限。用 AI 来生成测试用例可以更快地覆盖更多的场景尤其是那些边界场景和异常场景。但问题在于AI 生成的测试用例质量不稳定有时候会生成大量冗余的、无效的用例反而增加了验证的工作量。智能分析覆盖率漏洞是另一个有意思的方向。芯片验证有一个核心指标叫“功能覆盖率”衡量的是测试用例覆盖了多少设计功能。AI 可以分析覆盖率报告找出覆盖不足的地方并建议补充哪些测试用例。这个方向我觉得很有前景因为它把 AI 的模式识别能力用在了合适的地方。5.3 验证的本质是“建立信任”但不管 AI 在验证环节做多少事有一个核心问题始终绕不开你敢不敢信 AI 的验证结果验证的本质不是跑多少测试用例而是建立对设计的信任。这种信任的建立需要的是可追溯的证据链每个功能点都被验证过每个边界条件都被考虑过每个异常场景都被覆盖过。这个证据链必须是完整的、可审计的、可复现的。AI 目前的问题在于它的验证过程往往是黑盒的。你给它一个设计它告诉你“验证通过了”但你不知道它是怎么验证的不知道它覆盖了哪些场景不知道它有没有漏掉什么。这种黑盒的验证结果在芯片行业是很难被接受的。所以我认为AI 在验证环节的真正挑战不是技术上的而是信任上的。要让工程师敢用 AI 的验证结果AI 必须做到过程透明、证据完整、结果可复现。这三点目前都还有很大的差距。提示如果你在做 AI 验证工具建议把“可解释性”和“可追溯性”放在第一位。宁可 AI 的验证速度慢一点也要保证每一步都有记录、每一个结论都有依据。在芯片行业“快”从来不是第一优先级“稳”才是。6. 常见问题与排查技巧实录6.1 关于 AI 芯片设计的常见误解在和同行交流的过程中我发现有几个误解反复出现。这里整理一下附上我的看法。常见误解实际情况AI 可以端到端完成芯片设计目前只能在局部环节辅助端到端还差得远AI 会取代芯片设计工程师取代的是重复性工作核心判断能力反而更值钱AI 设计的芯片性能更好在特定优化目标下可能更好但全局折中能力弱AI 工具开箱即用需要大量领域数据训练和调优落地成本很高AI 验证结果可以直接采信需要人工复核黑盒验证结果风险很大6.2 实操中的排查思路如果你正在尝试把 AI 工具引入芯片设计流程遇到问题可以按这个思路排查。第一步确认问题出在哪个环节。是输入的设计意图不清晰还是 AI 的输出不可靠还是验证环节跟不上不同环节的问题解决思路完全不同。第二步检查数据的质量和数量。AI 在芯片设计中的表现很大程度上取决于训练数据的质量。如果你的数据是零散的、不规范的、有噪声的AI 的输出一定好不到哪里去。先把数据整理好再谈模型优化。第三步评估 AI 输出的可解释性。如果 AI 给出的建议你无法理解、无法追溯那这个建议就不应该被采纳。宁可不用也不要用一个你搞不懂的工具。第四步小范围试点逐步扩大。不要一上来就把 AI 用在核心模块上。先在一个边缘模块上试点积累经验建立信任再逐步扩大应用范围。6.3 几个实操心得最后分享几个我在实际工作中总结的心得。心得一AI 工具的价值不在于“替代”而在于“加速”。把 AI 当成一个不知疲倦的助手而不是一个全能的专家。它帮你跑仿真、整理数据、生成报告但最终的判断还是你自己做。心得二领域知识比算法更重要。在芯片设计这个领域一个懂设计的算法工程师比一个不懂设计的算法专家更有价值。因为只有懂设计才知道什么问题值得优化什么约束不能碰。心得三不要追求“全自动”追求“人机协同”。全自动的 AI 芯片设计目前还看不到落地的可能。但人机协同的工作模式已经在很多环节产生了实际价值。工程师负责定义问题和判断结果AI 负责搜索方案和执行重复劳动这个分工是目前最现实的。心得四验证环节的 AI 应用要格外谨慎。验证是芯片设计的最后一道防线这道防线如果被 AI 的“黑盒”特性削弱了后果可能是灾难性的。在验证环节用 AI一定要保留完整的人工复核流程。7. 对从业者的一点个人建议聊了这么多最后说点实在的。如果你是一个芯片设计工程师面对 AI 浪潮我的建议是不要焦虑但要主动适应。焦虑没有用因为焦虑改变不了趋势。AI 进入芯片设计领域是必然的就像当年 EDA 工具取代手工绘图一样。但适应是有用的因为适应能让你在新的工具环境下找到自己的位置。怎么适应我的建议是把时间从重复性工作中解放出来投入到那些 AI 做不了的事情上。比如多花时间理解系统需求多花时间思考架构方案多花时间积累跨领域的知识。这些事AI 短期内替代不了长期看也很难替代。另外如果你对 AI 本身感兴趣不妨主动去了解一些 AI 工具的原理和用法。不需要成为算法专家但至少要能看懂 AI 的输出知道它的局限性在哪里。这种跨领域的理解能力在未来会越来越值钱。芯片设计这个行业从来都是靠经验吃饭的。AI 的出现不会改变这一点反而会让真正有经验的工程师更加稀缺。因为当 AI 把重复性工作干掉之后剩下的都是需要经验和判断的工作而这些工作恰恰是资深工程师最擅长的。所以与其担心被 AI 取代不如想想怎么用 AI 把自己武装得更强。这个思路我觉得比什么都重要。