最近这阵子，AI-native 芯片设计的讨论几乎霸占了我手机里几个行业社群的主页。某海外头部科技公司的研究团队发了一篇文章，核心思路是把 AI 能力注入芯片设计全流程——从架构探索、逻辑综合、物理实现，一直延伸到验证和签核。文章一出来，朋友圈马上分成两派：一派转“AI 要取代前端工程师了”，另一派在吵“AI 生成的 RTL 到底能不能进流片流程”。

说实话，这两种反应我都不太认同。我这两年在基础设施组和芯片前端组中间做技术协调，干的事情很琐碎：把需求翻译成约束，把工具链串起来，把验证闭环补上。因为站在这个位置，我看了那篇文章的框架，又对照我们在一个高复杂模块上小范围试过的 AI 辅助设计流程，发现大家最热衷讨论的方向，和真正卡脖子的地方之间有明显错位。

大家总在追模型、追算力、追数据集规模，但把时间拉长到一次完整的设计迭代里看， AI-native 芯片设计真正稀缺的东西，往往不是模型本身，而是那些不容易被 PPT 量化、却在每个环节决定成败的能力。这篇文章我不打算复述报告内容，只想讲三个我特别想反驳的认知，以及我在实际项目里的对应验证。

1. 先别急着追热点，AI-native 芯片设计的前提得先划清楚

1.1 从“AI 辅助设计”到“AI-native”，差别不是工具，是模式

很多讨论把 AI-native 芯片设计简单理解成“用 AI 工具辅助跑一遍流程”，这是根本性的误解。传统意义上的 AI 辅助设计，是人在主流程上做决策，AI 在某个局部帮一把，比如用机器学习做 IR drop 预测、用强化学习做 floorplan 优化，人看到结果后觉得合适就采纳。整个过程里，AI 是插件，人为核心。

AI-native 的意思完全不同。它指的是 AI 从设计流程的起点就开始介入，成为第一公民，它会根据高层的性能、功耗、面积目标主动探索架构空间，会生成候选的微架构和 RTL，会参与布局规划的搜索，甚至会提出验证策略。人的角色从“操作者”变成“定义者”和“审查者”。

我这里用个生活化的类比。传统的辅助设计是叫了个专车，你告诉司机要去哪，司机帮你选路线；AI-native 则是你雇了一个规划团队，你只说要到某个地方、什么时间到、预算多少，团队自己出方案、自己选路线、自己应对突发情况。你的工作重心从开车变成了写任务书和验收方案。这个转变看起来只是一句话，实际操作上却会重写整个研发流程。

1.2 那份报告的能力图谱，重点其实不在模型层

那篇研究报告按我的理解，把 AI-native 芯片设计拆分成了好几个层次：大模型的并行训练框架、数据资产管理、自动化评测体系、面向物理设计约束的强化学习、多智能体协作等等。单看每一块都做得非常专业，但当我把这份能力清单拿到项目现场去比对时发现，它能落地的部分远没有大家想象得多。

举个例子，报告里会把“RTL 生成”作为一项核心能力摆得很高，观众也容易兴奋。可真到了项目里，我们缺的并不是“写代码”的那几秒钟，而是敢不敢给这个生成结果做签核背书。RTL 写出来只是第一步，后面连着断言、测试平台、覆盖率、形式验证、综合结果、STA 时序收敛，任何一个环节不匹配，生成得再漂亮都没有意义。

如果把芯片设计比作盖楼，AI-native 更像是让 AI 同时扮演建筑师、结构工程师和现场监理。报告的优势在于把“建筑师”这个角色培养得很好，但楼能不能盖起来，取决于后面几类角色能不能跟得上。大部分行业讨论恰好把讨论重心全放在了建筑师身上。

1.3 为什么“稀缺能力”这个话题必须回到现场

所以我认为，“什么能力真正稀缺”这个问题不能放在宏观层面空谈，必须回到具体的研发现场去问：谁在写任务书，谁在验收结果，谁在为错误买单，谁能把这次踩坑变成下一次的经验。站在现场看，答案自然就和多数舆论不一样了。

