Mustaffa 又提起了那个结算文件。
它写于 2023 年，约 8200 行 TypeScript。订单、风控、支付逻辑全挤在里面，向外导出 42 个函数，项目里还有 200 多处调用。团队此前估过，手工拆分大概要两周。
我在 Cursor 3.0 工作区打开项目，没有直接给 Agent 下“重构整个文件”这种指令。函数搬家不难，麻烦在于漏改引用、碰断调用链，最后把外围业务一起拖进来。
从打开项目到提交合并请求，任务跨了三个晚上。原文件最后缩到约 600 行，运行 tsc --noEmit，零报错。实际盯着屏幕操作的时间是 3.5 小时，另有半天花在兼容接口和迁移顺序上，这部分没有计入。
先给 200 多个调用方加一道隔离层
动代码前，我先锁定了 IOrderSettlement 兼容层。拆出的子模块可以调整目录和内部依赖，但必须原样实现这个接口，外部调用方式保持不变。
有了这层约束，改动基本能留在目录内部。每一批只处理一个子目录，Diff 足够小，审查时能看清，出问题也能整批回退。
Cursor 官方博客《AI 软件开发的第三个时代》提到，智能体要在更长时间尺度上完成更大的任务；开源中国对 Cursor 3 的介绍则提到了统一智能体工作区和多代码仓库支持。能力再强，这次也没有把 8200 行一次性交出去：每批只动一个目录，检查完 Diff，再决定是否继续。
Ask 画依赖图，Agent 按目录搬
旧版 Composer 没有上场。分析交给 Ask，改文件再交给 Agent。
我给 Ask 的指令是：
梳理当前文件的依赖树，按调用深度列出 42 个导出函数，并按订单、风控、支付归类，给出建议的目录结构。
不到 10 秒，Ask 给出了一份归类结果：1 个订单基类、9 个风控校验函数、32 个支付与结算函数。其中 4 个函数藏着隐式闭包引用，需要单独处理。
迁移从依赖较少的风控开始，接着是支付与结算，顶层聚合逻辑压到收尾。这样能避免一上来就生成难以审查的大 Diff。
知识铺收录的一篇 Cursor 指南提到，可以先设计提示词模板，再交付具体任务。我把这个思路压缩成三条约束，并固定到每一轮指令里：
IOrderSettlement不能改；- 每批只动一个目录；
- 每批修改必须能单独回退。
周一 19:00，Logger 让第一批返工
第一批迁移的是 9 个风控函数，目标目录为 risk-checks/。Agent 新建文件、迁出原函数，并更新内部引用。
审 Diff 时，一个边角函数暴露出对外部 Logger 的依赖。首版迁移没有处理好这条关系，我把整批修改回退，在指令里明确要求将 Logger 作为显式依赖带入，然后重新生成。
这一晚用了 1.5 小时，处理约 800 行逻辑。
周二 20:00，Agent 越过了接口边界
第二批是 32 个支付与结算函数。这里的隐式作用域依赖更多，第一版迁移出现了变量丢失。
Agent 给出的修复思路是引入类继承，但这会碰到已经锁定的兼容层。我直接回退，并把要求写得更窄：
仅通过参数传递解耦，禁止修改现有函数签名，提取必要的纯函数。
调整指令后，Agent 改用纯函数导入，最终生成 30 多个文件。这一轮用了 1 小时，整理约 2500 行逻辑。
周三 21:30，主文件缩到约 600 行
收尾处理的是调用关系最重的聚合部分。迁移完成后，原文件还剩约 600 行，主要负责流程编排。
Agent 随后清理了失效的 import，并补齐 TSDoc 注释。最后运行：
tsc --noEmit
结果为零报错。三个晚上的时间段包含 Agent 在后台执行的等待，实际交互仍按 3.5 小时记录。
3.5 小时不能直接换成 320%
把这次结果写成“效率提升 320%”并不严谨。两周是人工拆分的预估，3.5 小时只计算屏幕前的操作，还漏掉了半天的接口设计和迁移规划。口径不同，直接计算比例没有意义。
这次也没有可引用的 Token 账单，无法给出成本回报数字。能够确认的是，Cursor 接手了依赖梳理、文件创建、引用更新、import 清理和注释补充。接口怎么留、从哪一层开始拆、遇到什么情况立即回退，仍由人判断。
tsc --noEmit 零报错只说明类型检查通过，业务回归仍然要做。长上下文和失败重试也会增加 Token 消耗，因此小批次和可回退的 Diff 不能省。
能落到纸面上的结果很具体：约 8200 行的单文件被拆开，外部 200 多处调用没有被拖进改动，主文件收回到约 600 行。Cursor 没有为这套结算逻辑发明新算法，它按约束完成了大量模式化迁移。对遗留代码重构，这比一个口径含混的效率倍数更值得保留。
