芯片流片失败，真的是技术问题吗？

匈牙利医生汉斯·赛尔有个实验：给小白鼠注射一种无毒药剂，结果小白鼠大量死亡。后来查清楚了，杀死它们的不是药剂，而是注射过程带来的极度紧张。免疫力崩了，病就来了。

做过芯片项目的人都知道，流片窗口一旦定下来，整个团队的状态会变得很奇怪。

功能还是那些功能，时序还是那些路径。但出错的概率会莫名其妙地上升。

一个真实场景：流片前两周，工程师在做最后的sign-off检查。时序报告里有一条路径：

Path 1: MET Startpoint: u_mac/data_reg[7] (rising edge-triggered flip-flop) Endpoint: u_acc/sum_reg[7] (rising edge-triggered flip-flop) slack (MET) : 0.03ns

slack是正的，技术上没问题。但0.03ns这个数字，正常情况下会被标记出来复查。

结果那次没人提。因为大家都在赶，觉得MET就是MET，过了就行。

后来那颗芯片回来，在某个corner下时序违例，功能异常。

这件事的根源不是技术判断错了，是压力改变了人的决策阈值。

平时0.05ns以下的slack都会重新评估，那两周直接跳过了。

芯片项目的压力来源通常有两类：一类是客观的，工期紧、需求改了、工具跑出问题；另一类是人为制造的，比如不断拉会同步进度、每天要汇报百分比、管理层在群里频繁@人。

后者才是真正危险的。

前者会增加工作量，但人在清醒状态下还是能处理的。后者会持续消耗注意力，让工程师的认知资源被占满，然后在最关键的检查节点上出现判断失误。

真正稳的团队，会把关键的技术检查节点单独保护起来，不允许被进度压力打断。sign-off review就是sign-off review，不在那个会上讨论排期，不在那个会上问别的事。

保护技术判断的环境，和保证技术判断的质量，是同一件事。

汉斯·赛尔后来把这个现象叫做”应激反应”。他发现，让生物体垮掉的，往往不是外部的威胁本身，而是对威胁持续反应所消耗的资源。

下次项目出了问题，不妨先问一句：最后那段时间，团队的状态是什么样的。技术问题往往只是结果，不是原因。