下面这三条，是我特别想分享的“不同看法”，每一条都对应我在实际项目里见过、踩过、最后想办法绕过去的坑。我不打算否认模型和工具的重要性，只想把大家忽略的那部分补上。

2. 我的第一点不同看法：真正稀缺的不是生成结果，而是把需求翻译成约束的能力

2.1 大家都在卷模型推理，真正的瓶颈在输入侧

可能因为我是做工程出身，看问题比较刁。我发现行业里绝大多数兴奋点都集中在“AI 能生成多好的结果”上面——生成代码、生成网表、生成布局，每次 demo 都让人眼前一亮。但真正做过验证和集成的人知道，模型输出只是链条的一环，链条前面还有一道极其关键的转换：把你心里模糊的、不成体系的工程需求，变成机器能理解的、无歧义的约束条件。

这道转换，就是我说的“需求翻译能力”。它不性感，不容易展示，但它是所有下游工作成立的前提。

打个比方。你说“帮我把这个模块做出来”，这句话人理解得了，AI 理解不了。但如果你改说：“我需要一个 AXI4 接口的 DMA 控制器，支持最大 1024 字节突发传输，时钟频率 500MHz，目标面积小于 0.05 平方毫米，在典型场景下功耗低于 20 毫瓦，同时留出 5% 的时序余量”，AI 的搜索空间会被大幅压缩，生成质量才有保证。差别就在于你有没有能力把前者翻译成后者。

2.2 一个 RTL 生成场景里，“翻译需求”到底要做什么

我在我们的模拟项目 X 里测试过用 AI 生成 RTL。刚开始的时候，我们组的工程师把任务描述写得像需求文档一样详细，但填进去之后效果并不好。后来复盘发现，问题出在我们根本没把“约束”这个东西做结构化。

我总结下来，一个合格的 AI-native 输入侧要包含至少四层信息。

第一层是功能规格，这是最基础的，必须明确模块行为、接口时序、寄存器定义、异常处理策略。AI 不是猜谜机器，你少给它一条信息，它就多一份自由发挥的空间，而芯片设计最怕的就是自由发挥。

第二层是物理约束和目标，包括目标工艺节点、时钟频率、面积上限、功耗预算、可布线性风险。这些数据决定了 RTL 写出来能不能按时序收敛。

第三层是设计边界和例外路径，比如哪些路径不用做时序检查、哪些信号允许异步处理、哪些场景可以放宽功耗约束。不给 AI 这些信息，它会把所有东西都当成要严格优化的对象，最后生成一个看起来完美但根本过不了物理实现的方案。

第四层是验证意图，包括需要覆盖哪些关键场景、哪些事件得上 assertion、哪些覆盖率模型必须达标。把验证意图写进初始约束，等于提前告诉 AI：你不仅要生成代码，还要为自己的代码留下可验证的接口。

把四层信息组织成一份结构化的“任务规格书”，再交给 AI 生成逻辑，效果立刻不一样。生成出来的 RTL 可综合、可验证，后续集成沟通成本大幅下降。

2.3 怎么练这门手艺：需求约束化要点

既然需求翻译能力这么关键，那它能不能练习？我认为可以，而且方法很务实。

我建议每个想往 AI-native 设计方向走的团队，先建一个“约束模板库”，把所有历史模块的设计规格、物理目标、验证要求、例外条件收集起来，整理成统一的模板。下一轮迭代时，工程师只需要照模板填参数，不会遗漏关键约束。这一步看着简单，却是最容易见效的。

另一个技巧是给约束做“冗余校验”。很多时候工程师自己都拿不准面积目标定 0.05 还是 0.08 合适，那就别硬猜。先汇总裁历史模块的实际面积数据，做一个简单的分布统计，找出中位数和边界情况，再结合当前模块的复杂度做修正。AI-native 设计的起点不是拍脑袋，而是数据驱动。

还有一点容易被忽视：约束和约束之间会互相打架。面积定得太小，时序肯定跑不远；功耗目标压得太狠，性能可能不达标。真正成熟的“需求翻译者”，会在交给 AI 之前自己先做一轮约束一致性检查，把明显矛盾的参数调整好。这一步没办法完全自动化，需要大量的工程经验。

