如何利用 Cursor 的 Composer 模式快速重构一个复杂的遗留代码模块

面对那种逻辑混乱、缺乏文档的遗留模块，直接用 Chat 窗口问 AI 往往得不到好结果，因为上下文碎片化太严重。最有效的姿势是开启 Ctrl + I (Composer 模式)，把整个模块相关的 .ts 或 .py 文件全部 @ 进来，让 AI 在全局视角下进行重构。

我最近尝试把一个 2000 行的旧订单处理类拆分成多个单一职责的小类，如果靠手动改，光是处理依赖注入和类型定义就要花掉大半天。在 Composer 里，我直接下达指令：

重构 @OrderService.ts，将订单校验、支付状态同步、邮件通知逻辑分别抽离到独立的 Service 类中。保持原有接口签名不变，确保现有调用方无需修改代码。请在根目录创建新文件夹 /services/order 存放拆分后的文件。

这里有个关键技巧：不要一次性让它完成所有重构。我习惯先让它生成一个“重构计划”的临时文件，确认拆分维度正确后，再输入 Execute the plan。

在实际操作中，最容易踩的坑是 Cursor 在大规模移动代码时，容易丢失某些深层的 import 引用或者误删一些冷门的边缘case判断。为了规避这个问题，我会在 .cursorrules 中加入一条强制约束：

When refactoring legacy code, always preserve existing error handling blocks and log statements. Do not simplify logic unless explicitly requested.

效率提升最明显的地方在于，Composer 能同时修改多个文件。它在创建新类、删除旧代码、更新导入路径这三个步骤之间是无缝衔接的。比如它在拆分完 PaymentService 后，会自动回到原文件把 this.processPayment() 改为 this.paymentService.processPayment()，这种跨文件的原子操作比在 Chat 里复制粘贴代码块快了不止一个数量级。

如果遇到 AI 重构后导致类型报错，别急着手动改，直接在编辑器里选中报错代码，按 Cmd + K 输入 Fix type mismatch based on new structure，它会快速对齐新旧模块的接口定义。

这种“全局感知 → 计划确认 → 跨文件执行 → 局部微调”的链路，是我目前处理烂代码最高效的方案。