芯片工程师还有多久会被AI替代?

验证工程师用AI两个月后的真实体感

作者：福尔摩芯｜芯片验证工程师的日常 · 第2期

一、落地两个月，我们经历了什么

3月份公司内网接入Claude后，部门的使用状态大致经历了四个阶段：

Token考核 → 落地焦虑 → 大炼钢铁 → 冷静反思

这不是我们独有的现象——几乎所有接入大模型的团队都在重复这个周期。新鲜感驱动的狂热消退后，真正的问题浮出水面：这东西到底能在芯片验证的哪个环节产生实际价值？

两个月下来，有三个观察值得注意：

1. 部分方向确实跑通了，AI在特定场景下能提效

2. 模型选择的影响远超预期——换一个模型，体验可能是天壤之别

3. AI当前能做的事情，边界依然很清晰

关于第二点，很多人把"AI不行"归结为技术不够成熟，但其实很多时候是模型选错了。通用大模型和专门针对代码/工程场景优化过的模型，在Verilog这种小众语言上的表现差距可以非常大。与其说AI不行，不如说我们还没找到对的模型。

二、我们探索的四个方向

1. LLM Wiki知识库

把团队内部的流程文档、设计规范、验证方法论喂给大模型，搭建智能问答系统。核心价值在于降低新人上手成本——以前翻文档翻半天的问题，现在一句话就能拿到答案。

但有一个根本性的问题：知识库的准确性谁来保证？ 大模型的幻觉问题在专业领域是致命的。如果它给出一个错误的UVM配置建议，工程师可能要花更多时间去排查。所以现阶段更适合作为"快速检索+初步参考"，而不是"权威答案来源"。

2. 工具手册炼化

EDA工具的手册动辄几千页，这是目前最稳定、最实用的方向。让AI先消化VCS/Xcelium/Verdi的手册，后续工程师问具体命令和参数时，响应速度和准确率都不错。

本质上这是把大模型当作一个"永不疲倦的技术文档助手"。门槛低、见效快、风险小，适合作为团队AI落地的第一个切入点。

💡 延伸思考： 这个方向还有一个有趣的连锁反应——EDA公司的AE以后的工作可能会更多地转向解决工具bug，而不是工具support。 当工程师可以直接从AI获得工具使用指导时，AE传统的"教用户怎么用工具"的价值就被削弱了。AE的核心竞争力将变成更深的底层能力：定位工具本身的缺陷、推动修复、优化工具链。换句话说，AI吃掉的是AE的"重复性支持工作"，留下的是"需要深度理解工具内部实现"的工作。

3. 创建Skill操作EDA自动化验证

野心最大的方向——让AI直接操作EDA工具，自动跑仿真、看波形、做调试。

理论上的价值巨大：如果AI能自动执行回归测试、分析coverage、定位corner case，验证工程师就能把精力集中在更高层的策略制定上。

但现实很骨感——不稳定的成功率意味着什么？ 意味着你不能信任它的输出，每次都需要人工复核。而验证工作的核心恰恰是"可信度"——一个不能被信任的自动化工具，价值大打折扣。失败的原因可能是多层面的：EDA工具的CLI接口不稳定、AI对工具状态的理解有限、或者验证场景本身的复杂性超出了当前模型的处理能力。

4. 创建标准Agent编排流程

把验证任务拆解成标准化的Agent工作流，让AI按步骤自动执行。这其实是目前学术界和工业界都在探索的方向——用Agent来编排复杂的工程任务。

但芯片验证的特殊性在于：每一步的判断都依赖深厚的领域知识。"这个波形异常是否需要关注""这个coverage gap是否值得追"——这些决策不是简单的规则能覆盖的。Agent编排的前提是每一步都是确定性的，而验证工作中大量环节是非确定性的。

三、核心痛点：为什么AI在芯片领域特别难

痛点一：训练数据的结构性缺失

这不是"AI不够聪明"那么简单的问题。Verilog、SystemVerilog、UVM在大模型的训练数据里占比极低。 Python有数以亿计的开源代码和教程，而SV/UVM的资料大多锁在公司内网或付费平台上。

所以你让它写Python可能比大多数工程师强，但写一个标准的UVM Testbench——constraint的语法、sequence的启动方式、factory的覆盖机制——每一个细节都可能出错。而且是看起来对、实际不对的那种错，比明显的语法错误更危险。

痛点二：EDA工具操作的不稳定

给AI加上看波形、debug、trace的Skill后，理论上它能自动完成很多验证任务。但成功率很不稳定——这意味着每次都需要人工兜底。

不稳定背后的原因可能是多层面的：EDA工具本身不是为AI设计的（CLI接口不稳定、输出格式不统一、错误信息不友好）；AI对工具状态的理解有限（不知道当前仿真跑到哪一步、不知道上次操作有没有成功）；以及验证场景本身的复杂性——一个看似简单的debug任务，可能涉及多个模块的交互、时序关系、约束条件。

痛点三：长上下文的"失忆"问题

验证场景的context往往非常长——一个模块的spec、代码、波形、log加起来，轻松超过模型的上下文窗口。聊着聊着模型就开始"忘了"前面说过什么，输出前后矛盾。

这个问题在技术上是有解的——更长的上下文窗口、RAG、memory机制等。但在实际验证场景中，关键信息往往分散在多个文件和多个调试阶段中，如何有效地检索和组织这些信息，本身就是一个难题。

更危险的是"失忆"的反面——模型自信地给出错误分析。它不知道自己不知道，反而表现得很确定。这比"我不确定"更可怕，因为工程师可能会被误导。

四、更深层的思考

AI替代的不是岗位，是任务

很多人讨论"AI会不会替代工程师"时，用的是一个错误的框架。AI替代的不是"岗位"，而是"任务"。

一个验证工程师的工作可以拆解成：

任务类型	AI替代可能性	当前状态
查手册、查命令	高	已可用
写简单脚本/约束	中高	基本可用
写UVM Testbench	中低	需要大量修正
分析波形、定位bug	低	不稳定
定义验证策略	很低	接近不可用
理解spec、判断corner case	几乎不可能	短期无望

所以更准确的说法是：AI正在蚕食验证工程师的"低价值任务"，但"高价值判断"仍然牢牢掌握在人手里。 问题是，当低价值任务被自动化后，剩下的高价值任务是否需要那么多工程师？这才是真正值得焦虑的地方。

EDA生态的三条路

1. EDA大厂拥抱AI——Synopsys、Cadence已经在做了（DSO.ai、Jasper AI）。用过的人都懂，体验一言难尽。大厂的动作慢、定价贵，且倾向于把AI做成"黑盒增值服务"

2. 开源社区发力——cocotb、Chisel、SpinalHDL等项目正在降低验证的门槛。但开源生态的碎片化也是一个问题

3. 新EDA创业公司——用全新的技术栈和AI-native的方法论切入。但芯片验证的壁垒极高，创业公司能否存活是个问题

这三条路可能不是互斥的——最终的格局很可能是大厂提供AI增强的商业工具、开源社区提供标准化的接口和框架、创业公司填补特定场景的空白。

成本的真实账

Claude Opus每人每天1000+元（纯token费用），这确实接近工程师人力成本。但这个比较有一个盲区：AI的成本是线性的，而工程师的能力有上限。

一个工程师一天能做的事情是有限的——8小时工作时间、注意力有限、会疲劳。而AI可以24小时不间断运行。如果AI能稳定地处理重复性任务，即使单次成本高，总产出/总成本比可能仍然优于纯人力。前提是"稳定"——而当前的稳定性还远远不够。