那个永远在道歉、永远在犯错的“同事“，你真的需要吗？

用大模型写过代码的人，大概都有这种经历：

问它一个时序约束的问题，它给出一个看起来很有条理的答案。你按照它的方案改了，仿真挂了。再去问它，它一脸委屈地说"非常抱歉，我之前的回答确实有误"，然后给出一个新方案。新方案还是错的。再问，再道歉，再给方案……

这个循环可以无限持续下去。

它不是不配合，它根本不知道自己错在哪。🤔

这个问题在芯片研发里会被放大得非常明显。数字芯片的研发流程——从RTL到综合、从STA到signoff——每一个环节都对精确性有极高要求。一个setup violation漏掉了，流片出来就是废片。一个CDC问题没处理好，芯片上板之后就是玄学bug。

大模型在这类问题上的表现，有一个很典型的特征：它会生成"看起来正确"的答案。

比如问它怎么写一个跨时钟域的同步器，它会给你写两级寄存器，注释写得漂漂亮亮，格式也规范。但如果你的设计里有特殊的约束，比如这个信号是multi-bit的，或者源时钟和目标时钟有特定的频率关系，它给出的方案就开始出问题了。

追问它，它不会说"这个情况我不确定"。它会继续给你方案，继续道歉，继续给新方案。

// 大模型可能给你的"标准答案" always_ff @(posedge clk_dst) begin sync_stage1 <= data_src; sync_stage2 <= sync_stage1; end // 但它不会主动告诉你： // 这对 multi-bit 信号根本不够用，你需要握手或者格雷码

这背后有一个根本性的原因：大模型没有"我不知道"这个状态。

它的训练目标是生成合理的回答，不是生成正确的回答。当它面对一个超出训练数据覆盖范围的问题时，它会用相似的模式填充答案，表面上看很像那么回事。这在写文章的场景里影响不大，但在芯片研发里，"看起来像那么回事"和"真的正确"之间，差的可能是几百万的流片费用。

更关键的问题在于：它无法从错误中学习。

一个工作了三年的工程师，被leader骂过一次之后，下次就会主动去检查那个点。大模型每次对话都是全新开始，它没有这种积累。今天你纠正了它在时钟约束上的错误，明天它还会犯同样的错。那种"委屈地道歉"的姿态，不是谦逊，只是它的输出模式。

当然，这不意味着大模型没用。查资料、写注释、生成模板代码、做初稿，这些事情它做得比手动查文档快得多。但这些都是辅助性的工作。

芯片研发里真正有价值的东西，是判断力——在一堆可能的方案里，判断哪个在当前设计约束下是可行的；是对问题的嗅觉——在仿真波形里，感觉到某个信号的抖动"不太对"；是对历史经验的调用——这个问题上次在某个项目里出现过，最后是这么解决的。

这些判断，大模型没有。

还有一个现实层面的问题：在公司里，一个工程师出了问题是要负责的。他会认真对待，因为有后果。大模型没有后果，它只有对话窗口。

所以结论很简单：大模型是个不错的工具，但它是个永远无法成长的工具。在芯片这个行业里，工程师的核心价值在于持续积累的判断力和经验，这恰好是大模型结构上做不到的事。

把它当搜索引擎增强版来用，挺好。

指望它替代一个真正懂设计的工程师，那还差得远。