我始终觉得，输入侧是 AI-native 芯片设计里最像“手艺活”的地方。这个能力不会出现在模型卡上，但它决定了整条流水线能不能跑通。

3. 我的第二点不同看法：比“让 AI 把芯片画出来”更难的是“判断它画得对不对”

3.1 生成式 AI 带来的验证危机

当大家还在为“AI 能写 RTL ”“AI 能跑布局规划”欢呼的时候，我这边看到的却是另一幅画面：大量 AI 生成的结果堆在验证工程师门口，等着被确认能不能用。

这在半导体行业是一个很要命的问题。芯片设计行业经过几十年发展，形成了一整套严密的验证逻辑。前端要过的关卡包括 lint 检查、仿真功能验证、断言检查、覆盖率收敛，后端要过的关卡包括时序分析、功耗分析、IR drop、电迁移、可制造性签核。每一步设计都必须有据可查，任何一步出问题，轻则重做，重则流片失败。

AI-native 设计把“生成”这个环节变得极度便宜，成本也降下来了，结果就是大家敢不停地让 AI 试错。但便宜的生成只是放大了验证的压力。以前一个工程师写一个月代码，验证工程师有充分时间做检查；现在 AI 一小时生成几十个变体，验证资源没有同等增长，最终堆积成验证危机。

3.2 稀缺的是“可信度评估”，不是“结果生成”

正因为如此，我认为这个阶段真正稀缺的能力不是生成，而是“判断 AI 生成的东西值不值得信任”。

这个判断能力包括三个层次：首先，能快速识别生成结果是否满足基础语法和设计规则，把低级错误过滤掉；其次，能设计高效的验证策略，不用把所有资源砸向穷举仿真，而是针对 AI 生成结果里概率比较高的错误模式做定向验证；最后，能对 AI 生成过程中的不确定性做量化估计，知道哪些部分是需要人重点关注的，哪些部分是相对可信的。

有一次我们让 AI 生成一个跨时钟域处理模块，生成的 RTL 从功能仿真角度看几乎完美，测试跑两次全过。但我的同事在代码 review 时发现，AI 在跨时钟域的同步处理上用了不规范的拍数假设，在特定电压频率条件下会有触发时间问题。这种错误做随机仿真几乎很难复现，只有结合物理常识才能发现。

这就验证了我的判断：审查能力比生成能力稀缺。生成器拉高了错误的上限，但只有审查者能把错误上限压回去。

3.3 搭一套人机协同评估闭环的实操框架

那怎么把这个稀缺能力落地？我的经验是不要指望一个人扛下所有判断，要设计一套协同评估闭环。

第一步，要为 AI 生成结果建立一套自动化初审管线。包括 RTL lint、可综合性检查、静态时序预估、功耗预估、覆盖率统计，全部做成自动跑。这套管线不需要太复杂，目的就是把低级错误在交给工程师之前过滤掉。

第二步，要设计针对 AI 生成模式的定向验证用例。AI 生成的错误通常有类型上的偏好，比如它容易在边界条件上偷懒，容易对协议握手信号简化处理，容易忽略异步复位时的数据完整性。针对这些高频错误点设计专门的健壮性用例，比盲目的随机仿真高效得多。

第三步，要引入“决策可见性”机制。每份 AI 生成结果都附一个决策日志，记录 AI 在哪些地方做了选择、依据是什么、有哪些备选方案被放弃。工程师在做最终审查时可以参考这个日志，避免从零开始推演设计意图。日志的标准化程度越高，审查效率越高。

最后，还要给“人机意见不一致”留足流程空间。当工程师和 AI 生成方案产生分歧，不能简单相信任何一边。比较稳妥的做法是，把分歧点单独拎出来做一个小规模的对比实验，用数据说话。这不是浪费时间，反而是避免更大返工的投资。

4. 我的第三点不同看法：AI-native 最稀缺的是组织级的学习与决策机制，不是一个聪明模型

4.1 纸上谈兵容易，落地的三座山

我见过不少团队在尝试 AI-native 设计时，起步非常漂亮，模型选得先进，工具链装得齐整，Demo 也做得很惊艳。但一百个人起步，最后能坚持到流片阶段的寥寥无几。问题不在模型，而在组织。

