跨时钟域漏处理、验证约束文件过约束了——这些问题在流片前几乎每个项目都会遇到。没有人会因为工程师犯了这些错误就说"这个人不能用"。
那为什么大模型一旦出错，就有人开始质疑它的价值？
这个双重标准值得认真想一想。
现在很多团队在用大模型辅助芯片开发，比如让它帮忙写UVM testbench、生成初版的SystemVerilog模块、或者解释某段复杂的时序逻辑。用起来顺手的时候没人提，一旦模型输出有问题，马上就有声音说"是吧，还是不靠谱"。
这才是关键——模型的输出需要人来审，就像下游模块需要上游工程师review一样。这不是模型的缺陷，这是工作流程本身就该有的环节。
问题不在于模型犯不犯错，而在于整个开发流程有没有把"纠错机制"设计进去。
芯片开发本来就是一个层层验证的过程：仿真、形式验证、门级仿真、流片后测试……每一层都是在假设前一层可能有问题的前提下设计的。这套体系的底层逻辑就是：没有任何环节是完美的，所以要多层冗余。
把大模型引入这个流程，思路应该完全一样。不要期待它零错误，要把它当作一个需要被验证的环节。
进步比完美更实际，也更有意义。
如果模型能把一个工程师写初版RTL的时间从两天缩短到半天，哪怕它产出的代码有20%需要修改，整体效率还是提升了。
技术的准确性当然重要——芯片领域容不得模糊，一个bit的错误可能导致整片报废。但准确性应该由整个系统来保证，而不是把所有压力压在某个单一节点上。无论这个节点是人还是模型。
工程师自己也会在凌晨改bug时写出有问题的代码，也需要code review，也需要CI检查。要求模型做到工程师都做不到的事，这个逻辑本身就站不住脚。
目标是持续进步，不是等待完美降临。
