我帮一家AI芯片公司用大模型写RTL，半年后他们回到了手工设计

去年有家做端侧推理芯片的初创公司找到我。他们想用大模型自动生成RTL，把3个前端工程师的开发周期压到1个月。我那时刚把制造业的AI质检项目勉强做到盈亏平衡，觉得自己什么行业都能用LLM砸出效率，就接了这单。那是2024年初，我们直接用GPT-4o（当时最新版）和DeepSeek-Coder-V2搞原型，心想半年后要么成为芯片设计自动化的标杆，要么就彻底认清边界。结果是后者——我们烧了将近200万人民币，最终生成的Verilog在验证阶段暴露出大量跨时钟域和状态机死锁问题，项目经理不得不在第5个月叫停，全组回到手工RTL设计。这段经历让我第一次近距离看到AI在芯片前端设计上的真实水位，也逼着我重新审视整个半导体设计工具链正在经历的、被过度吹嘘的“范式转移”。

客户想用AI替代3个前端工程师，却多赔上2个验证工程师的时间

他们的真实处境：不是缺人，是被“手工的确定性”锁死了

这家公司做的是12nm工艺下、中等规模的端侧推理SoC，主打智能摄像头场景，团队总共不到90人。前端设计组只有8个人，其中3个负责核心计算单元的新一代架构实现——一个包含自定义向量指令集、支持稀疏计算加速的流水线级模块。传统做法下，两个资深工程师写RTL，一个人负责lint和CDC初步检查，从spec到冻结代码需要14-16周。CEO想把这14周压到6周，因为流片窗口就隔了不到一年，竞争对手已经在送样了。

他们的痛点不是“我们不会写RTL”，而是每行RTL背后都绑着大量的手工验证资源。如果AI真能可靠地生成一个正确率80%以上的初始版本，哪怕后面改，也能省下几周。听起来很合理，我们就是这么掉进坑里的。

GPT-4o加检索增强生成的RTL，初次看到结果我觉得稳了

我们先用公司内部的Verilog代码库和部分开源项目（如OpenTitan、RISC-V相关实现）构建了一个轻量级检索增强生成流程。流程很简单：用LangChain把模块spec切片后，通过向量检索拉出相似实现，然后把spec、参考代码、风格指南打包发给GPT-4o，让它生成目标模块的RTL。为了控制幻觉，我们加了两层校验：先用Verilator做语法级检查，再跑一个基于规则的结构性lint。（延伸阅读：我们的工厂大模型被提示注入攻破三次后，我翻遍了攻防武器库）

第一次跑一个中等复杂的流水线仲裁模块——大概300行RTL——只用了4分钟。Verilator零错误。我们拿给客户的架构师看，他花了一个下午读了代码，说：“逻辑意图基本对，但没考虑同一拍里两个请求同时释放的边界，少一种仲裁状态的锁存。”改完这处后重新生成，又有新的问题。我们统计了一下，连续生成5次，每次都能修到语法和lint通过，但平均每100行代码里藏着1.2个微架构级逻辑缺陷，而且这些缺陷在仿真测试中很难用随机向量一次性覆盖。

下面是我们当时用来调用GPT-4o生成RTL的核心片段（简化后）。可以看到prompt里我们拼命加约束，但模型依然会漏掉隐含的时序约束和状态转换优先级：

import openai
import re

SYSTEM_PROMPT = """You are an expert RTL designer. Generate synthesizable Verilog-2001 code.
Follow these constraints strictly:
- Use only posedge or negedge clocks with asynchronous reset.
- All state machines must be coded as three-block style (next_state logic, state register, output logic).
- No inferred latches, all if-else must be complete.
- Avoid blocking assignments in sequential blocks.
- Add assertions for any multi-cycle handshake protocols.
- Explain any design decisions in comments."""

