验证文档这活儿,早该交给 AI 了

回归跑完，屏幕上是空白的 verification report模板。这种场景在验证团队里循环上演了二十年，没人觉得光荣，也没人真想改。

现在有个能改的机会摆在面前，居然还有一堆人在讨论「AI 写的文档能信吗」。

先承认一件事：人写的文档也不怎么可信

反对 AI 写文档的常见理由是准确性。这个理由站不住，因为手写文档的准确性从来没有被真正验证过。

项目中期改了握手时序，验证文档里的那段描述有没有跟着改？某个 corner case 被删了，覆盖点表格里那一行还在不在？。文档和代码在项目第三周就分道扬镳，后面全靠交付前一周集中补作业维持体面。

 plan 里写着：验证 FIFO 满时的反压行为 // 代码里实际是： task test_case_007();   do_something(1, 0, 1);   wait(flag);      // 这个 flag 等的什么，写它的人自己也忘了   check_stuff(); endtask

这种偏差不是 AI 引入的，它一直都在。区别在于，AI 生成的文档可以每天重新生成一遍，而手写文档一年只更新一次，还是在压力下更新的。

支持 AI 写文档的真正理由：频率

文档的价值随时间衰减。一份三个月没动的验证计划，参考价值接近于零，因为没人敢确认哪部分还有效。

人工维护文档的成本高到只能低频进行，于是文档天然处在过期状态。AI 把单次成本压到接近于零之后，低频维护变成了持续同步——每次回归结束，从 testbench 里重新提取验证项，从覆盖率数据库里重算 gap，从 SVA 代码里刷新断言说明。文档从交付物变成了流程的副产品。

这个变化比「省了多少工时」重要得多。

AI 在这件事上的能力被严重低估

常见的误解是把 AI 当成只会重排格式的文字工具。实际能力比这个高一层。

给它完整的设计层次和 testbench，它能指出声明了但从未被采样的覆盖点，能找出plan 里写了却在代码中不存在对应 test 的验证项，能对着覆盖率报告直接列出哪几个 bin 从项目开始就没亮过。这些工作人也能做，只是没人愿意每周做一次。

一位工程师看几百页 HTML 报告需要半天，且第三个小时之后注意力已经不在了。工具没有这个问题，它在第八小时和第一小时一样迟钝，也一样稳定。

拿人的巅峰状态和工具的平均水平对比，是评估 AI 时最常犯的错。真实的比较对象是加班第三周的人类平均水平。

那些顾虑该怎么处理

数据安全是真问题。RTL 和 testbench 送到外部服务上，多数公司过不了内审。解法是本地部署加权限分级，数据留在本地工具环境内，agent 只通过受控接口访问。这属于工程问题，有明确的解决路径。

幻觉也是真问题。解法是别让 AI 凭空生成，让它从可验证的源头提取。从代码提取的验证项清单可以逐条回溯到 task 名；从覆盖率数据库生成的 gap 报告可以直接跟 UCDB 对账。凡是能对账的输出，幻觉就无处藏身。

真正会拖死这件事的是习惯。团队里总有有人担心流程一变自己的经验就不值钱了。这层阻力和技术无关，需要的是有人把生成好的第一版拍在会上，让大家看见基线在哪里。

顺带会发生的好事

一旦文档由 AI 从代码生成，代码质量会被动上升。

原因很直接：test_case_007 这种命名，生成出来的文档一眼就能看出是空的，写它的人会在下一次 review 里被问到。文档质量成了代码可读性的显示器，这比在编码规范文档里写十条命名要求有效。

同样的道理适用于覆盖点。覆盖点跟着 feature 走、名字带上语义之后，AI 生成的覆盖率总结就能直接给项目经理看，中间不需要一层人工翻译。

验证文档应该交给 AI，理由不在于省人力，在于只有机器才有耐心每天更新一次文档。

需要人保留的部分很清楚：为什么这样验，哪个模块值得多投两周，风险按什么顺序排。这些依赖对项目历史和硅后成本的判断，短期内交不出去。除此以外的信息搬运工作，继续用人力做属于浪费。

写文档现在让人痛苦，是因为它被安排在了流程的末端，一个天然缺乏预算和时间的位置。把它移到流程内部、变成自动产出的东西之后，痛苦会消失一大半。