一、先说一件丢人的事三个月前我接手了一个约八万行的 Node.js 老项目。当时需要给订单模块增加「部分退款加退款流水」功能我自信地评估了工期三天。结果第一天就卡住了。订单服务文件里有一个六百行的退款处理函数内部嵌套了五层 if状态字段散落在四张表里注释写着「FIXME 临时方案后面重构」落款日期是 2023 年。我用 grep 搜了两个小时依然不敢确定改动后会不会把支付回调搞崩。第三天下午我在 Cursor 里用 Agent 模式问了一句找出所有写入 refund_status 的地方画一条从支付回调到订单状态变更的完整调用链。大约四十秒后它列出了十一处引用其中三处是我完全没想到的——包括一个定时任务和一段消息消费者的补偿逻辑。那天我按时提交了代码。但老实说真正让我后背发凉的并不是这个功能有多复杂而是如果没有这些工具我大概率会漏掉那三处引用然后在上线当晚被报警叫醒。这就是我想写这篇博客的原因。我不想再写一篇「某某工具真香」的安利文而是想聊聊这两款工具在实际开发中究竟如何落地、踩过哪些坑以及它们到底省了多少时间、花了多少钱。二、我的环境和基线技术栈是 TypeScript 与 Node.js 加上 React辅以少量 Go 微服务数据库使用 PostgreSQL 和 Redis。主仓库约八万行另有三个两三万行的小仓库。工具方面Cursor 作为日常主力 IDEClaude Code 则处理终端侧的重型任务两者均使用官方订阅。统计周期为连续九十天覆盖约四个迭代和一次中型重构。基线数据取自同一人、同类任务在半年前的耗时记录 admittedly 不够严谨但方向可信。三、Cursor占我七成工作时间的副驾驶三种模式本质是三种权限级别很多人觉得 Cursor 时灵时不灵很大原因是模式选错了。我现在的选择逻辑非常简单。Ask 模式只读不改代码适合阅读陌生代码、解释报错以及确认设计意图。Plan 模式出方案经我确认后执行适用于影响面超过五个文件的改动和架构调整。Agent 模式可自主读写文件并运行命令用于需求明确的功能开发、批量修改和编写测试。有一条铁律我一直遵守权限只能从低往高升不要反过来。面对新仓库先用 Ask 摸清情况再用 Plan 定方案最后才让 Agent 动手。一开始就直接上 Agent 改大需求是我最常犯的错误——它经常一口气改十个文件项目跑不起来还得回滚重来。规则文件是性价比最高的投入在项目根目录放一个规则文件相当于给 AI 做入职培训。我的版本大概包含以下内容。语言要求使用 TypeScript 严格模式禁止 any禁止 ts-ignore。新增 API 必须同时编写 jest 单测放在同级测试目录。错误处理统一用自定义应用错误类禁止抛出裸字符串。数据库变更必须写 migration禁止手动改 schema。禁止修改 legacy 目录如需改动先提出方案让我确认。提交信息遵循 Conventional Commits。不确定时先问我不要自己猜业务含义。加上这个文件后最直观的变化是我不再需要重复强调「用 pnpm」「别动 legacy」这类废话了而且生成的代码风格终于跟团队保持一致。这是整个 Cursor 使用体验里投资回报率最高的一件事耗时不到二十分钟。两个真实提效场景第一个场景是代码考古使用 Ask 模式。选中一段看不懂的逻辑直接问这段代码为什么这么写、可能存在什么边界情况配合 Git 引用提交历史它能把当年的修复意图讲清楚。这比翻 git log 快得多而且能结合上下文进行解释。第二个场景是补测试使用 Agent 模式。我给 Agent 的指令通常是参照某个现有测试文件的写法为目标文件补充单测覆盖率不低于百分之八十重点覆盖余额不足、重复退款、并发请求这三种情况。关键在于给它一个现有文件当范本。Cursor 官方文档也反复强调这一点让它照着项目里已有的模式写而不是凭空发明一套。有了参照后生成代码的采纳率能从六成提升到九成以上。四、Claude Code那个我愿意让它自己干活的工程师如果说 Cursor 是坐在我旁边的结对编程伙伴Claude Code 更像是我派出去独立干活的人——交代好目标它就会自己去读文件、跑命令、改代码、执行测试最后回来汇报结果。项目说明文件九成的人没用好这是 Claude Code 的核心机制。它会在每次会话启动时自动读取项目根目录的说明文件内容会强制注入上下文并且会消耗 token。所以写的时候要注意两点要写机器可执行的约束别写散文要精简别把 README 整篇搬进去。我的模板包含技术栈信息如 Go 1.22、Gin、GORM、PostgreSQL 16、testcontainers。硬约束方面handler 必须有单测且覆盖率大于等于百分之七十禁止直接修改 legacy 目录涉及资金的逻辑必须先写测试再写实现所有外部调用必须有超时和重试。此外还列出了常用命令如 make test、make dev 和 linter 运行命令。另外有个实用技巧运行 init 命令让它先扫描项目自动生成一版你再在此基础上修改。这比自己从零起草快得多。Plan 模式做大改动时我一定会先切 Plan 模式。此时它只读不写会探索代码、分析影响面并给出方案但不会修改任何文件。我看完方案觉得没问题再切回正常模式让它执行。这个模式的价值在于把「做错」变成「看错」——看错方案的代价远低于改错代码的代价。子代理解决上下文污染有一次我需要在一个五十万行的 monorepo 里找某个函数的所有调用方。如果让主会话去搜大量中间结果会挤占上下文导致后面它开始「忘记」最初的约束。改成子代理之后它在自己的上下文窗口里干完脏活只把结论带回主会话整体稳定性明显提升。经验值是单个子任务如果预计会产出大量中间文本就拆给子代理。Hook从好用到可管控Hook 能在 Claude 生命周期的特定节点自动执行 shell 命令。我配了三条每次编辑后自动跑 formatter避免它写完一堆格式问题留给我禁止执行删除文件和删表这类高危命令任务完成时自动跑测试失败则中止。在团队协作中你不可能指望每个人都盯着 AI 的每一步操作。Hook 的作用就是把规则固化下来这也是我认为 Claude Code 适合进团队的核心理由。五、两者怎么分工我不会劝你在二者之间二选一因为它们的设计哲学本就不同。我现在的分工非常固定。形态上Cursor 是 VS Code 系的 IDE而 Claude Code 是终端 Agent 加桌面端。Cursor 的最强项在于高频小粒度编辑、实时补全和边看边改Claude Code 则擅长跨文件调研、批量重构和自主闭环。上下文方面Cursor 关注当前文件或已打开的标签页Claude Code 则针对指定目录整体。模型上Cursor 多模型可选Claude Code 锁定 Anthropic 自家模型。我每天的使用时长大约是 Cursor 占七成Claude Code 占三成。典型组合拳是这样的在 Cursor 里打开项目做日常开发遇到需要通盘理解或批量改动的任务时直接在内置终端里敲 claude。同一个项目、两套工具互不冲突。选型一句话总结不熟悉终端、主要写前端、想要开箱即用就选 Cursor愿意学命令行、常做重构和后端重型任务就选 Claude Code。预算够的话两个都用是最优解。六、真实收益与真实成本收益九十天统计明确需求的中小功能平均耗时从六到八小时降到约两小时。定位跨模块 Bug 的平均耗时从两到三小时降到二十到四十分钟。主仓库的单测覆盖率从百分之四十一提升到百分之六十八。因漏掉影响面导致的返工次数从平均每迭代一点三次降到零点四次。累计节省的时间大约在一百八十到两百小时。这个数字看着漂亮但我得泼点冷水节省下来的时间并没有让我少加班而是被拿去做了更多事——比如补测试、还技术债、接新需求。这其实是好事说明效率提升转化成了质量提升而不是单纯的闲暇。成本Cursor Pro 订阅费每月二十美元Claude Code 包含在 Anthropic Pro 订阅内重度月份会触发按量计费。我这三个月的总开销控制在每月一百美元以内。换算下来省下的时间价值远高于订阅费用这笔账是划算的。不过有两个成本容易被忽略。第一审查时间变长了。AI 一次改十个文件diff review 的时间比手写还要久。三路并行 Agent 实测能省百分之三十到三十五的总时间并非线性倍增多出来的时间基本花在了审查和解决冲突上。第二学习曲线是实打实的。前两周我花在调 prompt、重跑、回滚上的时间比省下的还多。熬过这个坎才有正向收益。七、踩坑清单第一条上下文偏移是头号敌人。对话轮数多了以后它会慢慢「忘记」初始约定开始自己造方法、造字段。解法是一个任务一个会话发现它在兜圈子立刻开新会话关键约束在 prompt 里显式重申。第二条它会自信地调用不存在的东西。编造 API、引用不存在的库函数、捏造类型字段都发生过而且语气极其笃定。解法是永远不让 AI 自证。跑测试、跑类型检查、跑 lint用机器验证代替人工信任。第三条过度工程化。让它写个小脚本它能给你整出工厂模式加策略模式再加三个抽象层。解法是在 prompt 里明确写「用最简单的方式实现不要抽象不要预留扩展点」。这条指令的回报率出奇地高。第四条复杂并发场景成功率低。多线程竞态、分布式锁、幂等设计这类活AI 给出的方案经常看着很对、跑起来有洞。解法是架构决策必须由人来做AI 只在既定架构内实现。这是我不可逾越的红线。第五条敏感信息。AI 生成的代码里可能出现假密钥、假凭据看着像真的。解法是密钥一律走环境变量或密钥管理服务代码扫描前置到 CI。第六条也是最重要的一条不理解就不合并。AI 写的每一行代码都必须有人能讲清楚它在干什么。做不到这一点今天省下的时间明天会以三倍代价还回来——而且是在凌晨的故障现场还。八、如果你想在团队里推别一上来就全员铺开。我见过的失败案例基本都是这么死的。第一步是单人试点周期两到四周。找一个熟悉业务且愿意折腾的人跑通一个真实小模块沉淀出规则文件、质量门禁和 AI-TDD 节奏。目标是产出一套可复制的规矩。第二步是小团队磨合周期一到两个月。扩大到三到五人统一规范和 PR 模板重点解决多人并行改同一文件的合并冲突。第三步是逐步推广但不强制一刀切。不同项目对 AI 编程的适配度差异很大让团队按自己的节奏采纳。衡量效果时也别只看「写得快」。我更关注这四个指标交付周期、线上缺陷率、技术债增速测试覆盖率或重复代码率、非作者修改该代码的平均耗时。最后一个指标尤其重要——它衡量的是 AI 生成的代码别人能不能看懂。九、结语用了九十天我的结论反而比刚开始更保守了。AI Coding 工具没有让我变成更好的程序员但它把我从「grep 两小时」「补三天测试」「回滚重来」这种低价值的苦力活里解放了出来让我有时间去做只有人能做的事判断边界、权衡取舍、为结果负责。AI 负责从 A 到 B 的高效执行人负责定义 A 和 B以及确认是否真的到了 B。这句话我会贴在显示器边上直到它成为肌肉记忆。