一群人开会做芯片＂人肉＂ LVS，最后验证了什么？当工具无法给出答案，我们最容易犯的错误，是用更多人的参与来替代更可靠的证据

芯片研发方法论

一群人开会做人肉 LVS，最后验证了什么？

开场

那天下午，我收到了一条临时的腾讯会议邀请。

会议标题很短：“LVS 确认。”

我点进去时，屏幕另一端已经坐着四五个人。有人在公司，有人在外地，有人刚结束手里的调试，有人甚至还没完全搞清楚这颗芯片的背景。

大家被临时叫到一起，只为了做一件事：

人肉 LVS。

为什么只能人肉

这不是一颗标准结构的芯片。

它里面有一块特殊传感器，版图形状、器件连接和常规数字或模拟模块都不一样。标准 LVS 工具无法直接把它当成普通电路完成验证。

换句话说，工具不能替我们回答最关键的问题：

版图上的每一根连接，到底接对了没有？

这件事最后只能交给人。

负责这个模块的工程师已经自己核对了很久。他不是完全不会做，也不是没有投入时间。真正困住他的，是一种更难处理的东西：

他看完以后，仍然不确定自己到底有没有看对。

工具无法自动验证后，工程师只能逐根检查复杂版图连接。

不确定性开始拉人

复杂连接最折磨人的地方就在这里。

你盯着一根线看十分钟，觉得没问题；过一会儿换个方向再看，又会怀疑刚才是不是漏掉了一个跨层连接。

你越看，脑子里的上下文越多；上下文越多，就越难把自己的判断解释给别人。

于是，一个很自然的念头出现了：

既然我一个人没有把握，那就多叫几个人一起看。

临时会议就这样被拉了起来。

那张图

会议开始后，负责人共享了屏幕。

他先截了一张芯片版图，又用画图软件在上面补了很多辅助线。红线表示一类连接，蓝线表示另一类连接，箭头指向器件，旁边还有编号、圈选和临时文字。

单独看每一个标记，似乎都有理由。

但它们叠在一起以后，整张图已经接近一团毛线。

更麻烦的是，这张图并不是一个独立、可复核的连接定义。它只是负责人脑子里那套理解的投影。

他能顺着自己的思路讲下去，其他人却必须一边听，一边重新建立整套上下文。

临时腾讯会议被拉起，多地工程师围绕共享版图做人肉 LVS。

会议里的半小时

鼠标在版图上不断放大、缩小、移动。

“这里是不是接到这一层？”

“等一下，我理解的不是这根。”

“你刚才说的编号三，是左边这个还是下面这个？”

“这个颜色前面不是代表另外一类线吗？”

有人试图确认局部，有人试图回到电路原理，还有人只是在等待负责人把故事重新讲完整。

会议看起来很忙。

每个人都说了话，每个人都贡献了一点意见，屏幕上也不断出现新的标记。

但四十多分钟过去，没有哪一根连接因为新的证据被证明是对的，也没有哪一个疑点被转化成可重复的检查步骤。

大家得到的，只是一个越来越模糊的共同感觉：

好像……问题不大。

情绪价值

会后，我说了一句不太客气的话：

这场会议提供了情绪价值，但没有提供事实价值。

这句话听起来像是在批评开会。

但真正的问题，并不是“会议太多”，也不是“某个人能力不够”。

真正的问题是：

我们在没有可靠验证手段时，下意识地用更多人的参与，替代更可靠的方法。

负责人需要的其实是确定性。

当他一个人无法获得确定性时，就会本能地把更多人拉进来，希望集体意见能够降低风险。

而参与者越多，心理压力确实会被分散。

如果最后出了问题，也不再像是一个人的判断失误，而变成了“当时大家都看过”。

这就是会议最隐蔽的功能：

它可以分担责任，也可以缓解焦虑。

但它不会自动增加事实。

红线、蓝线和问号越叠越多，讨论升温，但可复核证据没有增加。

共识不是验证

工程里有一个很危险的错觉：

参与确认的人越多，结论就越可靠。

这在一些主观判断中也许成立，但在电路连接、时序关系、版图规则和算法边界中，事实并不会因为赞同人数增加而改变。

五个人同时看错，仍然是错。

十个人都没有发现遗漏，也不能证明遗漏不存在。

当输入材料本身混乱、检查规则没有定义、每个人掌握的上下文不同，增加参与者只会增加新的解释路径。

人数从 5 增加到 10，潜在的沟通关系从

增加到

人翻了一倍，潜在沟通路径却变成了原来的 4.5 倍。

如果没有统一图纸、统一编号和统一判据，新增的人首先增加的不是验证能力，而是理解偏差。

人肉 LVS 真正缺什么

人肉 LVS 并非绝对不可做。

特殊器件、传感器结构、定制版图和工具无法识别的连接，本来就可能需要人工复核。

但人工复核和集体看图，是两件完全不同的事。

可靠的人肉 LVS，至少应该具备四样东西：

第一，独立于讲解者的连接表。
每个器件、端口、层次和网络都有唯一编号，任何人拿到材料都能重建连接关系。

第二，明确的检查规则。
检查什么、按什么顺序检查、什么情况算通过、什么情况必须回退，不能靠现场感觉。

第三，双人独立复核。
两个人分别完成检查，再比较结果，而不是一个人讲、所有人跟着他的思路走。

第四，可追踪的证据。
每一个结论都要落到标记、表格、截图或脚本结果上，不能只留下“会上大家确认过”。

方法论升级

芯片研发真正需要的，不是把更多工程师塞进同一个屏幕，而是把一个人的理解，转化成团队可以独立复核的工程对象。

能自动化的部分，就写脚本。

能结构化的部分，就形成 netlist、连接矩阵或检查表。

能形式化描述的部分，就变成断言和约束。

工具暂时做不到的部分，也应该尽量让人工过程具备工具的特征：

输入明确、规则明确、过程可重复、结果可追踪。

这才是方法学。

方法学不是一个听起来高级的词。它真正解决的是一个朴素问题：

下一次换一个人来做，能不能得到同样的结果？

真正的验证最终落到连接矩阵、检查表、Netlist 与可追踪的 Sign-off 记录。

行业里的同一种错觉

人肉 LVS 只是一个缩影。

在芯片项目里，我们经常用同样的方式处理别的问题：

仿真结果解释不清，就再拉一个评审会。

规格存在歧义，就让更多负责人一起口头确认。

Root Cause 没找到，就把更多部门拉进群里。

项目延期，就再招几个人。

这些动作都能制造进展感。

会议更多了，群更热闹了，参与者更多了，管理者也更容易感觉“事情已经被重视”。

但复杂工程最残酷的地方在于：

重视不等于解决，参与不等于验证，共识也不等于事实。

结尾

那场人肉 LVS 会议最后并没有真正解决问题。

它只是让一个人的不确定，变成了一群人的不确定；再把一群人的不确定，包装成了一个看起来比较安全的共同结论。

这可能就是工程管理里最容易被忽略的一类风险：

我们以为自己在验证事实，其实只是在交换情绪。

真正可靠的团队，不是从不开会，也不是拒绝多人协作。

而是知道什么时候需要讨论，什么时候必须停止讨论，转而建立证据。

因为在芯片研发里，最后决定流片成败的，从来不是会议里有多少人点头。

而是那根线，究竟有没有接对。

讨论可以产生共识，但只有证据能够完成验证。