72个文件10分钟改完，省下撸串时间

上周我用Cursor改一个重构需求，改了18个文件，差点把自己送走。手残党真的伤不起。

后来发现这玩意有个隐藏技能——一键批量编辑多个文件，整个人生都亮堂了。今天把这些血泪经验倒出来，免得你走我的弯路。

先讲个鬼故事

刚入职新公司那会儿，leader扔给我一个需求：把整个项目的日志库从log4j换成logback。我心想这不就是全局搜索替换吗，Ctrl+Shift+F走起。

结果你猜怎么着？

72个文件。

手动改了一下午，还漏了3个配置文件。上线当天凌晨两点被报警炸醒，群里消息疯狂@我，leader发了句"明天来我工位聊聊"。

那种窒息感，懂的都懂。

如果当时会用Cursor的多文件编辑模式，这活儿10分钟就能干完，还能赶上晚饭撸串。这不是夸张，是真能省命。

实战一：全局依赖替换的正确姿势

就刚才说的日志库替换，最经典的场景。看看Cursor怎么操作。

第一步：Cmd/Ctrl + Shift + F 打开全局搜索，搜 import org.apache.log4j。Cursor右边会列出所有命中的文件，带文件名、行号、匹配内容预览。

第二步：别急着一个个点开改。搜索结果面板右上角有个「Open in Editor」按钮，点它。所有包含匹配内容的文件会同时打开，像浏览器标签页一样堆在那。

第三步：这时候随便点开一个文件，Cmd/Ctrl + Shift + L 选中所有匹配项，然后多个光标下把 import org.apache.log4j.Logger 改成 import org.slf4j.Logger。

等等，这里我要更正一下。

刚才说的第三步其实有个坑——改一个文件的时候，其他文件并不会自动同步。我一开始以为会同步，结果改了半天发现只有当前文件变了，白忙活。真正的批量操作在下面。

正确姿势是用AI Chat面板：

打开Composer（Cmd/Ctrl + I），直接说：

"帮我把当前打开的所有文件中的 `import org.apache.log4j.Logger` 替换成 `import org.slf4j.Logger`，同时把 `Logger.getLogger` 调用改成 `LoggerFactory.getLogger`"

Cursor会遍历所有已打开的文件，一次性完成修改。你只需要检查diff然后点一下「Apply All」。

搞定。

踩坑提醒：别一次性改太多不相关的东西。我上次自以为是，让AI同时改导入、变量命名、异常处理，结果diff排了十多页，光检查就花了半小时。记住：一次只干一件事，分批提交。

实战二：跨文件重构组件名

这个是我2024年11月做的真实案例。项目里有个 UserCard 组件要改名叫 MemberCard，涉及20多个文件：组件定义、引用、测试、路由配置、文档。

传统的全局替换会出大问题。因为 UserCard 可能出现在字符串里、注释里、甚至是API返回的字段名里，直接替换直接炸。我见过有人这么干过，然后加班到凌晨三点修bug。

Cursor的正确用法：

1. 先搜 UserCard，拿到所有引用位置

2. 在Composer里下指令：

"重命名 UserCard 组件为 MemberCard，注意：

- 修改组件文件名和组件定义

- 修改所有 import 引用

- 保留字符串中的 UserCard 不变（比如注释和文档）

- 保留API字段名 userCard 不变

- 同时更新测试用例"

Cursor会逐个文件分析上下文，智能判断哪些该改哪些不该改。

我实际跑了之后，20个文件只错了一处——它把一段错误日志里的 "UserCard not found" 也给改了。这种字符串在运行时是用于错误追踪的，改了反而不好排查问题。我后来在指令里加了一句"保留所有日志和错误消息中的原始字符串"，就没再出过这问题。

所以你的指令越具体，结果越靠谱。 别装大款说"帮我重构"，要说清楚边界条件。据我了解，很多同事就是在这上面栽跟头的。

实战三：给多个文件统一加错误处理

这个技巧估计很多人不知道。

上周我在处理一堆API接口文件，大概15个service文件，每个里面都有三四百行的业务逻辑。但全部没有try-catch。

前人留下的代码，嗯...这个比较复杂，就不展开吐槽了。

一个个文件加try-catch会死人的。但用Cursor的多文件编辑，操作是这样的：

