当AI开始帮你写RTL，芯片工程师的饭碗真的变了

芯片行业最近有点不一样了。

这次不是工艺节点又推进了，也不是EDA工具又出了新版本——而是越来越多的工程师开始用一种很奇怪的方式干活：跟AI说话，然后看代码从屏幕上冒出来。

说实话，刚开始很多人是抗拒的。写了十几年RTL，突然有人告诉你"你可以不用自己写了"，换谁都会觉得这话有点冒犯。

芯片的复杂度这些年涨得太快了。一个中等规模的SoC，IP模块少则几十个，多则上百个。验证的代码量早就超过了设计本身。每次做功能验证，光是搭环境、写testbench、跑回归就要花掉大量时间，真正思考架构的时间反而被压缩得很少。

来看一个具体的场景

假设你在做一个AXI4总线的仲裁模块，需要支持4个master，优先级轮询，同时要处理outstanding transaction。

以前的工作流是：查手册，设计状态机，一行行写Verilog，自己画时序图，再写testbench验证。整个过程可能要两三天。

现在的方式变了。工程师可以直接描述需求：

设计一个AXI4仲裁器，支持4个master， 采用优先级轮询，权重可配置， 需要处理最多8个outstanding transaction， 用SystemVerilog实现，加assertion

AI给出初版代码，工程师review、挑问题、提修改意见，来回几轮。关键的时间花在了判断上，而不是敲键盘上。

这是真的分工变了。

准确性是红线

这里要说一个很重要的点，很多文章都在吹AI有多厉害，但在芯片领域，AI生成的代码绝对不能直接用，这是基本常识。

AI经常犯的错误包括：时序约束理解不准确、跨时钟域处理有问题、对某些EDA工具的综合限制不了解、生成的always块里blocking和non-blocking混用。

这些错误不像软件bug那样好抓，跑仿真可能都过了，上板子才出问题。所以工程师对AI输出的审查标准，必须比review同事代码还要严格。

真正在变的是什么

表面上看是工具变了，实际上是工程师思考问题的方式在变。

以前很多精力花在"怎么实现"，现在更多要想"实现什么"和"为什么这样实现"。架构决策、功耗权衡、时序收敛的策略——这些判断AI现阶段还给不了，还得靠人。

有意思的是，这反而要求工程师的基础更扎实。你得看得出AI写错了哪里，你得知道一个仲裁逻辑为什么这样设计而不是那样设计。如果基础不够，AI给你什么你就信什么，出了问题都不知道往哪查。

所以那种"AI出现了工程师就没用了"的说法，逻辑是反的。AI让"会用但不懂原理"的人更容易暴露，让真正懂技术的人效率更高。

芯片工程是不太愿意叫自己RTL工程师，现在这个问题更复杂了——当你的工作从写代码变成描述需求、审查代码、做技术决策，你算什么？

工程师这个职业的核心从来都不是会用什么工具，而是对问题的理解深度和判断能力。工具一直在变，从原理图到HDL，从HDL到高层次综合，现在到AI辅助生成——每一次变化都淘汰了一批只会用旧工具的人，同时让真正懂技术的人解放出来干更重要的事。

这一次也不例外。

变化已经发生了，不适应的代价会越来越高。

芯片工程师职业成长（第四期）