最近某头部互联网平台在内部技术复盘里抛出一个判断直接把“AI-native 芯片设计”这个词顶到了热搜位置。大意是与其争论能不能用大模型自动画版图、能不能让 AI 写 RTL不如先想清楚一个更底层的问题——在这轮所谓“AI-native”的设计范式里真正稀缺的能力到底是什么我看了一圈讨论多数回答还是停留在“缺算力”“缺懂芯片的工程师”“缺高质量标注数据”这三个老方向上。但结合我自己在 AI 加速器、软硬件协同设计、以及芯片后端物理实现的多年实操经验我觉得这个答案被很多团队低估了。今天我把自己的三点不同看法摊开来讲顺便把整个事情的来龙去脉、以及我们踩过的一些坑一并说清楚。1. 先对齐AI-native 芯片设计到底在说什么1.1 两条容易被混淆的技术线先说个前提不然下面所有争论都会失焦。所谓“AI-native 芯片设计”至少有两层完全不同的意思。第一层叫“AI 辅助芯片设计”指的是把机器学习引入传统 EDA 流程。典型场景包括用图神经网络做布线拥塞预测、用强化学习做宏单元布局、用大模型自动生成验证用例。这一层的核心目标是让现有芯片设计流程“更快、更省人力”本质上是工具的升级。第二层叫“为 AI 而生的芯片设计”指的是把 AI 工作负载作为第一公民来设计专用加速器。比如某平台的推荐推理芯片、各类大模型训练卡里的脉冲阵列、数据流架构、低精度算子单元等等。这一层的核心目标是让硬件架构贴合算法让每一个算子在硬件上都有明确的映射。而最近这波讨论里的“AI-native”其实强调的是第三层把上面两层彻底打通让 AI 工作负载在架构定义、微架构选型、物理实现、编译适配等所有阶段都能被原生地考虑进去而不是先设计完芯片再赶紧写编译器去“适配”。1.2 为什么单点工具升级解决不了全局问题如果只是让 AI 替人做个别环节的自动优化那 AI-native 这个词汇就没什么存在感。它之所以能成为热点话题是因为越来越多团队意识到单点上的 AI 化并没有带来端到端的颠覆性收益。举个我在实践里反复看到的例子。某团队前期上了很先进的 AI 布局工具在物理实现环节省了不少时间。但到了系统联调因为架构定义阶段没考虑清楚内存带宽的约束整个加速器在跑真实工作负载时只能达到理论峰值的六成左右。后端省下的时间在系统级性能验证环节成倍赔了回去。这就是我在实践里最信奉的一句话芯片设计的瓶颈从来不是某一个工具跑得快不快而是整个工作负载映射链条上有没有人被漏掉。链条上的谁在“定义正确的问题”谁才真正握着稀缺的能力。2. 常规答案为什么不够三个被高估的资源2.1 “算力不够”其实可以被钱买到每次聊到 AI 芯片第一个冒出来的答案就是“GPU 不够用”。头部企业砸钱买卡云厂商大规模扩容开源社区里各种分布式训练框架迭出——这些都是资源投入型问题。资源投入型问题有信心被解决因为它们有着清晰的边界买更多机器、租更多集群、提升利用率。只要预算到位算力的总量是可堆积的。可“定义需求”这件事不是能靠堆算力解决的。2.2 “工程师不够”也不是最深的红线芯片设计人才确实稀缺一个合格的物理设计工程师培养周期往往要三五年以上学校相关的头部实验室每年输出的人数有限。但过去几年行业里“招不够人”的情况早已出现各家也用了很多办法去缓解流程标准化、智能工具降门槛、把知识固化成内部库。这些举措能稀释对熟练度的依赖却没法真正替代一类经验——就是那种“在模糊需求下依旧能判断什么方案对、什么方案错”的判断力。这种判断力无法编码进脚本也很难用一套标准流程去固化。2.3 “数据不够”确实存在但数据短缺只是表象很多人说“AI-native 设计需要海量芯片设计数据而芯片公司的高质量数据太少了”。这句话对。但再往下一层看数据不够往往反映的是“我们还没有建立一个稳定的组织机制让跨团队的问题定义口径保持一致”。数据不是天上掉下来的而是协同过程中沉淀的。当你说“缺数据”的时候通常更准确的说法是“我们根本没想清楚该记录什么、该对齐什么”。一旦这个问题搞清楚数据的采集、清洗、标注才有章法。所以数据不足是显性问题隐藏在其背后的定义组织能力才是真正的稀缺点。3. 观点一真正稀缺的是“把模糊需求变成可设计规格”的能力3.1 需求不清晰才是返工的万恶之源我在多个跨平台项目里见过同一个现象项目启动时大家都很兴奋算法团队给出一个大概的“性能目标”架构团队画了几页 PPTRTL 团队在一个月内就把核心模块搭出来了所有人觉得进度喜人。然后第一个里程碑一联调发现算法团队说的“线上真实延迟”和架构团队计划里的“典型负载模型”根本不是一回事。返工的时间往往是启动阶段的数倍。芯片设计跟纯软件最大的不同在于软件你可以在上线前打补丁但芯片一旦流片回来很多架构层面的错误是无法通过软件修复的。所以在最早期就把需求从“大概方向”拆成“可计算的规格”是整个链条里回报最高的一件事。3.2 可设计规格具体长什么样我在实际操作里习惯用“三层澄清法”来保证需求落到芯片设计层面不再模糊。第一层是产品层。要解决的问题是什么是大规模推荐场景里的在线推理延迟还是大模型训练里的吞吐量这个目标必须用业务语言说清楚不能用一套浮空的指标带过。第二层是算法层。模型结构、算子分布、数据模式分别是什么每个算子的计算量是多少激活值大小是多少权重参数规模是什么量级只有把这几项变成可估算的公式架构团队才能动手。第三层是硬件约束层。在这个算力和功耗预算下存储带宽能不能跟得上互联带宽会不会成为瓶颈把这三个层次放在一起才能真正写出一页纸的“可设计规格”。3.3 为什么这项能力反而稀缺很多团队低估了“写清规格”的难度。不是大家不会写文档而是写出一份“所有下游环节都能照着执行、并且能在早期就暴露矛盾”的规格需要同时具备软件算法视野和硬件物理直觉。会写 RTL 的人往往对算法级算子分布不敏感懂算法的人又常常不知道“片上总线带宽每提升一档功耗和面积要付出多大代价”。这两类人才本来就不多能坐到同一张桌前把需求当场碰撞成可执行方案的更是凤毛麟角。而且最讽刺的是这种能力在绩效考核里最难量化。你没法把“减少返工”直接算到某个人头上也没法给一份规格文档打一个客观分数。于是组织里资源往往都倾向那些立刻动手写字的环节忽略了对齐需求这一最前期的关键动作。4. 观点二真正稀缺的是跨层协同设计经验而不是单点工具熟练度4.1 单点熟练不等于全局高效这一两年来各类 AI 代码生成工具确实让验证环境搭建、寄存器模型生成的效率提升不少。很多团队开始猛冲“单点工具使用率”仿佛每多生成一份代码就是在拥抱 AI-native。但芯片设计最核心的特征是全局联动。你改了算法里的算子融合方式编译器要跟着变编译器变了指令调度要变指令调度变了微架构里的流水线深度要变微架构一变物理设计阶段的时钟频率和功耗又受牵连。这个链条环环相扣只要有一层没接住到最后都是性能损失。真正值钱的人是能在这些层级之间来回穿梭、一眼看出“这里改了之后下一个瓶颈会出现在哪里”的人。这类经验无法靠读文档获得必须在真实的横向项目里反复磨。4.2 一个让我印象深刻的横向踩坑案例某次优化一个图像预处理相关的专用加速器模块算法团队提出“把片上缓存扩大一倍可以明显提升数据复用率”。他们说得没错但只考察了缓存局部效果。跨到系统层一看就发现片外 DRAM 带宽本来就只能支持当前吞吐的七成。缓存翻倍之后本地命中率确实高了可数据从 DRAM 搬进来的总时间开销没有改善最终系统吞吐依然卡在带宽上。于是整个小组围绕着“要不要做缓存翻倍”开了好几轮会最后在系统层精确定位到带宽瓶颈把缓存面积预算拿去优化了数据预取逻辑性能才真正提升。这个案例的教训特别简单如果你只在某一层做局部优化流程越顺畅反而越容易让你产生一种“事情在变好”的错觉。算法、编译器、微架构、物理实现这几套思维方式必须在一个真实项目中碰撞过才能互相理解对方的语言。4.3 怎么建这种跨层能力我自己带团队时一直主张让每位工程师定期轮岗做“横向小项目”。比如原本写 RTL 的人要求在六周内配合编译器团队完成一个算子融合的小原型原本做训练框架的人要求到物理设计组待两周理解时钟树综合和拥塞控制的痛点。这种轮岗不一定能立刻产出业务价值但它能让人在内心深处建立一张“全局地图”。有了这张地图后面做任何决策时大家会自然去追问“这个改动会影响哪一层”。团队里愿意这么问的人越多跨层协同出错的概率就越小。这正是我认为 AI-native 设计的真正转折点不是某个 AI 工具让你手里的活儿更省力而是整套流程里能站出来说“这个方案在另一层会引发问题”的人越来越多。5. 观点三真正稀缺的是验证与保证能力而不是生成效率5.1 AI 带来的“高置信幻觉”最危险大模型在辅助生成代码、文档甚至测试激励时确实能大幅提升效率。但芯片有个硬性要求你必须能证明设计是正确的而不是“看起来大概率正确”。真实工作中我见过不少团队在引入 AI 辅助验证用例生成后回归测试的覆盖率数字变得很漂亮。但只要你往深一层去抽查就会发现相当一部分激励用例根本没有约束到关键数据通路或者断言写得模棱两可。它们的数量上来了却没有给最终交付增加真正的可信度。这就是所谓的“高置信幻觉”所有人都以为验证做得更充分了实际上只是在用更大的规模掩盖更深的不确定性。芯片设计的容错空间本来就很窄一个未被覆盖的状态可能直接导致流片后行为异常。到那时候问题已经不在“勤劳”的范畴而是在“可信”的范畴里彻底失败了。5.2 验证的核心不是跑更多用例而是问“什么情况下你敢签这个字”衡量验证能力不应该只看跑测试的机时而应该看团队能不能回答这三个问题第一个问题关键风险点是否被识别并被充分覆盖对算力单元、数据通路、存储一致性这些高风险模块有没有专门的故障注入和边界测试。第二个问题断言和参考模型是否具备独立维护基础如果生成断言的逻辑本身和被验证的设计来自同一个草率流程那两者同时出错时你根本发现不了。第三个问题从模块级到系统级的回归信号是否串联模块验证单独通过不等于拼起来后跨模块的时序、握手行为都正确。这个在芯片领域特别常见。只有能回答好这三个问题团队才算拥有真正的验证与保证能力。AI 生成的用例数量和速度都不缺缺的永远是那个“敢在签字栏写上自己名字、并且清楚每一行用例背后在验证什么风险”的人。5.3 可证明性比生成性更稀缺有人可能觉得AI-native 代表着我们能用更少的人、跑更短的时间来完成验证。大方向没有错但真实情况往往会反着走AI 生成的代码、用例越多你反而需要更多的时间去审查它、推理它、确认它。原因很简单。芯片设计失败的代价太高了尤其是在先进工艺节点上一次流片费用、几个月周期、多部门协同的时间成本全都压在一次“能不能证明它正确”上。在这种约束下任何未经验证资格的“生成物”都只能算作“待确认的草稿”。这让我对 AI-native 有一个清醒判断它更像一个放大器。它放大了我们定义需求的速度、产生代码的速度、生成测试的速度但同时也放大了错误被掩盖的速度。一个团队真正稀缺的是能在放大镜底下依旧保持冷静、不放过任何一个未证明环节的能力。6. 实操起步清单团队到底怎么培养这些稀缺能力6.1 用一次“规格澄清周”代替动辄开干的惯性如果团队现在还在靠 PPT 起步我建议立刻尝试“规格澄清周”这个动作。拉上产品、算法、架构、验证、后端各派一到两名骨干用一周时间集中回答一个问题这个项目最终要交付的可验证规格是什么。每天只做一件小事早上集体再过一遍上一版规格的“矛盾清单”下午各子团队带着自己负责的指标来横向对齐。一周结束必须产出一份一页纸的可设计规格并让各团队的负责人当场签字。签字的含义是我承认这份规格定义了我要交付的目标如果后续发现规格本身有缺陷我必须在这个周例会上第一时间提出修改而不是等到自己做的模块失败再惊呼。这套玩法最大的价值是把“隐性的相互误解”提前变成“显性的冲突”。冲突并不可怕早冲突比晚返工强。6.2 搭一条能跑通的最小横向原型链路不要等到正式工程启动才开始跨层协同。我推荐的做法是选一个尽可能小但覆盖完整链条的原型项目从某个开源模型的一小段算子到编译器映射再到 FPGA 原型上跑通最后记录延迟、吞吐和资源占用。整个周期控制在六到八周不要给它过高的业务预期就当作一次团队内部的“装备演练”。参与的人会在这个过程中经历算法变形、算子融合、调度策略、硬件资源约束之间的一系列拉扯。这些拉扯就是建立跨层经验的最快路径比任何跨部门培训都有效。6.3 建立“风险登记-验证闭环”的日常工作方式验证能力不是靠某个季度突击就能有的它需要组织形成一种持久的工作习惯。我会建议每个项目专门维护一份风险登记清单不只记录已经发生的 Bug更要记录“什么地方还没被有效覆盖”。每两周进行一次验证抽检重点看的不是用例数量而是这些用例背后对应的风险点是否发生变化。当完成一次验证回归时团队负责人必须回答一个面子问题根据现阶段的风险覆盖情况你有多大置信度在某个日期前签下质量确认这个数字不需要百分之百准确但它必须是有依据的估计而不是拍脑袋的承诺。一旦风险登记和验证覆盖对齐了你就能把“感觉上很稳”和“数据上很稳”这两件事区分开来。AI-native 流程再高效如果没有一个诚实、可审计的风险感知体系最终交付物只能是空中楼阁。7. 常见问题速查与避坑实录我把自己这些年实操里最常被问到的几个问题整理成一个速查表方便大家回去对照。常见疑惑我的实测结论关键避坑点用了 AI 布局布线工具就算实现 AI-native 设计了不算。它只是后端环节的辅助手段后端做完了前端的规格矛盾一样会流片后爆发节省的时间会在联调里赔掉需要一上来就把规格写得很厚很完整吗不需要但要写清楚关键的量化指标和取舍边界“算力”“功耗”这类大词没有意义要用乘累加次数、内存带宽、目标面积的具体范围来定义验证很慢Leader 又催着上流片怎么办把未覆盖的风险登记出来让决定变成显性决策口头承诺“应该没问题”是最大的隐患一定要用风险清单和置信度数字来沟通团队没做过芯片能不能做这类项目可以做但建议先用 FPGA 原型拉通整个软硬件链条FPGA 原型和 ASIC 在时序、功耗上差别很大但它是培养跨层直觉的最佳低成本方案AI 生成的代码可以直接信任吗绝不能直接信任要当成“又一个实习生写的初稿”来审查生成代码和设计规格共用同一个错误源头时最危险必须做独立的断言检查和覆盖回溯7.1 一个小而有效的组织习惯决策日志除了上面的速查表我还想单独分享一个配合方法论落地的小工具叫“决策日志”。这不是什么新概念就是在每次关键项目决策之后由决策者写几行文字记录三件事当时面对什么关键矛盾、为什么选择这个方案、我们在哪个不确定性前做了权衡。坚持记录三四个项目之后你会发现它的价值远超预期。一方面它能帮你复盘以前的决策是否经得起时间的考验另一方面它会在团队内部形成一种约定俗成的习惯没有人可以只凭“我觉得”来做一个重大技术决策他需要留下一份可以被追问的记录。今天再看 AI-native 芯片设计我最大的感受是它的起点未必是更聪明的工具而是一群人愿意在早期投入时间去理顺需求、打通跨层协同、并且诚实地记录验证风险。我在实际操作中最大的体会就是——一旦这些被忽略的“软能力”补齐了AI 工具无论多初级你都能把它放到正确的位置上发光反之即使拥有最前沿的模型和最强的算力最终也很可能在流片前的最后一公里翻车。最后再分享一个小技巧无论你的岗位是算法、架构、验证还是后端每个季度请强制自己只读一份其他方向的技术手册并做成笔记。坚持一个季度后你就会发现自己再和别人开需求对齐会时已经能听懂对方真正的痛点了。这个习惯是我见过的培养稀缺能力最便宜、也最容易被忽视的杠杆。
最近某头部互联网平台在内部技术复盘里抛出一个判断直接把“AI-native 芯片设计”这个词顶到了热搜位置。大意是与其争论能不能用大模型自动画版图、能不能让 AI 写 RTL不如先想清楚一个更底层的问题——在这轮所谓“AI-native”的设计范式里真正稀缺的能力到底是什么我看了一圈讨论多数回答还是停留在“缺算力”“缺懂芯片的工程师”“缺高质量标注数据”这三个老方向上。但结合我自己在 AI 加速器、软硬件协同设计、以及芯片后端物理实现的多年实操经验我觉得这个答案被很多团队低估了。今天我把自己的三点不同看法摊开来讲顺便把整个事情的来龙去脉、以及我们踩过的一些坑一并说清楚。1. 先对齐AI-native 芯片设计到底在说什么1.1 两条容易被混淆的技术线先说个前提不然下面所有争论都会失焦。所谓“AI-native 芯片设计”至少有两层完全不同的意思。第一层叫“AI 辅助芯片设计”指的是把机器学习引入传统 EDA 流程。典型场景包括用图神经网络做布线拥塞预测、用强化学习做宏单元布局、用大模型自动生成验证用例。这一层的核心目标是让现有芯片设计流程“更快、更省人力”本质上是工具的升级。第二层叫“为 AI 而生的芯片设计”指的是把 AI 工作负载作为第一公民来设计专用加速器。比如某平台的推荐推理芯片、各类大模型训练卡里的脉冲阵列、数据流架构、低精度算子单元等等。这一层的核心目标是让硬件架构贴合算法让每一个算子在硬件上都有明确的映射。而最近这波讨论里的“AI-native”其实强调的是第三层把上面两层彻底打通让 AI 工作负载在架构定义、微架构选型、物理实现、编译适配等所有阶段都能被原生地考虑进去而不是先设计完芯片再赶紧写编译器去“适配”。1.2 为什么单点工具升级解决不了全局问题如果只是让 AI 替人做个别环节的自动优化那 AI-native 这个词汇就没什么存在感。它之所以能成为热点话题是因为越来越多团队意识到单点上的 AI 化并没有带来端到端的颠覆性收益。举个我在实践里反复看到的例子。某团队前期上了很先进的 AI 布局工具在物理实现环节省了不少时间。但到了系统联调因为架构定义阶段没考虑清楚内存带宽的约束整个加速器在跑真实工作负载时只能达到理论峰值的六成左右。后端省下的时间在系统级性能验证环节成倍赔了回去。这就是我在实践里最信奉的一句话芯片设计的瓶颈从来不是某一个工具跑得快不快而是整个工作负载映射链条上有没有人被漏掉。链条上的谁在“定义正确的问题”谁才真正握着稀缺的能力。2. 常规答案为什么不够三个被高估的资源2.1 “算力不够”其实可以被钱买到每次聊到 AI 芯片第一个冒出来的答案就是“GPU 不够用”。头部企业砸钱买卡云厂商大规模扩容开源社区里各种分布式训练框架迭出——这些都是资源投入型问题。资源投入型问题有信心被解决因为它们有着清晰的边界买更多机器、租更多集群、提升利用率。只要预算到位算力的总量是可堆积的。可“定义需求”这件事不是能靠堆算力解决的。2.2 “工程师不够”也不是最深的红线芯片设计人才确实稀缺一个合格的物理设计工程师培养周期往往要三五年以上学校相关的头部实验室每年输出的人数有限。但过去几年行业里“招不够人”的情况早已出现各家也用了很多办法去缓解流程标准化、智能工具降门槛、把知识固化成内部库。这些举措能稀释对熟练度的依赖却没法真正替代一类经验——就是那种“在模糊需求下依旧能判断什么方案对、什么方案错”的判断力。这种判断力无法编码进脚本也很难用一套标准流程去固化。2.3 “数据不够”确实存在但数据短缺只是表象很多人说“AI-native 设计需要海量芯片设计数据而芯片公司的高质量数据太少了”。这句话对。但再往下一层看数据不够往往反映的是“我们还没有建立一个稳定的组织机制让跨团队的问题定义口径保持一致”。数据不是天上掉下来的而是协同过程中沉淀的。当你说“缺数据”的时候通常更准确的说法是“我们根本没想清楚该记录什么、该对齐什么”。一旦这个问题搞清楚数据的采集、清洗、标注才有章法。所以数据不足是显性问题隐藏在其背后的定义组织能力才是真正的稀缺点。3. 观点一真正稀缺的是“把模糊需求变成可设计规格”的能力3.1 需求不清晰才是返工的万恶之源我在多个跨平台项目里见过同一个现象项目启动时大家都很兴奋算法团队给出一个大概的“性能目标”架构团队画了几页 PPTRTL 团队在一个月内就把核心模块搭出来了所有人觉得进度喜人。然后第一个里程碑一联调发现算法团队说的“线上真实延迟”和架构团队计划里的“典型负载模型”根本不是一回事。返工的时间往往是启动阶段的数倍。芯片设计跟纯软件最大的不同在于软件你可以在上线前打补丁但芯片一旦流片回来很多架构层面的错误是无法通过软件修复的。所以在最早期就把需求从“大概方向”拆成“可计算的规格”是整个链条里回报最高的一件事。3.2 可设计规格具体长什么样我在实际操作里习惯用“三层澄清法”来保证需求落到芯片设计层面不再模糊。第一层是产品层。要解决的问题是什么是大规模推荐场景里的在线推理延迟还是大模型训练里的吞吐量这个目标必须用业务语言说清楚不能用一套浮空的指标带过。第二层是算法层。模型结构、算子分布、数据模式分别是什么每个算子的计算量是多少激活值大小是多少权重参数规模是什么量级只有把这几项变成可估算的公式架构团队才能动手。第三层是硬件约束层。在这个算力和功耗预算下存储带宽能不能跟得上互联带宽会不会成为瓶颈把这三个层次放在一起才能真正写出一页纸的“可设计规格”。3.3 为什么这项能力反而稀缺很多团队低估了“写清规格”的难度。不是大家不会写文档而是写出一份“所有下游环节都能照着执行、并且能在早期就暴露矛盾”的规格需要同时具备软件算法视野和硬件物理直觉。会写 RTL 的人往往对算法级算子分布不敏感懂算法的人又常常不知道“片上总线带宽每提升一档功耗和面积要付出多大代价”。这两类人才本来就不多能坐到同一张桌前把需求当场碰撞成可执行方案的更是凤毛麟角。而且最讽刺的是这种能力在绩效考核里最难量化。你没法把“减少返工”直接算到某个人头上也没法给一份规格文档打一个客观分数。于是组织里资源往往都倾向那些立刻动手写字的环节忽略了对齐需求这一最前期的关键动作。4. 观点二真正稀缺的是跨层协同设计经验而不是单点工具熟练度4.1 单点熟练不等于全局高效这一两年来各类 AI 代码生成工具确实让验证环境搭建、寄存器模型生成的效率提升不少。很多团队开始猛冲“单点工具使用率”仿佛每多生成一份代码就是在拥抱 AI-native。但芯片设计最核心的特征是全局联动。你改了算法里的算子融合方式编译器要跟着变编译器变了指令调度要变指令调度变了微架构里的流水线深度要变微架构一变物理设计阶段的时钟频率和功耗又受牵连。这个链条环环相扣只要有一层没接住到最后都是性能损失。真正值钱的人是能在这些层级之间来回穿梭、一眼看出“这里改了之后下一个瓶颈会出现在哪里”的人。这类经验无法靠读文档获得必须在真实的横向项目里反复磨。4.2 一个让我印象深刻的横向踩坑案例某次优化一个图像预处理相关的专用加速器模块算法团队提出“把片上缓存扩大一倍可以明显提升数据复用率”。他们说得没错但只考察了缓存局部效果。跨到系统层一看就发现片外 DRAM 带宽本来就只能支持当前吞吐的七成。缓存翻倍之后本地命中率确实高了可数据从 DRAM 搬进来的总时间开销没有改善最终系统吞吐依然卡在带宽上。于是整个小组围绕着“要不要做缓存翻倍”开了好几轮会最后在系统层精确定位到带宽瓶颈把缓存面积预算拿去优化了数据预取逻辑性能才真正提升。这个案例的教训特别简单如果你只在某一层做局部优化流程越顺畅反而越容易让你产生一种“事情在变好”的错觉。算法、编译器、微架构、物理实现这几套思维方式必须在一个真实项目中碰撞过才能互相理解对方的语言。4.3 怎么建这种跨层能力我自己带团队时一直主张让每位工程师定期轮岗做“横向小项目”。比如原本写 RTL 的人要求在六周内配合编译器团队完成一个算子融合的小原型原本做训练框架的人要求到物理设计组待两周理解时钟树综合和拥塞控制的痛点。这种轮岗不一定能立刻产出业务价值但它能让人在内心深处建立一张“全局地图”。有了这张地图后面做任何决策时大家会自然去追问“这个改动会影响哪一层”。团队里愿意这么问的人越多跨层协同出错的概率就越小。这正是我认为 AI-native 设计的真正转折点不是某个 AI 工具让你手里的活儿更省力而是整套流程里能站出来说“这个方案在另一层会引发问题”的人越来越多。5. 观点三真正稀缺的是验证与保证能力而不是生成效率5.1 AI 带来的“高置信幻觉”最危险大模型在辅助生成代码、文档甚至测试激励时确实能大幅提升效率。但芯片有个硬性要求你必须能证明设计是正确的而不是“看起来大概率正确”。真实工作中我见过不少团队在引入 AI 辅助验证用例生成后回归测试的覆盖率数字变得很漂亮。但只要你往深一层去抽查就会发现相当一部分激励用例根本没有约束到关键数据通路或者断言写得模棱两可。它们的数量上来了却没有给最终交付增加真正的可信度。这就是所谓的“高置信幻觉”所有人都以为验证做得更充分了实际上只是在用更大的规模掩盖更深的不确定性。芯片设计的容错空间本来就很窄一个未被覆盖的状态可能直接导致流片后行为异常。到那时候问题已经不在“勤劳”的范畴而是在“可信”的范畴里彻底失败了。5.2 验证的核心不是跑更多用例而是问“什么情况下你敢签这个字”衡量验证能力不应该只看跑测试的机时而应该看团队能不能回答这三个问题第一个问题关键风险点是否被识别并被充分覆盖对算力单元、数据通路、存储一致性这些高风险模块有没有专门的故障注入和边界测试。第二个问题断言和参考模型是否具备独立维护基础如果生成断言的逻辑本身和被验证的设计来自同一个草率流程那两者同时出错时你根本发现不了。第三个问题从模块级到系统级的回归信号是否串联模块验证单独通过不等于拼起来后跨模块的时序、握手行为都正确。这个在芯片领域特别常见。只有能回答好这三个问题团队才算拥有真正的验证与保证能力。AI 生成的用例数量和速度都不缺缺的永远是那个“敢在签字栏写上自己名字、并且清楚每一行用例背后在验证什么风险”的人。5.3 可证明性比生成性更稀缺有人可能觉得AI-native 代表着我们能用更少的人、跑更短的时间来完成验证。大方向没有错但真实情况往往会反着走AI 生成的代码、用例越多你反而需要更多的时间去审查它、推理它、确认它。原因很简单。芯片设计失败的代价太高了尤其是在先进工艺节点上一次流片费用、几个月周期、多部门协同的时间成本全都压在一次“能不能证明它正确”上。在这种约束下任何未经验证资格的“生成物”都只能算作“待确认的草稿”。这让我对 AI-native 有一个清醒判断它更像一个放大器。它放大了我们定义需求的速度、产生代码的速度、生成测试的速度但同时也放大了错误被掩盖的速度。一个团队真正稀缺的是能在放大镜底下依旧保持冷静、不放过任何一个未证明环节的能力。6. 实操起步清单团队到底怎么培养这些稀缺能力6.1 用一次“规格澄清周”代替动辄开干的惯性如果团队现在还在靠 PPT 起步我建议立刻尝试“规格澄清周”这个动作。拉上产品、算法、架构、验证、后端各派一到两名骨干用一周时间集中回答一个问题这个项目最终要交付的可验证规格是什么。每天只做一件小事早上集体再过一遍上一版规格的“矛盾清单”下午各子团队带着自己负责的指标来横向对齐。一周结束必须产出一份一页纸的可设计规格并让各团队的负责人当场签字。签字的含义是我承认这份规格定义了我要交付的目标如果后续发现规格本身有缺陷我必须在这个周例会上第一时间提出修改而不是等到自己做的模块失败再惊呼。这套玩法最大的价值是把“隐性的相互误解”提前变成“显性的冲突”。冲突并不可怕早冲突比晚返工强。6.2 搭一条能跑通的最小横向原型链路不要等到正式工程启动才开始跨层协同。我推荐的做法是选一个尽可能小但覆盖完整链条的原型项目从某个开源模型的一小段算子到编译器映射再到 FPGA 原型上跑通最后记录延迟、吞吐和资源占用。整个周期控制在六到八周不要给它过高的业务预期就当作一次团队内部的“装备演练”。参与的人会在这个过程中经历算法变形、算子融合、调度策略、硬件资源约束之间的一系列拉扯。这些拉扯就是建立跨层经验的最快路径比任何跨部门培训都有效。6.3 建立“风险登记-验证闭环”的日常工作方式验证能力不是靠某个季度突击就能有的它需要组织形成一种持久的工作习惯。我会建议每个项目专门维护一份风险登记清单不只记录已经发生的 Bug更要记录“什么地方还没被有效覆盖”。每两周进行一次验证抽检重点看的不是用例数量而是这些用例背后对应的风险点是否发生变化。当完成一次验证回归时团队负责人必须回答一个面子问题根据现阶段的风险覆盖情况你有多大置信度在某个日期前签下质量确认这个数字不需要百分之百准确但它必须是有依据的估计而不是拍脑袋的承诺。一旦风险登记和验证覆盖对齐了你就能把“感觉上很稳”和“数据上很稳”这两件事区分开来。AI-native 流程再高效如果没有一个诚实、可审计的风险感知体系最终交付物只能是空中楼阁。7. 常见问题速查与避坑实录我把自己这些年实操里最常被问到的几个问题整理成一个速查表方便大家回去对照。常见疑惑我的实测结论关键避坑点用了 AI 布局布线工具就算实现 AI-native 设计了不算。它只是后端环节的辅助手段后端做完了前端的规格矛盾一样会流片后爆发节省的时间会在联调里赔掉需要一上来就把规格写得很厚很完整吗不需要但要写清楚关键的量化指标和取舍边界“算力”“功耗”这类大词没有意义要用乘累加次数、内存带宽、目标面积的具体范围来定义验证很慢Leader 又催着上流片怎么办把未覆盖的风险登记出来让决定变成显性决策口头承诺“应该没问题”是最大的隐患一定要用风险清单和置信度数字来沟通团队没做过芯片能不能做这类项目可以做但建议先用 FPGA 原型拉通整个软硬件链条FPGA 原型和 ASIC 在时序、功耗上差别很大但它是培养跨层直觉的最佳低成本方案AI 生成的代码可以直接信任吗绝不能直接信任要当成“又一个实习生写的初稿”来审查生成代码和设计规格共用同一个错误源头时最危险必须做独立的断言检查和覆盖回溯7.1 一个小而有效的组织习惯决策日志除了上面的速查表我还想单独分享一个配合方法论落地的小工具叫“决策日志”。这不是什么新概念就是在每次关键项目决策之后由决策者写几行文字记录三件事当时面对什么关键矛盾、为什么选择这个方案、我们在哪个不确定性前做了权衡。坚持记录三四个项目之后你会发现它的价值远超预期。一方面它能帮你复盘以前的决策是否经得起时间的考验另一方面它会在团队内部形成一种约定俗成的习惯没有人可以只凭“我觉得”来做一个重大技术决策他需要留下一份可以被追问的记录。今天再看 AI-native 芯片设计我最大的感受是它的起点未必是更聪明的工具而是一群人愿意在早期投入时间去理顺需求、打通跨层协同、并且诚实地记录验证风险。我在实际操作中最大的体会就是——一旦这些被忽略的“软能力”补齐了AI 工具无论多初级你都能把它放到正确的位置上发光反之即使拥有最前沿的模型和最强的算力最终也很可能在流片前的最后一公里翻车。最后再分享一个小技巧无论你的岗位是算法、架构、验证还是后端每个季度请强制自己只读一份其他方向的技术手册并做成笔记。坚持一个季度后你就会发现自己再和别人开需求对齐会时已经能听懂对方真正的痛点了。这个习惯是我见过的培养稀缺能力最便宜、也最容易被忽视的杠杆。
