流片失败，损失谁来背？

其实答案很清楚：工程师的设计出了问题，工程师和公司承担后果。工具本身顶多是个辅助，最终的sign-off是人做的。

先看一个具体场景——

某项目用了EDA厂商的AI辅助布局工具，AI给出了一版Floorplan建议，工程师审核后觉得没问题，按这个方向推进。最终流片后发现某模块的电源完整性出现问题，根源是AI生成的布局在特定工艺角下PI估算有偏差。

AI建议了，工程师采纳了，出了事——责任在谁？

去问EDA厂商，他们的授权协议里写得很清楚：工具结果仅供参考，最终设计责任由用户自行承担。几乎没有例外。

这不是在批评厂商，这是整个行业目前的现实。

自动驾驶领域已经在为这个问题吵了很多年。车撞了人，算车主的责任还是算制造商的责任？如果是全自动驾驶，车里的乘客根本没有机会干预。但制造商又会说，系统在设计规格内运行，是道路条件超出了设计边界。

责任链断了。

芯片研发里，这条链断得更隐蔽。没有事故现场，没有监控录像，只有一份流片报告和一堆log文件。AI工具的推理过程本身就不透明，出了问题很难还原”AI到底为什么给出那个建议”。

再举个例子，假设AI生成了一段SDC约束：

set_multicycle_path -setup 2 -from [get_cells core/dsp_block/*] -to [get_cells core/accum/*]

这条约束看起来合理，工程师快速扫了一眼通过了。但如果AI对路径的识别范围有误，把某个不应该放松约束的路径也包进去了，时序分析会通过，仿真也可能通过，问题留到流片后才暴露。

这种情况下，工程师”审核”了，但审核深度远不够。AI”建议”了，但不负责任。两边都沾了一点，两边又都说不是自己的问题。

现在行业里有一种声音，觉得AI工具只要足够成熟，准确率足够高，这个问题自然就消失了。

这个判断过于乐观。

准确率再高，也不是100%。芯片流片的代价决定了，哪怕是0.1%的失误率，在某些项目上都是不可承受的损失。高准确率解决不了责任归属的问题，只是让这个问题出现的频率降低了而已。

需要解决的，是在工具出问题的时候，有没有一套清晰的机制能说清楚：AI给的建议是什么，工程师做了什么判断，最终的决策依据是什么。

现在大多数引入AI工作流的项目里，这条记录链根本不存在。

这件事迟早要被正式讨论。

随着AI在芯片研发里介入越来越深，出问题的概率不会降为零，损失会越来越大，纠纷也会越来越多。到那个时候再去谈责任框架，代价已经付出去了。

现在就应该想清楚：用了AI工具，到底意味着承担了什么，又放弃了什么。