1. 从“脚本加速”到“范式转移”：大模型入场后的EDA新格局
我是从ICC2和Innovus时代一路用过来的老工程师，刚入行那会儿，跑一个百万门级的布局布线要挂机一整个通宵，早上来先看log有没有爆红，再决定是调floorplan还是改约束。那些年我们解决芯片设计复杂度靠什么？靠流程标准化、脚本批处理、更多核的服务器。说白了，是把人和工具之间的交互压缩到极致，用经验和脚本去填工具理解的间隙。
但大模型这一波进来，我明显感觉到事情不一样了。它不是又给EDA加了一个“智能按钮”，而是把EDA整个链条里“人理解机器、机器执行人意图”的那一层薄冰给敲碎了。以前我们写UVM验证环境，要一句一句拼SystemVerilog，现在可以让模型生成主干，我们只改约束和checker；以前看时序报告，要在成百上千条path里人工挑critical ones，现在模型能直接总结“这几条path共同的问题是clock skew偏大，建议调整CTS配置”。这不是加速，是换了一种工作方式。
业内现在常说大模型正在重塑EDA，我觉得更准确的说法是：它正在把EDA从“规则驱动”变成“知识驱动”。规则是死的，知识是可以迁移、可以对话、可以举一反三的。一个在某个项目里沉淀下来的时序收敛经验，过去只能写进wiki然后腐烂掉，现在可以作为语料让模型学习，下次直接以对话形式给到新项目的工程师。这种变化，才是本质上的。
这篇内容我不打算给你讲太多花哨的学术名词，就以一个一线数字IC工程师的视角，聊聊大模型在EDA里头到底能干什么、不能干什么、怎么落地、踩过哪些坑。读完你至少能对“大模型+EDA”这个热点有个冷静的判断，知道哪些是真实可用的，哪些还在demo阶段。
1.1 大模型在EDA里能解决什么核心问题
先说结论：大模型在EDA里的价值，集中在三件事上——减少重复劳动、降低专业门槛、沉淀隐性知识。
减少重复劳动最好理解。写testbench、写约束注释、生成寄存器描述文档、补齐SDC里大段大段的时钟分组说明，这些活儿技术含量说高不高，但极度消耗精力。我见过一个项目组，专门安排一个工程师花了两周时间给两千多个寄存器写文档，最后生成的docx几乎没人看。这种活，大模型干得又快又好，你只需要给它一个寄存器列表，它就能生成规范、格式统一、覆盖所有信号的描述文档。
降低专业门槛是更深远的价值。EDA的门槛高，高在知识体系极其庞杂。一个刚从学校出来的学生，理解setup time和hold time容易，但要把一条违例路径修到收敛，需要的是对综合、布局、Clock Tree Synthesis、信号完整性乃至工艺偏差的整体理解。大模型可以作为“随身专家”，你问它“为什么这条path的hold slack在CTS之后变差了”，它能把CTS的插入延迟、common path pessimism removal、OCV derate这些概念串起来解释，而不是像文档那样孤立地叙述。实测下来，这种交互式学习比看三遍官方文档都有效。对资深工程师来说，它同样有用——换到不熟悉的工艺节点或新工具版本时，很多经验要推倒重来，有个大模型帮你梳理差异，适应期能缩短一大截。
至于沉淀隐性知识，这是最容易被忽视但长期价值最高的一点。芯片公司的EDA flow积累了大量经验，比如“3.0V电压域下的hold fix建议直接加delay cell，不要依赖useful skew”“这个工艺角下，长走线比门延迟更容易出问题”。这些经验过去存在于资深工程师脑子里，人一走就没了。大模型可以把这些知识做成可查询、可对话的知识库，相当于把人的经验变成公司的资产。
1.2 为什么说这次不是“工具升级”而是“范式变化”
过去二十年，EDA工具的改进基本是线性的：算法更快、容量更大、GUI更好看。综合工具从DC到Genus、PT到Tempus，内核逻辑没变，变的是速度和容量。但大模型带来的改变是另一条轴线上的——它改变了人和工具的交互界面。
传统EDA的使用模式是：工程师根据经验设定约束和策略，工具按照算法自动执行，输出报告，工程师再解读报告、调整策略。这里面有一个核心瓶颈——人对工具的理解深度决定了设计质量的上限。你理解不了工具的cost function，就不知道为什么它把这条path优化的同时破坏了另一条path。
大模型的模式则是：工程师用自然语言描述意图，模型理解意图，将其转化为工具的配置、命令或约束，然后再把工具输出翻译回人类可读的结论。工具还是那个工具，跑在服务器上的算法没变，但中间多了一个“理解层”。这个理解层让“不太懂工具细节的工程师”也能用好工具，让“很懂工具的工程师”从繁琐的配置和报告解读中解放出来，去处理更上层的问题。
所以我说这是范式变化，不是工具升级。就像从命令行到图形界面，不是让你敲命令更快，而是让更多不会敲命令的人也能用电脑。大模型之于EDA，就是这个级别的改变。
2. 大模型进入EDA的三条主赛道：验证、时序、物理实现
聊完理念，来看实际落地。我观察下来，大模型在EDA领域最有希望率先规模落地的是三条赛道：验证、时序收敛、物理实现。这三个方向各有各的特点，适合大模型发挥的环节也完全不同，一个一个拆开说。
2.1 功能验证：从“覆盖率驱动”到“意图驱动”
功能验证是芯片设计流程里人力投入最重的环节之一，也是大模型最容易见效的场景。常规验证流程是：根据spec写验证计划，搭UVM环境，写testbench、sequence、checker，跑仿真，分析覆盖率，补用例，再跑，直到覆盖率达标。这里面有大量重复的、模板化的代码工作。
我试过一个比较典型的场景：给大模型一段AXI总线协议描述，让它生成一组master/slave的UVM验证组件骨架。用GPT级别的大模型，生成的UVM基础框架质量相当高，driver/monitor/sequencer的基本结构是对的，代码风格甚至比团队里多数新人写的更规范。但这只是第一步，真正有价值的是它在分析验证场景时的表现——你告诉它设计里有fifo，有背压逻辑，有水位线预警，它可以列出需要覆盖的关键场景：fifo满时写入、读空时读出、同时读写时水位线变化、back-to-back burst等。这些场景清单拿给一个有经验的验证工程师看，基本能覆盖80%的corner case方向。这个价值，比生成代码本身大得多，因为它直接帮你想“要验什么”，而不仅是“怎么验”。
不过要泼盆冷水，大模型生成testbench的随机约束时容易出问题。约束里涉及跨模块信号的取值范围、协议字段的位宽、reserved bit的处理，这些细节模型容易“想当然”，生成不匹配RTL实际定义的约束。所以我的经验是：大模型生成的验证代码，必须结合编译、仿真、覆盖率数据的反馈做多轮修正，不要指望一次生成直接进回归。具体做法后面实操章节会详细讲。
2.2 时序收敛：从“经验排查”到“智能诊断”
时序收敛是另一个大模型能发挥明显价值的领域。传统STA流程跑完，会吐出海量时序报告。一个中等规模的设计，setup和hold违例加起来可能有上千条。工程师通常关注的是最差路径、关键路径群，但真正判断“这个违例是结构性问题还是局部问题”，需要综合很多信息：是cell delay主导还是net delay主导、是否跨时钟域、是否经过multicycle path、是否受congestion影响等。大模型读取时序报告后，可以自动归类、总结根因模式，并给出优化方向。
以我自己的实测体验，大模型对时序报告的理解能力超出预期。给它Typical Corner下的一堆setup violation路径，它能准确识别出“这些路径共同经过了大扇出的复位网络，建议先做寄存器复制”或者“这些路径的net delay占比超过60%，大概率是布局拥塞导致，建议优化floorplan”。这类结论，有经验工程师看半小时才能归纳出来，大模型几秒钟就能给到，还能把相关路径列出来供你核对。
时序报告的语言是高度工程化的，Slack、Arrival Time、Required Time、Transition这些字段，本身就适合大模型解析。我甚至做过一个实验，把PR工具生成的congestion map数据，转成结构化文字描述，让模型判断哪些区域需要调整macro摆放。它给出的建议里有一条是“这块区域左侧的pin density过高，考虑把存储器阵列右移两格”，听起来像人话，实际操作中也有一定参考价值。当然，这类“智能诊断”目前还只能辅助工程师判断，让模型直接给出可落地的详细修改方案并保证时序收敛，还做不到，但作为放大器来用，已经能显著提升效率。
2.3 物理实现：从“经验驱动”到“预测驱动”
物理实现层面，布局布线、拥塞预测、功耗分析这些方向，大模型也在渗透。传统PR流程高度依赖工程师对floorplan的把控，一个macro摆得不好，后面CTS和布线阶段会连锁反应，修复成本极高。过去我们靠经验判断“这个模块大概占多大面积、应该放哪个区域”，现在数据驱动的模型可以学历史项目的布局数据和结果，预测新RTL在特定工艺下容易出现拥塞的位置。
但这种应用目前还比较初步，因为物理实现的数据大多是结构化的几何数据，不是自然语言，大模型的优势发挥不出来。更适合的做法是混合方案：用传统机器学习模型做定量预测，用大模型做定性分析和决策解释。比如预测拥塞用图神经网络，预测出来之后，让大模型解释“为什么这个区域拥塞度高、怎么调整”，这算是取长补短。
我听到一些同行提到，已经有工具开始尝试用大模型做布局建议的问答，比如“这个desigen里，DMA模块放在左下角好还是右下角好”。模型结合网表信息、工艺库特征和过往案例给出倾向性建议，然后由工程师结合自己的判断做最终决定。这个思路不错，能辅助新人快速做出不差的选择。
3. 工程化落地：大模型与现有EDA流程怎么融合
不同的工作场景，对大模型的依赖程度是不同的。验证场景需要模型精通SystemVerilog语法和UVM机制，时序场景需要掌握STA引擎的内部逻辑和工艺偏差带来的影响，物理实现场景则更依赖对几何信息和历史数据的理解。所以大模型引入EDA，不是简单“装一个模型就够了”，而是要区分场景、按需集成。
3.1 人机协同的三种工作模式
我把大模型在EDA里的工作模式分成三种，按自动化程度从低到高排列。
第一种是副驾模式（Co-pilot），模型辅助工程师完成具体任务。工程师写UVM环境，模型补全代码；工程师看时序报告，模型做总结归类；工程师写ECO脚本，模型根据描述生成Tcl脚本框架。这种模式下，最终决策和验证由工程师完成，模型相当于一个知识渊博的助手。这是当前最成熟、最容易落地的模式。我目前在实际项目里用最多的就是这种。第二种是监督自治模式（Supervised Automation），模型在既定流程里自动执行特定环节，但关键节点需要人来确认。比如自动生成testbench并跑完编译仿真后，由人来审查覆盖率报告是否符合预期；或者让模型自动从多个历史项目的时序报告里学习最佳修复套路，给出推荐方案，然后由人来执行。这种模式对模型输出质量要求更高，目前在小范围内可用，但需要建立严格的评测和信任机制。第三种是自主优化模式（Autonomous Optimization），模型独立完成从分析到优化的闭环。比如模型读入设计、自动识别关键路径、自动迭代修复时序违例，直到满足收敛目标。这种模式在学术demo里见过一些，离大规模工业落地还有距离，主要原因是芯片设计的风险太高——一个小错误就是几百万元的流片损失，业界不敢轻易把最终决策交给模型。
现在大家讨论比较多的“AI辅助EDA”大多停留在第一种，少数团队在尝试第二种，第三种更多是用来讲故事。认清这个现实，能帮你在公司立项时避免过度承诺。
3.2 私域部署还是云端API：这是个选择题
大模型要用在EDA流程里，第一个绕不开的问题就是：模型部署在哪。芯片公司的数据高度敏感，RTL代码、工艺库参数、时序报告都属于核心资产。把这些数据送到公开的云端API，绝大多数公司法务这一关就过不去。
我的建议是分三层考虑。
第一层，公开API只用于处理非敏感数据。比如让你了解某个协议的标准规范、生成最基础的代码模板、帮你理解某个EDA概念，这些不涉及公司核心数据，用公开API没问题，效率也高。
第二层，私有大模型部署在公司内网。这是大多数有一定规模的芯片公司应该走的路。开源的代码模型可以在内网服务器上用A100/H100跑推理，处理内部RTL和报告数据，安全可控。如果公司资源有限，也可以考虑私有化部署一个中等规模的模型，配好权限管理，只允许特定项目组使用。
第三层，也是最理想的方案，是构建领域知识库+RAG，让大模型能检索公司历史设计文档、经验总结和设计规范。这个方案能把公司多年积累的团队经验变成可查询的知识资源，大模型结合知识库回答问题时，专业度和准确性都会明显好于裸模型。
3.3 微调 vs RAG：哪个更值得投入
这是我在各个场合被问到最多的问题。先说结论：对大部分公司来说，RAG的投入产出比远高于微调，但微调在特定垂直场景下有其不可替代的价值。
RAG的核心思路是让模型在回答问题时先检索知识库，把相关知识作为上下文提供给大模型，再让大模型基于这些知识生成回答。优点是：知识更新灵活，不用重新训练模型，可追溯和解读模型的知识来源，也方便控制权限。在EDA这样的专业领域，规范、文档、历史案例都在持续更新，用RAG随时更新知识库，比微调一个旧数据训练出来的模型要可靠得多。我自己搭过一个简单的内部知识库系统，把团队的历史时序收敛经验、验证环境搭建案例、常见bug与解决方案整理成索引文档，大模型回答问题的准确性明显提升，新人上手速度也快了不少。
微调更适合相对稳定的语言模型任务，比如专有代码生成风格、内部RTL编码规范。如果你希望模型生成的SystemVerilog代码严格符合公司模板风格，小规模微调是可行的。但微调需要高质量标注数据、训练GPU资源和持续的模型维护，前期投入大，效果也不容易评估。我的建议是：先做RAG，解决“知识缺失”的问题；等业务验证了价值，再考虑针对高频场景做微调。这个顺序，踩坑最少。
4. 实操记录：把大模型接进验证流程的完整过程
理论讲了不少，说说我自己做的一个具体项目。某图像处理Demo项目的验证环境，因为设计代码量不大、模块耦合度适中，我拿它做了个实验：让大模型深度参与UVM验证环境的搭建和testbench生成。整个流程走下来大约花了三天，效果超出了预期，也暴露了不少问题。
4.1 环境准备与模型选型
硬件环境方面，我申请了一台8卡A800的服务器跑私有大模型。模型选型上，对比过好几款开源模型，最终选了代码能力较强、上下文窗口比较充裕的一个——因为用RAG需要把大量验证规范塞进上下文里，窗口太小的话，塞完规范就没地方放RTL代码了。
软件开发环境是常规的Linux工作站+Verilog仿真器，结合开源的波形查看工具。整个架构分三层：底层是私有化部署的模型服务，中间是RAG检索服务，上层是我写的一个交互脚本，用来把自然语言指令翻译成模型调用、把RTL代码切片喂给模型、再把模型输出整理成文件。
这个交互层是整个方案的灵魂。因为大模型单次能处理的token数有限，而一个RTL文件可能很大，直接整个塞进去不现实。我的做法是：先用脚本把RTL代码切成模块级的文件，再用正则提取出端口列表、always块、赋值语句等关键信息，连同自然语言描述一起作为Prompt的一个部分，模型基于这些内容生成对应的UVM代码。
4.2 三步走：切场景、写提示词、迭代修正
整个实验我分三步走。第一步是切场景，把验证需求拆解成若干独立的场景，每个场景对应一个验证目标，比如“验证fifo在背压条件下不丢数据”“验证读写同时发生时优先级正确”。明确场景是后续一切工作的基础。
第二步是写提示词，这是目前最考验功力的环节。好的提示词不是简单说“请生成一个UVM testbench”，而是要告诉模型：设计的功能是什么、接口信号有哪些、时序关系是什么、你期望的验证场景是什么、你希望用什么风格写。我最后使用的提示词模板大致是一个结构化格式，其中“设计功能”“接口信号”“待验证场景”“生成要求”是一个比较实用的框架。比如我让它生成一个UVM sequence，提示词里会写明“设计有一个fifo，深度16，当水位线高于12时输出高电平预警信号，backpressure信号有效时必须暂停写入”。模型收到的信息越精确，生成结果越可用。
第三步就是迭代修正，这是最费时间但价值最大的一步。第一轮生成出来的代码，编译之后通常有一堆语法错误和接口不匹配。把编译报错信息回给模型，它通常会自己承认“这里的位宽定义有误”“这个变量应该声明为logic类型”，然后重新生成修改后的完整代码。有个典型的例子，模型生成的monitor里用了“@(posedge clk)”来采样数据，但协议要求数据在负沿变化、正沿稳定，这样采样没问题；问题在于它同时也在posedge里采样了backpressure信号，而这个信号是异步变化的，导致仿真里出现了建立时间冲突。我没有直接改代码，而是把这段波形图特征用文字描述给模型：“backpressure信号与时钟没有固定相位关系”，它就能理解并改用“@(negedge clk)”来采样这个信号。来回迭代了四五轮之后，编译仿真全部通过，覆盖率从零开始跑，最终功能覆盖率达到了86%，补了几个边界case之后过90%。
4.3 有些关必须人类来把
这个过程让我印象最深的一点是：模型生成验证代码的效率和规范性确实好，但它没有“验证的直觉”。它不知道什么场景最容易出bug，不知道什么配置最可能暴露设计缺陷。它可以帮你写“验证代码”，但“验证什么”这个决策，最后还得靠人来定。
比如我让它验证FIFO的“almost full”标志，它生成的sequence只在“水位线达到12”的情况下触发了一次写入，导致该标志在仿真过程中反复翻转。这确实测到了标志位功能正常，但没测到“标志拉高后，如果又连续写了两拍，是否会溢出”这个更有价值的边界场景。如果你指望大模型帮你把所有关键corner都覆盖到，不现实。
我在实验中发现，解决这个问题最有效的方式是：让大模型生成一份覆盖场景清单，你作为工程师基于对设计逻辑的理解来审核清单，补上模型遗漏的、但你知道的高风险场景。然后再让模型为这些场景逐个生成sequence。这样人和模型各司其职，才能把覆盖率做扎实。
4.4 RAG知识库的接入与调参
在这个实验里，RAG知识库起了很大作用。我把公司内部的验证环境搭建规范、常见错误写法与修正建议，以及UVM基础教程整理成了几个纯文本文档，建立索引。当模型生成代码时，会先检索与当前任务相关的知识片段，拼进Prompt后作为参考。
我的调参经验是：知识库文档数量不用多，质量比数量重要。刚开始我放了几十份文档进去，检索混乱，模型不知道引哪份才好，回答质量反而下降。后来精简到每类场景只保留一份权威文档，加上一份常见问题FAQ，效果立刻改善。另一个关键参数是检索返回片段数，个人经验是取3到5条就够，太多会让上下文过长、模型注意力涣散，太少又覆盖不了关键信息。另外提示词里要明确“必须优先参考检索出来的规范”，否则模型容易被“带偏”，凭自己的预训练知识回答，忽略知识库里的公司特有规范。
5. 大模型在EDA里的能力边界：哪些事它真做不了
前面讲了不少能做的，现在必须泼泼冷水。大模型不是万能的，尤其在EDA这种安全要求极高的领域，它的能力边界非常清晰。搞不清这些边界，项目迟早要翻车。
5.1 形式验证：模型的“自信”救不了它
最典型的例子是形式验证。形式验证的本质是数学证明，要穷举所有输入状态验证设计等价性。大模型擅长的是“近似推理”和“模式匹配”，但它做不了“穷举证明”。你让模型判断两个网表是否等价，它可能基于结构相似性给出“看起来等价”的结论，但三个隐藏的、只在特定状态组合下出现的不等价点，模型根本发现不了。后果就是，你把错误的网表拿去流片，一回来就冒烟。
更危险的是，大模型在回答这类问题时往往非常自信。它不会告诉你“这个我无法证明”，它会洋洋洒洒写一大段看起来很专业的分析，然后给出一个确定性结论。如果不是有经验的工程师警觉地去验证，很容易被带沟里去。所以在形式验证、等价性检查这类场景里，大模型只能理解需求、生成形式化验证的断言代码，最终的等价性证明必须交给专用的形式化工具。
5.2 精确时序数值：模型学不会“更”与“最”
另一个大模型做不好的事是精确的时序数值计算。一个单元的rise delay在特定电压、温度和工艺角下的精确值，取决于工艺库里的查找表和SPICE仿真结果，这些数值不是预训练数据里能涵盖的。模型可以给你一个“大概在几十到几百皮秒范围内”的estimate，但对时序收敛没有任何实际帮助——你需要的是精确到小数点后几位的具体数值，而不是一个大致区间。
这方面我见过一个很典型的失败案例。有人让模型估算一条关键路径在特定跑完CTS之后的arrival time，模型给了一个乐观估计，比实际值少了将近一倍。工程师如果盲信这个数值去评估时序余量，后果不堪设想。芯片设计里没有“大概”这两个字，每个数字都对应真实的物理延迟。
工具配置命令的精确参数也一样。不同版本的EDA工具，命令名、option名和格式都有差异，模型基于预训练数据给出的命令在旧版本上可能对，但换成新版本就容易报错。所以涉及具体工具的精确命令，正确做法是让模型从官方文档里检索，而不是让它凭记忆生成。
5.3 设计意图推断：复合逻辑模型的盲区
大模型在阅读自然语言和常规代码方面很强，但对复杂的、包含大量异步逻辑或模糊设计意图的RTL代码，理解能力有限。它看一个模块代码，可以帮你总结功能，但如果模块的状态机有几十个状态、每个状态有复杂的转移条件，或者代码里包含了大量为了满足特定时序约束而做的非直观表达，模型很容易误判设计意图。
我之前遇到一个模块，为了保护跨时钟域的数据一致性，写了一个“在特定条件下重复采样一拍”的逻辑。模型把这个逻辑识别为“数据同步电路”，但实际上它是一个规避亚稳态的特殊设计，它真正的意图是“用牺牲一拍的代价换取CDC路径的确定性”。模型给出的重构建议如果被采纳，CDC问题就出来了。这种隐含的设计意图，大模型很难从纯代码层面准确推断，必须依赖资深工程师的背景知识。
6. 数据安全、评估标准和团队协作：落地前得想清楚的三件事
前面讲了很多技术上的细节，但大模型在EDA里的落地，还有几个非技术层面的问题必须想清楚，否则技术上全对，项目也可能死在合规或组织协作上。
6.1 芯片公司的数据红线怎么划分
芯片公司的数据安全比一般软件公司要严格得多。RTL代码、工艺库参数、时序约束、功耗报告，这些都是核心资产。公司里的EDA服务器通常有严格的权限管控和审计日志。大模型接入之后，数据流向变得复杂了——工程师在对话里贴一段代码，这段代码会不会被模型服务方看到？日志里会不会留下代码片段？这是法务和IT最关心的问题。
我的建议是，在公司内部画一张数据风险分级表和AI使用边界表，把数据分成公开、内部、机密、绝密四类，明确哪些可以给大模型处理、哪些必须去除敏感信息后才能处理、哪些绝对不允许。把表格发给团队，让每个人心里有谱。
区分标准参考如下。公开类数据，如公开协议文档、开源代码，可以放心用任何模型处理。内部类数据，如不包含公司核心算法的测试代码、匿名化的设计数据，可以在内网私有化模型里处理，但要避免员工直接粘贴到外部API。机密类数据，如含完整RTL代码的文件，不仅必须在私有化模型里處理，还要有审计日志，记录谁在什么时间把什么数据喂给了模型。绝密类数据，如流片级别的GDSII版图或未公开的工艺库文件，原则上不应当让任何大模型接触，这类数据一旦泄露，影响是致命的。
6.2 大模型生成结果的质量怎么评估
大模型生成的是代码、报告、建议，你怎么判断它“好”还是“不好”？在传统软件工程里，你有一堆测试用例，跑得过就是对的。但大模型生成的RTL代码，没有预先写好的测试集，你只能靠编译仿真、覆盖率数据和人工审查来评估质量，这些手段都慢且主观。所以建立一套针对大模型生成内容的质量评估标准，非常必要。
我建议从三个维度来评估：正确性、可读性、实用性。正确性最直接，代码能否通过编译和仿真，报告里的结论与真实数据是否一致，建议是否可行。可读性指代码风格是否规范、是否有清晰的注释、报告总结是否简洁明了。实用性考察的是生成内容是否对实际工作有帮助，比如覆盖率提升是否明显、时序总结是否准确命中关键问题。把三个维度拆开打分，团队内部定期review，才能判断大模型到底是在帮你还是在拖你后腿。
我自己的经验是：早期的项目尽量让大模型多输出，然后人工严格review，积累足够多的典型案例，形成团队内部的质量基线。等模型在特定场景下输出质量稳定了，再逐步放开。不要一上来就完全信任模型输出，那样风险太高。
6.3 数字化团队的角色转型
大模型进入EDA之后，受影响的不只是工具和工作流，还有团队的角色和分工。以前，验证工程师的核心竞争力是“会写UVM代码”“会搭验证环境”；以后，当大模型能自动生成大部分常规验证代码时，这些基础技能的重要性会下降，取而代之的是“会定义验证范围”“能设计高效的验证策略”“能审查模型生成的验证质量”这些更高层次的能力。
我并不是说大家不用学SystemVerilog了，而是说，常规的、模板化的编码工作确实会被替代，但验证的核心——理解设计意图、设计验证策略、评估验证完备性——依然需要人类来完成。换句话说，大模型让“写代码”这个动作变便宜了，但“想清楚代码要做什么”这个动作变得更值钱了。
团队配置上，未来很有必要增加一个新的角色：AI/EDA交叉工程师。这个人既要懂芯片设计流程，又要懂大模型的部署、调优和评估。他负责把大模型接入团队的工作流，维护知识库，评估模型输出质量，以及培训其他工程师如何有效使用大模型。这类角色目前市场上极其稀缺，如果你所在的公司有意识培养，建议尽早入手。
7. 从实验到大规模落地：我的个人实践体会
前文聊了很多理论和实践，但这几年真正让我形成判断的，还是那些踩过坑之后的体会。最后就把实操层面的经验和教训坦白交代一下，给你做个参考。
先说一个最有价值的认知：大模型进EDA，最忌讳贪多求全。很多人上来就想要一个“全流程AI助手”，既能写代码又能修时序又能布版图。想法很好，现实是每个环节的成熟度差异很大，强行整合只会得到一个每件事都懂一点但每件事都做不好的四不像。我的建议是，单点突破，选择一个最痛、最容易被量化的场景切入，比如“验证代码生成”或者“时序报告分析”，在内部做出标杆案例，让团队看到实际效果，再逐步扩大。
其次，建立一个“优秀Prompt案例库”这个动作，值得每个团队认真做。你可能会觉得，Prompt有什么好积累的？等你真正用起来就会发现，同样一句话，不同工程师写出来效果差很多。一个高水平的Prompt，不只是描述清楚任务，它还会主动约束模型的输出格式、注入领域限定条件、给出预期结果的示例。把这类高质量Prompt沉淀下来，做成团队共享的知识库，新手也能快速产出水准以上的结果。这跟过去老工程师总结“这条路径要用这种脚本修”是一样的逻辑，只是载体从脚本变成了Prompt。
第三，一定要区分“demo好看”和“生产可用”。我们在内网部署私有模型后，第一周各种惊艳，覆盖率提升、代码生成快，感觉AI马上要取代半个验证组了。但到第二周，模型在边界case上的幻觉问题开始暴露、在长上下文场景里的性能下降，才让我们回到现实。生产环境要求的是稳定、可预期、可追溯，而目前大模型在这三方面还有很多不足。所以我现在做方案设计时，都会刻意保留“人类把关环节”——凡是生成内容，必须有工程师确认后才能进入正式流程。这不是对AI不信任，而是对芯片工程的基本敬畏。
最后分享一个我个人比较看好的方向：大模型+形式化验证的结合。大模型可以基于设计意图，语义化生成SVA断言，帮助工程师写出更全面、更贴合spec的断言。断言覆盖率高了，形式化验证的效率会大幅上升。这是目前我看到的大模型和EDA结合中，少有的能同时发挥“大模型理解力”和“传统工具精确性”的场景。如果你所在团队有形式化验证方面的积累，值得在这个方向上多做投入。
大模型正在改变EDA，这一点已经没什么好争论的了，但它到底会把EDA变成什么样，取决于我们这一代工程师怎么驾驭它。把它当成放大器，它能让你过去积累的经验和判断力产生十倍的价值；把它当成替身，它就会在关键的地方给你挖坑。所以我的态度是：拥抱它，但保持清醒。用大模型去处理那些重复、琐碎、消耗精力的事，把你自己解放出来，去思考更高层次的架构问题、验证策略和团队协作——在大模型时代，工程师最值钱的恰恰是AI最不擅长的那些事：判断和决策。