第一座山叫“流程断层”。AI-native 要求的过程是“AI 生成→人审→反馈→再生成”，这个闭环在单个小组内部容易做；可一旦跨越前端组、验证组、物理设计组、DFT 组，信息传递就会断裂。前端组交给验证组的 AI 生成代码没有附带充分的意图说明，验证组不敢信任；物理设计组拿到的网表和脚本风格与历史流程不一致，连续出现问题后干脆回到手工模式。

第二座山叫“责任归属”。传统流程里，每个环节有一个明确的负责人，出了问题可以回溯。AI-native 流程里，很多设计决策是模型做的，出了问题谁来担责，团队里没有共识。于是大家出现了很微妙的回避心态：谁用 AI 谁背锅，不用就没责任。这个文化问题不解决，AI-native 推一步退两步。

第三座山叫“经验沉淀断层”。传统设计里经验积累在工程师个人头脑中，资深工程师看一眼网表就能意识到风险；AI-native 设计里经验积累应该转移到可复用的数据资产中，包括历史设计数据、失败案例、验证结论、约束调整记录。多数团队没有认真建设这个资产池，每次迭代都是从零开始。

4.2 可复用的数据资产比想象中更稀缺

前面说到经验沉淀，必须重点展开一下。我在多个项目里观察到一个共性：大家嘴上都说数据重要，但手里几乎没有任何可用于 AI-native 流程的结构化数据资产。

为什么？因为芯片设计的数据从来不是现成的。完整的 RTL 仓库只是最粗糙的原料，真正需要的是把每个模块在更迭过程中的约束变化、时序收敛、功耗优化、验证盲区按统一格式记录下来。这些信息散落在邮件、聊天记录、个人脚本和无数个 Excel 表格里，没人整理，更谈不上喂给 AI 做训练或辅助决策。

我见过一个最可惜的失败项目：某小组做了一个 AI 辅助 floorplan 工具，首次测试效果非常好，帮物理设计组节省了大量迭代时间。但因为数据格式没有留存，三个月后换了一个工艺节点，想把经验迁移过去，发现完全无法复用，所有工作推倒重来。

所以我建议任何推进 AI-native 的团队，从项目第一天就立一项规矩：所有设计决策，无论是人做的还是 AI 做的，都以标准化数据格式记录到统一平台上。这些数据短期看是负担，长期看是整个组织最不可替代的资产。

4.3 团队里要长出三个新接口

如果要给组织级的 AI-native 落地提一些具体建议，我会说团队里需要长出三个新接口。

第一个接口叫“规格接口人”。这个人负责把来自产品、架构、设计的不同需求，整理成结构化的 AI 可消费任务规格。他必须是技术功底深厚的人，能听懂架构师的高层意图，也能理解验证工程师的底层顾虑，还要能把常人难以量化的东西量化为约束。

第二个接口叫“评估接口人”。这个人负责设计评估策略、管理自动初审管线、主导 AI 生成结果的信任判定。他不会把所有时间花在跑仿真上，而是花在思考“哪些错误 AI 可能犯”“哪些地方值得投入验证资源”上。

第三个接口叫“学习接口人”。这个人负责把项目过程中产生的数据、结论、失败案例回流到统一的资产池，确保组织级的学习不发生断裂。同时他要持续观察 AI 模型的短板，把那些反复出现的错误类型整理成反馈样本，驱动下一轮模型迭代或工具升级。

这三个接口不一定必须是专职岗位，但必须有明确的人对这些事负责。没有责任人的事情，在组织运行里等于不存在。

5. 基于常见实践的补充：我们自己的一次 AI 辅助设计复盘

5.1 背景：某跨平台芯片项目里的小范围尝试

前面讲的都是我观察到的行业共性，下面补一段我们自己的实操经历，算是把上面的观点落到具体场景里。

我们当时在一个跨平台芯片项目里尝试 AI 辅助设计，范围控制得很小：只选了模块中的一个 DMA 控制器作为实验对象，目标是让 AI 生成一份可以进入标准验证流程的 RTL。模型是现成的，我们主要把精力花在约束准备和验证闭环上。第一版约束很快做出来了，功能规格、接口定义、时序目标都填好，但第一次生成结果就给了我们一个下马威。

