AI-native芯片设计：稀缺的不是工具调用，而是问题定义与验证判断力

1. 从"AI 写 RTL"说起：被误读的稀缺能力

最近圈子里讨论很热的一个话题，是某头部研究机构放出的一个观点——AI-native 芯片设计时代，真正稀缺的能力到底是什么。原始说法大致落在"会用 AI 工具""懂 prompt 工程""能跑通自动化流程"这几个方向上。我盯着这个结论看了很久，越看越觉得哪里不对。

先说我的核心判断：在 AI-native 芯片设计这件事上，稀缺的从来不是"会用 AI"，而是"知道该让 AI 做什么、以及凭什么判断它做对了"。前者是操作技能，半年就能练熟；后者是领域判断力，十年未必够。把稀缺能力定位在工具使用层面，本质上是一种"把手段当目的"的错位。

我之所以对这个话题有话说，是因为过去两年我一直在做一件很具体的事：把 AI 能力嵌进真实的芯片设计流程里，从 RTL 生成、验证用例补全，到时序约束辅助、物理设计阶段的拥塞预测。踩过的坑、翻过的车、以及少数几次"这东西真香"的时刻，让我对"稀缺"两个字有了完全不同的体感。

这篇文章不打算复述任何机构的原始结论，而是从一线实操的角度，把"AI-native 芯片设计"这件事拆开讲清楚：它到底改变了什么、没改变什么、哪些能力被高估了、哪些能力被严重低估了。如果你是从业者，或者正准备往这个方向转，希望这些内容能帮你少走两年弯路。

提示：本文讨论的"AI-native"指的是把 AI 作为设计流程的一等公民来组织工作流，而不是在传统流程末尾挂一个"AI 助手"按钮。这两者的差别，后面会反复提到。

2. 三点不同看法：稀缺能力的重新排序

2.1 第一点：稀缺的是"问题定义能力"，不是"工具调用能力"

我先抛一个反直觉的观察。在我接触过的团队里，真正把 AI 用出效果的，往往不是那些把工具玩得最花的人，而是那些能把一个模糊的设计需求拆成 AI 可执行、可验证的子任务的人。

举个具体场景。假设你要设计一个中等复杂度的总线仲裁模块。工具调用能力强的人会直接写一句"帮我生成一个仲裁器"，然后拿到一段能编译但时序和面积都不可控的代码。而问题定义能力强的人会这么做：

• 先明确仲裁策略（轮询、优先级、加权公平），因为这决定了状态机结构；
• 再明确接口时序（握手协议、背压处理），因为这决定了跨时钟域和组合逻辑深度；
• 然后明确约束边界（最大延迟、面积预算、可综合性要求）；
• 最后才把这几条拆成 AI 能逐条生成、逐条验证的子任务。

你看，差别不在"会不会用工具"，而在"知不知道要问什么"。前者是调用，后者是定义。而定义能力来自哪里？来自你对这个模块在系统里扮演什么角色、会被谁调用、在什么 corner case 下会出问题的深刻理解。这种理解，AI 给不了你，因为它不在你的项目上下文里。

我个人的经验是，一个能被 AI 高效执行的芯片设计任务，其问题定义的工作量往往占到整个任务的 60% 以上。剩下 40% 才是生成、迭代、验证。很多人把顺序搞反了，以为 90% 的时间应该花在调工具上，结果就是反复生成、反复不满意，陷入"抽卡式开发"。

2.2 第二点：稀缺的是"验证判断力"，不是"生成速度"

第二点更关键，也更反直觉。AI 把 RTL 生成速度提升了十倍，但验证这些 RTL 是否正确的成本，并没有同比下降，甚至在某些场景下还上升了。

原因很简单：AI 生成的代码有一个隐蔽特征——它看起来总是对的。语法正确、风格统一、注释齐全，甚至 lint 都能过。但芯片设计里最致命的 bug 从来不是语法错误，而是语义错误：边界条件漏了、复位逻辑有竞争、跨时钟域没做同步、状态机有不可达状态。这些错误，AI 生成时不会主动告诉你，lint 工具也未必抓得住。

