1. 当所有人都在聊"AI设计芯片"时，我更关心它到底卡在哪
最近圈子里聊得最热的一个话题，就是某头部研究机构放出的那份关于"AI原生芯片设计"的报告。标题很唬人，内容也确实有料，但我翻完一圈讨论之后发现，绝大多数人把注意力放错了地方。大家要么在惊叹"AI居然能自己设计芯片了"，要么在焦虑"芯片工程师是不是要失业了"，很少有人认真去问一个更本质的问题：在这套流程里，真正稀缺的能力到底是什么？
我自己在芯片设计和工具链这条线上摸爬滚打了十来年，从最早手写RTL、跑综合、盯时序，到后来接触各种自动化布局布线工具，再到现在看各种AI辅助设计的方案，有一个感受越来越强烈：AI能替代的从来不是"设计"本身，而是设计过程中那些可以被形式化、可以被搜索、可以被暴力枚举的部分。而真正决定一颗芯片成败的那些判断，恰恰是AI目前最不擅长的。
这份报告我读了两遍，也和一些做EDA工具、做架构设计的朋友聊了聊。下面我想从三个角度说说我和主流观点不太一样的地方。不是抬杠，而是觉得如果大家都顺着"AI万能"的思路往下走，很可能会在真正关键的地方踩坑。这篇文章适合三类人看：一是正在做芯片设计、想知道AI到底能帮上什么忙的一线工程师；二是做工具链、做平台、想把AI能力接进现有流程的产品和技术负责人；三是对这个方向感兴趣、想判断趋势的观察者。我会尽量把原理讲透，把实操层面的东西说清楚，也会分享一些我自己踩过的坑。
先说结论，我认为真正稀缺的能力有三个：把模糊需求翻译成可验证约束的能力、在巨大搜索空间里定义"好"的能力、以及为AI产出兜底做物理验证的能力。这三点，报告里要么一笔带过，要么归到了"工程实践"这种模糊的筐里，但在我看来，它们才是决定AI原生芯片设计能不能真正落地的命门。
2. 拆解"AI-native芯片设计"：它到底在做什么，不做什么
2.1 从RTL到GDSII，哪些环节真的被AI改写了
要聊清楚稀缺能力，得先搞清楚AI在芯片设计流程里到底介入到了哪一步。一颗数字芯片从想法到流片，大致要经过这么几个阶段：架构定义、RTL设计、功能验证、逻辑综合、布局布线、时序签核、物理验证、最后送交制造。这条链路非常长，每一环都有大量的工具和人力投入。
AI介入最深的地方，其实是布局布线（Place & Route）和逻辑综合的优化环节。原因很简单，这些环节本质上是一个超大规模的组合优化问题。比如布局，你要把几十万甚至上百万个标准单元放到一个芯片版图上，同时满足时序、功耗、面积、拥塞等一堆约束。这个搜索空间大到什么程度？打个比方，就像让你在一个足球场上摆放上百万颗棋子，每颗棋子的位置都会影响其他棋子的"心情"，而且你还要让整个棋盘的"效率"最高。传统做法是靠启发式算法加人工调参，而AI，尤其是强化学习，特别擅长在这种环境里做试错和搜索。
但AI介入浅、甚至基本没介入的地方，是架构定义和需求翻译。也就是说，"这颗芯片到底要干什么、性能指标怎么定、哪些功能必须硬件实现、哪些可以软件兜底"这些最顶层的决策，目前还是人在做。报告里提到的"AI-native"，我理解更多是指流程原生地为AI设计、让AI在优化环节发挥主导作用，而不是说AI能从零开始想出一颗芯片该长什么样。
这里有个很容易被忽略的点：优化问题的前提是目标函数已经定义好了。而芯片设计里最难的部分，恰恰是定义这个目标函数。你说"我要一颗低功耗的芯片"，这句话对AI来说毫无意义，因为它不知道"低"是多少，不知道功耗和性能怎么权衡，不知道在什么场景下功耗最重要。把这些模糊的、充满 trade-off 的需求，翻译成一组可量化、可验证的约束，这才是人真正不可替代的地方。
2.2 为什么"能跑通"和"能流片"之间隔着一条鸿沟
我见过太多demo级别的AI设计案例，跑出来的结果在仿真里漂亮得不行，时序收敛、面积还小，但一到物理验证阶段就原形毕露。原因在于，AI优化时用的模型和真实物理世界之间，存在巨大的简化误差。
举个具体的例子。很多AI布局工具在优化时会用一个简化的拥塞模型来估算布线难度，这个模型通常基于单元密度和引脚分布做统计预测。但真实的布线拥塞还跟金属层堆叠、通孔规则、电源网络、甚至制造工艺的偏差有关。AI在简化模型里找到的"最优解"，放到真实规则下可能根本布不通，或者布通之后时序崩了。
这就是我说的第三个稀缺能力——为AI产出兜底做物理验证的能力。这个能力不是简单地跑一遍DRC/LVS工具，而是要有能力判断：AI给出的这个方案，它的"乐观"到底来自哪里？是模型简化带来的系统性偏差，还是搜索过程中对某些约束的隐性放松？只有把这个问题搞清楚，你才能知道该在哪个环节加冗余、该在哪个环节收紧约束。
我自己的经验是，凡是AI参与优化的环节，验证的强度都要比人工设计时更高，而不是更低。因为人工设计时，工程师的直觉里已经包含了大量物理约束的隐性知识，他不太会给出一个物理上明显不合理的方案。但AI没有这种直觉，它只认目标函数，只要目标函数没覆盖到的约束，它就可能去"钻空子"。所以AI原生流程里，验证不是最后一道工序，而是贯穿始终的、需要被重新设计的一环。
3. 我的第一个不同看法：稀缺的不是算力，是"翻译需求"的人
3.1 把"我要低功耗"翻译成可搜索的目标函数，到底难在哪
报告里花了很多篇幅讲算力、讲模型规模、讲训练数据，这些当然重要，但我觉得它们都不是瓶颈。算力可以堆，模型可以调，数据可以攒，真正难的是把一句人话翻译成AI能优化的数学表达。
我拿一个真实场景来拆解。假设产品团队说："我们要做一颗面向边缘推理的芯片，功耗要低，但延迟不能太高，成本要控制在某个范围内。"这句话里有三个目标：功耗、延迟、成本。问题来了：
- 功耗是动态功耗还是静态功耗？峰值功耗还是平均功耗？在什么工作负载下的功耗？
- 延迟是单次推理延迟还是吞吐延迟？batch size 是多少？最坏情况延迟还是平均延迟？
- 成本是die面积决定的，还是封装、测试、良率综合决定的？
这些问题的答案不同，最终优化出来的芯片可能完全不一样。而AI不会自己问这些问题，它只会接受你给的目标函数然后开始搜索。如果你给的目标函数是错的，AI会非常高效地给你一个错误的最优解。这比人工设计出错更可怕，因为人工设计出错你还能从过程中看出端倪，而AI给出的结果往往"看起来很美"，直到你流片回来才发现方向就错了。
所以我认为，AI原生芯片设计里最稀缺的人，是那种既懂芯片、又懂优化、还能跟产品团队对话的"翻译者"。他要能把模糊的商业需求，拆解成一组层次分明、优先级清晰、可量化验证的技术指标，然后再把这些指标转化成AI能理解的优化目标。这个角色，目前在任何团队里都是极度稀缺的。
3.2 一个可操作的"需求翻译"检查清单
基于我自己的实践，我总结了一个把需求翻译成优化目标的检查清单，分享出来供参考。这个清单的核心思路是：任何进入AI优化器的目标，都必须能回答"怎么测"和"和谁比"这两个问题。
| 维度 | 必须回答的问题 | 常见坑 |
|---|---|---|
| 指标定义 | 这个指标的精确定义是什么？单位是什么？ | 把峰值和平均混为一谈 |
| 测量条件 | 在什么工作负载、什么温度电压下测量？ | 用理想条件测出来的数据做优化目标 |
| 优先级 | 多个目标冲突时，谁让谁？ | 把所有目标设成同等权重，导致优化器无所适从 |
| 约束边界 | 哪些是硬约束（绝不能违反），哪些是软约束（可权衡）？ | 把硬约束当软约束，优化结果不可用 |
| 验证方法 | 优化完成后，用什么方法验证这个指标达标？ | 验证方法和优化模型不一致，结果对不上 |
这张表看起来简单，但我在实际项目里见过太多团队栽在上面。最常见的就是把硬约束和软约束搞混。比如时序，在某些设计里是硬约束，必须满足；但在另一些设计里，稍微差一点可以通过降频来兜底。如果你不把这个区分清楚就丢给AI，它可能会为了优化面积而牺牲时序，最后给你一个面积很小但根本跑不到目标频率的芯片。
提示：在把任何目标交给AI优化器之前，先让团队里最懂这个指标的人写一段话，说明"这个指标怎么算达标"。如果写不出来，说明这个目标还没定义清楚，不要急着开始优化。
4. 我的第二个不同看法：搜索空间不是越大越好，定义"好"才是关键
4.1 为什么给AI更大的搜索空间反而可能更糟
现在有一种很流行的观点：AI能力强，是因为它能在巨大的搜索空间里找到人找不到的解。所以很多人做AI设计工具时，倾向于把搜索空间开得越大越好，觉得这样才"充分发挥AI的优势"。
我的看法恰恰相反。在芯片设计这种物理约束极强的领域，搜索空间开得太大，往往意味着大量算力被浪费在物理上根本不可行的区域，而且会让优化结果变得不可解释、不可复现。
我举个自己的例子。早些年我参与过一个用遗传算法做电路参数优化的项目，一开始我们把参数范围设得很宽，觉得这样能找到更优的解。结果跑了好几天，出来的方案确实在目标函数上比人工调的好一点，但问题是：这个方案对参数极其敏感，稍微有一点工艺偏差，性能就崩了。后来我们收窄了搜索范围，把一些明显不合理的区域排除掉，反而得到了更鲁棒、更容易复现的结果。
这件事给我的教训是：搜索空间的设计本身就是一种知识注入。你把哪些区域排除掉，其实是在告诉AI"这些地方物理上不靠谱"。这种知识，是资深工程师多年经验的结晶，比让AI盲目搜索要宝贵得多。AI原生设计不是要把人的知识排除出去，而是要把人的知识以更高效的方式注入进去。
4.2 定义"好"的三个层次：可行、可复现、可解释
那怎么定义"好"？我认为要分三个层次来看，而且这三个层次是有优先级的。
第一层是可行。这是底线，方案必须满足所有硬约束，物理上能实现，能流片。很多AI优化的demo就卡在这一层，仿真里可行，物理上不可行。
第二层是可复现。同一个输入，多次运行应该得到相近的结果，而且这个结果对工艺偏差、环境变化要有一定的鲁棒性。如果一个方案只在特定条件下最优，稍微一变就崩，那它在工程上价值有限。
第三层是可解释。这一点最容易被忽略，但在实际项目里极其重要。当AI给出一个方案时，工程师需要能理解"它为什么这么选"。如果完全是个黑盒，那一旦出问题，排查成本会高到无法接受。而且，不可解释的方案很难被复用、被改进，每次都要从头再来。
我见过一些团队，为了追求目标函数上的极致表现，牺牲了可复现性和可解释性，结果方案在实验室里很漂亮，一到量产就各种问题。在芯片这种一次流片成本极高的领域，"好"的定义必须包含工程可行性，而不只是数学上的最优。
4.3 实操：如何为AI优化器设计一个"有边界"的搜索空间
具体怎么做？我分享一套自己用过的方法，分四步：
- 先用人工经验划出"绝对不可行区"。比如某些参数组合会导致电路无法工作，这些区域直接排除，不要浪费算力。
- 再用历史数据划出"高风险区"。那些历史上出过问题、或者对工艺偏差敏感的区域，标记出来，让优化器在进入这些区域时格外谨慎，或者直接加惩罚项。
- 在剩余空间里，按优先级分层搜索。先优化最重要的指标，锁定之后再去优化次要指标，而不是一上来就多目标一起上。
- 对优化结果做敏感性分析。跑完之后，扰动一下关键参数，看看性能变化大不大。变化大的方案，即使目标函数值更好，也要慎重采用。
这套方法的核心思想是：不要指望AI在无边的空间里自己找到方向，而是用人的知识给它画一张地图，让它在有意义的区域里高效搜索。这比单纯堆算力要有效得多。
5. 我的第三个不同看法：验证不是收尾，而是AI原生流程的"第一性"环节
5.1 AI越强，验证越要"往死里做"
前面已经提到，AI优化依赖简化模型，而简化模型和真实物理之间有误差。这个误差在人工设计时，工程师的直觉会帮你兜住一部分；但在AI原生流程里，没有人去兜，所以验证必须做得更狠。
我自己的做法是，凡是AI参与生成的方案，验证强度至少是人工方案的两倍。具体来说：
- 仿真用的模型，要和优化用的模型不同源。如果优化用的是简化模型，验证就要用更精确的模型，甚至上SPICE级别的仿真。
- 验证的corner要更全。人工设计可能跑几个典型corner就够了，AI方案要把工艺、电压、温度的各种极端组合都跑一遍。
- 要做对抗性验证。也就是主动去找AI方案的"软肋"，看它在什么条件下会失效。这有点像安全领域的渗透测试，目的是在流片前把问题挖出来。
听起来很费时间？确实费。但比起流片失败重来的成本，这点验证时间根本不算什么。我见过太多团队为了赶进度，验证做得不充分，结果回来一堆bug，反而更慢。
5.2 一个真实的排查链路：AI布局方案为什么在时序上崩了
我来讲一个自己经历过的排查过程，完整还原一下思路，因为我觉得这种"排查链路"比结论更有价值。
当时的情况是：我们用一套AI布局工具生成了一个模块的布局方案，工具报告说时序收敛得很好，WNS（最差负时序裕量）是正的。但我们用另一套签核工具跑的时候，发现时序崩了，WNS是负的，而且差得不少。
排查第一步，确认两套工具用的是不是同一套约束。结果发现，AI工具用的时钟定义和签核工具用的不完全一致，AI工具里少定义了几个生成时钟。这是第一个问题，但补上之后，时序还是对不上。
排查第二步，对比两套工具用的寄生参数提取方式。AI工具为了跑得快，用的是估算的寄生参数；签核工具用的是更精确的提取结果。把签核工具的寄生参数喂给AI工具重新评估，时序确实变差了，但还没到崩的程度。
排查第三步，检查布局本身有没有物理问题。这一查发现了关键：AI布局在某些区域把单元堆得太密，导致布线时不得不绕远路，绕远路又引入了额外的延迟。AI工具在优化时用的拥塞模型没有准确预测到这一点，因为它没有考虑某些金属层的实际可用性。
最后怎么解决的？我们在AI优化时，把拥塞模型的权重调高，并且手动限制了几个关键区域的单元密度上限。重新跑之后，时序和签核工具对上了。
这个案例说明什么？AI方案的失败，往往不是因为它"算错了"，而是因为它"算的时候用的世界模型和真实世界不一样"。而发现这个差异，靠的就是系统性的验证和排查。这个能力，是AI原生流程里最稀缺、也最需要被重视的。
5.3 把验证前移：在优化循环里就嵌入物理检查
基于这些教训，我现在做AI设计流程时，会坚持一个原则：不要把物理验证放到最后，而是把它嵌入到优化循环里。
具体做法是，在AI优化的每一轮迭代中，都插入一个轻量级的物理检查。这个检查不需要像最终签核那么精确，但必须能捕捉到那些"方向性"的错误。比如：
- 检查布局的单元密度分布，有没有明显不合理的聚集。
- 检查关键路径的布线长度估算，有没有超出合理范围。
- 检查电源网络的完整性，有没有明显的压降风险。
这些检查跑起来很快，但能在早期就把那些"物理上不靠谱"的方案筛掉，避免AI在错误的方向上越走越远。这比等到最后再发现问题，效率高太多了。
注意：嵌入优化循环的物理检查，精度可以低，但覆盖面要广。宁可多报一些"疑似问题"，也不要漏掉方向性错误。因为早期筛掉的成本，远低于后期返工的成本。
6. 如果让我搭一个AI原生芯片设计团队，我会怎么配人
聊完三个不同看法，我想落到一个更实际的问题上：如果现在要组建一个真正能跑通AI原生芯片设计的团队，人应该怎么配？
我的答案可能和很多人想的不一样。我不会优先招"AI算法专家"，我会优先招"懂芯片的优化工程师"和"懂物理的验证工程师"。
原因很简单。AI算法本身，现在开源工具和框架已经非常成熟，一个合格的算法工程师很快就能上手。但懂芯片设计流程、知道每个环节的物理约束在哪里、能把工程直觉转化成优化约束的人，才是真正稀缺的。这种人往往需要多年的一线设计经验，不是短期能培养出来的。
具体来说，一个最小可用的团队应该包含这几类角色：
- 需求翻译者：负责把产品需求拆解成技术指标和优化目标。这个人通常是有架构设计背景的资深工程师。
- 优化工程师：负责设计搜索空间、定义目标函数、调优AI优化器。这个人要既懂优化理论，又懂芯片物理。
- 验证工程师：负责为AI产出兜底，设计验证方案，做对抗性测试。这个人要有丰富的签核和物理验证经验。
- 工具链工程师：负责把AI能力接进现有EDA流程，处理数据格式、接口、自动化等问题。
这四类人里，需求翻译者和验证工程师是最难招的，也是我认为最值得投入资源去培养的。AI算法专家可以外部合作，但这两种人必须自己团队里有，因为他们掌握的是"隐性知识"，很难通过文档传递。
7. 关于"AI会不会取代芯片工程师"，我的真实体会
最后说点个人感受。每次有AI设计芯片的新闻出来，总有人问"芯片工程师是不是要失业了"。我自己的体会是：AI取代的不是工程师，而是工程师工作中那些重复的、可形式化的部分。它把工程师从繁琐的调参、试错中解放出来，但同时也对工程师提出了更高的要求。
以前一个工程师可能花80%的时间在跑工具、调参数，20%的时间在思考架构和权衡。AI来了之后，那80%的时间可能被压缩到20%，但剩下的80%时间，你要用来做AI做不了的事：定义问题、翻译需求、设计验证、做工程判断。这些能力，以前可能被繁琐的日常操作掩盖了，现在会被放大。
所以我的建议是，如果你在做芯片设计，不要焦虑AI会不会取代你，而要问自己：我有没有能力去做那些AI做不了的事？如果你只会跑工具、只会按流程操作，那确实危险。但如果你能定义问题、能判断方案好坏、能为结果兜底，那AI对你来说是放大器，不是替代者。
我自己现在的工作方式已经变了很多。以前我大量时间花在手动调优上，现在我把这些交给AI，自己更多地去想"这个优化目标定得对不对""这个结果物理上靠不靠谱""验证方案有没有漏洞"。说实话，这比单纯调参有意思多了，也更有价值。
这个方向后续还有很多可以展开的地方，比如怎么把工艺知识注入到AI优化里、怎么设计人机协作的交互界面、怎么建立AI设计方案的评估标准。这些我都还在摸索，有机会再单独写。如果你也在做类似的事情，欢迎一起交流踩过的坑。
