如何利用 Kimi 的长文本上下文能力快速分析并重构旧项目源码

面对一个完全没有文档、变量命名随意的陈年旧项目，最痛苦的不是写新功能，而是试图理清逻辑链路。以前习惯用 IDE 的全局搜索加脑补，现在我直接把整个 /src 目录打包喂给 Kimi，利用它的长上下文窗口把它当成“项目活字典”。

分析旧代码最忌讳直接问“这段代码在干什么”，因为 AI 容易陷入局部细节而忽略全局依赖。我的实操路径是：先构建索引图谱 → 梳理逻辑链路 → 局部重构方案 → 实施。

第一步是强制 Kimi 建立全局认知。我会把所有核心业务文件（剔除 node_modules 和构建产物）一次性上传，配合这个 Prompt：

你现在是该项目的首席架构师。请分析上传的所有文件，输出一份【项目逻辑拓扑图】：
1. 核心入口文件及其启动流程；
2. 关键业务模块之间的调用依赖关系（用 A -> B -> C 形式）；
3. 识别出项目中定义不统一、重复实现的冗余逻辑点。
不要解释具体代码，只要结构化的映射关系。

在理清链路后，重构时的关键技巧是“上下文锚定”。比如我想重构一个臃肿的 OrderService.js，我不会只传这个文件，而是把这个文件以及它所依赖的 UserStore.js 和 ApiConfig.js 全部选入上下文。

针对具体的重构，我会让它采用“伪代码对比法”来降低出错率：

针对 OrderService.js 中的 calculateTotal 方法，请执行以下操作：
1. 用自然语言描述该方法当前的隐藏逻辑（包括那些没写在注释里的边界处理）；
2. 给出重构后的 TypeScript 版本，要求：提取重复的税率计算逻辑到独立函数，将 magic number 替换为常量。
3. 给出重构前后的逻辑对比表（原逻辑点 vs 新实现方式）。

踩过的一个大坑是：长文本虽然能吞下整个项目，但如果文件过多，AI 在生成具体代码时可能会出现“幻觉”，编造一些并不存在的 API 接口。解决办法是在要求写代码前，先让它执行一遍 grep 式的确认，例如：“在修改前，请先在所有文件中搜索 handlePayment 这个词，确认它被哪些文件引用了，防止重构导致其他模块崩溃”。

效率提升最明显的地方在于，以前手动梳理一个 50 个文件的旧模块需要一天，现在通过“全量上传 → 逻辑映射 → 针对性重构”的链路，大约 2 小时就能把核心链路摸透并完成初步的解耦。