把fetch换成safeFetch，Cursor比全局替换聪明在哪

上周我在一个屎山项目里改了 47 个文件，花了......算了，老实说。

11 分钟。

没吹牛。Cursor 那个多文件批量编辑，把两天活儿压到了一杯咖啡的时间。但真没你想的那么简单——我踩的坑够写个小册子了。跟你唠唠，省得你也掉进去。

那个让我想砸键盘的下午

去年 11 月接了个 Next.js 14 的项目，需求听着特简单：把全部 API 路由的 fetch 换成公司内部封装的 safeFetch，顺便统一错误处理逻辑。

老板说两小时够了。

我打开一看，42 个路由文件，每个里 fetch 出现 3 到 15 次，有的嵌套在 .then() 链里三层，有的是 async/await，还有些写法我盯着看了十分钟没看明白——后来才反应过来是上家离职同事从 StackOverflow 抄的。

那一刻我想起《黑客帝国》的代码瀑布。只不过我不是 Neo，我是那个看得想吐的人。

编辑模式 vs 全局替换，真不一样

等等，这里我要更正一下。很多人觉得 Cursor 就是个高级点的 Cmd+Shift+F，我以前也这么想。直到有一次把 user_id 全局替换成 userId，顺带把 Prisma schema 里数据库字段也改了。DBA 追了我三天。

傻逼了。

Cursor 真正牛逼的不是替换，是它大概能看懂你想干嘛。

给你看个对比。

普通替换：

把 A 换成 B → 所有文件里的 "A" 都变 "B"

Cursor 编辑模式：

把 API 路由文件里的 fetch 改成 safeFetch，
参数结构别动，catch 块加上 Sentry 上报

一个就是个正则引擎。另一个......嗯，像个读过你代码的实习生。偶尔犯浑，但起码知道上下文。

先让它看懂你的意图

刚开始我特傻，直接说"把 fetch 替换成 safeFetch"。

它确实做了。然后发现 safeFetch 里还有 fetch 调用，它又把那些改了一遍。套娃了。

别笑。你早晚也会遇到。

正确的路子：

1. 先手动改一个文件，让 Cursor 看明白你想要的

2. Ctrl+K 呼出面板，写清楚指令

3. 把边界说死："只动 src/app/api 下的 .ts 文件，别碰其他目录"

我现在用的指令模板长这样：

参考我刚在 users/route.ts 里改的，把 api 目录下所有路由文件的 fetch 调用改成 safeFetch，参数结构和类型标注保持原样，catch 块里加 captureException 上报

拆开看就三个东西：

• **参考样本**（你手动改的那个）
• **范围**（路径或匹配规则）
• **边界**（什么不能动、什么必须加）

缺一个，翻车概率直接翻倍。我试过。

分批搞，别贪

有次我膨胀了。让 Cursor 一口气处理 60 多个组件文件，把状态管理从 useState 迁到 useReducer。

它咔咔改，我看得热血沸腾。

改完一跑——43 个报错。

有些 reducer 类型定义没跟上，dispatch 写得驴唇不对马嘴，还有个文件它直接跳过了。我去看那段代码，沉默了。那是我三年前写的，一个 200 行的 useEffect，依赖数组里塞了 7 个变量。不怪 AI，我自己都看不懂。

血的教训：

• **15-20 个文件一批**，改完就 git add -p
• **每批之间跑一遍测试**，别等全改完
• **按复杂度分组**，简单的先让它搞，复杂的最后自己上

看起来保守。实际上比一口吃成胖子快得多——因为你不用花半天修 bug。这道理我也是 2024 年春节加班那会儿才想明白的。

给它一张地图

这个是提升准确率的关键。Cursor 默认把每个文件当孤岛，但真实项目里文件之间互相引用。你改了个导出函数签名，所有 import 它的文件都得跟着动。

我的做法：项目根目录扔个 CONTEXT.md。

