AI-native芯片设计：真正稀缺的不是AI人才，而是这三项能力

你问我对这份研究的看法我确实有些不同意见。这不是我第一次看类似的报告了说实话这类标题很容易让人产生两个极端反应要么觉得这个词就是包装出来的新概念要么就把它捧成颠覆一切的银子弹。实际聊下来之后我更倾向于认为如果把“AI-native芯片设计”当成一个纯粹的工程技术问题来看会错过它真正重要的部分。先说我的结论这份研究真正的价值不在于它展示了多少自动化流程而在于它非常准确地定义了一种新的劳动分工——在AI成为设计流程的主要执行者之后人类工程师的核心竞争力变成了“提问题的能力和判断答案的能力”而不是亲手去敲代码、调参数。而关于“稀缺能力”外界最常讨论的是人才。大家觉得IC设计人才本来就稀缺会用AI的IC人才更缺。这当然没错但我觉得这只是表层。更深一层的问题是我们现在缺乏一整套能够让AI在芯片设计领域安全、可控、可靠地发挥作用的“基础设施”——这不是指服务器和EDA工具而是指方法论、验证体系、数据管理和组织协作流程。所以这篇文章我起了标题里那个名字。下面聊聊我具体的三点不同看法。1. 把“AI-native芯片设计”当成概念炒作会漏掉真实信号1.1 我对这个术语的理解不是“用AI辅助”而是“让AI成为主体”“AI-native”这个词天然自带争议尤其是放在芯片设计这种极其严谨、一个bug可能导致几千万美元损失的领域里。不少人看到这个词第一反应是又来了AI辅助设计就AI辅助设计搞什么“原生”。但我的理解不太一样——传统EDA工具里的AI辅助和AI-native本质上是两码事。传统路径是人类工程师定义流程每个步骤的调度、判断和决策都由人来完成AI只是某个节点上的功能模块。比如在布局布线时AI算法可以帮我预估congestion但这个预估只是给我一个参考信号怎么调整、调整到什么程度、下一步怎么走都是我来拿主意。AI-native的路径则完全反过来了**AI承担了流程的主体调度者角色它自己决定当前这一步的目标拆解是什么、该用什么策略、资源怎么分配以及什么时候需要请求人类介入。**人类不再事无巨细地参与每一步而是退居到“定义目标和审核结果”的位置上。这差别听起来只是参与方式的变化但实操中对流程的冲击非常大。传统流程中一个经验丰富的工程师能靠直觉在几十个参数里迅速锁定问题所在但在AI-native流程里人类几乎不可能实时追踪AI在做什么、为什么这样做——如果中间某个决策出了问题你只能看到最终结果得去复盘它的思路这要求你能跟AI的决策轨迹又是另一种能力。我看过研究报告里的一些初步数据在标准单元摆放和布线任务上AI原生流程在PPA性能、功耗、面积指标上能做到和人类专家相当甚至略优的水平而且缩短的是总设计周期。但这里有个需要我们警惕的点是这些结果基本都是在测试基准和限定场景下跑出来的真实项目中那种充满冲突约束、不确定性和历史包袱的场景评估结果要打折扣。这也是为什么我不赞同把这当成一种“话术升级”——它背后的工作方式确实是断层式的变化会真实影响我们未来设计芯片的方式。1.2 为什么现在这个节点适合讨论这个话题从行业节奏来看现在讨论AI-native芯片设计比五年前或三年后都更有实际意义。五年前的问题是数据和算力都没到位。制造工艺节点还在快速推进中设计本身已经非常复杂但AI能拿到的有效数据少得可怜——每家公司的设计数据都是机密就算愿意共享清洗、标注、统一的成本也高得离谱。三年后的问题变成了如果没有提前准备好方法论、验证体系和数据架构等AI能力进一步扩展时你所谓的AI-native只是让AI帮你把活干了而不是AI帮你把活干对、干好。那时候再补课就变成总结了。而现在的这个窗口期很微妙一方面AI大模型在推理、代码生成和多模态理解上的能力已经扩展到足以处理复杂设计任务了。另一方面芯片设计流程的复杂度已经超过人类能完全掌控的范围靠纯人力去优化PPA已经是极限了。EE和CS领域很多团队都在做相关研究但真正能落到大规模生产流程里的还很少。真正稀缺的东西在这个时间点恰好开始暴露出来不是工具不是算力而是“谁能定义清楚问题、谁能验证AI方案的靠谱程度、谁能在AI犯错时兜得住”。这个时间节点的讨论本质上是一场能力重构的前瞻准备。2. 第一点不同看法稀缺的不是AI人才而是“问题定义者”2.1 大家都在抢“会用AI的人”但会用AI真的代表能做好芯片吗这个话题下最常见的观点集中在人才上AI-native芯片设计需要既懂芯片又懂AI的复合型人才这种人才太稀少了。这说法没问题但我觉得有点简化和表浅了——真正稀缺的并不是“会用AI的人”而是清晰定义问题的人。说个真实场景。某团队拿到一个高性能计算模块目标是优化PPA。传统做法是物理设计工程师开始调排布、布线策略、功耗墙高频优化迭代现在换成AI-native流程的话操盘手需要做的第一件事其实不是调参而是把优化目标定义清楚。这个模块是重性能还是重功耗在什么温度范围内什么工作负载下跑哪些宏单元的位置会对关键路径产生直接影响允许AI在哪些范围内自主尝试哪些范围必须锁定不动这些问题如果定义不清楚AI无论多强最后给的方案都会是南辕北辙。另一个层面上高级工程师和初级工程师之间的差异也恰恰在于定义问题的能力——初级工程师拿到任务后第一反应是找工具run高级工程师会先问一句“我们真正要解决的到底是什么”在传统流程中这种能力只是加分项在AI-native流程里它变成决定成败的核心能力。因为当AI承担了执行层的全部重活之后人唯一没法外包出去的就是“在模糊和矛盾中找到正确问题并且表述清楚”的能力。2.2 问题定义能力包含哪些实际维度具体拆解一下这项能力在AI-native芯片设计场景里至少包含下面这几个维度。第一抽象层级的转换能力。从系统架构需求出发合理地把上层需求拆解成物理设计、验证、功耗等子领域的具体约束。这个转换过程需要对芯片设计全流程有完整的理解而不是只熟悉自己负责的那一小块。AI被训练的时候就能够跨领域泛化但如果给它设定的目标是割裂的、片面的结果就会失衡。第二约束表达和冲突消解能力。芯片设计里天然存在各种冲突约束面积和性能冲突功耗和时序冲突成本和良率冲突。人类规划师要能够把这些冲突明确地构建出来并设定好优先级。AI-native流程本质上是一个多目标优化问题——但多目标之间怎么权衡是需要人来拍板的。第三对失败模式的前瞻能力。一个经验丰富的工程师在看到电路结构或布局方案的瞬间就能大致预估出哪些位置可能出现信号完整性问题、哪些模块容易在PVT角落上请求时序违例。这种对失败模式的预判就是靠经验和直觉积累出来的“身体记忆”目前很难被AI取代——至少没有被完整取代。在AI-native流程里人反而必须更早发挥这种预判能力提前把边界条件和禁避区加入约束而不是等AI跑完一版结果再去纠偏。这些能力加在一起看起来似乎还是“资深工程师”的代名词但在AI-native的背景下它们的价值被显著放大了以前你是一个人跟工具打交道现在你是间接地通过工具跟一个能力更强但判断力更弱的“执行者”打交道——你就得把它管住、管对、管好。2.3 这种稀缺是“组织能力”而非“个人能力”还有一个容易被忽视的点问题定义很多时候不是一个人能完成的而是团队协作的结果。传统流程中系统架构师给出一份设计规格物理设计团队接到文档后自己消化理解、自己拆解。这个环节中信息流转是线性的A传给BB传给C每个人只消化自己需要的那部分就行。但是AI-native流程里AI作为一个横跨整个流程的执行实体要求所有参与者在更早的阶段就统一对问题的定义架构师指定的目标、物理设计团队设置的约束、验证团队设定的检查规则必须是同一套逻辑。这听起来像一个协作流程的问题但对组织能力提出了新要求**大家需要共同定义AI工作的边界和评价标准需要有一整套“AI工作说明书”来保证各方对目标的解读一致。**这不是某个个人能够独立完成的稀缺能力而是组织层面的一种集体能力。所以我说稀缺的不只是人才更准确地说是组织集体的问题定义能力——抢一两个懂AI的人回来是不够的团队整体的认知和工作方式都得跟着变。3. 第二点不同看法A到的绝大部分价值在“AI之外”3.1 大部分阻力根本不在模型能力而在数据基建业界谈论AI-native芯片设计时习惯把目光聚焦在模型、算法和算力上——好像只要把AI往流程里一放效率就自动上来了。但真做过相关工作的都会知道阻力最大的环节其实是数据基建。打个可能不太准确的比方AI大模型像是高性能引擎但没有合格的燃油引擎再强也只能原地打转。芯片设计流程中产生的数据质量很差分散在不同的工具链中格式五花八门。就拿一个典型的设计流程来说前端RTL代码在版本仓库里仿真结果在日志文件里综合报告在另一个目录物理设计的DRC/LVS结果又在EDA工具自己的数据库里。要把这些数据全部拉通、对齐、清洗成AI能拿来训练的格式工程量远超想象。更麻烦的是数据标注的困境。监督学习需要标签数据而芯片设计领域里的根本问题恰恰在于你很难定义什么是绝对正确的好方案。同样的模块在功耗优先和性能优先的场景下最优解可能是完全不同的两套方案。人工标注的结果掺杂了大量主观判断这些主观判断本身又依赖经验。数据质量不对AI训练出来的模型就会片面甚至有系统性偏差。所以现在做AI-native设计真正稀缺投入的不是发多少篇论文而是扎实的数据基础工程统一数据格式、建设数据治理流程、积累高质量的标注数据、设计数据版本管理方案。这些工作一点都不“性感”但都是决定AI能力上限的关键。3.2 验证和签核体系AI出题谁来批改经常被外界忽略的是验证体系如何适应AI-native流程。传统验证有一个明确逻辑人写断言、建testbench、跑覆盖率然后基于覆盖率和断言来决定是否签核。这套体系是建立在“设计是由人写的、因此会对人的失误进行针对性验证”这个前提之上的——AI生成的代码和布局错误模式不一定和人的一致。AI-native流程里验证的核心矛盾变了AI产生设计结果的速度极快但现有验证工具链却还停留在“人操作工具”的模式上。举例来说AI跑了十个小时生成了一个版本人要用三天时间去做完整验证——这个时间差让整个迭代失去意义。我们必须有能够跟上AI产生新版本的自动验证、自动签核体系否则AI加速的部分全被验证环节的瓶颈吃掉了。更重要的是验证策略本身需要变化。传统验证是针对确定性设计的AI-native流程的设计结果带一定的统计特性和不确定性验证体系需要从“证明设计正确”转向“证明设计是在一个可接受的可靠性区间内”。这要求验证工程师具备概率思维能够定义什么是可接受的错误率以及设计和验证之间的置信度指标怎么计算和校准。这项工作在目前几乎没有任何现成工具——每个团队都需要自己做研究、搭建工具链、定义验证策略。可它偏偏是决定AI-native设计能否真正量产的命脉——没有可信的验证签字生产端根本不敢流片AI生成的方案做得再漂亮也白搭。3.3 安全和可追溯性法律、审查和伦理的硬边界这是讨论中最容易被提及但实际执行起来最麻烦的部分。芯片设计本身涉及大量知识产权。当你让AI去生成、优化和组合大量已有设计时如何确保AI不会在不经意间复制了某个专利保护的结构如何确保训练数据里不会包含某个特定公司的受保护信息这些都不是纯粹技术层面的问题它们嵌入在法律、合规和商业竞争的逻辑里。更有意思的一点是可追溯性。传统设计流程中任何一处的改动都能清晰地追溯到具体的修改人、修改时间、修改原因。但如果是AI自主学习后生成的改动工程师可能根本说不清楚“为什么这里是这么做的”——因为它们是模型从千万个案例中总结出来的规律性判断无法还原成一个明确的逻辑链条。这在工程审查上是大麻烦。你拿着一个AI生成的最优结果去参加设计评审然后评审人问这个区域为什么做成这样你的回答可能是“这是AI的输出我问了它的决策逻辑它给了一个近似概率分布的解释”——这在现在的流程中根本通不过。要解决这个问题需要的是一整套“AI行为审计”基础设施能够记录AI的每一个决策路径、训练数据来源、版本迭代历史必要时还能给出一份“AI决策解释报告”。这个体系目前几乎不存在谁先把它做出来谁就真的能拿到AI-native设计的入场券。所以我一直认为的结论是阻碍AI-native芯片设计的不是AI本身不够强而是AI外面的那些基础设施没有跟上。模型越强这种基础设施的缺口就越明显最后就会成为卡点。4. 第三点不同看法AI-native芯片设计的最大变量不在工程而在组织4.1 组织流程不改变AI落地就是“锦上添花”说一个很多文章不会直接讲的点AI-native芯片设计对组织的冲击可能比对技术的冲击更大。芯片设计公司的组织架构基本是围绕传统设计流程定型的架构组把规格定下来前端设计组写RTL验证组开发测试平台后端团队做综合和物理设计然后是一个严格的审查和签核流程。每个组有自己的KPI每个组有自己的工具和流程组和组之间通过文档交接。现在把AI-native流程推进去会发生什么AI横跨了所有环节——它可以同时参与架构探索、RTL生成、验证优化和物理设计微调。但组织的部门墙还在每个部门习惯性地认为“AI辅助我可以但流程还得照着现有体系走”。AI没办法在整个流程里贯穿起来只能变成一个又一个环节里孤立存在的效率工具。你没有改组织协作流程AI就只能帮你节省每个环节里的30%人力而不是把整个流程缩短50%以上。真正要让AI-native落地不是买几个AI工具就完事了而是要重新设计协同研发流程——定义好AI在流程中的切入点和退出点、审计节点和人工介入节点明确跨部门协作时AI的输出怎样被对接和验收。这种变革比引入任何单一工具都难因为它动的是现有团队的协作方式、决策权和问责关系。阻力来自组织惯性看不见、摸不着但实际影响力比技术挑战更大。4.2 组织信任问题工程师敢不敢用AI的结果另一个被长期忽视的点是设计团队对AI给出的方案有多信任在传统流程里工程师是决策的最终负责人。负责某个模块的工程师对它的设计负全责也拥有最终决定权。但AI-native流程里AI给了方案工程师只是负责审核和批准。这里有一个微妙的博弈如果AI的方案通过了功劳算谁的如果AI的方案出了问题责任算谁的实际上很多团队之所以对AI持观望态度不是因为AI效果不够好而是责任边界不清楚。尤其芯片设计这种高风险领域流片失败一次的成本可能是几千万美元。在责任归属还没理清之前任何一个理性的工程师都不敢拍板说“这个AI方案可以上”的。所以让AI真正落地光解决技术问题不够还必须制定一套清晰的问责制度AI生成方案、人类审批通过最后出了问题审批人需要承担什么责任AI方案的贡献度怎么在组织里被公平评价这个制度设计不出来AI-native就永远停留在实验室和小范围试点阶段。4.3 变革管理从“人人会用AI”到“人人都能掌控AI”最后想说的一点关于团队技能转型的问题。“HBM技能培训”听起来像个标准的培训计划但实际落地时比预想的要艰难得多。芯片设计团队的成员背景差异很大有人做了二十年物理设计有人是刚毕业的机器学习博士。他们面对AI-native工作方式时的接受度和学习速度会非常不同。资深工程师的经验恰恰是他们在AI时代最大的包袱——他们已经习惯了靠自己的判断去做很多事情要让他们接受一个AI对他们的专业领域给出建议甚至在某些场景下让AI直接给出方案他们会经历一个比较漫长的信任重建过程。反过来年轻工程师接受AI很快但缺乏资深工程师那种对设计全流程的直觉和判断力。两条路径最终需要的都是同一种能力——理解和掌控AI的能力而这种能力的建成远不是看几份文档、参加几次培训就能完成的。团队里可以设立一个结构化的过渡机制初期让AI扮演“超级EDA工具”的角色帮助工程师把重复性工作交给AI处理但关键决策仍由工程师拍板中期让AI在限定领域内自主解空间但工程师保留否决权后期再逐步扩大到AI自主方案工程师审核的模式。在这个过程中工程师不仅学到了AI的使用方式更重要的是逐渐理解AI的判断逻辑、行为边界和失败模式——这才是真正意义上的“复合型人才”。任何跳过这个节奏的转型表面上速度很快但底层信任和掌控力是空的。5. 当我们在讨论“稀缺能力”时到底在讨论什么5.1 三者缺位的现实才是行业真正的瓶颈回到文章标题的问题AI-native芯片设计真正稀缺的能力是什么我倾向于认为它不是某个单一能力而是一套组合第一层是定义问题的能力——把模糊的产品需求拆解成准确、清晰、可验证的设计约束。第二层是建设AI外基础设施的能力——数据、验证、可追溯性、审计。第三层是组织变革的能力——跨部门协同、问责制度、信任构建和技能转型。这三层能力少了任何一层AI-native芯片设计都只能停留在“演示很漂亮落地很困难”的水平上。而目前的行业现状恰恰是这三层能力都处于严重缺位的状态大家谈AI都头头是道但你去问数据基础设施很可能还在用最原始的文件管理你去问验证流程依然是把AI生成的结果丢给人类验证团队去跑你去问组织协同部门和部门之间的墙甚至比五年前更坚固了。这才是行业的真实瓶颈。5.2 给正在起步的团队的三点建议如果团队正准备尝试AI-native芯片设计我会建议按这个顺序排优先级第一先把数据基础打牢。不管你有没有想清楚AI怎么接入流程设计数据的一致性、可检索性和版本追溯能力一定是未来所有工作的基础。这一步做得越早后面的AI尝试就越顺。它不性感的也要花很多时间但值得。当初我们自己梳理数据架构时也低估了这个环节的工程量乃至花了很长时间。第二找一个小而明确的场景做试点。不要一上来就搞全流程AI-native。找一个模块级的、有明确评价标准的优化任务让AI负责任务的执行团队的目标清晰AI跑出来的结果可以由现有的验证体系迅速判断好坏。在这个小试点的过程中团队会积累起关于AI行为特征的第一手经验也会发现自己团队在数据、验证和组织协同上到底缺什么。这些经验是看多少报告都得不到的。第三从现在就设计组织转型路径。不用一步到位但可以从设立“AI协调人”的角色开始——这个人既懂芯片设计流程又懂AI的能力边界负责在工程师和AI之间做翻译和仲裁。他在初期可以协助团队定义问题规划AI任务的边界后期逐步承接组织层面的AI导入和流程治理。这样一个小角色的设置重复性劳动地帮团队少走很多弯路。说到底AI-native芯片设计这件事最终检验的不是谁会写prompt、谁会调模型而是谁能够定义清楚正确的设计问题、搭建起可靠的AI外部环境、并带领整个团队长期稳定地跟AI协作。这三件事都到位以后AI才真的从“演示品”变成“生产力”。我也说不好未来三到五年这个领域会变成什么样子但有一点是确定的在这个窗口期里愿意把那些“不够性感”但至关重要的能力补齐的团队会在下一波真正拉开差距。这比对比参数和指标有意思多了。