Cursor 已经能把代码自动化推到很远。官方在《迈向自动驾驶代码库》中披露，一套 agent harness 编排了数以千计的 Agent，系统可以连续运行一周，并为一个研究用 Web 浏览器完成绝大多数代码提交。
官方也把实验边界说得很清楚：这个浏览器不打算对外使用，代码预期存在不完美之处。对开发团队来说，这是一条直接的提醒——生成速度越来越快，改动范围、测试路径和撤退方式仍要有人控制。
大型仓库里，麻烦往往不在某一行代码，而在一份同时穿过接口、状态机、数据库和调用方的 diff。改动铺得太开，审查者很难分清哪些是结构调整，哪些已经改变了业务行为。
动代码前，先让 Cursor 把旧逻辑说清楚
知乎的一篇 Cursor 重构案例记录了一个实用动作：作者面对一段不熟悉的代码，没有立即要求 Cursor 重写，而是选中一个 150 行的函数，在 Mac 上按 Cmd+I 调出 Chat，先问清楚这段代码在做什么。
这一步可以把问题问得更具体：
先不要修改代码。请按输入、输出、状态变化、外部调用和异常路径解释这个函数；无法从代码确认的地方单独标出。
Cursor 给出的解释需要和现有测试、接口文档以及维护者掌握的业务约定对照。只要有一处对不上，就先把疑点写进 issue 或 PR 描述，暂缓生成补丁。
Easton 的 Cursor 重构指南提到提取函数、优化逻辑和添加类型注解等操作。这些任务边界清楚，适合作为第一批改动。接口迁移、数据结构变化和跨服务调用，可以留到后面的独立批次。
按行为边界切批次
一次重构可以涉及很多文件，但一个批次最好只处理一种变化。例如：
- 保持行为不变，只提取函数或补充类型注解；
- 单独迁移一个接口的读取侧或写入侧；
- 调整内部状态机，不同时修改数据库 schema；
- 准备数据迁移时，暂时保留旧调用路径。
判断批次是否足够小，可以看三个问题：当前 diff 能否由审查者完整说明，能否独立跑完相关测试，出现问题后能否清晰地撤销。如果其中一项做不到，就继续拆。
PR 标题也要写出改动边界。重构订单模块几乎没有信息量，refactor: order.state 从 string 迁到 enum，仅调整写入侧会清楚得多。半年后再查提交记录，也能知道这一批到底碰了哪里。
Cursor 可以查漏，合并仍由人拍板
每轮修改完成后，可以把当前 diff 交给 Cursor，让它只做审查，不直接写文件：
只检查当前 diff。列出行为变化、受影响的调用方、可能遗漏的测试，以及无法从代码确认的假设。
这类回答适合转成检查清单。涉及接口、数据库 schema 或跨服务调用时，仍要由人核对调用链和迁移方案。Cursor 没有指出风险，只能说明它没有发现，不能作为安全证明。
Cursor V4 的对话搜索可以帮助找回之前讨论过的约束，例如某个兼容分支为什么保留。不过，真正需要长期留存的决策还应写进 commit message 和 PR。聊天记录方便找上下文，Git 记录负责说明改了什么，也负责提供回去的路。
测试别和实现一起“自证”
开始重构前，先跑一遍现有测试并保存结果。每完成一个小批次，再用同一套命令验证。这样才能区分原有问题和新引入的回归。
需要 Cursor 补测试时，可以先让它列测试场景，再逐条审查断言，尤其是异常路径、兼容逻辑和回滚分支。如果实现和测试建立在同一个错误理解上，两边完全可能同时通过。
Smoke test 也应尽量在大范围修改前准备好。测试基线太弱时，优先缩小改动范围，别让 Agent 一边重写业务代码，一边替自己的结果出具证明。
回滚要写进分支和提交
回滚方案不该等到线上出错后再讨论。动手前，至少把下面几件事安排好：
- 每个批次使用独立分支，提交里只放一种可识别的变化；
- 新旧实现需要并存时，用 feature flag 控制切换；
- 数据库 schema 能安全回退时，提前准备 down migration；无法直接回退时，在合并前写清数据恢复步骤；
- PR 中记录影响模块、测试命令和回滚位置，避免信息只留在 Cursor 对话里。
这套做法会增加几次提交和审查，却能把一场难以判断的大改动，拆成多次可以验证的修改。Cursor V4 可以负责读代码、提取函数、补类型和检查 diff；范围确认、合并与回滚仍由开发者守住。
如果一个批次无法独立解释、测试和撤销，它还没有切得足够小。继续拆，通常比让 Agent 再重写一遍省事。
