我使用AI解构了一个从未接触过的遗留服务
一位工程师分享如何利用AI快速理解并修复一个陌生的遗留Node.js微服务中的间歇性字段丢失bug。关键方法是角色驱动、分步输入代码文件，让AI充当结构化思考伙伴，而非简单问答。最终在90分钟内定位根因，修复仅需11行代码。
文章情报
要点
- 面对遗留代码，不要直接问AI“这是什么”，而是赋予它角色并逐步输入文件
- 通过AI识别出导致bug的函数路径：静默返回undefined的字段转换函数
- 总耗时90分钟定位问题，修复仅11行代码
- 该方法适用于代码库入职、重构前侦察和文档编写
为什么重要
这条新闻值得关注，因为面对遗留代码，不要直接问AI“这是什么”，而是赋予它角色并逐步输入文件。
技术影响
可能影响模型选型、推理成本、产品能力和评测基准。
三周前，我接手了一个支持升级事件，涉及一个我从未打开过的服务。这是一个大约有四十年历史的Node.js微服务，由两位已离职的工程师编写。没有有意义的README，测试已有数月未在CI中运行，Slack线程中充满了“这东西是个黑箱”的抱怨，持续了两年。
这次bug是真实存在且影响客户的。我有一天时间来处理。
该服务位于API网关和第三方履约提供商之间。请求转换逻辑中间歇性地丢失字段——但仅发生在特定的请求形状和负载组合下。输出错误，日志无帮助，代码分散在14个文件、3200行中，逻辑在三个中间件层间交错，责任划分不清。
通常，这种情况意味着半天的console.log驱动的考古工作，然后才能形成值得测试的理论。但这次我尝试了不同的方法。
我的第一直觉是将主处理器粘贴到AI聊天框中询问“这是做什么的？”这给了我一个表面级别的总结——没错，但并不有用。它告诉我代码说了什么，而不是在整个系统上下文中的含义。
真正解锁服务的关键提示模式是将AI视为新加入团队的工程师，而不是搜索引擎。我按顺序喂给它核心文件，并赋予它具体角色和具体目标：“你是新加入的后端工程师。我将一次展示一个遗留微服务的核心文件。每个文件后，更新一个运行列表：1）此文件负责什么；2）你能看到的任何假设或隐式契约；3）在触碰此代码前你想得到答案的问题。不要总结代码。识别承载逻辑，标记任何看起来脆弱的地方。”
三个文件后，它发现了我忽略的东西：一个字段转换函数在输入不符合预期形状时静默返回undefined——没有错误，没有日志，只是下游字段丢失。那就是bug，已在代码库中存在了四年。
有了理论后，我用了第二个提示来压力测试：展示函数和示例载荷，要求逐路径分析输出是否可能静默丢失或转为undefined。它分析了五个代码路径，标记了两个可能产生undefined的路径，并正确识别出与间歇性故障模式相关的路径。
端到端来看：根因定位总耗时约90分钟（通常至少半天），手动阅读的文件4/14，修复代码11行，后续AI辅助撰写了一个回归测试。关键不是AI替我做工作，而是AI作为结构化思考伙伴，而我保留诊断的所有权。
如果你被丢进不熟悉的遗留代码中，不要问AI解释它。给它一个角色，增量地喂文件，要求它维护系统的运行模型——包括它不知道的东西。这样的输出远比一个总结有用。