def generate_rtl(spec_text: str, reference_snippets: list[str]) -> str:
    ref_block = "nn".join(f"// Reference:n{s}" for s in reference_snippets)
    messages = [
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": f"""
Specification:
{spec_text}

Reference implementations of related modules:
{ref_block}

Generate the complete Verilog module, including timescale, I/O ports, internal signals, and all logic."""}
    ]
    resp = openai.c正确调用应为:
resp = openai.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    temperature=0.1,
    max_tokens=4096
)
raw = resp.choices[0].message.contentces[0].message.content
    # 提取Verilog代码块
    match = re.search(r"```verilogs*(.*?)```", raw, re.DOTALL)
    return match.group(1) if match else raw

看上去我们做了很多约束：禁止锁存器、三段式状态机、断言。但模型根本不理解“为什么”要这些约束。它会机械地套用三段式模板，却在状态机中忽略某些组合的状态跳转——比如从WAIT_REQ到WAIT_GRANT的过渡漏掉了一个data_valid信号的采样窗口，而这个窗口是架构师脑子里默认的“常识”，并没有写在spec里。这种缺口靠自动pattern匹配根本捕获不到，只能在深度仿真时暴露。

ROI倒挂：我们多烧了9周，验证团队跟着遭殃

项目一开始的ROI账本是：3个前端工程师 * 14周 = 42人周；AI辅助后预计1个资深工程师 review 加 prompt 工程，6周完成，相当于节省24人周。实际结果是：prompt 工程师加上代码审查，不断迭代修复，用了11周拿到第一个基本可用的模块。这还没完，因为生成代码风格不一致、局部逻辑不可预测，验证团队额外补了2个工程师做定向测试，多耗了约18人周才达到和手工RTL一样的覆盖率签名。（延伸阅读：AWS Inf2推理实例：号称成本直降40%，但我的压测数据揭示了什么投资委员会必须知道的事）

我粗算一笔账：硬件工程师的年薪加公司成本在80-120万区间，我们团队加客户的投入，总计多付出了近2个工程师年的人力成本。更灾难的是，时序收敛阶段发现生成电路的关键路径比手工版长了18%，后端团队不得不重新插流水级，相当于把前端的债还到了后端。

这次教训让我意识到：在RTL生成上，大模型能给你一个“看上去对”的起点，但离“工程上可依赖”还隔着一次完整的验证革命。而那场革命，现在根本还没到。

AI在芯片设计不同阶段的真实水位：有人吹上了天，有人还在旱地里刨食

我根据自己碰过的钉子，画了一张AI成熟度矩阵

为了不再被骗第二次，后来几个月我拉着两个之前做EDA的朋友，把当前AI在数字设计各阶段的真实能力和落地阻力整理了一遍。我们把“成熟度”拆成三个维度：技术可行度（算法是否稳定可用）、工程集成度（能否嵌入现有工具流）、商业验证度（是否有可复制的ROI案例）。下面这张表是我们基于十几个真实项目（我们自己踩过的、朋友公司的、公开可查的客户案例）整理出来的判断：

最让我意外的是，物理设计是AI渗透最深也最靠谱的环节，而离“写提示就能出芯片”最近的RTL生成，反而是商业ROI最差的一环。这种反差告诉我们：越接近物理实现的优化问题——布局布线本质上是数学优化——AI拿到的训练信号越强；而越接近人类设计意图、需要常识推理的部分，AI越容易装成“懂了”，实际上没懂。（延伸阅读：我看了三年企业AI账单：90%的大模型调用是在烧钱，SLM才是盈利的分水岭）

架构师暂时还不会被取代，他们的经验是不可压缩的知识

有人问我，AI能不能把架构师也替代了？我讲个细节你就能明白。我们那次在做计算单元微架构时，客户架构师判断必须在数据路径上插入一个轻量级压缩引擎，这个决策来自他对下游应用的负载特征（大多是稀疏的深度可分离卷积）的深层理解，spec里根本没写。AI从没“见过”这个新组合，它只能从已有的设计里做插值，不可能独立提出这种跨层的妥协方案。架构师的价值在于在需求还没完全形式化之前，找到一个能平衡物理限制、应用前景和市场窗口的折中。这是基于因果推理的决策，而大模型目前还是统计相关性的化身。

当然，这不意味着架构师不会变。未来架构师可能需要懂得怎么写高质量的spec和约束，让AI去填充底层细节。但“架构师”这个职位本身并不会消失，只是技能树会移向更高级的抽象和验证。

验证工程师会先于设计工程师面临结构性冲击

和多数人的直觉相反，我判断验证这个岗位会率先感受AI的颠覆。原因是验证的信号链比设计更闭环：你给一组测试，拿覆盖率数据回报，AI可以直接用这个信号优化策略。Cadence和Synopsys已经在高端产品里把强化学习用在覆盖率收敛上，能自动挖掘一些人类工程师忽略的corner case。我们自己也拿定制RL环境尝试过在一个验证项目上替代初级验证工程师的手动约束生成，结果覆盖率收敛速度快了35%，而且发现了一个罕见的状态机死锁——就是前面AI生成代码引入的缺陷，最后是人没查出来，机器查出来的。

验证工程师未来不会消失，但会从“写testbench、构造激励”转向“训练和调试AI验证策略”。需要的技能从Verilog+SystemVerilog转向Python+RL框架+对半导体特性的深层理解。这种转变会更早发生，因为它的ROI已经可以在局部验证模块上跑正。（延伸阅读：我在工厂大模型产线上烧了8个月，才发现运维得重学概率论）

巨头赌的是平台，创业公司赌的是某个环节的十倍效率差

Synopsys和Cadence不是在做玩具，他们在重塑自己的商业模式

去年Synopsys靠DSO.ai在三星和联发科几个大客户那儿做实了物理设计自动化优化的案例，Cadence用Cerebrus跟英特尔在先进工艺节点上死磕布局。两者最大的武器不是算法多漂亮，而是能直接读写自己的封闭数据库，把RL代理无缝嵌入到sign-off流程里。这种深度集成让任何第三方想插一根AI的针进来都极难。

初创公司如果还想着做一个“更好的大模型来生成RTL”，坦白说，我觉得路基本堵死了。不是因为技术不可能，而是因为没有商业闭环。你生成的RTL最终还是要在Synopsys或Cadence的仿真器上跑验证，如果质量不够，客户的切换成本高到无法接受。我身边有两家AI芯片设计工具创业公司去年都转型了：一家去做面向模拟电路的小模型自动调参，另一家转而做芯片设计日志的智能分析。后者反而活得不错，因为它解决的是人类根本不想看的那堆垃圾日志，切走的是一小块但明确有痛点的肉。

我们试过自研一个LLM做跨时钟域检查，烧了半年钱，然后放弃

这也是我第三个创业项目中另一个失败的尝试。我们觉得大模型既然能理解代码结构，是不是可以训练它去抓CDC问题？我们用开源RTL数据集加上内部标记过的问题库，微调了Code Llama 34B（当时最新版），花了大半年时间开发了一个原型。结果在客户的实际设计上，误报率高到工程师直接关掉我们的插件。每报10个问题，只有1个是真的，其余都是把正常同步逻辑误判为跨时钟域冒险。我们尝试加规则过滤，加结构分析，但根本问题在于：模型没有电路底层的时序图模型，它只能基于文本模式猜测，而CDC是一个物理问题，需要时钟树和相位关系才能判断。

这次失败比上次RTL生成更让我清醒：如果你不能把物理世界的信息输入给模型，就别想让它解决物理层的问题。纯软件方法在芯片设计的大部分阶段都会撞上这堵墙。（延伸阅读：Optimus搬运技术的ROI陷阱：99.2%精确度为什么还是让我在投委会上投了反对票）

从写代码到写提示？别天真了，中间还差一套可验证的知识系统

提示工程救不了芯片设计，我们需要“结构化设计意图”

很多人鼓吹未来芯片设计就是“写提示”，我认为这是一种危险的简化。你让架构师写“请生成一个支持128位宽、4路组相联、带预取功能的L2缓存控制器”，AI可能会给你一个看起来像模像样的东西，但它不会为你解释为什么选了一种替换策略而不是另一种，也不会告诉你它对下游latency的影响。真正的设计过程需要的是结构化、可验证的意图表示，比如把设计规约拆成时钟域约束、数据路径断言、状态转移表——这些形式化的东西才是AI能可靠处理的输入，而不是自然语言的散文。

我们后来在公司内部做了一个小实验：用SystemVerilog Assertions作为中间表示，先让工程师写SVA，再让AI去生成对应的RTL。结果质量立刻提升了一个台阶，逻辑bug下降约40%。这说明问题不在于AI不行，而在于我们给它的输入信息量严重不足。那种“对着spec写prompt直接出RTL”的路子，短期内看不到希望，因为人类语言本身就不足以承载芯片设计的全部信息密度。

新角色会出现：设计意图工程师和验证策略师

我看到的趋势是：未来芯片设计团队会裂变出两个新岗位。一个是“设计意图工程师”——把架构师的意图翻译成机器友好的形式化描述（SVA、时序约束、协议状态机等）；另一个是“验证策略师”——专门设计和训练AI驱动的高效验证闭环。这两个角色分别处在设计和验证两条线的上游，传统写RTL和写testbench的工作会逐渐被压缩成这些上游任务的从属部分。

这对人才结构的冲击是真实的：只擅长手工编写代码，却不能做形式化抽象的人，会面临很大的职业压力。但这不是突然发生，而是随着AI工具链成熟逐渐渗透的。

别被“无人化”的数字乌托邦骗了，我们要对抗的是设计的复杂性，不是工程师

回到最初那位CEO问我多久能实现“无人化数字设计”，我的回答是：在退休前也许能看到某些标准化模块达到接近零人工干预，但整颗SoC的端到端自动化，可能比自动驾驶L5还遥远。原因不是算力不够，而是设计本身是不断创造新未知的过程。每一个新架构、新工艺节点都会带来物理效应和设计规则的突变，AI模型如果没有持续的人类反馈信号去适应，就会迅速衰减成废铁。

过去两年我投入了真实项目去试探这波AI能重构多少芯片设计流程，结论是：最可信的回报在物理实现优化、验证加速和日志分析这些有明确反馈信号的地方。其他领域，尤其是前端RTL自动化，现在还处在“看起来很有希望，实际上非常烧钱”的阶段。对技术负责人来说，最务实的策略不是幻想一步到位，而是识别出那些AI可以马上带来30%以上效率提升的局部环节，先吃下来，再求扩张。

我依然相信AI最终会深刻改变芯片设计，但改变的方式将是渐进地替代一个个可优化的子任务，而不是炸掉整个方法论重新来过。真正懂行的创业者，应该盯着那些EDA巨头暂时看不上、但有高密度的痛苦点去扎。而不是跟风画“写一句话出芯片”的大饼，那个饼离我们还隔着无数个像我们这样烧过钱、然后默默退出的项目。