AI 不是对手,是工具!记录一次 claude,+EDA 仿真验证实测过程

1. 反向生成验证计划：无 SPEC 前提下，让 AI 读取 RTL 代码提取验证点，直接输出验证计划；

1. 冒烟测试 demo：指令 AI 解析仿真目录下的 Makefile 和环境配置，快速跑通冒烟测试；

1. 测试用例开发：按我定义的宏格式，AI 自动生成验证计划对应的全部测试用例；

1. 回归脚本编写：AI 根据环境特点，生成可直接执行的回归脚本；

1. 回归测试与迭代 debug：

• 首轮回归出现失败 case，AI 直接生成第一版测试报告；

• 连续 3 轮指令 AI debug→修复 case→重新回归，每一轮失败率都显著下降；
• 覆盖率优化：发现模式 C 地址偏移覆盖率仅 50%，指令 AI 分析原因并新增 2 个针对性 case，最终覆盖率拉满至 100%；
• 漏测补全：最后人工发现 “非对齐地址” 未测试，补充指令后 AI 快速新增对应 case。

二、一顿操作总结下来：这 3 点效率确实高

全程体验下来，AI这 3 点让我感受到强烈的 “危机感”：

以前自己读 RTL、提验证点、写用例，至少半天起步；AI 能快速定位 RTL 核心逻辑，按我定义的宏格式直接生成用例，单个模块的用例交付仅需几分钟，还能自动调用宏定义，完全不用手动调整格式。

从验证计划→用例→回归脚本→debug→覆盖率优化，整个流程仅用 1-2 小时（环境已就绪的前提下），以前人工做按 天计算，尤其是回归脚本编写和重复 debug 的环节，简单的debug AI效率确实可以。

没有提前训练 AI，也没写 Skill 脚本，仅通过自然语言描述我的需求（比如 “按这个宏格式生成 case”“修复这个 fail 的原因”），AI 就能精准匹配我的使用习惯，输出的代码可直接集成到现有环境。

三、AI 的 “短板”：目前还离不开人工把关

虽然 AI 效率拉满，但此次测试也暴露了不少问题，验证工程师的 “不可替代性” 依然存在：

四、验证工程师的反思：AI 是工具，不是对手

这次粗糙的尝试，确实让我感受到了 AI 对验证的冲击 —— 重复的用例编写、回归脚本、基础 debug 等工作，AI 能做得又快又好，大幅降低了 “机械性劳动” 的成本。但这并不意味着验证工程师会失业：

AI 的发展确实在倒逼我们成长，与其焦虑 “会不会失业”，不如思考 “如何用好 AI”。未来的验证工作，大概率是 “AI + 人工” 的协同模式 ——AI 负责 “执行”，人工负责 “决策”，两者结合才能实现验证效率和质量的双重提升。

最终失业不失业也不是自己能决定的，也不用想太多，踏实进取走好每一步就行了。

后续计划：尝试学习编写Skill 脚本，给 AI 更明确的约束和引导，看看能否实现更深度的自动化验证，敬请期待～