AI 生成的整体接口完全正确，DMA 的 descriptor 读写逻辑也没有明显问题，但一旦进入带时序的模块级仿真，出现了一个很隐蔽的 read-after-write 冒险场景。问题根源是 AI 在生成控制逻辑时，对 FIFO 空满状态的更新时机做了过于激进的假设，导致在读操作尚未完成时就去检查标志位。这个逻辑在纯功能测试里跑不出来，只有在加入物理时序信息后才暴露。

这次经历完美印证了我前面的判断：生成不是问题，验证才是问题。

5.2 三个坑和对应排查思路

第一个坑：约束模板里漏了“验证意图”。我们第一版约束只写了功能规格和物理目标，没有写验证意图，导致 AI 生成的结果虽然功能对，但没有留下足够的断言和 controllable 信号，验证组不得不花大量时间重写测试平台。教训是必须提前把验证意图写进任务规格，而不是等 RTL 出来后再补。

第二个坑：过分相信 AI 生成结果的“一次正确”假象。AI 生成的代码风格和语法都规整，这种“规整感”很容易让人放松警惕。实际经验是，规整的代码更容易藏住语义层面的错误，因为表面上没有任何 warning。我们后来规定，不管 AI 生成结果多么干净，必须走一遍完整的静态检查加定向验证，不允许跳过。

第三个坑：迭代反馈没有闭环。第一轮发现的问题修正后，我们重新生成了一次，但发现 AI 在修复 read-after-write 问题的时候，引入了新的性能回退。原因是没有把上一步的验证结论结构化地反馈给模型，只给了一条泛泛的“请修复该问题”指令。后来我们把验证结果转成具体的约束补充项，再重新生成，效果立刻改善。这逼着我们建立了一套“验证结论转约束”的转换规则，以后的迭代就顺畅多了。

5.3 如果重来，我会怎么调配资源

复盘之后，如果让我重新启动这个小范围实验，我会做三件不同的事。

第一，把 60% 的精力放在约束设计上，只留 20% 给模型调参。因为约束设计直接决定了 AI 生成质量和后续验证成本，是最值得投入的杠杆点。

第二，提前建立 AI 生成结果的“定向错误库”。先把常见的 AI 错误类型收集好，给每个类型配置专项验证用例，而不是等到问题暴露了再临场想对策。

第三，让验证工程师从项目第一天就参与约束设计，而不是等 AI 生成结果出来后再把验证组拉进来。验证工程师能提供大量关于可观测性、可控性和覆盖率的实际要求，这些是架构师和设计工程师容易忽略的。

这次小范围尝试最终没有进入完整流片，但给我们整个团队带来的认知提升非常明显。现在无论做什么模块，大家都会下意识先问一句：约束写清楚了吗？验证闭环建好了吗？我觉得这才是 AI-native 最需要的文化底色。

6. 常见问题速查：关于 AI-native 能力建设的六问六答

结合这段时间社群里的高频提问，整理成一张速查表，方便大家在实际推进时对照。

这六问六答看起来简单，背后提炼的全是我和同行交流中最常踩的认知误区。以前大家问得多的是“用哪个模型”“花多少钱训练”，现在问得多了反而是“怎么定义需求”“怎么验证结果”“怎么沉淀经验”，我自己觉得，这种提问方向的变化本身就是行业成熟的信号。

我做了这么多年芯片工程，最大的体会是技术演变的底层逻辑没变过：真正稀缺的从来不是工具，而是使用工具的人如何定义问题、组织协作、并为结果负责。AI-native 把生成环节变得极度高效，反而把这些本质上属于人的能力推到了聚光灯下。

如果你正在带着团队往这个方向走，我的建议可能和多数舆论相反：别急着换更亮的模型，先把团队里那个能把需求翻译成约束的人找出来，把验证闭环建起来，把每一次踩坑都变成下一次的条件反射。这些事做扎实了，AI 才会真正成为你的队友，而不是一个让人又爱又怕的协作对象。