文中观点仅代表个人立场。
2024 年面试一家当时风头正劲的公司，大佬问我：你愿不愿意去做验证？我的答案是不假思索、斩钉截铁的 no。两年之后，验证成了我和其他团队讨论最多的话题之一。在 AI 时代，我反而觉得验证是最难被取代的那个环节，也是最被低估的那个环节。
架构是什么？是取舍之道。说得再具体一点，就是 design space exploration。芯片的 design space 大得惊人，这也是为什么架构师往往需要十几年甚至几十年才能沉淀成熟——慢慢养出来的是对设计的敏感度，帮公司和产品快速排除掉不可行的选项，找到 local，if not global，的最优解。
这件事 AI 能替代吗？可以，也不可以。AI 确实能极快地做 design space exploration，但从第一性原理讲，当这个 design space 完全没有 bound 的时候，搜索是低效的，甚至根本无法收敛。
那我们怎么划出一个圈，让 AI 在圈里自主搜索？我认为要靠验证。当我设计了一个架构、需要 AI 帮忙搜索的时候，我需要精准地划出这个圈，并且能验证 AI 有没有待在圈里。这个圈不只是功能性验证——性能相关的验证和 test vector 同样需要被精准地表达出来。当 test 和 assertion 足够 complete 的时候，我才可以放心地把设计交给 AI 去自动化。
现在不少芯片设计人员想的是让 AI 去接管验证，我觉得这件事可以反过来看。AI 当然能帮你更快地写出验证方案、补齐 assertion；但如果设计和验证之中一定要有一个先交给 AI，我会先交出设计。这不是说设计更简单——恰恰相反，把一个设计做对所需要的功力一点都不少。区别在于责任落点：验证是人必须 review 和 sign off 的那道关，因为它定义了"什么才算对"；而当验证足够完整的时候，设计的正确性可以由验证来担保，不必再靠人逐行去读。
试想两个场景：
- 你手写了设计，交给 AI 去测，AI 开心地告诉你测试全过了——但你根本不知道它测了什么、又是怎么测的。
- 测试层层把关、coverage 非常高，然后 AI 写了设计，所有测试都能跑过。
哪个更让人放心？我选第二种。也许场景一里手写的设计质量依然更优——但我对它到底对不对没有把握；而第二种给我的，是可以检验的把握。
这也是我说验证是架构师的爱之语的原因。架构师真正想传达的东西——什么必须成立、什么绝不能发生、性能的边界画在哪里——靠文档和口头描述是传达不过去的，尤其是传达给一个不会揣摩言外之意的 AI。而 test 和 assertion 是可执行的意图：你不是在描述你想要什么，你是在用一种可以被机器检验的方式说出你想要什么。你写下的每一条 assertion，都是在告诉对方"我在乎这个"。
我导师曾经和我说：如果一个 design，你在 debug 的时候需要去看 waveform，then you are doomed——那说明设计里没有足够的 debug infra，而看 waveform 是效率的杀手。
放到 AI 时代，这句话几乎可以原样改写：如果你需要逐行阅读 AI 写出来的 design，却没有一个快速的方法验证它的正确性和性能，then you are doomed。