前面我聊过一个判断：AI 会写 Verilog，不等于 AI 能交付芯片。这句话听起来像结论，但落到工程里，真正的问题是：AI 写完 RTL 以后，谁来告诉它“对不对”？如果错了，谁来告诉它“错在哪一个周期、哪一组信号、哪一条约束”？
我最近连续看了几篇围绕芯片 AI Agent、SVA、TestBench feedback 和验证反馈学习的工作，感受很强：AI4EDA 的竞争，正在从“能不能生成代码”，转向“能不能进入验证闭环”。
图 1｜TestBench、Assertion、波形/日志和 Coverage/Formal，是芯片 AI Agent 看懂设计、判断对错、闭环修复的四类关键证据。
一、先用一个简单比喻：AI 写 RTL 是交作业，验证是在批改作业
如果把 RTL 看成学生交上来的答案，那么 TestBench 就是考场和考题，Assertion 是不能违反的判分规则，波形和日志是事故回放，Coverage 和 Formal 则是在追问：题目到底考全了吗？有没有盲区？
这也是很多人低估芯片 AI 工程化难度的地方。软件代码错了，很多时候可以跑单测、看报错、改一行再试；硬件设计错了，错误可能不在某一行代码，而在某几个周期之间的信号关系。比如 valid 提前了一拍，ready 晚了一拍，数据在握手没有成功时被消费了。代码静态看上去没问题，但波形一拉开，问题就藏在时间轴里。
二、TestBench：不是“测试脚本”，而是硬件设计的考场
很多人会把 TestBench 简单理解成“测试脚本”，但在芯片验证里，它更像一个完整考场：谁来发题，谁来驱动输入，谁来观察输出，谁来判分，谁来统计还没考到的场景。
Driver：把输入送进 DUT，相当于考官发题。
Monitor：把 DUT 的输出和内部现象记录下来，相当于监考。
Checker / Scoreboard：把实际输出和期望行为对比，相当于判卷。
Coverage：统计哪些场景考到了，哪些边界还没碰到。
举个最常见的 valid-ready 握手：如果 TestBench 只喂一个理想场景，AI 生成的 RTL 很可能“看起来能跑”；但一旦加上 backpressure、reset 中断、连续 burst、ready 抖动，真正的问题就会浮出来。
三、Assertion：不是注释，而是硬件行为契约
Assertion，尤其是 SystemVerilog Assertion（SVA），不是给代码写几句注释，而是把设计里“必须成立”的行为写成机器可检查的契约。
例如：FIFO 满的时候不能继续写；请求发出后，响应必须在规定周期内回来；复位释放后，状态机不能进入非法状态。工程师脑子里知道这些规则，但如果不写成 Assertion，仿真器和形式验证工具就很难自动帮你抓住违反规则的时刻。
近期的 AssertLLM2 就很有代表性。它不只是看大模型能不能写出一段 SVA，而是把问题拆成更接近工程验证的几层：语法是否正确、是否能证明属性、覆盖是否有效、能不能杀掉真实 bug。这比“看起来像不像 SVA”要严格得多。
图 2｜AssertLLM2 更关注 SVA 的工程有效性：不仅要能写，还要能编译、能证明、能覆盖、能抓 bug。图源：AssertLLM2, arXiv:2605.27472。
四、SpecAlign 的提醒：验证目标必须和设计意图对齐
SVA 写出来还不够，关键是它有没有对准设计意图。SpecAlign 这类工作提醒我们：验证规则和自然语言 Spec 之间也存在“语义对齐”问题。
这件事可以用一个简单例子理解：如果 Spec 说“黄灯至少保持 3 个周期”，Assertion 却只检查“黄灯出现过”，那工具可能全部通过，但它并没有验证真正的需求。
所以芯片 AI Agent 不能只会把中文需求翻译成代码。它还要能追问：这条 Assertion 对应哪一条 Spec？有没有遗漏边界条件？有没有把“至少”“最多”“必须”“直到”这些时序语义翻译错？
图 3｜SpecAlign 关注自然语言 Spec 与 SVA 之间的语义对齐，这正是芯片 AI Agent 需要补上的验证理解能力。图源：SpecAlign, arXiv:2605.25181。
五、波形：不是截图，而是硬件 debug 的事故回放
如果说 TestBench 是考场，Assertion 是判分规则，那么波形就是事故回放。很多硬件问题，单看 RTL 很难看出来；但一旦把 clk、rst_n、valid、ready、data、error 放到同一条时间轴上，因果关系就开始变清楚。
读波形可以很简单：先看复位是否释放，再看握手是否成立，然后看数据是否在正确周期被消费，最后看错误信号或 Assertion failure 在哪个周期触发。
图 4｜波形把“代码看不出来的问题”放到时间轴上：先看复位，再看握手，再看数据，最后定位错误触发周期。
图里的问题并不复杂：第 8 个周期附近握手关系开始异常，data 仍然被消费，随后 error 被拉高。对人类工程师来说，这是一段很直接的 debug 证据；对芯片 AI Agent 来说，如果它看不到这样的证据，就只能在 RTL 文本里反复猜。
六、Phoenix-bench 给出的直接证据：TestBench feedback 比文件定位更有用
Phoenix-bench 的实验很适合说明这个问题。它构建了来自 GitHub 开源硬件仓库的 benchmark，让 AI Agent 去修复真实硬件设计问题。结果里有一个信号非常清楚：仅仅告诉 Agent 相关文件位置，帮助有限；把 TestBench failure、编译错误、仿真日志这类反馈喂给它，解决率提升明显。
图 5｜Phoenix-bench 结果显示，TestBench feedback 能显著提升芯片 AI Agent 的修复解决率。图源：Phoenix-bench, arXiv:2605.15226。
这其实很符合工程常识。你让一个工程师修 bug，只告诉他“文件在这里”，他也要先跑仿真、看日志、拉波形；如果你把失败 case、报错位置、Assertion 触发点一起给他，他才有办法快速缩小范围。
七、Trace2Skill：把失败轨迹变成下一次修复的经验
Trace2Skill 这类工作则往前走了一步：它关心的不只是这一次修复成功，而是能不能把一次失败轨迹沉淀成下一次可复用的技能。
这很像真实工程团队的成长方式。一个资深验证工程师不是每次都从零开始猜，他会记住：某类 ready/valid 问题先看握手边界；某类 reset bug 先看复位释放后的第一拍；某类状态机 bug 先看非法状态和默认分支。
图 6｜Trace2Skill 的核心启发：把失败轨迹转化为可复用技能，让 Agent 从一次次验证反馈中成长。图源：Trace2Skill, arXiv:2605.21810。
八、把四类证据合起来，芯片 AI Agent 才开始像工程师
我更愿意把芯片 AI Agent 看成一个“带工具链的工程系统”，而不是一个会聊天的代码生成器。它需要的不是单点能力，而是一条闭环：理解需求、生成 RTL、生成验证、跑仿真、看失败、定位原因、修改代码、重新回归。
九、给团队选型的一张检查清单
如果企业、高校或者工程团队正在评估 AI4EDA 工具，我建议不要只问“能不能生成 RTL”。更应该问下面这些问题：
能不能根据 Spec 自动生成 TestBench，并覆盖 reset、边界、异常和 backpressure？
能不能生成 Assertion，并解释每条 Assertion 对应哪一条设计意图？
能不能读懂 compile error、simulation failure、assertion failure，而不是只把日志贴回来？
能不能分析波形，指出错误发生在哪个周期、哪些信号关系异常？
能不能修复后自动回归，确认老 case 没被破坏？
能不能把失败轨迹沉淀成团队可复用的规则、模板和知识？
一句话判断：能写代码只是助理，能解释验证证据，才开始像工程师。
十、我的判断：AI4EDA 的下一道分水岭，是验证可解释性
过去一段时间，大家很容易被“AI 自动写 Verilog”的演示吸引。但真正进入芯片工程之后，最难的不是生成第一版代码，而是把它带过验证，带过回归，带到可以交付。
所以我对芯片 AI Agent 的判断越来越明确：下一阶段真正拉开差距的，不是谁的模型更会补全语法，而是谁能更好地接入仿真器、形式工具、覆盖率系统、日志系统和波形分析链路。
后面我会继续沿着 AI4EDA、AI4Chips、AI4FPGA 和 Physical AI 这条主线，拆一些更具体的问题：比如芯片 AI Agent 如何真正接入 EDA 工具链，FPGA 为什么会变得更加重要，以及 AI 芯片从算力堆叠走向系统工程后，工程团队应该补哪些能力。
参考来源
AssertLLM2: Evaluating Language Models for SystemVerilog Assertions, arXiv:2605.27472。
SpecAlign: Aligning Natural Language Specifications with SystemVerilog Assertions, arXiv:2605.25181。
Phoenix-bench: Evaluating AI Agents on Real-World Hardware Design Problems, arXiv:2605.15226。
Trace2Skill: Learning Reusable Skills from Agent Traces, arXiv:2605.21810。