连接机器：早期车载电脑故障回忆Hook It Up to the Machine

21世纪初，父母带我们一家去蒙大拿州的冰川国家公园自驾游。

我们乘坐的是家里新买的（二手）厢式货车——一辆绿色的道奇 caravan，很快它就成了“柠檬车”的代名词。

当时我还是个青少年，对周围发生的事情并不太留意细节，但至今仍记得那辆车总是过热。在高速公路上行驶时一切正常，但只要车速低于每小时40英里，水温表就会飙升到危险区域。

我记得在蒙大拿州的一个小镇停下来找修理工检查。他检查了一番，还试驾了一下，然后告诉我父亲，车子之所以过热是因为怠速风扇不转。在高速行驶时没问题，因为空气流动足够冷却发动机；但在低速时就会过热。修理工说他不明白为什么风扇不工作，从机械结构上看没有任何问题，但他也束手无策。他告诉父亲，这类越来越常见的“电脑化”汽车必须连接另一台电脑才能诊断故障原因，而他没有那种设备。

于是我们继续上路。剩下的旅程中，父亲只能绕远路走乡间小路，以便保持较高车速，避免车子过热。对我们这些孩子来说，这简直像一场冒险，因为父亲终于有了开快车的正当理由（不用说，母亲对此很不高兴）。

旅行结束后回到家，父亲把车送到经销商那里，他们用电脑连接车辆系统来诊断并修复了问题。具体细节我已经记不清了，但问题是某个数字传感器失效，导致怠速风扇无法启动。更换传感器后，一切恢复正常。

计算机与计算机对话。

成长于从模拟转向数字、机械转向电子的时代，我时常想起这次旅行。

如今在新一波用大型语言模型（LLM）开发软件的时代，我又一次想起了这段往事。

我不禁想到那位修理工。他是在机械汽车环境中长大的，习惯通过目视检查、诊断和修理来解决问题。面对这种电脑化的汽车，他过去积累的经验和知识几乎完全派不上用场。

你可以用眼睛看出机械开关是否坏了，却看不透数字组件的问题。你需要一台电脑来理解另一台电脑。

这会成为我的未来吗？

如果一段代码是由 LLM 协助编写的，它的复杂性和 bug 是否只能通过 LLM 才能被检查、理解、诊断和修复？

“嘿，能帮我看看我的代码库出问题了？”

“好的，我可以确认问题存在，但要修复它，你得把代码库连到 LLM 上。”