上周我接了一个特别憋屈的活把一个老项目的状态管理从内部 Context 迁移到 zustand触摸到的文件横跨 24 个组件还带着路由层和两个自定义 hook。我一开始老老实实打开 Cursor一个一个文件地 引用、改代码、对着 diff 反复确认。三个小时过去改了不到一半git status 已经乱成一锅粥。最后实在受不了切到 Claude Code把需求、约束、文件清单一次性扔进去18 分钟跑完 26 个文件的联动改造git diff 拉到最后一屏我甚至有点恍惚这个改动确实是我要的。从那之后我就形成了一个固定的前端工作流多文件改动用 Claude小修小改用 Cursor。这套分工不是拍脑袋定的而是建立在两个工具完全不同的交互模型和执行方式之上。这篇就当是把我过去几个月的实测经验、踩坑记录和工作流模板完整分享出来给正在纠结「到底该用 Cursor 还是 Claude Code」的人一个直接的参考。1. 为什么前端工程师需要两套 AI 工具1.1 从「用 AI 写代码」到「用 AI 管代码」大多数前端开发者刚开始接触 AI 工具的时候都会走同一个弯路把 Cursor 当成一个「能自动补全的编辑器」把 Claude 当成一个「能聊天写代码的网页」然后遇到任何问题都在两个工具之间来回横跳。我最初也是这样。直到那次 Context 迁移失败我才意识到一个关键问题AI 编程工具真正决定的不是「能不能写代码」而是「能不能理解并推进一个大范围内的代码变更」。Cursor 的本质是个编辑器它的优势是即时反馈、局部上下文、人与代码之间高频率的交互。Claude Code 不一样它是个跑在终端里的 agent可以独立分析项目结构、批量读取文件、跨模块执行修改它的心智模型是「一个能听懂指令的工程师」。所以不是「谁更强」的问题而是「谁更适合当前这个动作」的问题。局部修改用编辑器形态的工具更顺手全局改造用 agent 形态的工具更靠谱。这句话听起来像废话但真正想明白并且执行下去我的效率至少提升了一倍。1.2 两个工具的定位差异即时反馈型与工程推进型如果要把两个工具的核心差异讲清楚我会用一张表来对比。这个表我平时也会发给团队里的新人看避免他们在一个工具上死磕。对比项CursorClaude Code交互形态IDE 内的内联编辑、对话面板命令行 agent自主执行任务上下文组织以当前文件为主通过 手动引用相关文件自动扫描项目结构可同时感知多文件依赖执行粒度一行、一个函数、一个组件一个模块、一个依赖链、一次完整重构反馈方式即时 diff 预览逐行确认分阶段执行阶段性汇报进度最适合的场景调样式、修 bug、写单测、局部重构跨文件改接口、批量迁移、大规模抽象设计启动成本打开编辑器就能用需要安装 CLI配置项目级指令从这张表能直接推导出一个结论小修小改追求的是交互密度多文件改造追求的是上下文广度和执行的一致性。Cursor 在「人反复调整」的场景里胜出Claude Code 在「机器连续推进」的场景里完胜。两者不是替代关系是互补关系。1.3 我踩过的第一个坑拿 Cursor 去改全局状态管理那次失败的 Context 迁移复盘下来问题出在三个地方Cursor 的对话窗口对上下文的组织是「线性」的。我虽然用 把相关文件都引进去了但它对文件之间跨层级的依赖关系理解得很浅经常出现改了 A 组件忘了 B 组件的 import。24 个文件的改动量让对话本身变得不可维护。每次继续对话都需要重新确认「刚刚改到哪里了」这种高频率的人工对焦让我身心俱疲。核心抽象发生了变更这意味着不是简单的「照着旧逻辑改一行」而是「每个组件都要理解新的 context 从哪拿、怎么拿」。这种需要全局一致性的任务本质上是让 AI 代替我做「工程推进」而不是「代码编辑」。踩过这次坑之后我开始把改造类任务从 Cursor 里剥离出来逐步形成了「Claude Code 负责大改Cursor 负责小改」的分工。为了让你少走这个弯路下面两章我会分别拆解这两条工作流的具体操作和关键细节。2. Claude Code 的多文件改造工作流从 26 个文件到一次提交2.1 安装与项目级初始化别跳过 CLAUDE.mdClaude Code 是 Anthropic 官方出的命令行编程工具本质上是一个可以读写项目文件、执行命令、自己跑测试的 agent。安装并不复杂前提是你本机已经有 Node.js 18 以上版本npm install -g anthropic-ai/claude-code装完直接执行claude按提示完成账号登录用 Claude 账号或者 API key 都行。第一次进入项目目录运行claude的时候它会问你「是否在项目里创建 CLAUDE.md」我强烈建议你选是。CLAUDE.md是这个工具的「项目作战手册」里面写清楚项目的技术栈、目录结构、代码规范和禁止事项。每次 Claude Code 启动时都会自动读取它相当于变相给它做了一个「入职培训」。我的做法是维护一份精简的版本例如# 项目约定 - 这是一个 React 18 TypeScript 5 项目状态管理使用 zustand。 - src/components 存放通用组件src/pages 存放页面级组件。 - 组件命名使用 PascalCase普通函数使用 camelCase。 - 禁止直接修改 src/constants 下的配置文件。 - 任务结束后必须列出所有修改过的文件。别小看最后那条「列出所有修改过的文件」它能让你的审查效率变得极高也避免了 AI 悄悄动了你不希望它动的文件。2.2 让 Claude Code 干大活的正确启动姿势很多人第一次用 Claude Code 会犯一个错误扔给它一句「把 A 模块迁移到 B 方案」然后静静等结果。不出意外的话它多半会给你一个「想当然」的方案因为任务描述里缺少约束。我测试下来最稳的启动模板是「分阶段推进 关键节点人工确认」。同样以上面的 Context 迁移为例第一阶段先让它做分析与计划。我会说先扫描 src 下所有组件和 hooks梳理当前 Context 的使用链路把需要改的文件按依赖层级列出来输出一份迁移计划。这一步不改任何代码。第二阶段人工确认计划。看它列出的文件清单和改动顺序是否合理如果发现自己不想动的文件混进来了直接告诉它排除。第三阶段让它按计划逐批执行。并明确约束每改完一批文件停下来汇报一次不要一口气全部改完。第四阶段跑测试和 TypeScript 检查。让它自己处理类型报错和遗漏的 import。这套流程的关键在于你不必等它全做完再去 review而是在每一个「可能出方向性问题」的节点上插入检查。AI 工具不是不可信而是大范围改动里方向错了代价太高人工在关键节点兜底远比最后推翻重来划算。2.3 实例复盘把 prop-types 校验迁移到 TypeScript 定义这是一个非常典型的「机械但量大」的任务一个老组件库34 个组件文件全部用 prop-types 做运行时校验需求是统一改成 TypeScript 类型定义。这种任务如果用 Cursor 手动改至少要一个下午而且极易漏掉某个PropTypes.oneOf的枚举值。我用 Claude Code 的处理过程第一步在 CLAUDE.md 里临时追加一段「本次迁移规则PropTypes.string 对应 stringPropTypes.number 对应 numberPropTypes.oneOf([...]) 对应联合类型字面量每个组件新增 interface Props 并导出迁移完成后删除 prop-types 的 import」。第二步运行claude指令只有一句话「按 CLAUDE.md 中的迁移规则把 src/components 下所有组件的 prop-types 全部替换为 TypeScript 类型定义替换完成后运行 npm run type-check 并修复报错」。第三步等它跑完。期间它会多次停下来说明进度某个组件的旧 props 里有自定义 validator它选择保留原逻辑并在注释里标明某个枚举值在三个组件里重复定义它建议抽成公共类型。最终它在 20 分钟内处理完所有文件npm run type-check一次通过。我 review 了一轮 diff唯一需要手工调整的是一个组件的可选属性默认值问题。复盘这次经历Claude Code 能跑得这么顺并不是因为它比我聪明而是它能在整个项目范围内保持同一套规则的一致性。这种一致性在多文件重构中就是命根子。3. Cursor 日常小改动的生产力细节3.1 哪些活儿我会坚持留给 Cursor虽然 Claude Code 很强但它不是万能的。我现在把「需要频繁视觉反馈」和「需要连续人工决策」的活全部留在 Cursor 里具体包括调整组件的样式、间距、颜色尤其是需要不断看浏览器效果的时候。修一个具体函数的边界 bug改动范围就在几百行之内。写测试用例、补充注释、做代码格式整理。快速问答类型的需求比如「这个 hook 为什么 moment 设置无效」。需要跟代码运行结果反复比对的调试任务。这类任务最大的特点是单次改动信息量小但需要人和代码反复互动。Cursor 的即时 diff 和高频 Tab 补全在这种场景下是最舒服的硬切到 Claude Code 反而要频繁打字沟通效率极低。3.2 我每天用得最多的三个 Cursor 功能Tab 补全Cursor 的 Tab 补全不局限于单行很多时候一个函数体都能给你生成出来。我用了半年之后的体感是它对「当前正在写的代码风格」学习得很准尤其是在连续写 20 个相似组件的时候Tab 几乎成了肌肉记忆的一部分。⌘K 内联编辑选中一段代码按 ⌘K输入修改意图它会直接生成 diff 形式的新代码你可以逐行接受或丢弃。改函数逻辑、改条件判断这个功能完胜对话式修改。⌘L 结合 引用对话当局部修改需要一点全局上下文时我会按 ⌘L 打开对话面板用 引用当前文件和相关文件而不是把整段代码贴进去。这种方式适合「理解一段陌生代码再改」的场景。另外一个我很推荐的习惯是在 Git diff 视图打开的状态下使用 ⌘K。让 Cursor 直接看到当前未提交的改动它会基于你最近的修改风格来做增量调整这个细节让很多次「改了 A 忘了 B」的情况彻底消失。3.3 Cursor 的轻量配置关于 .cursorrules 与中文设置很多人刚上手 Cursor 时会到处找「中文汉化方法」。其实 Cursor 本身基于 VS Code 内核切换界面语言直接使用 VS Code 的语言设置即可按CtrlShiftPMac 上是CmdShiftP输入Configure Display Language安装 Chinese(Simplified) 语言包并选择 zh-cn重启就生效了。不需要任何第三方汉化补丁也不建议去下载来路不明的汉化包。.cursorrules这个文件我也一直在用但我的建议是「少而精」。你要是写一堆「你是一个资深前端工程师」这种空话模型其实没什么感觉。真正有效的是把你的具体偏好写进去比如- 组件样式优先使用 Tailwind CSS 类名不写内联样式。 - 接口请求使用项目封装好的 request 函数不直接使用 fetch。 - 新建组件时同步补一个 .stories.tsx 示例文件。这样的规则每一项都能直接影响产物比那些「通用大师 prompt」实用得多。每次让 Cursor 生成新组件的时候它都会自动带上 stories 文件和约定的请求封装省掉了我大量的「事后纠正时间」。4. 双工具协作的边界判断什么「小修」其实应该走「大改」4.1 三个判断标准文件数、联动性、抽象度既然分工了那最核心的问题是什么时候该从 Cursor 切到 Claude Code我给自己定了一套判断标准准确率很高影响文件数涉及 5 个文件以上的改动我默认切 Claude Code只有 1-2 个文件留在 Cursor3-5 个是一个灰色地带需要继续看下一个标准。是否涉及接口或类型协议的定义变更如果我要改的是函数签名、类型定义、路由路径、后端返回值的结构哪怕现在只改了 2 个文件我也倾向用 Claude Code。因为类型/接口一变受影响的是所有调用方用 Cursor 一个个 很容易漏。是否需要引入新的抽象只是「照当前的逻辑改个点」用 Cursor 足够但如果我打算「新建一个公共 hook 来抽走这 5 个组件的共同逻辑」这种抽象工作建议交给 Claude Code它能更快扫完所有调用点找到边界和例外。4.2 灰色地带边界模糊时的兜底策略即使有上面三个标准实际操作中还是不可避免地会遇到「说大不大、说小不小」的任务。这时候我的兜底策略是先在 Cursor 里把新抽象的具体形态写出来再用 Claude Code 做批量化迁移。举一个真实的例子有次要给项目里所有表单页统一加「未保存离开时的确认弹窗」。逻辑本身不复杂但涉及 11 个页面组件每个页面的表单提交方式还不太一样。我如果直接用 Claude Code 一把梭它很容易做出「千篇一律」的处理忽略各页面的差异但如果用 Cursor 一个一个手动改又太磨人。我的做法是先在 Cursor 里挑一个典型页面做出一个可供参考的「标准改法」确认这个改法的边界哪些页面可以复用哪些页面特殊。然后把这段标准改法和特殊页面的名单一起交给 Claude Code让它按模板做批量迁移。最终 11 个页面在半小时内全部处理完特殊页面单独走了一遍人工确认。这个模式我称之为「小工具做小样大工具做铺开」两个工具配合起来比任何一个工具单打独斗都快。4.3 别神化「自动挡」AI 之前先想清楚「改什么」用了这么久工具我最大的一个心法反而是最朴素的让 AI 改代码之前你自己至少要能在 5 分钟内说清楚这次改动涉及哪几个概念、影响哪些模块、边界在哪里。Claude Code 并不是「把你的需求变成代码」的魔法棒它更像一个执行力极强的同事——你猜不透它的想法的时候它也会给你搞出幺蛾子。有一次我给它的任务描述里少写了一句「保留旧 props 的 default 值」它非常勤快地帮我「清理」掉了结果导致两个页面在边缘条件下直接报错。所以每当任务里涉及「某些旧行为需要保留」的时候我一定会明确写进约束而不是觉得「它应该懂」。5. 实战排坑环境配置、权限管理与工作区安全5.1 在 Windows 上运行 Claude Code 的 VM Platform 报错排查很多 Windows 用户第一次运行claude时会撞上一个报错Claudes workspace requires the Virtual Machine Platform on Windows. Enable it and try again.我第一次看到这个报错也有点懵我只是想用个 CLI 工具怎么就牵扯到虚拟机平台了实际原因是 Claude Code 在 Windows 上依赖 WSL2 提供的完整 Linux 环境来执行命令和文件操作而 WSL2 需要在系统层面开启「虚拟机平台」功能。解决路径如下打开控制面板 → 程序和功能 → 启用或关闭 Windows 功能。勾选「虚拟机平台」和「适用于 Linux 的 Windows 子系统」两项确定后重启。如果重启后仍然报同样的错以管理员身份打开命令提示符执行bcdedit /set hypervisorlaunchtype auto再次重启然后运行wsl --install装好 WSL2 内核。需要提醒的是开启 Hypervisor 之后如果你平时在用一些依赖老版本虚拟化技术的模拟器某些旧版安卓模拟器或者虚拟机软件它们可能会出现冲突。我自己的处理方案是开发机保持 Hypervisor 开启模拟器相关的工作放到另一台机器或者改用支持 Hyper-V 的新版本模拟器。5.2 给 AI 开一个不会翻车的工作区Claude Code 默认是在你当前目录下直接做文件修改的。它虽然不会主动git push到远端但在本地主干分支上直接开工还是有风险的——尤其当它执行批量替换时万一改坏了你连一个清晰的回滚点都没有。我的习惯是每次让 Claude Code 做大任务之前先切一个专门的分支git checkout -b refactor/ai-migrate-context-to-zustand所有 AI 产生的改动都落在这个分支上。等 review 通过、测试跑绿之后再合并回主干。这么做还有一个额外的好处每次 AI 执行完任务git diff出来的内容就是它的「答卷」你审阅时一目了然不满意就直接丢弃整个分支 —— 成本降到最低。5.3 权限配置让 Claude Code 知道哪些不能碰Claude Code 支持通过配置来控制它能执行的操作范围。在项目根目录的.claude配置里可以设置allow和deny规则。我最常用的一套组合{ permissions: { allow: [ Read(**), Write(src/**), Edit(src/**), Bash(npm run test), Bash(npm run type-check) ], deny: [ Write(package-lock.json), Write(src/constants/**), Bash(git push) ], defaultMode: ask } }翻译一下就是读取全项目没问题但写操作只允许在src目录内可以跑测试和类型检查但不能推代码package-lock.json和src/constants下的配置都列为禁区避免它改完锁文件造成一堆无关 diff。这套配置的效果是默认情况下每一步操作都会问我但白名单内的操作自动放行白名单外但没被禁止的会提示确认。既不会被「是否允许」弹窗烦死也不会放它乱跑。实测下来批次重构任务的安全性显著提升我再也没遇到过 AI 顺手改爆配置文件的惨案。6. 我的工具分工模板可直接抄作业6.1 一周典型任务分配速查表下面这张表基本就是我日常工作的「分配器」。每次遇到需求我都会在心里过一遍这张表再决定打开哪个工具任务类型首选工具原因跨文件重命名变量/函数/文件Claude Code能自动扫描所有引用点一致性有保障修改接口签名或类型定义Claude Code类型一变影响所有调用方需要全局依赖分析从 prop-types 迁移到 TypeScriptClaude Code机械但量大同一套规则批量执行最稳调整组件内部一段逻辑Cursor⌘K上下文小、即时 diff反复试错成本低修改样式、间距、布局Cursor视觉反馈密切需要在浏览器里反复检查写单测用例两者皆可少量用 Cursor大批量用 Claude Code 铺新增一个页面/组件Cursor单文件产出为主Tab 补全效率高把一个模块拆成多个文件Claude Code涉及 import 链和依赖关系需要全局视角这张表不是我拍脑袋定的而是从「工具的执行粒度」反推出来的。核心逻辑就一句话「看得到局部」的需求丢给 Cursor「摸得到全局」的需求丢给 Claude Code。6.2 一天的开发节奏怎么安排操作细节决定效率上限。在实际工作里我一天的节奏大致是这样的上午精神比较好的时候优先安排「大改」任务。我会先把 Claude Code 的改造任务启动起来然后人盯在终端旁边看它输出分析、改动、报错。这个阶段不需要我一直敲键盘但需要保持注意力随时在关键节点喊停插话。有几次它写到一半我发现方向跑偏了马上在对话里纠正比等它全部跑完再返工节省了至少半小时。下午进入业务开发期主要靠 Cursor 顶着写。这时候我会打开浏览器开发环境一边调页面一边用 ⌘K 改逻辑交互节奏非常快思维也不会被大段的任务描述打断。临近收尾我会再回到 Claude Code 跑一遍整体检查让它看一遍所有未提交的改动自动补测试、清理无用 import、执行全量 type-check。相当于让两个工具分别承担了「开发期的推进」和「收尾期的审查」效率非常平衡。6.3 关于这套工作流我最后还想补充两句第一句是关于 prompt 的。给 Claude Code 下任务时养成一个习惯在指令最后加一句「改完后逐文件列出修改原因」。这能让它的输出从「默默执行」变成「带汇报的执行」你 review 时的压力骤降也能更早发现它理解偏差的苗头。第二句是关于心态的。工具再强前端开发的「为什么」仍然在你自己手里。Claude Code 帮我铺开了 26 个文件但决定这 26 个文件应该朝哪个方向走的人是我。多个项目跑下来我最大的体会是工具可以越用越少但对自己代码库的掌控感和设计判断永远是 AI 替代不了的核心竞争力。