大模型能帮你查芯片 Bug，但“修“这个动作，必须你来确认

让大模型按规则排查，而不是自由发挥

大模型在信息不足的情况下，依然会非常自信地给出答案。

这个特点在日常聊天里无所谓，但放到芯片工程里，后果就不一样了。

举个真实场景：一个工程师把一段 Verilog 扔给大模型，附上一句报错信息：data_out is X at time 500ns，让它分析原因、修复代码：

"X 态传播问题，请按以下顺序排查：①检查复位信号的初始赋值；②检查 testbench 的驱动完整性；③再看设计代码本身。请逐条给出结论，遇到信息不足的地方，明确告诉我需要补充什么。"

这样，大模型的输出就从"自由联想"变成了"按图索骥"，排查结果的可信度会大幅提升。

最危险的操作，是让它全自动地"试改"

排查是一回事，动手改代码是另一回事。

很多工程师会直接让大模型一条一条地去"试"：改复位极性，改敏感列表，加$display打印，甚至开始动顶层连线。每改一处，新的问题就可能冒出来。等到最后发现原来是 testbench 的事，设计代码已经被改得面目全非，原本验证过的逻辑被破坏了，新的 bug 反而引进来了。

这在实际工程中相当常见。

大模型没有"不该动"的概念。它不知道哪段代码是经过严格验证的，哪段逻辑动了会牵连一大片。它只是在做文本生成，顺着"修复"这个方向一路往下走。

芯片工程的特殊性在于，模块之间的耦合往往很深。一个模块的时序改了，综合结果变了，后端约束可能就不再成立。这种精准性要求，容不得无差别的试错。

所以，大模型每给出一个修改建议，都应该经过工程师确认后再执行，而不是全自动地批量应用。

一个更稳健的工作流：排查交给大模型，决策留给工程师

实践中，可以把大模型的介入分成两个阶段：

第一阶段：协助排查
按照工程师指定的排查逻辑，让大模型逐步分析，列出可能的问题点，并明确标注哪些结论有依据、哪些是推测、哪些需要补充信息。这一步可以走得快，大模型在这里帮你省的是思路梳理的时间。

第二阶段：确认后再修
大模型给出具体的修改建议后，由工程师判断：

• 这个修改是否动了不该动的地方？

• 改动的范围是否超出了当前问题的边界？

• 有没有更小代价的修复方式？

确认之后，再执行修改。一次只改一处，验证通过再走下一步。

这套流程多了一个确认环节，但它保住了最重要的东西：工程师对代码状态的掌控权。

大模型适合做什么，不适合做什么

用大模型查语法、解释工具报错、生成重复性的代码框架，这些没问题，它在这些地方确实能省时间。

但一旦涉及跨模块调试、时序收敛问题、或者任何"这个信号为什么不对"的问题，在没有完整上下文之前，不要让它开始"修"。

更重要的是，问法要对：

❌ "帮我修复这段代码"
✅ "按照 X 态传播的标准排查逻辑，告诉我每一步的分析结论，以及你需要我补充哪些信息"

工程师保留判断权，大模型只是一个按规则工作的排查助手。

芯片研发本质上是一件高度依赖精确信息的工作。工具越强大，对使用者的判断力要求反而越高。

大模型是好工具，但流程设计决定它是助力还是风险。让它按规则排查，让工程师来确认修改——这一步不能省。