我拿Claude死磕支付模块4轮全崩，换Gemini一次就找到真凶

---

别再让一个模型干所有活了——我上周差点把支付模块搞崩

先说结论：用单一模型硬刚所有场景，等于拿螺丝刀撬钉子——能撬，但你会累死。

上周五晚上十一点，我还在跟一个支付模块死磕。

Claude 3.7 已经给我生了300多行代码。每次都说“这次一定行”，跑起来就报错。修了四轮。四轮啊兄弟们。我盯着屏幕，眼睛都快瞎了，突然想起 Cursor 首席设计师 Ryo Lu 说过的话——模型是独一无二的，就像人类一样。

行吧，换个思路。

我把同样的报错信息丢给 Gemini 2.5。这哥们儿沉默了大概15秒。

然后给出了一个让我拍大腿的答案。

问题不在支付逻辑，在上游的用户权限校验里。有个异步处理没等结果就往下跑了。Claude 3.7 一直在修支付模块，压根没找对地方。Gemini 2.5 一次就定位到了。

绝了。

模型不是万能工，得学会派活

这事儿让我重新理解了模型选择。之前我总觉得 Claude 3.7 最强，什么活都让它干。但 Ryo Lu 那个比喻很精准：Gemini 2.5 像个高级软件工程师，需要推动；Claude 3.7 是个过度思考者，热衷使用工具，需要驯服；Claude 3.5 是全能高手，依然稳。

说白了，你得学会给不同的模型派不同的活。

我现在的工作流是这样的——用 Claude Sonnet 3.5 写代码。对，3.5 在执行层面比 3.7 更听话。3.7 老想着“优化”，结果越改越乱。遇到复杂 bug 就丢给 GPT o1 或者 o3-mini-high 去调试，这俩定位问题的准确率大概在 85% 以上，比我手动排查快 3 倍。需要扫描整个代码库更新文档的时候，用 Gemini Flash 2.0，速度贼快，2000 行代码扫完不到 30 秒。

至于 Gemini 2.5，它现在是我用 Claude 解决不了难题时的救命稻草。一个被严重低估的编程模型。真的。

上下文工具用不对，代码白写

说到文档，Cursor 官方最近专门出了一篇指南，讲怎么用好 @Docs、@Web 和 MCP 这三个上下文工具。我实践下来，发现很多人压根没搞懂这三者的区别。

@Docs 是直接连到官方文档的接口。 比如你用 Next.js，文档已经更新到 2025 年 5 月了，但 Gemini 模型的训练数据只到 2025 年 1 月。不用 @Docs 的话，Cursor 给你的建议可能是过时的。

我踩过这个坑。生成的代码在运行时各种报错，查了半天才发现是 API 已经改了。浪费了我整整 3 个小时。

@Web 是联网搜索，适合找社区教程、不同角度的解决方案。MCP 是访问企业内部文档的，比如公司自己的 API 规范、编码标准。这三者各管一摊，别搞混了。

有个技巧很多人不知道：处理不熟悉的技术栈时，可以直接粘贴文档链接让 Cursor 逐行解释错误和修复。获取最新文档链接可以用 Context7 这个工具——context7.com——或者直接装 Context7 MCP，每次对话时加一句“使用 context7”就行。巴适得很。

大型项目？让它整夜索引

说到大型项目，Cursor 官方给了个建议：让项目整夜索引。

我第一次听到这个建议的时候笑了。真的。但后来发现 Codebase Indexing 在处理大型项目时确实需要数小时甚至更久。我当时用的 MacBook Pro M2，一个 5000 文件的项目，索引跑了大概 4 个半小时。晚上跑完，第二天早上来用，体验完全不一样——代码跳转、智能补全的准确率从 60% 飙升到 90% 以上。

限制上下文范围也能保持性能敏捷，别什么都往上下文里塞。我见过有人把整个 node_modules 都索引了。

翻车了。

官方还强调了一个点，我深以为然：规划先行。

在让 Agent 写代码之前，先用 Plan Mode 把需求理清楚。我见过太多翻车现场了——前期不拆分，中期不审查，后期代码一坨屎，跑不起来还改不动。正确姿势是把项目拆成小模块，一个一个让 AI 写，写完就测试、审查。每个模块控制在 200 行以内，超过这个数就容易出问题。

不同工具，不同场景

说到拆分，Cursor 官方对不同工具的使用场景也给了建议：Tab 做快速编辑，Cmd+K 做专注修改，Chat 模式做大规模改动。 大型项目重构时，初期规划用 Chat 模式分析项目结构，结合 @folder 理解全局上下文，制定重构计划。

这个方案——不对，应该叫策略——我现在一直在用。讲真，效率提升了至少 40%。

开局先立规矩也很关键。在 .cursor/rules/ 目录下建个文件，写上 5-10 条清晰规则，告诉 AI 你项目的技术栈、版本、约束条件。比如“Always use const or let, never var”，“Use snake_case for variable names”。老项目可以用 /generate rules 让它自己学，省时省力。

提需求也得具体。别说什么“帮我做个按钮”，要说清楚用什么框架、什么样式、什么交互。Prompt 写得好，AI 才不跑偏。我现在的 prompt 模板至少包含 4 个要素：技术栈、功能描述、样式要求、边界条件。

0.50 版本的新变化

对了，Cursor 0.50 版本前几周上线了。计费模式更清晰了。Pro 套餐还是 500 次快速请求加无限次慢速请求。没大脑图标的消耗 1 次，有大脑图标的消耗 2 次。Claude 3.7 默认只能 thinking，所以每次消耗 2 次——这个有点坑，但没办法。

Max Mode 是解决上下文超了的问题的，按 Token 算钱。超过 100K token 效果也会减弱。大概是这个数吧，官方文档里写的是 120K，但我实测到 100K 就开始不稳定了。

还有个新 Tab 模型，跨文件编辑更丝滑了，补全建议还带上了语法高亮。你在 A 文件里改了个函数名，去 B 文件里改调用，它自动就帮你处理了。这玩意儿快得像开了挂。

20 美元到底值不值？

写到这里我突然想起一件事。

很多人问我 Cursor 到底值不值那 20 美元一个月。我的回答是：如果你只会用一种模型、一种模式去解决所有问题，那确实不值。但如果你学会了根据不同场景选择合适的模型和工具，这 20 美元可能是你每个月最划算的一笔投资。

你可能会问，那 Auto-select 模式怎么样？

说实话，我之前一直觉得它不够智能。但最近实测下来，大部分时候是好用的——准确率大概在 80% 左右。它会根据当前需求选择最适合的模型，检测到输出性能下降时自动切换。不是不行，就是偶尔会抽风。

所以问题来了：你还在用一种模型硬刚所有场景吗？

如果是，赶紧停手。学会给模型派活，你的头发会感谢你的。