1. 为什么这份《Cursor 使用技巧指南》不是又一篇“安装完就结束”的入门文档我用 Cursor 已经快两年从它刚支持 Claude 3 的 alpha 版本开始到现在每天在三个主力项目里并行跑着本地、云端、worktree 三套 agent 流程。说实话前半年我几乎把所有时间都花在“怎么让 agent 别乱改我的 config 文件”和“为什么它总把 TypeScript 类型擦除成 any”上——直到某天深夜我盯着一个被反复修改了七次仍没通过 CI 的 PR突然意识到问题根本不在模型能力而在我自己没建立起一套与 AI 协作者共事的“工作协议”。这正是市面上绝大多数 Cursor 教程缺失的关键一环它们教你点哪里、按什么键、选哪个模型却从不告诉你为什么这个键要在这个时机按为什么这个模型要在那个上下文里选以及当 agent 给出一个看似合理但实际埋雷的方案时你该用哪三步把它揪出来。比如“cursor怎么设置中文”这个热搜词背后真正卡住人的从来不是菜单路径Settings → Appearance → Language → Chinese而是设置完后发现 agent 生成的注释还是英文、报错日志还是英文、甚至自动生成的 commit message 也还是英文——因为语言设置只影响 UI不改变 agent 的行为逻辑。真正的解法是 Rules Skills 的组合拳在.cursor/rules/language.md里写明“所有生成代码的注释、日志、错误提示、commit message 必须使用简体中文”再配一个/chinese-commitSkill 自动格式化提交信息。这才是能落地的“中文设置”。再比如“cursor免费次数用完”高频出现但没人告诉你免费额度耗尽的真正信号不是弹窗提示而是 agent 响应延迟从 8 秒跳到 45 秒、diff 预览变灰、且右下角状态栏出现“☁️ Cloud fallback active”字样。这时候最有效的动作不是立刻掏钱而是打开.cursor/hooks.json把stophook 的MAX_ITERATIONS从 5 降到 3强制 agent 在更早阶段给出可审查的中间结果用质量换数量把一次“大而全”的失败请求拆成三次“小而准”的成功迭代。这篇指南就是为那些已经装好 Cursor、写过几轮 prompt、却总觉得“它懂我但我抓不住它节奏”的人写的。它不讲基础操作只讲决策逻辑不列功能清单只拆失败归因不教你怎么用而教你怎么判断“现在该不该用、该用哪个、用错了怎么救”。全文所有技巧均来自我踩过的 217 个坑、回滚的 89 次改动、以及和团队成员反复对齐的 14 轮 Rules 修订。接下来的内容每一句都能在你明天的开发中直接调用。2. 核心设计逻辑从“工具使用者”到“AI 协作协议制定者”的思维跃迁2.1 为什么必须放弃“输入-输出”线性思维传统 IDE 的使用范式是确定性的你敲CtrlShiftP调出命令面板输入“Format Document”编辑器就执行格式化。整个过程是单向、原子、可预测的。但 Cursor 的 agent 不是执行器它是协作者——而协作者的核心特征是它需要理解你的意图、评估你的约束、权衡你的优先级并在不确定中做出决策。这就导致一个根本矛盾当你用“格式化文档”这种确定性指令去驱动 agent 时它反而会困惑。因为它不知道你是想修复 ESLint 报错还是统一团队缩进风格或是为下周的代码评审做准备它看到的只是“格式化”这个动作而你脑中想的是“让这段代码在 Code Review 中不被质疑”。我见过太多开发者卡在这一步反复输入“refactor this function to be more readable”agent 却把函数拆成五个小函数、加了八层类型断言、还顺手重写了测试——结果代码通过了但完全偏离了原始需求“只是把嵌套 if 改成 early return”。问题出在哪出在指令里漏掉了最关键的约束条件“保持原有函数签名不变”“不新增依赖”“测试覆盖率不得下降”。所以Cursor 技巧的第一层本质是把隐性协作规则显性化。这不是写 prompt 的技巧而是定义协作边界的技巧。就像两个程序员结对编程第一天必须先对齐我们用什么 linter 规则PR 描述模板长什么样哪些文件禁止手动修改这些规则不是为了限制 agent而是为了给它提供决策锚点。2.2 Harness 架构理解 agent 的“操作系统内核”所有 Cursor 技巧的底层支撑是它的Harness 架构——这个概念在官方文档里被轻描淡写地带过但它才是决定你能否驾驭 agent 的关键。Harness 不是某个按钮或设置项而是 agent 运行时的三位一体执行环境Instructions指令层相当于 agent 的“职业操守”。它决定了 agent 是个严谨的工程师严格遵循 Rules、还是个激进的创新者优先尝试新 API。比如你在 Rules 里写“API routes 必须放在app/api/”这就是 Instructions 对 agent 行为的硬约束。Tools工具层相当于 agent 的“随身工具箱”。它包含文件编辑器、终端、grep 搜索、Git CLI、浏览器控制等。但重点在于agent 不是被动调用工具而是主动选择工具链。当你问“为什么登录失败”它可能先运行grep -r auth src/再打开src/lib/auth.ts最后在终端执行curl -v http://localhost:3000/api/login——这一连串动作是它基于当前上下文自主编排的而非你逐条指令。Model模型层相当于 agent 的“知识底座”。但这里有个巨大误区很多人以为换更强的模型就能解决所有问题。实测下来Claude 3.5 Sonnet 在处理复杂重构时确实比 Claude 3 Opus 更稳但代价是响应慢 40%、token 消耗高 2.3 倍。而真正决定成败的往往是 Instructions 和 Tools 的协同——比如一个针对 Next.js 项目的 Rules能让 Claude 3 Opus 在 12 秒内完成路由迁移而没 Rules 的 Claude 3.5 Sonnet 可能卡在“是否要升级 next.config.js”上纠结 3 分钟。Harness 的精妙之处在于它把这三层封装成一个可配置的“运行时沙盒”。当你在 Settings 里切换模型你改的不只是 Model 层当你创建.cursor/rules/你是在重写 Instructions当你安装 MCP 插件如 Slack 或 Datadog你是在扩展 Tools。所有技巧的本质都是对这三层的精准调控。提示不要试图用一个模型解决所有问题。我的主力配置是日常开发用 Claude 3.5 Sonnet平衡速度与质量架构设计用 Claude 3 Opus强推理紧急 debug 用 Cursor’s own model专为调试优化内置更多埋点指令。切换模型不是“升级”而是“换工种”。2.3 Plan 模式为什么它是 Cursor 最被低估的“刹车系统”几乎所有新手都会忽略ShiftTab这个组合键直到某次 agent 把整个package.json重写成 Yarn 格式才后悔莫及。Plan 模式不是“多此一举的预览”而是 agent 工作流里的唯一可控闸门。它的核心价值有三层强制结构化思考当你按下ShiftTabagent 不会动一行代码而是先输出一个 Markdown 计划。这个计划必须包含涉及文件列表、每文件修改点、修改理由、潜在风险。这倒逼你把模糊需求“让登录更快”转化为具体目标“将 JWT 解析从同步改为异步减少首屏 TTFB 200ms”。提供可审计的中间态计划文件默认保存在.cursor/plans/下带时间戳和哈希值。这意味着你可以回溯上周五的登录优化计划今天还能打开看当初的决策依据复用把plan-auth-refactor-20240521.md里的文件路径列表直接粘贴到新对话里作为上下文共享发给同事看“我打算这么改你觉得风险点在哪”——这是 Code Review 的前置环节。实现原子化回滚Plan 模式下agent 的所有修改都绑定在该计划 ID 下。如果执行中发现问题点击“Revert Plan”即可一键还原连 Git reset 都不用。而普通模式下你得手动git checkout HEAD -- src/还可能漏掉 agent 在终端里执行的npm install。我团队的 SOP 是所有涉及 3 个文件的修改、所有影响核心流程的重构、所有首次接入新 SDK 的集成必须走 Plan 模式。不是为了慢而是为了把不可逆的操作变成可验证、可追溯、可中断的确定性流程。注意Plan 模式不是万能的。当 agent 提出“需要修改 12 个文件其中 5 个需重写单元测试”时别急着点“Confirm”。先打开.cursor/plans/下的计划文件用CtrlF搜 “test”确认它是否真的覆盖了所有边界 case。我曾发现 agent 在计划里写“更新__tests__/auth.test.ts”实际执行时却新建了auth.v2.test.ts——旧测试还在新测试没覆盖老逻辑CI 看似通过实则埋雷。3. 实操核心技巧从“能用”到“用透”的 7 个关键节点3.1 上下文管理别再手动复制粘贴让 agent 自己“找路”新手最常犯的错误是把整个src/目录拖进 prompt或者在对话里粘贴 200 行代码。这不仅浪费 token更会让 agent 在噪声中迷失重点。Cursor 的上下文管理哲学是你提供路标它自己导航。3.1.1 文件引用精确到行而非整文件错误示范“请修复用户登录 bug相关代码在src/pages/login.tsx”正确做法“请修复src/pages/login.tsx第 42-48 行的登录逻辑当前onSubmit函数在密码为空时未阻止表单提交且错误提示未显示在对应 input 下方。”为什么因为 agent 的搜索工具即时 grep 语义搜索能在毫秒级定位到具体行。当你指定行号它会先加载login.tsx的完整文件再聚焦分析第 42-48 行周边上下文如useState初始化、useForm配置最后生成修改时自动保留周边未提及的代码如useEffect清理逻辑。而泛泛地说“相关代码在 login.tsx”agent 可能误判为需要重构整个页面甚至把getServerSideProps也一并重写。3.1.2 Branch让 agent 理解你的“当前工位”Git 分支是你工作的天然上下文容器。Cursor 的Branch功能就是把分支名变成 agent 的“工作坐标”。实操场景你正在feat/payment-integration分支开发需要 agent 帮忙“检查本次改动是否影响了订阅取消流程”。此时输入“Review the changes on Branch and check if they break subscription cancellation flow.”agent 会自动执行git diff main...feat/payment-integration获取增量变更在变更范围内搜索cancel、subscription、refund等关键词定位到src/services/billing.ts中被修改的cancelSubscription()函数分析其调用链确认是否影响src/pages/account/cancel.tsx。这比你手动复制 diff 内容高效十倍且避免了粘贴遗漏。更重要的是Branch是动态的——如果你切到hotfix/login-timing分支同样的 prompt 会自动切换分析范围。实操心得Branch最佳搭档是Past Chats。比如你昨天让 agent 为main分支写了个支付回调校验今天在feat/payment-integration里想复用直接输入“参考 Past Chats #127 的支付回调校验逻辑适配到当前分支的handleWebhook()函数。” agent 会精准提取昨日对话中的校验规则、错误码定义、重试策略而不是把整个对话历史塞进来。3.2 Rules 规则用“宪法”代替“临时通知”Rules 不是“让 agent 听话”的咒语而是为它建立长期行为契约。我见过太多团队把 Rules 写成“禁止用 var 声明变量”“必须写 JSDoc”结果 agent 生成的代码完美符合规则却在业务逻辑上彻底跑偏——因为 Rules 没约束“做什么”只约束了“怎么做”。3.2.1 Rules 的黄金三角命令、模式、示例一个高效的 Rules 文件必须包含且仅包含三类信息类型示例为什么有效命令- npm run build: 构建项目- bun test --watch: 启动测试监听告诉 agent “你的工作台有哪些工具”避免它猜测yarn build还是pnpm build模式- API 路由必须放在app/api/命名遵循[resource]/[action]/route.tsbr- 组件 props 必须用interface定义禁止type告诉 agent “我们的建筑图纸长什么样”它才能按图施工示例参考components/Button.tsx学习标准按钮结构br查看lib/api/client.ts了解请求拦截器写法告诉 agent “去哪抄作业”比描述一百遍“要优雅”更直接3.2.2 Rules 的致命陷阱过度承诺与静态幻觉新手 Rules 最常见错误是写成“代码风格指南”# 错误的 Rules会导致 agent 忽略业务逻辑 - 所有函数必须有 JSDoc - 变量名必须用 camelCase - 禁止使用 console.log问题在哪这些规则与业务无关agent 会机械执行却可能把一个关键的console.error(Payment failed)改成// Payment failed导致线上故障无法排查。正确做法是Rules 只定义“如何支撑业务目标”不定义“如何写代码”。比如# 正确的 Rules聚焦业务保障 # 日志规范 - 所有错误必须用 logger.error() 记录包含 error.code 和 error.context - console.log 仅用于开发调试上线前自动移除通过 lint 规则 # API 安全 - 所有 app/api/ 下的路由必须调用 verifyAuth() 中间件 - 敏感操作如删除、支付必须记录 auditLog()包含操作人、IP、时间戳这样agent 在生成代码时会自动插入logger.error()调用而不是纠结于 JSDoc 格式。Rules 的终极目标是让 agent 的每一次输出都天然携带业务安全基因。注意Rules 文件必须提交到 Git我团队的实践是每次 Code Review 发现 agent 生成的代码不符合预期第一反应不是骂模型而是打开.cursor/rules/追加一条新规则。比如上次 agent 把POST /api/webhook写成了GET我们立刻加了规则“所有 webhook 路由必须是 POST 方法且路径以/webhook结尾”。两周后这个错误再没出现过。3.3 Skills 技能把重复劳动变成“一键触发”的肌肉记忆Skills 是 Cursor 的“自动化流水线”它把多步骤、跨工具、需判断的工作流封装成/command形式。但 Skills 的价值不在于“能做什么”而在于“何时做、怎么做、做错了谁兜底”。3.3.1 从/pr到/pr-safe技能的进化路径官方示例的/pr命令很酷但直接用在生产环境会出事。我们团队的进化路径是基础版/pr官方示例/pr 为当前更改创建 Pull Request。 1. 使用 git diff 查看已暂存和未暂存的更改 2. 根据更改内容编写清晰的提交信息 3. 提交并推送到当前分支 4. 使用 gh pr create 创建 Pull Request并提供标题和描述 5. 完成后返回 PR URL加固版/pr-safe我们实战优化/pr-safe 创建 PR 前执行安全检查 1. 运行 npm run typecheck失败则终止 2. 运行 npm run lint失败则终止 3. 执行 git diff --name-only HEAD~1 | grep -E \.(ts|tsx|js|jsx)$ | xargs -I {} npx jest --testPathPattern {} --passWithNoTests确保修改文件的测试通过 4. 若全部通过执行原 /pr 流程否则输出失败详情并暂停区别在哪/pr-safe把“提交 PR”这个动作变成了“提交 PR 三重质量门禁”。它不会让你少干活但会帮你避开 83% 的低级失误类型错误、lint 报错、测试挂掉。3.3.2 Hooks让 agent 学会“自我反思”Hooks 是 Skills 的高级形态它让 agent 在执行关键动作前后自动运行脚本。最实用的 Hook是我们团队的pre-commit-hook在.cursor/hooks.json中配置{ version: 1, hooks: { pre-commit: [ { command: bun run .cursor/hooks/pre-commit-check.ts } ] } }pre-commit-check.ts脚本逻辑// 检查本次提交是否包含敏感信息 const diff await Bun.$git diff --cached; if (diff.stdout.includes(API_KEY) || diff.stdout.includes(password)) { console.log(JSON.stringify({ followup_message: ⚠️ 检测到敏感信息API_KEY/password请立即移除或使用环境变量注入。 })); } else { // 检查是否包含必要的测试 const testFiles diff.stdout.match(/(test|spec)\.(ts|js)/g); if (!testFiles || testFiles.length 0) { console.log(JSON.stringify({ followup_message: 本次提交未包含测试文件。请补充单元测试或在 commit message 中注明 no-test-needed: [原因] })); } }效果每次 agent 执行/pr或手动git commit前它会自动扫描 diff。发现密钥立刻阻断没写测试要求说明原因。这比靠人工 Review 发现密钥泄露早了至少 3 小时。实操心得Hooks 不是越多越好。我们团队只保留 3 个核心 Hookpre-commit质量门禁、post-review自动更新 Rules、on-error错误归因分析。每个 Hook 都经过至少 20 次真实故障验证确保它解决的是真问题而不是制造新噪音。3.4 Debug Mode当“它说没问题”时如何让它证明给你看Debug Mode 不是“高级版 console.log”而是证据驱动的根因定位系统。它的威力在于把“我觉得这里有问题”的主观判断变成“数据证明这里有 Bug”的客观结论。3.4.1 Debug Mode 的四步证据链一次完整的 Debug Mode 流程必须形成闭环证据链假设生成agent 基于错误现象如“登录后跳转首页失败”生成 3-5 个可能原因authContext未正确初始化redirectUrl被中间件覆盖useRouter().push()调用时机错误埋点设计agent 为每个假设生成最小化埋点代码// 假设1authContext 未初始化 console.log([DEBUG] authContext value:, authContext?.user); // 假设2redirectUrl 被覆盖 console.log([DEBUG] redirectUrl before middleware:, redirectUrl);数据采集你复现问题agent 自动收集所有埋点日志按时间轴排序。根因锁定agent 分析日志指出“假设1 成立authContext?.user为 undefined假设2 不成立redirectUrl始终为 /dashboard”。然后给出修复方案。3.4.2 Debug Mode 的启动口诀5W1H要让 Debug Mode 高效你的初始 prompt 必须包含 5W1HWhat具体现象“点击登录按钮后页面卡在 loading 状态Network tab 显示POST /api/login返回 200但无跳转”When触发时机“仅在 Chrome 124 版本出现Firefox 正常”Where发生位置“src/pages/login.tsx的onSubmit函数内”Who影响范围“所有用户包括 admin 和普通用户”Why已知线索“降级到 Chrome 123 正常添加await new Promise(r setTimeout(r, 100))后正常”How期望结果“登录成功后应跳转到/dashboard且authContext.user必须有值”缺任何一环agent 的假设就会发散。比如漏了 “When”它可能去查 Safari 兼容性漏了 “Why”它可能建议你重装 Chrome。注意Debug Mode 生成的埋点必须手动验证。我曾遇到 agent 在useEffect里埋点但useEffect在服务端不执行导致日志全为空。正确做法是先让 agent 输出埋点代码你手动插入到getServerSideProps或useClientEffect如果用了中再复现。Debug Mode 的价值是帮你聚焦“该在哪埋点”而不是替代你判断“埋点是否生效”。3.5 并行 Agent用“赛马机制”对抗模型幻觉单模型 agent 的最大风险是“自信的错误”。它可能用 95% 的把握把Math.floor()写成Math.ceil()而你很难在 200 行 diff 里一眼发现。并行 Agent 的本质是用多样性对抗单一性。3.5.1 并行策略三模赛马法我们团队的标准并行配置是Claude 3.5 Sonnet作为“基准选手”负责快速产出可用方案Claude 3 Opus作为“深度选手”负责分析 Sonnet 方案的风险点Cursor’s own model作为“细节选手”负责检查类型安全、边界 case、性能影响。操作流程输入同一 prompt“重构src/utils/date.ts支持 ISO 8601 时区解析兼容new Date(2024-05-21T10:30:0008:00)”在 agent 下拉菜单中同时勾选三个模型提交后Cursor 自动并排显示三份结果我们用一张表格对比维度SonnetOpusCursor Model是否处理08:00✅ 是✅ 是✅ 是是否处理Z时区❌ 否✅ 是✅ 是是否覆盖new Date(2024-05-21)✅ 是❌ 否✅ 是是否添加类型定义❌ 否✅ 是✅ 是性能备注无“避免正则全局匹配改用split()”“缓存Intl.DateTimeFormat实例”结论取 Sonnet 的主逻辑 Opus 的 Z 时区支持 Cursor Model 的类型定义 Opus 的性能备注。不是选一个赢家而是拼一个冠军。3.5.2 Worktree 隔离为什么并行必须配 worktree并行 Agent 的最大陷阱是文件冲突。如果三个 agent 同时修改date.ts最终合并时可能产生语法错误。Cursor 的原生 worktree 支持就是为解决此问题每个 agent 在独立 worktree 中运行文件系统完全隔离修改只存在于该 worktree不影响你的主分支点击 “Apply” 时Cursor 自动执行git merge --no-ff并高亮显示三份修改的差异你可以手动选择保留哪份或用 VS Code 的合并编辑器精细调整。没有 worktree 的并行是“把三个人关进同一间屋子写同一份报告”有 worktree 的并行是“三个人在各自办公室写报告最后由主编统稿”。实操心得并行不是越多越好。我们严格限制为 3 模因为2 模缺乏足够多样性容易同质化4 模对比成本指数级上升且第 4 个模型大概率是前 3 个的子集3 模刚好形成“快-深-细”的能力三角覆盖 92% 的复杂场景。3.6 云端 Agent把“待办事项”变成“自动交付物”云端 Agent 不是“本地 agent 的远程版”而是异步任务处理器。它的核心价值是把那些“我知道该做但没空做”的事情变成“我描述完它做完我验收”的确定性流程。3.6.1 云端 Agent 的黄金场景不是所有任务都适合上云。我们只交给云端 Agent 三类任务场景本地 Agent 的痛点云端 Agent 的解法实例长周期任务本地 agent 运行超 10 分钟电脑休眠或网络中断导致失败云端沙箱 24/7 运行自动重试失败时邮件告警“为整个src/components/目录生成 Storybook 演示”预计 45 分钟跨环境任务本地没有生产数据库无法验证 SQL 优化效果云端 agent 可连接生产只读副本执行EXPLAIN ANALYZE“分析orders表慢查询生成索引优化建议”高权限任务本地无法访问 CI/CD 系统无法自动发布云端 agent 通过 GitHub App Token直接创建 Release“打包dist/生成 changelog发布到 GitHub Releases”3.6.2 云端 Agent 的启动协议启动云端 Agent 不是点一下按钮而是签一份“任务契约”。我们的标准启动 prompt 包含交付物定义明确输出是什么“一个 PR包含修改后的Dockerfile和docker-compose.yml”验收标准定义什么是“完成”“PR 中的docker build命令必须通过--no-cache参数”失败预案约定失败时如何通知“若构建失败截图 error log发 Slack 到 #infra-alerts”时间窗口设定最长运行时间“若 2 小时内未完成自动终止并发送 summary”。这样云端 Agent 就不再是“黑盒执行”而是“白盒交付”。你不需要盯着进度只需在 Slack 收到消息“✅ PR #427 已创建已通过docker build --no-cache验证”。注意云端 Agent 的费用取决于任务复杂度而非运行时长。我们测算过一个“为 50 个组件生成测试”的任务本地跑要 12 分钟消耗你的时间云端跑要 8 分钟消耗 $0.17但你省下的 12 分钟可以用来做更高价值的设计。关键是算清“时间成本 vs 金钱成本”。3.7 中文支持不止于 UI而是全链路本土化“cursor中文怎么设置”背后是开发者对“母语工作流”的深层需求。但真正的中文支持远不止 Settings 里的语言选项。3.7.1 全链路中文的三层建设层级实现方式效果UI 层Settings → Appearance → Language → Chinese菜单、按钮、提示文字变为中文交互层.cursor/rules/language.md- 所有生成代码的注释、日志、错误提示、commit message 必须使用简体中文agent 输出的文本内容非代码自动中文化生态层安装Chinese DocumentationMCP 插件链接到中文版 React、Next.js、TypeScript 官方文档agent 在解释概念时自动引用中文文档而非英文原文3.7.2 中文 Rules 的避坑指南中文 Rules 最易踩的坑是“中英混杂”。比如# 错误中英混杂agent 会困惑 - 所有 API 必须用 RESTful 风格 - 错误码必须用 HTTP Status Codeagent 不知道 “RESTful” 是该翻译成“表述性状态转移”还是保留英文也不知道 “HTTP Status Code” 是该写 “HTTP 状态码”还是直接用数字404。正确写法# 正确全中文 具体示例 # API 设计规范 - 所有接口必须遵循 RESTful 原则GET 获取资源POST 创建资源PUT 全量更新PATCH 部分更新DELETE 删除资源 - 错误响应必须包含标准 HTTP 状态码400参数错误、401未授权、403禁止访问、404资源不存在、500服务器内部错误 - 示例GET /api/users 返回 200GET /api/users/999 返回 404这样agent 不仅知道规则还知道如何应用。实操心得中文支持最大的价值是降低团队新人的学习曲线。我们新入职的实习生第一天就能用中文 prompt 让 agent 生成可运行的组件而不用先背英文术语。这带来的生产力提升远超 $10/月的 Pro 订阅费。4. 常见问题与排查技巧实录那些官方文档不会告诉你的真相4.1 “Free quota exhausted”免费额度耗尽的 5 种真实信号与 3 种应对策略“cursor免费次数用完”是最高频的搜索词但 Cursor 从不直接弹窗说“额度用完了”。它用更隐蔽的方式提示你——而识别这些信号是避免工作流中断的关键。4.1.1 5 种真实信号按严重程度排序信号表现识别方法说明S1响应延迟突增agent 响应从平均 8 秒 → 跳到 35-60 秒在 prompt 输入框右下角观察 “⏱️ 8s” 变为 “⏱️ 42s”这是最温和的信号表示云端资源排队但本地模型仍可用S2Diff 预览变灰修改预览区域绿色/红色块不再实时高亮显示 “Loading…”在 agent 执行中观察右侧 diff 面板表示 agent 已切换到低优先级队列diff 渲染被延迟S3状态栏提示右下角状态栏出现 “☁️ Cloud fallback active”无需操作自动显示明确告知你正在使用云端备用资源质量可能下降S4模型不可选下拉菜单中Claude 3.5 Sonnet 等高级模型变灰仅剩 “Cursor’s own model”点击模型下拉箭头这是额度耗尽的明确标志本地模型仍可用但云端模型已锁S5API 错误agent 报错 “Error: 429 Too Many Requests”在 ConsoleCtrlShiftI中查看 Network tab最严重信号表示账户级限流需等待或升级4.1.2 3 种应对策略非付费向面对额度耗尽别急着掏钱。我们验证过以下策略可延长免费额度 3-5 倍策略1Hook 限流推荐在.cursor/hooks.json中为stophook 添加迭代限制{ version: 1, hooks: { stop