Claude 17分钟破解20年旧系统，还抓出一个Bug

有这么一个模块，全公司只有几个头发花白的工程师真正懂。二十年了，我都会绕开它干活，但说不清它内部逻辑。这事情一直让我不舒服。

Claude 3.5 Sonnet 只花了17分钟，就摸清了它的核心依赖。然后，它发现了我们所有人都没发现的东西。

黑匣子：我们天天依赖它，却没人懂它

这个模块负责在集团各子公司之间分配稀缺组件。它用 COBOL 写在90年代末，是整个供应链系统的中枢。而我们正在做的，是把这套系统升级成 AI 驱动的预测分析平台。

原来的设计文档？没人见过。我甚至怀疑它根本不存在。

代码不能直接重写，必须把埋在里面的业务逻辑抽出来。可文档太少、太旧、或者干脆没有。当年写系统的人基本都退休了，剩下的只有“部落知识”——几个老工程师在凌晨2点被电话叫醒，在压力下摸索出来的经验。

我决定把 Claude 当作一个不需要睡觉的初级架构师，把手头所有材料都喂给它：COBOL 代码片段、旧设计文档残页、我入职前的会议手写笔记（有些字迹模糊到 OCR 都认不出来，我只能亲手重新打几行）、还有样本数据流。我打算不断迭代提示词，一步步逼出深度，直到隐含规则全部变成显式规则。其实“深度”到底是什么，我也说不清。但我知道，那种平铺直叙的总结绝对不是我要的。

实际发生了什么

一开始我偷懒，直接粘了500行 COBOL 让 Claude 解释。得到的是一份语法正确、措辞优美、但信息量几乎为零的总结——就像教科书摘要，而不是我需要的电路图。说实话，喝完咖啡给自己打了半天鸡血，就等来这么个东西，有点泄气。

然后我收窄了范围。不再问整个程序，只挑一个段落、一个变量变换、一个条件块。“重点看 PERFORM PARAGRAPH-X，说明 WS-CUSTOMER-CODE 是干嘛的，它的值在这三个段里怎么变。” Claude 一层一层地拆，我顺着它的输出继续往下剥。这一步比我想象的费时间——大半个下午加一个整晚，那晚本来没打算搭进去的。

接着，我们碰到了一条没人能解释的规则。

这是一条埋在 GOTO 迷宫里的库存分配规则。大概长这样：如果X，就做Y；除非Z，那先查P；但如果Q是昨天发生的，就另说。多年来，团队全靠人工手动覆盖和紧急电话来处理边缘情况。没人弄清楚过它为什么是这副德行。我自己几年前也打过两次这种电话，接受了变通方案，没深究原因。

我把这段逻辑连同样本数据丢给 Claude。它没只是复述规则，而是给出了三种合理诠释，每一种都有代码依据和碎片注释支撑。它还标出了一个死锁条件，正好对应我们多年来一直在打补丁、却从未真正定位的场景。

我们有变通办法，但从来没有诊断。Claude 给了诊断。我读了两遍才敢信，然后翻出旧事故日志核对——成立。

它还在继续，这点我没想到。当我把模块更广的一段喂进去，它提出了一个更干净的模块化数据模型，把原始设计里缠在一起的东西拆开了。它还指出了代码里从未写下来的假设：某个供应商总是和特定的二级供应商配对，这纯粹是集团内部多年形成的操作习惯。Claude 仅凭数据流就把这些标记为“未解释的关系”——一台机器能对你自家公司的习惯提出这种评语，有点诡异。

这些发现并没有取代我的经验。它只是让我把时间花在验证解释、补充上下文上，而不是半夜对着语法逆向工程。整个过程不像自动化，更像和一个异常耐心、永不疲倦的初级架构师开了场高强度的讨论会——他不需要喝咖啡，但我需要，喝了两杯。

最终，我们得到了一份完整的、简化过的模块逻辑流程图。它成了新平台微服务和特征存储的设计蓝图。原本要在会议室里泡上大半年、靠人工反编译才能做完的活，几周就搞定了。老实说，我还是有点怀疑它怎么能这么快。二十年形成的“这种事永远比你想的慢”的直觉，不会因为一个顺利的星期就消失。