我踩过最惨的一次坑，是一个 AI 生成的 FIFO 控制器。代码读起来毫无破绽，仿真跑基础用例也全过。但我们在做形式验证时发现，在"几乎满"和"几乎空"同时触发的极端场景下，读写指针会短暂指向同一地址，导致数据被覆盖。这个 bug 在常规仿真里几乎不可能被随机命中，但它真实存在。

从那以后我形成了一个习惯：AI 生成的任何模块，验证投入不低于手写模块的 1.5 倍。多出来的 0.5 倍，专门用来设计"AI 容易犯错的场景"——极端边界、并发冲突、复位序列、跨时钟域。这不是不信任 AI，而是理解它的失效模式。

所以稀缺能力是什么？是知道该验证什么、以及凭什么判断验证已经充分。这个能力，本质上是对"设计可能在哪里出错"的先验知识。AI 越强，这种先验知识越值钱，因为生成变得廉价之后，判断就成了瓶颈。

2.3 第三点：稀缺的是"系统级权衡能力"，不是"单点优化能力"

第三点，也是我认为最被低估的一点。AI 非常擅长单点优化：给你一段代码，它能优化面积、优化时序、优化功耗。但芯片设计从来不是单点问题，而是系统级的多目标权衡。

举个真实例子。我们在做一个数据通路模块时，AI 建议把某个组合逻辑路径打拍，以改善时序。单看这个建议，完全正确——打拍后关键路径缩短，频率能上去。但放到系统里看，这一拍引入了一个周期的延迟，而下游模块的握手协议假设的是零延迟响应，结果就是功能错了。

AI 看不到这个"下游假设"，因为它不在它的上下文里。它只看到了局部的最优解，而系统级设计要的是全局的可行解。这两者经常冲突。

系统级权衡能力的核心，是知道每个局部决策会如何影响其他部分。这种能力需要你同时理解：架构、微架构、时序、功耗、面积、可验证性、可测试性、以及软件栈的假设。AI 可以在每个单点上给你建议，但把这些建议整合成一个自洽的系统，仍然是人来做。

我甚至认为，随着 AI 在单点优化上越来越强，系统级权衡能力的重要性会指数级上升。因为单点优化的建议会越来越多、越来越快，而整合这些建议的认知负荷会越来越大。谁能高效地做这种整合，谁就是稀缺的。

3. 一个真实项目的拆解：AI 到底在哪一环真正省了时间

光讲观点容易空。我拿一个去年做过的项目来拆，看看 AI 在真实流程里到底在哪一环省了时间、哪一环反而增加了负担。项目是一个中等规模的数据处理加速模块，大概两万行 RTL 量级，团队三个人，周期四个月。

3.1 需求到微架构：AI 几乎帮不上忙，但能当"陪练"

第一阶段是需求到微架构。这部分 AI 基本插不上手，因为需求来自系统组的模糊描述，微架构要在"性能、面积、功耗、开发周期"之间做取舍。这些取舍依赖大量隐性知识：这个模块未来会不会被复用、上游的带宽瓶颈在哪、下游的软件栈能不能改。

但 AI 有一个用法我觉得很值：当陪练。我会把微架构方案讲给它听，让它扮演一个"挑刺的评审"，专门问"如果这里出问题会怎样"。它问的问题未必都对，但能逼我把方案里没想清楚的地方补上。这个用法不省时间，但提升方案质量。

3.2 RTL 生成：省时间，但省的是"打字时间"不是"思考时间"

第二阶段是 RTL 生成。这是 AI 最直观的省时环节。一个典型的控制状态机，手写大概半天，AI 生成加调试大概两小时。但要注意，省下来的是打字和查语法的时间，思考时间一点没少——你仍然要想清楚状态转移、边界条件、复位策略。

我统计过，AI 生成的 RTL 里，大约 70% 可以直接用或小改，30% 需要重写。那 30% 主要集中在：跨时钟域处理、复杂握手协议、以及需要精确控制综合结果的逻辑。这些恰恰是最需要经验的部分。

3.3 验证：AI 补用例很香，但"验证充分性"仍靠人

第三阶段是验证。AI 在补测试用例上确实好用，尤其是随机约束的编写和覆盖率驱动的用例生成。但"验证是否充分"这个判断，仍然完全靠人。我们最后是靠形式验证加定向用例才敢签核，AI 生成的随机用例只是补充。

