“你们主要用AI做什么？”一位程序员在社区抛出问题后，评论区成了大型共识现场。他的回答是：写代码只是偶尔，真正高频的用途，是让AI解释别人写的代码——尤其当代码库里全是遗留系统的时候。

他手头有三个AI助手轮换着用：Claude、ChatGPT和Copilot。但用得相当随性，有时把任务拆开，让一个助手定计划，另一个生成代码，再换一个做代码审查；有时懒得切换，同一个模型从头跟到尾。他说自己没有固定的工作流，纯粹看当天顺手程度。

团队里渐渐摸出一条规律：只要是在全新项目（俗称“绿地项目”）上生成代码，几个AI助手都发挥得相当亮眼，质量高、思路也清晰。可一旦扎进遗留代码，那种让人眼前一亮的稳定输出就开始打折了。修改老功能时，AI给出的建议经常抓不住上下文依赖，甚至会忽略历史遗留的边界条件。这一观察不是他一个人的感觉，周围的同事也都有同感，反复验证后大家得出了一个颇为一致的结论：遗留代码是AI代码生成能力的分水岭。

偏偏他们的代码库百分之百由遗留代码构成。在这种环境下，他对AI代码生成功能的期待顺势降了下来，转而把主力用在另一个方向上：让AI帮忙解释代码。这个选择意外地替他省下大把时间和大量情绪消耗。以前遇到一段复杂到让人怀疑人生的代码，如果运气好，原作者还留在公司，可以厚着脸皮去问当时的设计思路；如果运气差，那人早走了，就只能硬啃注释（多数时候还不存在），靠调试一步步反推逻辑，那种煎熬只有常年维护旧系统的人能懂。

现在他养成一个新的习惯：每当文档支撑不住，就把那段代码扔给AI助手，让它解释背后的意图和运行机制。他说，绝大多数时候AI会给出一个合乎逻辑的解释，顺着这个解释再回头读代码，那些原本缠绕在一起的判断分支、变量命名、深层调用栈，会突然都有了脉络。就像手里多了一张模糊地带的地图，准确率虽然达不到百分之百，但比起在漆黑里摸索，效率提升是实打实的。

当然，AI输出的解释有时会离谱到让人哭笑不得——比如把一段为了绕过旧版框架bug的临时补丁，解释成“优雅的设计模式”；更危险的是那种一本正经的幻觉，把根本不存在的调用关系说得条条是道。但他的应对方式很朴素：把常识请出来当裁判。既然代码就在眼前，读着AI补充的说明，我们完全有能力判断这个解释到底靠不靠谱。读得通，思路可以继续沿用它给的线索往下理；读不通，弃掉重问就是了。整个过程里，扮演决策者的始终是人，AI提供的只是一份可以随时撕掉的参考稿。

这个工作流背后藏着一层更深的改变：开发者对AI产出的审视，已经从“它会不会出错”进化到“我怎么快速用好它给出的信息”。他不再追求AI全自动把遗留代码理清楚，而是把AI当成一个随时在线、不厌其烦的代码搭档。搭档有时给妙手，有时给烂招，但用最低成本筛选出那部分有价值的信息，就成了程序员自己的新本事。

当“全面替代旧系统维护工作”还只是一个遥远的许诺时，这种务实拆分——把生成交付给可靠场景，把理解交给AI辅助——已经让一群被老代码缠身的开发者悄悄找到了那条好走一点的路。