在Composer输入：

"给所有已打开文件的async函数包裹try-catch，catch块里用logger.error记录错误，并重新throw。保持原有代码缩进，不要改变其他逻辑。如果函数中有参数校验的early return，try-catch只包裹可能出错的异步操作部分。"

15个文件，大概3分钟搞定。我检查了一下，缩进、逻辑、变量作用域全部正确。

但这里有个坑：如果你的函数里有early return语句，AI可能会把try-catch放错位置。比如：

async function getData(id) {
 if (!id) return null; // early return
 const res = await fetch(...) // 这才是需要包裹的部分
}

AI可能会粗暴地把整个函数体包起来，包括那个 return null。我觉得这个问题跟AI的训练数据有关，它倾向于把整个函数体当成一个块来处理。所以指令里最好加一句丑话说前头，省得后面擦屁股。

我踩过的最惨的坑

说个糗事让你开心一下。

2024年9月，我重构一个电商项目，要把购物车相关的逻辑从6个文件拆到12个文件。我想着Cursor这么牛逼，直接让它在Composer里批量操作。

结果我没注意到它改了项目的入口文件，把一个懒加载路由的import语句给改了。上线后用户点购物车就白屏，报错：

Error: Cannot find module './pages/Cart'

更惨的是这个问题在灰度阶段没测出来——我们灰度只切了5%用户，偏偏这一批用户都没点购物车。

全量发布半小时后，客服电话被打爆。我那天晚上十一点还在公司回滚，外卖都凉了。

问题根源：批量操作时我没仔细检查所有diff。入口文件隐藏在十几页变更里的倒数第二页，我扫了一眼就Accept了。

从那以后我定了个规矩：

1. 超过5个文件的修改，必须逐个检查diff，一个都不能跳

2. 涉及路由、入口文件、配置文件的改动，单独处理，不跟其他文件一起批

3. 改完先跑一遍完整的测试套件，别偷懒

血的教训。

一些野路子技巧

再说几个官方文档不会教你的：

技巧一：用TODO标记批量处理点

如果需求很复杂，别一上来就让AI改。先在所有要改的地方加TODO注释，比如 // TODO: refactor to use new logger。完了之后全局搜索这些TODO，打开所有含TODO的文件，再让AI根据TODO的描述统一处理。这样你心里有数，改了多少个地方一清二楚。

技巧二：先让AI生成改动计划

动大改之前，在Composer里先问一句：

"我要重构UserCard为MemberCard，涉及约20个文件。请先列出需要改动的文件清单和各自改动的内容，别动手改，我先看看。"

AI会给你一个改动计划，你确认没问题了再让它执行。这步省了我无数次返工。大概省了...嗯，反正很多次。

技巧三：把改前改后存成git stash

进行大范围多文件编辑前，用 git stash 存一下当前状态。改完了别急着commit，用 git diff 全局过一遍。看diff的时候注意颜色标记——新增的绿色和删除的红色，确保每处改动都在你预期之内。如果担心漏看，git difftool 可以逐个文件展示，比看终端舒服多了。

什么时候不该用多文件编辑

最后泼点冷水。以下几种情况，老老实实手动改：

1. 改动涉及业务逻辑判断（比如"VIP用户走新接口，普通用户走老接口"）。AI不理解你司的业务规则，让它批量改这种逻辑等于赌博。我试过，翻车了。

2. 文件之间改动模式不一致。如果你要改10个文件，但每个文件的改动逻辑都不同，那Composer的批量操作反而容易搞混。

3. 你不确定要改哪些文件。这种情况下最好先手动确认文件范围，别让AI替你做决定。

Cursor的多文件批量编辑，省时间的核心不是"改得快"，而是"检查得快"。你把重复劳动扔给AI，把精力省下来做决策和验证，这才是正确打开方式。

真香。

说个事：最近我在整理一套Cursor高阶使用技巧，包括怎么给Composer写提示词模板、怎么用Rules功能定制团队规范。感兴趣的话评论区扣个"蹲"，人数多了我下周就发出来。

你平常多文件编辑还有哪些骚操作？评论区聊聊，互相抄作业。

#Cursor #多文件编辑 #批量重构 #AI编程 #程序员效率 #踩坑记录 #前端工程化