3月，仓库被打上“紧急”标签。14万行 Python，单体架构，没有测试，维护过它的三个前任都已离职。客户给出的窗口是3个月：拆成微服务，同时上线首期功能。
团队把主力编辑器完整切换为当时最新升级的 Cursor 4.0，按 AI-first IDE 的方式使用。它被放进四个最费时间的环节：读代码、拆模块、补测试、处理跨文件修改。项目最后用了2个月。这个结果不能全记在一款工具头上，但哪些时间是它省下来的，项目记录里看得很清楚。
第一天下班前，先把主链路找出来
过去，新成员熟悉这个项目平均要2周。跳转定义和全文搜索能找到文件，却很难直接回答两个业务问题：订单状态怎么流转，风控规则从哪里进入。
我在 Cursor 对话框里输入：
我需要理解整个项目的架构和数据流，特别是订单状态流转和风控规则引擎的入口。
Cursor 扫描项目结构并建立索引，几分钟后给出一张模块依赖图，标出模块职责、关键函数和瓶颈。它还单独指出：rule_engine.py 里的 evaluate 函数长达2000行，应该优先拆解。
第一天结束前，我们已经能说清项目主干，并确定首批拆分对象。对一个过去平均要2周熟悉的仓库，这次摸底被压到了1天。
拆服务时，先让改动跨过文件边界
我们先选中 rule_engine.py 里的一段错误码检测逻辑，给出指令：
将这段提取为独立微服务，保留接口兼容，并生成 FastAPI 路由和 Pydantic 模型。
几秒钟后，Cursor 创建了 services/fraud_detection/ 目录，其中包括 main.py、models.py 和 config.py。原文件的导入引用也被更新，旁边还多了一套单元测试骨架。
第一版并不干净。接口签名里混进了一个项目不用、数据库里也没有的参数。我补了一句：删除这个参数，改用现有 user.profile 结构。Cursor 随即重新生成，没有中断后续修改。
拆分5个主要服务时，从选中代码到拿到新文件、测试骨架和更新后的依赖，平均每个服务不到30分钟。过去手工完成同一组工作并验证，通常要2—3天。生成结果仍要审查，但第一轮改动出现得足够快，开发者可以把时间用在接口和业务规则上。
测试从零起步，先把漏掉的分支找出来
零测试的遗留代码，麻烦在于旧行为没有被写下来。我们对重点模块运行测试生成命令，Cursor 根据函数签名和调用链，补出正常流、异常流和边界条件。
以信贷风险评分函数为例，生成的用例除了正常范围，还包括负数输入、缺失关键字段、数据库返回空值。代码中出现 if user is None 分支后，它也补上了对应的 None 场景。
稍作调整后，测试覆盖率从0%提高到85%，额外手工加入的几个场景也通过了。按团队原先每天100行测试代码的估算，同样的工作至少需要4周；自动生成加人工审核用了1周。
85%只说明测试触达的代码范围。金融风控逻辑是否正确，还要按照业务规则逐项检查。
改一个字段，十几个文件一起跟
项目中的 Transaction 类原本使用 order_id 关联订单。业务方要求改成 txn_id，并增加 channel 字段。
我在 models.py 中修改属性后，对整个项目运行智能修复引用。Cursor 找到了：
- 5个数据库迁移脚本
- 4个序列化器
- 2个外部 API 适配器
- 1个 Celery 任务
另有3处动态属性访问无法自动处理，被单独高亮出来，交给我确认。整个修改用了20分钟。部署后，没有出现因字段名不一致导致的 bug。
把项目账摊开看
项目结束后，我们按原估算和实际耗时做了复盘：
| 环节 | 原估算或历史用时 | 实际结果 | 项目内折算 |
|---|---|---|---|
| 代码理解 | 2周 | 1天 | 时间减少93% |
| 模块拆分（5个主要服务） | 15人天 | 2.5人天 | 时间减少83% |
| 测试补全 | 4周 | 1周，覆盖率从0%到85% | 人力投入减少75% |
| 跨文件字段修改 | 8小时 | 20分钟 | 时间减少96% |
项目总工期由计划的3个月缩到2个月。这些比例只对应这次重构，代码质量、审核要求和团队经验一旦变化，结果也会不同，不能直接外推。
两类工作仍要人兜底
一类是非常规协程嵌套，特别是复杂的 async 回调。Cursor 4.0 在这里生成过有缺陷的代码，最后仍由开发者手工纠正。
另一类是金融风控的合规和逻辑验证。AI 生成的代码需要二次审查，测试覆盖率也不能替代业务确认。团队给 Cursor 的角色很清楚：快速产出改动、追踪引用、补测试；架构决策、合规判断和上线签字仍由开发者负责。
从补一行代码，到整理一组改动
Cursor 把自己定位为 AI-first Code Editor。联合创始人 Aman Sanger 在智源社区整理的访谈中说：“我们需要一个全新的 AI 驱动的 IDE，需要重新设计软件开发流程。”同一份访谈整理称，Andrej Karpathy 曾多次在推特上夸赞 Cursor，认为其体验“碾压式地超过 GitHub Copilot”。
落到这次项目，贡献最大的都是项目级任务：先搭出主链路地图，再把修改铺到多个文件，最后根据现有分支补测试。开发者省下的是反复查找和搬运代码的时间，精力可以回到架构取舍、业务规则和代码审查。
如果要判断是否值得迁移，拿一个有历史包袱的仓库做一次可回滚改动，比看演示更直接。先检查它能否说清调用链，再看跨文件修改和测试是否经得住审查，然后再扩大使用范围。
Cursor 4.0 在这个项目里已经参与到一组受控的跨文件改动。合并和上线的责任没有转移，仍在开发者手里。
