前两天我反复琢磨一个问题：如果 AI 写代码的能力越来越强，验证工程师最该焦虑的到底是什么？
是 AI 能写 sequence 吗？是 AI 能自动生成 assertion 吗？还是 AI 能不能搭一套完整的 UVM 环境？
想了一圈，我觉得这些都不是关键。
真正值得关注的，是 AI 能不能帮我们把验证计划（testplan）做得更完整。写代码在很多情况下只是执行，但 testplan 不一样——它决定你到底要验证什么、不验证什么、先验什么，以及整个设计里最容易出问题的地方在哪里。
说句大白话：testbench 是手，testplan 才是脑子。如果一名工程师只会写代码，却不清楚为什么要写这些测试用例，那他很容易被工具替代。但反过来，如果一个人能拆清模块风险、列全验证点、想透各种 corner case，那 AI 不但抢不走他的位置，反而会成为他能力的放大器。
1. 小白最容易低估的就是 testplan
刚接触验证那会儿，我也不怎么把 testplan 放在心上。总觉得它不就是一个 Excel 表格吗？写几条功能特性、列几个测试用例、标一标 pass 或 fail，看起来没什么技术含量。
后来才慢慢明白，根本不是这么回事。
真正的 testplan，绝不是“列清单”，而是你对设计理解的直接体现。比如同样面对一个 FIFO，最基础的验证点是：写进去能读出来；满了不能再写；空了不能再读；复位后状态正确。这些当然得测，可这些顶多算入门。
再往深里想，问题就变成：full 边界上同时 push 和 pop 会怎样？empty 边界上同时 push 和 pop 会怎样？从 almost full 跳变到 full 有没有隐患？读写指针绕回时会不会出错？复位正好插在某笔传输中间会引发什么？连续背靠背操作会不会丢数据？各种 flag 和内部计数器是不是始终一致？
这时候你才会发现，testplan 做的其实不是文档工作，而是在反复追问一个极其核心的问题：这个设计，最可能在什么地方出错？ 这，才是验证工程师真正开始进阶的地方。
2. 为什么 AI 特别适合辅助写 testplan？
最近不少关于大语言模型和芯片验证的研究，重点都放在生成测试用例、生成 assertion、辅助提升覆盖率这些方向。比如 VerilogReader 这类工作，是让模型读 Verilog 代码，帮忙生成更容易打到未覆盖分支的测试；而 AssertLLM 则是从规格文档里提取信息，再自动生成硬件验证用的 assertion。
这些探索背后，其实有一个共同的指向：AI 正在尝试理解“规格、代码、验证目标”三者之间的关系。而 testplan，恰好就卡在这个位置。它不像 UVM 代码那样纯偏实现，也不像 spec 那样纯偏需求。它处于中间那层翻译——把自然语言描述的需求，转换成可执行、可检查、可覆盖的验证目标。
这件事，天然适合交给 AI 来辅助。比如，你可以把模块 spec 直接丢给 AI，让它先帮你列出一版内容：功能点、异常场景、边界条件、协议检查点、覆盖率建议、assertion 候选位置，甚至可能被你遗漏的 corner case。这当然不代表它列得一定对，但它能帮你快速打开思路，尤其是在面对一个全新模块、不知道该从何下手的时候。
3. 但 AI 写 testplan，有一个致命缺陷
它太擅长写“看起来非常完整”的东西了。这既是优点，也是最大的陷阱。
你让 AI 给一个 APB slave 写 testplan，它大概率能给你列出：读写寄存器、非法地址访问、复位测试、背靠背传输、等待状态、错误响应、随机测试等等。乍一看挺像那么回事。
但项目里真正容易翻车的地方，往往是这些：某个寄存器 bit 写 1 清 0；某个状态位读一次就被自动清除；某组配置只能在 idle 状态下修改；某两个字段绝对不允许同时打开；某个中断只在边沿触发，而不是电平触发；复位后收到的第一个传输存在特殊限制。
这些细节，AI 未必能凭空知道。所以，用 AI 写 testplan，最可怕的不是它写错了，而是它写得太像对的，以至于你轻易就信了。
这也正是验证工程师绝不能只做复制粘贴的原因。你必须把 AI 生成的 testplan 当成“初稿”，而不是“最终答案”。
4. 未来价值拐点：从“写得快”变成“审得准”
我觉得，验证岗位以后会慢慢分化。
一部分偏向执行的常规工作，会越来越多地被 AI 接管，比如：生成定向用例、补充覆盖率、整理日志、写脚本、生成 assertion 初稿、把文档转成检查清单。这些活儿，AI 干起来又快又不会喊累。
但另一类更高阶的工作不会消失，反而会更加珍贵：判断验证目标是否真正完整；判断覆盖率的意义到底在哪里；判断 assertion 是否真实约束住了协议；判断 AI 生成的测试用例有没有漏掉关键风险；判断一个 bug 暴露出来的究竟是局部错误，还是架构层面的问题。
换句话说，未来验证工程师的核心能力，或许不再体现为“我能不能从零开始写一堆代码”，而是：我能不能判断眼前这堆验证内容，到底靠不靠谱。
这话听起来不怎么燃，却很现实。AI 越是擅长生成内容，人就越要擅长审视内容。
5. 初学者可以怎么练？
我不建议一上来就搞复杂的 SoC，也别急着追什么多智能体架构。可以先找一个最普通的小模块来练手，比如 FIFO、arbiter、APB register block，或者 UART 接收端，这些都可以。
练习方法很简单，一共四步：
第一步，先别问 AI，逼自己独立写出 10 条验证点。
第二步，再让 AI 写一版。提示词可以这样组织：
你是芯片验证工程师。
请根据下面这个模块说明，生成 testplan。
要求按功能测试、边界测试、异常测试、协议检查、覆盖率建议分类。
不要写 UVM 代码，只列验证目标和检查点。
第三步，把两版放在一起对比。看看 AI 帮你补上了哪些点，你又敏锐地发现 AI 漏掉了哪些真实风险。
第四步，也是最关键的一步，把每一条验证点都改写成“可检查”的形式。不要再写“测试 FIFO full”这种模糊描述，而要写成：“当 FIFO 从 depth-1 写到 depth 时，full 信号应在下一拍正确拉高；在 full 状态下，如果没有 pop 却继续 push，存储内容和写指针不应发生任何变化。”
一个验证点如果不能被检查，它就只是一句口号。
6. 今天的结论
AI 走进芯片验证领域，不光是帮我们写 testbench，更深层的冲击是，它会迫使验证工程师重新审视自己的价值。
如果一个人只是照着别人写好的 testplan 来补测试用例，那这类工作确实会因为 AI 的到来而变得不那么稀缺。但如果一个人能读懂 spec、拆清风险、设计覆盖策略，并且有能力判断 AI 产出的质量，那他只会变得更强。
所以，验证小白下一步要练的，不是背更多 API。
而是开始锻炼一种能力：把模糊的需求，拆成清晰、可执行、可检查的验证计划。这件事，AI 可以帮你，但最后拍板的那个人，必须是你自己。
你觉不觉得，验证新人最难补齐的能力究竟是哪一块？是写测试代码本身，还是看波形，是 debug，还是写 testplan？
在 云栈社区 里，我们也常常聊到，未来的技术竞争力正在慢慢从“手快”转向“眼毒”——能看穿 AI 输出背后的疏漏，才是真本事。如果你对“用 AI 给一个 FIFO 写 testplan，然后逐条挑错”这个实操练习感兴趣，后面我可以专门做一期内容，带大家一起来审一审 AI 的作业。
发表于 2 小时前
|
查看: 4|
回复: 0