# 项目上下文
- 组件导入统一用 `@/components/xxx`
- API 函数在 `@/utils/api.ts`，用 safeFetch 包装
- 类型定义在 `@/types/` 下，组件 Props 单独文件
- 错误处理用 try/catch + captureException
- Node 版本 20.11.1，别用太新的语法

每次批量编辑前，先让它读这个：

先读 CONTEXT.md，然后把 api 目录下所有 fetch 调用改成 safeFetch

准确率直接从 70% 蹦到 90% 以上。相当于给了它一张地图，不是让它摸黑过河。

diff 是你的救命稻草

说个真实翻车记录。

去年 12 月 19 号，改完 12 个文件，瞟一眼觉得挺好，直接 commit push 上线。两小时后客服群炸了——支付流程挂了，因为 Cursor 把某个条件判断里的 >= 改成了 <。我看 diff 的时候手太快，没注意到。

那个 bug 造成的影响......大概损失了两百多单吧。领导没骂我，但那沉默比骂人还难受。

现在我的流程是铁律：

1. 用 Cursor 内置 diff 逐个文件过（别用 git diff，太累眼睛）

2. 死盯逻辑条件、类型转换、正则表达式，这三个是重灾区

3. 让 AI 自己总结改了啥

变更摘要我这么要：

总结你刚才做的修改，按风险排序，标出可能影响业务逻辑的地方

它会老实交代。有时候坦白得让你心惊——"我把 3 个文件里的错误处理简化成只返回 null，可能丢失错误上下文"。

嗯...这个其实挺矛盾的。它知道有问题还这么改，但你不问它就不说。所以得问。

别让它动你没搞懂的代码

听起来像废话对吧。

但太容易犯了。

上个月让 Cursor 重构某个目录下所有 utils 函数，把函数式写法改成现代版本。它改到一个递归函数，我看一眼觉得没问题就过了。

后来线上出了个极端 case 的 bug，我去查那个递归函数，发现 Cursor 把尾递归优化给改没了，深层嵌套下直接 RangeError: Maximum call stack size exceeded。

我连那段递归逻辑都没完全搞懂，就敢让 AI 去改。

现在我的原则：一个文件里的逻辑我自己讲不清楚，就别让 AI 碰。要么先啃明白再改，要么标成手动处理。这条规矩救了我好几次。

真实数据

说了这么多，给你看看数字。

同一个需求（迁移 40+ 个 API 路由的错误处理），我的三次经历：

| 方法 | 时间 | Bug 数 | 心情 |

|------|------|--------|------|

| 纯手动 | 6 小时 | 3 个 | 想转行 |

| 无脑全量 AI 改 | 20 分钟 | 17 个 | 更想转行 |

| 分批 + 检查 + 上下文 | 45 分钟 | 2 个 | 觉得自己又行了 |

省了 85% 时间，bug 反而比手动改还少。那两个 bug 还是我自己漏看 diff 造的孽，不关 Cursor 的事。

最后说两句

AI 编程工具没那么神，也没那么坑。它就是个涡轮增压——你技术好，它让你飞；你技术烂，它让你撞得更快。这话我跟好几个朋友说过，他们都说对。

Cursor 多文件编辑真正厉害的地方，不是替你写代码，是让你把精力花在决策上，不是执行上。具体怎么改、边界在哪、风险点是什么，这些还是得你拍板。至少 2025 年是这样。

我花了大半年才从"这玩意儿靠谱吗"过渡到"没它我浑身难受"。希望你看完能少走点弯路。

你在用 Cursor 批量编辑时踩过什么坑？或者有没有更骚的操作？评论区聊聊，我跟你一起骂，或者一起学。

标签: #Cursor #AI编程 #开发效率 #实战技巧 #工具分享 #前端开发

相关阅读:

• 《我用 Cursor 三个月，删库跑路的冲动少了 80%》
• 《AI 帮你写代码可以，但别让它替你做架构决策》