AI工具出了问题，找谁？

流片失败损失谁来背其实答案很清楚工程师的设计出了问题工程师和公司承担后果。工具本身顶多是个辅助最终的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工具到底意味着承担了什么又放弃了什么。