别忙着神话AI：从一次生产环境阻塞的戏剧性解决说起

  最近遇到一个bug，和异步阻塞有关。照理说借助AI可以三下五除二的修掉。问题在于它只在生产环境偶现， 在测试环境没出现过，测试组的同学也没法通过人工点击来重现。

  那么问题来了，当我们提供log和代码让AI去解决时，我们没法简单的判断这个bug是否修复了，因为常规环境下代码都是运行正常的。这时必须具备这个领域的知识，用自己的大脑来判断AI的方案是否有效。

  你可能会说我可以用另一个AI来校验前一个AI的答案，那么问题来了，如果两个AI给出的答案相反，我们怎么确定该信谁？

  实际上的情况确实如此，御三家的模型给出的答案都不同。我的判断依据主要靠这2点：1是这么改看着至少不会出错，2是这么改有没有让代码/流程/架构更简洁。这时候，靠的就是经验和知识储备了。所以别盲目听信AI取代程序员的话术。就算可以替代，到底用A方案替代还是B方案替代，又由谁说了算呢？

   折腾过后，代码确实没有出错。但问题也没有解决。更头疼的是，由于是生产环境的bug，每天只能在峰谷区发布一次，然后第2天看log来验证。就这么折腾了3天3个版本，问题依然没有解决。

  这一块的代码也已经被AI和我打磨的锃光瓦亮了，虽然复杂，但比起第一版简洁了许多，不可能有这么明显的bug。我开始觉得这么下去不是办法，换了一个思路。 让AI写一套脚本，去复现这个阻塞的bug。之前只是考虑到人去复现这个bug不容易，但是让AI去触发这个bug，去构造一个这样的脚本，应该是不难的。

  这时问题又来了, AI虽然写出来这么个复现的脚本。但却没有意义。因为它只是把它认为会出问题的语句附近，加了一些mock，让目标代码片段，返回它预测会出现的值，来达到它的复现目的。这种感觉就好像，它说地板湿的，所以刚才下雨了。 然后让它复现，于是它造了一场雨，然后说你看，下雨了，地板是湿的。  完全把逻辑搞反了。

  这个问题要复现，得模拟很多客户端过来的TCP长链接，然后还得精确的控制每个链接发送的数据时序和服务端接收到的数据量，最后还要让TCP的链接处于某种超时断开的临界区。到达所有这些条件，才是真正的复现。现阶段的coding agent，我不认为可以简单地实现这一点。

  这里AI的问题在于它虽然写代码很强，但是在代码之外的领域，比如操作系统控制，TCP/IP的控制上，还缺少某种可操控的“世界模型”，让它可以在微观层面去操作最基本的“粒子”，从而达到宏观层面的某种“行为”。

  事情的转机还是来自于巧合。后期和AI的某次对话，它提出了一个线索，说是因为我们使用的web服务器Granian的版本问题。于是我去GitHub找它的changelog，确实发现它最近的版本在解决了很多类似的链接问题。

  正当我认为原来不是自己的锅，是开源库的问题，升级一下就搞定了的时候。不小心又去逛了一下这个项目的issue列表，碰巧又发现另一个人提了个很相似的问题。因为这个问题没有明确的报错信息，所以只能从语义上去判断我的问题和这个问题是否相关。经过一番英语阅读理解，我有八成的把握是同一个问题了。这个issue帖子是前两天才发的，最近的版本是一个星期前。说明这个问题和AI说的版本其实无关，但没有AI对版本提了一嘴，我也就不会去GitHub上浏览，也就不会看到这个issue贴来确认真正的问题是什么。所以AI最终还是帮了忙，只是以一种迂回的，戏剧化的方式帮到了我。结果就是：AI给了一个错误的线索，却指引了一条正确的道路。

  回顾整个过程，我认为最大的问题在于上下文的层面。我们都知道需要提供足够的上下文，AI就会有更优的表现。 但我们其实并不知道，我们提供了大量的自认为优质的上下文，有没有可能压根和问题无关？而现阶段的AI，又很容易被上下文带偏，上下文中出现的某种倾向，不管是隐性还是显性，AI都会不遗余力的去挖掘出来，构成“证据链”，去回答你的问题。

  这有点像一个人晕船，于是他把洋流，气候，船只的各种信息，都提供给AI，让AI根据这些上下文来驾驶船只，最大程度的减轻眩晕。但其实这个人晕船纯粹就是因为他昨天换了一副新的眼镜，度数不匹配，导致了他的眩晕。

  作为程序员，一旦用了AI，是回不了头的。没有AI效率会极大降低，甚至会和断网一样没法继续工作。但神话AI也大可不必，多想想多写写AI当前阶段的局限，利己利他。