3.4 物理设计：AI 预测有用，但别信"一键收敛"

第四阶段是物理设计。AI 在拥塞预测和布局建议上有一定价值，但"一键收敛"这种说法我是不信的。物理设计的收敛依赖太多工艺和工具细节，AI 目前更多是辅助而非替代。

这张表我想说明的是：AI 的省时是不均匀的，而且省下来的时间高度集中在"执行"环节，而非"决策"环节。如果你的瓶颈在决策，AI 帮不了你；如果你的瓶颈在执行，AI 能帮大忙。搞清楚自己的瓶颈在哪，比盲目上工具重要得多。

4. 被高估与被低估的能力清单

基于上面的分析，我把当前讨论里常见的能力项做个重新排序。这张清单是我的主观判断，但每一条都有项目里的具体依据。

4.1 被高估的三项

第一，Prompt 工程。这东西重要，但被神化了。在芯片设计里，好的 prompt 来自好的问题定义，而问题定义来自领域理解。你领域理解到位了，prompt 自然就写得好；理解不到位，背再多模板也没用。我见过太多人花大量时间研究"怎么问 AI"，却不肯花时间研究"这个模块到底该怎么设计"。

第二，工具链熟练度。会用某个 AI 辅助工具，是入门门槛，不是竞争力。工具会迭代、会过时，今天熟练明天可能就换了。把竞争力押在工具熟练度上，风险极高。

第三，生成速度。生成快不等于交付快。芯片设计的交付瓶颈在验证和收敛，不在生成。生成快了，验证压力反而更大。追求生成速度，容易陷入"生成一堆、验证不过来"的困境。

4.2 被低估的三项

第一，领域判断力。知道什么是对的、什么是错的、什么是可疑的。这是所有能力的底座，也是 AI 最替代不了的。

第二，验证设计能力。能设计出"能抓住 AI 错误"的验证方案。这需要你对失效模式有深刻理解。

第三，系统整合能力。能把 AI 的单点建议整合成自洽的系统。这是 AI 时代最稀缺的能力，没有之一。

注意：这三项被低估的能力有一个共同点——它们都无法通过"学工具"获得，只能通过"做项目、踩坑、复盘"积累。这意味着它们的积累速度慢，但一旦形成，护城河极深。

5. 如果你要往这个方向走，我的实操建议

最后落到可操作层面。如果你是从业者，或者准备往 AI-native 芯片设计方向走，我给几条具体建议，都是我自己验证过的。

5.1 先把一个模块从需求做到签核，完整走一遍

不要一上来就研究工具。先完整做一个模块，从需求、微架构、RTL、验证到综合，全程自己走。走完之后你才知道瓶颈在哪、AI 能在哪帮你。没有这个完整体感，所有关于 AI 的讨论都是空中楼阁。

5.2 建立自己的"AI 失效模式库"

每次 AI 生成出错，都记下来：错在哪、为什么错、怎么发现的。积累半年，你会有一个非常值钱的清单。这个清单就是你的验证重点，也是你和别人的差距所在。

5.3 刻意练习"问题定义"

拿到一个任务，先别急着让 AI 生成。先花时间把它拆成可执行、可验证的子任务，写清楚每个子任务的输入、输出、约束、验收标准。这个练习做多了，你会发现 AI 的输出质量直线上升——不是 AI 变强了，是你问对了。

5.4 把验证投入当成投资，不是成本

AI 生成的代码，验证投入要加倍。这不是浪费，是投资。因为 AI 的错误更隐蔽，漏掉一个的代价远大于多验证一轮的成本。我现在的习惯是，AI 生成的模块，验证用例数量至少是手写的 1.5 倍，且必须包含形式验证。

5.5 保持对"一键"说法的警惕

任何声称"一键完成芯片设计某环节"的说法，都值得警惕。芯片设计的本质是多目标权衡，权衡就需要判断，判断就需要人。AI 可以加速执行，但替代不了判断。把这句话记在心里，能帮你避开很多坑。

我在这个方向上的体会是，AI-native 不是让设计变简单了，而是让设计的重心从"执行"转移到了"判断"。执行变便宜了，判断变贵了。谁能在这个转移中站稳，谁就是稀缺的。这个判断，比任何工具都重要。