Agent的决策过程是透明的但不直觉的——你能看到它每一步的输入输出，但要理解它为什么在某个地方做出了一个错误的判断，需要相当的分析成本。每次调用都有出错的概率，假设每次出错率是5%——这已经是比较乐观的估计了——那么十次调用全部正确的概率是 0.95^10，大约是60%。不同的步骤，不同的容错要求，不同的可接受出错率——这些加在一起，才是AI在芯片流程里的真实应用边界。在这些场景里，Agent的

芯片工程师都知道，RTL 设计和验证之间的沟通从来就不简单。你写了一段仲裁逻辑，验证工程师跑出一个波形异常，光是复现这个问题、对齐理解，来回就要折腾好几轮。听到一种说法：用一个 Agent 写代码，另一个 Agent 做验证，两者相互制衡，大模型的局限性就能被绕过去。换成两个 Agent 在中间传消息，这个来回的代价只会更高，不会更低。这个想法听起来很美，但落地之后问题一大堆。

一个工程师真正理解 CDC（跨时钟域）问题，往往是因为他自己在项目里踩过坑，仿真过波形，看着随机 fail 排查了好几天，最后才把同步器的原理和实际电路行为对应起来。大模型确实很厉害，你问它 AXI 协议的 outstanding transaction 怎么处理，它能给你一段流畅的解释，配上例子，还能帮你补充一些你没想到的边界情况。大模型的问题在于，它把反馈周期压缩到了接近零——你问，它答，你直

直接跟大模型说："我有一份 Synopsys PT 的 timing report，帮我写个脚本，找出所有 violated paths，按 clock domain 分组，输出前 10 条最差的路径，含 startpoint 和 endpoint。这些判断，需要对系统的深度理解，需要经验的积累，需要对 spec 本身的把握。如果你的价值在于深度理解芯片设计的某个环节，能准确判断问题出在哪、能给出

这在写文章的场景里影响不大，但在芯片研发里，"看起来像那么回事"和"真的正确"之间，差的可能是几百万的流片费用。芯片研发里真正有价值的东西，是判断力——在一堆可能的方案里，判断哪个在当前设计约束下是可行的；比如问它怎么写一个跨时钟域的同步器，它会给你写两级寄存器，注释写得漂漂亮亮，格式也规范。但如果你的设计里有特殊的约束，比如这个信号是multi-bit的，或者源时钟和目标时钟有特定的频率关系，它

大模型训练吃的就是文本，GitHub上几十亿行开源代码，全部喂进去，模型自然就学会了。开源的RTL代码，和GitHub上的软件代码相比，量级差了好几个数量级。但要让大模型真正参与到RTL核心设计里，还需要两件事：更大规模的高质量芯片设计数据集，以及能与EDA工具深度集成的推理-验证闭环。一个模块写完，要跑仿真，少则几小时，复杂的跑几天。写错了，运行一下，报错信息马上出来，大模型可以立刻改。数字芯片

哲学家塞尔有个著名的"中文房间"实验——一个不懂中文的人，关在房间里，靠着一本形式符号规则手册，把中文输入翻译成中文输出。外面的人以为房间里有个"懂中文"的人，实际上里面什么理解都没发生。它在你给的约束范围内找最优解，但那个"范围"本身，还是人定义的。如果对问题本身模糊，AI只会更快速地帮你跑偏。和几个做芯片验证的同事聊天，聊到AI辅助设计工具，有人说"这玩意居然真的懂电路"。所以"人工智能"里的

举个例子，做时序收敛的时候，工程师需要查某个路径的约束条件。这个约束可能定义在SDC文件里，也可能藏在某个tcl脚本的注释里，还可能是三年前某个离职同事口头传下来的经验。没有结构化的文档，没有统一的代码规范，没有可追溯的设计决策记录。大家习惯了用Perl脚本处理文件，习惯了在几万行的Verilog里搜索信号名，习惯了开会时拖拽波形图讨论问题。外面的世界已经在用大模型做代码补全、文档生成、bug分析

现在AI模型的基准测试也在快速膨胀。MMLU、HumanEval、GSM8K……每隔几个月就有新的benchmark出来，评的方向也越来越细。但这些测试，和芯片研发的实际工作基本没什么关系。让大模型帮你写一段APB总线的Verilog，它能写出来。但它写的时序逻辑是否满足建立保持时间？这些细节，通用基准测试根本不考察。每一个细分领域，最终都会沉淀出一套公认的测量方式。怎么证明它真的能用在芯片设计上

AI 接到需求之后，通常是直接开始干的。它的默认行为是尽快给出答案，而不是先确认所有前提条件。这意味着，如果你的需求里有任何歧义，AI 会自己做出假设，然后基于这个假设开始生成代码，一口气写完，等你看到输出的时候已经是数百行了。跟人说需求，哪怕说得不完整，对方通常会停下来问你："等等，你说的这个接口是 AXI 还是 AHB？burst 传输要支持吗？"这个反问很自然，因为人对"需求不完整就开始做"