上周三下午我把屏幕切成两半左边 Cursor 在给我补一个刚聊出来的导出模块右边终端里的 Claude Code 正一行行读一个五年没人敢碰的订单结算类。两个工具同时在跑风扇呼呼转但那天我干了平时两天的活。这就是我现在固定的双 IDE 工作流——Cursor 负责写新功能Claude Code 负责啃老代码。这套东西不是什么玄学配置就是把自己当项目经理把两个 AI 助手当两个性格完全不同的下属一个手快、爱表现、敢想敢写另一个话少、耐心、翻遍整个仓库才肯开口。你要做的就是把活儿分对。这篇分享主要讲三件事为什么要把新功能和老代码拆给两个不同的工具、两边各自的实操步骤和配置细节、以及并行跑的时候那些必然会踩的坑。适合已经在用 AI 写代码但总感觉效率没提上来的人也适合刚装好工具、还不知道怎么下嘴的新手。全文不讲概念只讲我怎么干的。1. 双 IDE 工作流的底层逻辑把创造和考古拆开1.1 新代码和老代码压根是两种活儿我带的项目里活儿的性质差别特别大。一种是新增新接口、新页面、新的数据处理流程需求是上面刚聊出来的代码库里根本没有对应实现你需要的是一份能跑、结构看得过去、能被同事 review 通过的初稿。另一种是改造一个 2019 年写的模块当年的人早走了注释只有一句临时方案后续优化现在要加一个字段、换一个计算口径或者干脆把它从同步改成异步。这两种活儿的脑力消耗结构完全不同。写新代码难在想清楚要什么。你脑子里的画面一旦清晰代码其实很快。所以这种活儿适合让一个上下文感知强、补全速度快、能跟你来回对话的工具来干——它看着你当前打开的文件、看着你光标附近的内容猜你下一步要写什么。写老代码改造难在搞清楚现在是什么。你需要的不是快是耐心把十几个文件串起来读一遍搞清楚这个字段是谁写的、谁读的、什么时候被清空、有没有地方靠它的空值做判断然后才敢动第一刀。这种活儿需要一个能自己满仓库乱逛、主动去 grep、去读文件、去追调用链的工具。把这两种活儿塞给同一个工具结果就是两边都拉胯。用对话式工具去啃老代码你得手动把十几个文件贴进上下文贴到最后自己都乱了用终端智能体去从零写新功能它会过度思考动不动就给你来个重构写出来的东西比你想要的复杂三倍。1.2 我的分工原则与工具选型理由我的原则一句话能说清手边有明确目标、要产出新文件的活儿交给 Cursor目标模糊、要理解存量代码的活儿交给 Claude Code。选这两个工具不是随便挑的。Cursor 本质上是编辑器它的优势是贴着你的手——补全、Tab 跳转、选中一段然后按快捷键让它改、多文件同时改。它跟你的编辑动作是融为一体的你改一行它立刻知道你打开一个文件它立刻读。这种紧耦合天生适合边想边写。而且它的界面就是 IDE你原有的插件、主题、快捷键、终端、调试器都在迁移成本几乎为零。Claude Code 是终端里的智能体它的优势是自己有手脚。你给它一句话它会自己去列目录、自己去搜关键词、自己去读十几个文件、自己跑测试命令然后回来告诉你结论。它不需要你把文件一个个拖进来也不需要你告诉它这个类在哪个目录。这个特性在存量代码里价值巨大因为老代码最大的问题就是你不知道你不知道什么——你连要读哪些文件都不清楚怎么可能手动喂给它。一句话总结选型逻辑谁掌握的信息多谁就干那部分活。Cursor 掌握的是你当前视野里的信息适合局部深挖Claude Code 能主动获取全仓库信息适合全局扫描。1.3 这套工作流适合谁、不适合谁先说适合的。第一种手上有一定规模的存量项目同时在迭代新功能的人。你的仓库大到你自己都记不清所有模块这时候双工具收益最明显。第二种接手别人项目的人。你要快速搞清楚一个陌生仓库的结构Claude Code 那一套先画地图再动刀的流程能省你几天时间。第三种独立开发者或者小团队。没人跟你结对编程AI 就是你的结对伙伴两个不同性格的伙伴刚好互补。再说不太适合的。如果你的项目就是几百行脚本或者你每天都在写完全独立的小工具那单开一个工具就够了双开纯属给自己找麻烦。还有一种情况要先缓一缓如果你的代码里有大量不能外传的核心资产或者团队对代码外发有严格规定那在配置和使用之前先跟你们负责人把边界聊清楚这个前提比什么技巧都重要。注意这套工作流的价值来自分工不来自同时开两个窗口。如果你两个窗口干同一件事那只是把成本翻倍。2. 环境搭建Cursor 与 Claude Code 的安装与中文配置2.1 Cursor 下载安装与界面汉化的完整步骤Cursor 的安装没什么门槛去官网下对应系统的安装包Windows 是 exemacOS 是 dmgLinux 有 AppImage 和 deb。装完之后第一次打开会让你导入 VS Code 的配置——这一步很关键一定要选导入它会把你原来的插件、主题、快捷键、代码片段一起搬过来省掉一两个小时的重新配置。如果你之前用的是别的 IDE比如 Java 生态那套导入不了也没关系核心插件重新装一遍就行。界面汉化这块我被问过太多次。Cursor 是 VS Code 的分支所以汉化方式跟 VS Code 一样两步搞定按CtrlShiftPmacOS 是CmdShiftP打开命令面板输入Configure Display Language回车。在列表里选中文(简体)。如果列表里没有中文会提示你安装语言包点确认它会自动装好简体中文语言包装完重启一下就是中文界面了。如果你在命令面板里找不到那个选项还有一条备用路径左侧扩展面板搜索Chinese (Simplified)找到微软官方那个中文语言包点安装然后重启。这个方法更直观适合不想记命令的人。提示装完中文界面之后建议把几个 AI 相关功能的快捷键先过一遍在设置里搜索快捷键把接受建议拒绝建议触发内联编辑这几个改成你顺手的组合。这一步花五分钟后面每天省很多次手部动作。装好之后还有一个设置我强烈建议打开在设置里搜format on save打开保存时自动格式化再搜auto save改成失焦自动保存。AI 生成的代码经常有缩进和空行的小瑕疵自动格式化能帮你抹掉一大半评审的时候不至于因为格式问题被退回。2.2 Claude Code 的安装、登录与终端接入Claude Code 是命令行工具装法很直接。前提是你的机器上有 Node.js版本不要太老18 以上基本没问题。装之前先确认node -v npm -v两个命令都能正常输出版本号就可以装了npm install -g anthropic-ai/claude-code装完之后在任意项目目录下敲claude第一次会走一遍登录或者配置凭证的流程跟着提示走完就行。凭证配置好之后它会把配置存在用户目录下后续不用重复登录。关于在 IDE 里用有两条路。第一条是纯终端在 Cursor 里按Ctrl打开内置终端直接在项目根目录敲claude。这样做的好处是上下文统一你 Cursor 里打开的就是 Claude Code 要读的那个目录不容易搞错仓库。第二条是装 IDE 插件把 Claude Code 的能力挂到编辑器面板里。我个人更推荐第一条原因下面会讲。有一类报错新手特别容易遇到敲claude提示命令找不到。九成情况是全局安装的 bin 目录没进 PATH。解决办法是先跑npm config get prefix拿到那个路径把它的bin子目录加进系统环境变量重开终端再试。Windows 上还有一种情况是权限问题用管理员身份的终端装一次就好。2.3 让两个工具共享同一份项目上下文这一步是很多人忽略的但直接影响输出质量。两个工具如果读的是不同的目录或者读到的项目说明不一致写出来的代码风格会打架。我的做法是在项目根目录放两个文件README.md给人看的讲项目是干什么的、怎么启动、目录结构大概什么样。CLAUDE.md或者你喜欢的任何名字在 Claude Code 里指定给 AI 看的写清楚技术栈、代码规范、命名约定、不要碰的目录、常用命令。这份给 AI 看的说明文件内容要写得像给新同事的交接文档不要写套话。举个例子我会写清楚接口层统一返回{code, message, data}三段结构、数据库访问一律走repository层不要在 service 里直接写 SQL、legacy/目录是历史遗留改动前必须先确认引用方。这三句话能挡掉大量返工。Cursor 那边也有类似机制就是项目规则文件。你可以在项目根目录建一个规则目录里面放几条明确约束比如这个项目用 TypeScript 严格模式、组件一律用函数式写法。规则不要写太多超过十几条它就开始忽略后面的了。我的经验是控制在 5 到 8 条每条一句话只写最容易出错的那几条。注意两个工具的规则文件内容要尽量一致。我踩过的坑是 Cursor 用两空格缩进、Claude Code 读到的说明里没写结果它按四空格改了一批文件diff 里全是格式噪音review 的时候根本看不清真实改动。3. Cursor 侧的实操新功能怎么从需求变成可提交的代码3.1 需求拆解与前 30 分钟的准备工作很多人一有新需求就直接对着 Cursor 说帮我写个 XX 功能然后拿到一坨东西改了半天发现方向不对。我的做法是先花二三十分钟做三件事。第一件把需求写成一段给同事看的话。不是写给自己看的备忘是写给一个完全不了解背景的人看的那种。你得说清楚输入是什么、输出是什么、什么情况算异常、有没有边界条件。这段话说清楚了提示词的质量自然就上去了。第二件把要碰的文件先打开。Cursor 对当前打开的文件感知最强你打开的文件越多、越相关它生成的代码越贴合项目。我会把接口定义文件、数据模型文件、一个写法类似的既有实现三个文件并排打开再去提需求。第三件找一个抄作业的对象。项目里如果已经有一个结构类似的模块我会直接告诉它参考xxx模块的组织方式按同样的分层来写。这一句能解决 80% 的风格不一致问题。AI 很喜欢自创结构你不给它参照物它就自由发挥。3.2 提示词怎么写才不返工我写过很多次提示词总结下来有效的写法是分三段先讲现状再讲目标最后讲约束。现状部分写清楚现在有一个ExportService只有一个导出全部数据的方法返回数组。目标部分写清楚我要加一个按条件导出的方法支持时间范围和状态两个筛选参数返回同样格式的数组并且要给已有方法加上参数校验。约束部分写清楚不要改动已有方法的签名、新增逻辑放在同一个类里、不要引入新的依赖。这三段写下来通常一次就能拿到七八成能用的东西。反过来如果你只说帮我加个筛选导出它会顺手帮你重构成一个策略模式多出四个文件你反而要多花时间删。还有几个实用的操作习惯一次只让它干一件事。加方法、写测试、改文档分开提别一句话塞三个任务它做完第一个就开始飘。用小范围选中来提需求。选中一个函数再提需求比在文件末尾提需求精准得多。它给的代码先看 diff 再接受。Cursor 会有变更预览别习惯性按接受。我见过太多人一路回车下去最后提交了一个把原有逻辑删掉的版本。3.3 生成结果的验收清单代码生成完我有一套固定的验收动作大概五分钟检查项具体看什么常见问题边界值空输入、超长输入、负数、时间跨天空数组直接取值报错异常路径参数非法、下游返回失败只写了正常流程命名一致性方法名、变量名跟项目现有风格混用驼峰和下划线依赖引入有没有新增第三方库为了一个小功能引一个大包既有逻辑有没有偷偷改动别的方法顺手优化了老代码日志与错误码跟项目统一规范是否一致直接抛原始异常这张表是我从无数次被打回中学来的。其中最坑的是顺手优化老代码——AI 特别喜欢在你没要求的情况下调整周边代码而这类改动往往没有测试覆盖上线才发现问题。我的应对方法是每次接受改动前先扫一眼 diff 里跟需求无关的文件只要出现的一律撤销。4. Claude Code 侧的实操老代码怎么啃才不翻车4.1 第一步永远是画地图不是改代码我在老代码上翻过最大的车就是拿到需求直接让工具改。第二次学乖了现在固定先做画地图这一步。具体怎么下指令我会让它先做四件事列出这个模块涉及的所有文件找出目标函数被哪些地方调用列出这个函数读写的数据表或者外部接口把这个函数的业务规则用中文逐条写出来。做完这四件事它给我的东西就是一张地图。我要的是这张地图不是代码。地图拿到手之后我会做一次人工核对。这一步不能省。因为 AI 读代码是按文本理解它对这个分支永远不会走到这种业务常识是没有概念的。我会重点核几件事有没有它漏掉的调用入口比如通过反射、配置、定时任务触发的有没有靠约定而不是显式代码连接的逻辑比如同名约定、日志解析有没有它理解反了的状态含义。这一步花的时间通常在半小时到一小时但它能挡住后面几天的返工。我的经验是在存量代码里读代码的时间本来就该比写代码多三倍AI 只是把这个比例还给你了。4.2 小步改造与回归验证的节奏地图确认之后改代码我固定按这个节奏走先加测试再改逻辑。让它先针对现有行为写一批测试跑通确认测试是通过的。这批测试就是你后面的安全网。一次只改一个点。比如先把字段重命名跑测试再改计算口径再跑测试。不要一次提重命名 改算法 顺带优化性能。每步都保留可回退的提交。我会在每一步之后单独提交一次信息写清楚改了什么。哪怕后面发现方向错了回退成本也就一分钟。让它自己复述改动。改完之后我习惯问一句你刚才改了哪些文件、每个文件改了什么、有什么风险。它复述的过程经常会暴露它自己都忘了的改动。关于测试这一步我要多说一句。让 AI 给老代码补测试不要追求覆盖率追求的是特征刻画把这批代码现在实际的行为固定下来哪怕行为看起来是 bug。老代码里很多奇怪的地方是业务需要你顺手修好了反而出事。测试是拿来防你手滑的不是拿来评判代码好坏的。4.3 大仓库里的上下文控制技巧仓库一大最头疼的就是上下文被塞满效果反而下降。我踩过的坑包括让它扫全仓库它读了三百个文件然后开始胡说让它改一个模块它把不相关的模块也读了一遍。有效的几条做法在合适深度的目录启动。别总在仓库根目录启动直接进到你要改的那个模块的目录再启动它的搜索范围天然就小了。先让它产出文件清单再动手。让它先列出你认为需要读的文件你看一眼把明显不相关的删掉再让它按这个清单去读。明确告诉它不要碰哪些目录。node_modules、构建产物、第三方源码这些一定要在项目说明文件里写清楚排除。它有时候会去读生成的压缩文件纯浪费。让它先写结论再展开。我习惯让它先说三句话结论我确认方向对了再让它写细节。提示如果你要改的逻辑散落在多个模块不要一次全塞给它。拆成每个模块一次会话最后你自己做整合。整合这件事人做得比 AI 好。5. 双工具并行时的冲突、报错与成本控制5.1 代码冲突与重复劳动的预防两个工具同时改一个仓库最容易出的问题是互相覆盖。我遇到过两次左边的 Cursor 在改一个工具类右边的 Claude Code 觉得这个类需要顺手重构两边同时写盘最后靠 git 才发现一半改动没了。预防办法其实很简单就是用 git 分支做物理隔离。我在同一个仓库里开两个分支feature/xxx放新功能legacy/xxx放改造两边各自提交最后自己合并。因为工作目录只有一份所以实操上我会用 git 的 worktree 能力把两个分支 checkout 到两个不同目录这样两个工具各自盯着自己的目录物理上不可能冲突。git worktree add ../project-legacy legacy/order-refactor这条命令执行完之后../project-legacy就是另一份独立的工作目录跟主目录共享同一个 git 仓库但文件互不干扰。我一般让 Cursor 开主目录Claude Code 的终端切到那个 worktree 目录里跑。还有一个隐形的重复劳动两个工具给出两套不同风格的实现你最后要花时间统一。我的应对是在动手前先定一个目标形态——比如接口签名、返回结构、错误码先写下来贴在项目说明里。这两个工具都照着这个目标形态来返工就少很多。5.2 常见问题速查表下面这张表是我这大半年攒下来的遇到问题先查这里能省不少时间。现象大概率原因处理方式命令行敲工具名提示找不到全局安装目录不在 PATH查 npm 全局前缀把 bin 目录加进环境变量界面还是英文语言包没装或者没重启装简体中文语言包后完整重启生成的代码风格跟项目差很远项目规则文件缺约束补 5 到 8 条最关键的规范改完跑不起来报找不到符号它改了别的模块没同步检查 diff撤销无关文件改动让它读老代码它开始编业务逻辑上下文太长开始猜缩小目录范围先出文件清单一次对话越聊越糊涂会话太长开新会话把结论带过去没人改的文件出现在 diff 里自动格式化或者重构关掉保存时全文件格式化只看必要改动提交里混进了缓存目录没配忽略规则检查忽略文件把产物目录排除这几条里我最想强调的还是无关文件出现在 diff 里这一条。它不是工具的问题是使用习惯的问题。养成看 diff 的习惯能挡掉一大半低级事故。5.3 额度、成本与节奏管理最后说钱和节奏这两件事直接决定你能不能长期用下去。额度和用量方面我现在的分配原则是Cursor 用在写Claude Code 用在读和查。写代码的会话短、来回快消耗相对可控读老代码动辄读几十个文件消耗大得多所以要挑重点会话不要把整个仓库的探索都扔给它。当你发现某次会话它开始反复读同一个文件、结论也含含糊糊直接中断重新开一个更聚焦的会话这比让它硬扛省得多。节奏方面我的时间分配大概是这样上午用 Claude Code 做理解和规划因为这类活儿需要连续思考被打断代价大下午用 Cursor 写代码因为写代码可以被打断切回来还能接上。晚上我会花二十分钟把当天两边的改动过一遍写清楚提交信息。这二十分钟是我整个流程里性价比最高的部分——它让你第二天打开电脑时知道自己在哪。还有个小习惯值得分享我给两个工具各建了一个待办清单文件Cursor 那边记要写但没写的东西Claude Code 那边记要理解清楚但还没搞清楚的东西。每天收工前把这份清单更新一遍第二天开工直接照着做不用重新回忆。这个习惯看起来笨但确实是我坚持最久的一个。如果你是团队里第一个用这套工作流的人还有一个非技术的坑要提醒你别在评审里说这是 AI 写的。你就正常讲你的设计思路、你的取舍、你的验证方式。评审关注的是代码能不能维护不是谁敲的键盘。你越把 AI 当普通的输入工具别人越容易接受这件事。我自己用下来最大的感受是这套工作流真正省下的不是打字时间是切换成本。以前我改老代码改到一半又想去写新功能脑子要在两种状态之间来回切切一次损耗十几分钟。现在两块屏幕各管一摊我只需要决定这一小时站在哪一边。对独立开发者来说这种不用换脑子的连续性比任何单个工具都值钱。