把 Cursor 当工程工具，而不是聊天窗口

很多人刚开始用 Cursor 时，会把它当成一个更懂代码的聊天窗口。遇到问题就把需求、日志、截图、文件一股脑放进去，然后开 Agent 等它改。

短期看，这样确实省事。长期看，很容易遇到几个问题：模型越用越贵，上下文越来越乱，Agent 改动越来越大，最后 review 成本反而升上去。AI Coding 的价值来自一组匹配关系：合适的任务、合适的上下文、合适的模型，以及合适的验证方式。

有位技术负责人讲过一段话，我很喜欢：

最近大家在日常开发中越来越熟练地使用AI Coding，不少人的编码效率明显提升，不少团队也在积极探索AI Coding的能力边界，这很好，公司也愿意持续为大家提供必要的额度支持，但额度不是福利，而是生产资料，也希望大家在使用过程中思考和注意以下几点：

1、成本意识，根据任务复杂程度按需选配合适模型，而不是一刀切都用最好最新的

2、团队协作和沉淀，每个项目，业务历史包袱，代码逻辑，开发习惯都不一样，基于现状和协同习惯持续总结提炼可复用的skill、工作流

3、整体效率提升，目前大部分还是在单点提效，从需求到上线的整体链路并没有提升，协同链路的提效可以不设边界积极探索

这段话里的三个关键词很适合拿来理解 Cursor：成本意识、团队沉淀、整体链路提效。

成本意识要求模型、模式和任务复杂度匹配。团队沉淀要求把项目规则、排障路径、测试命令和 review 经验写进可复用的 Rules、Skills 和文档里。整体链路提效关注需求理解、方案设计、开发、自测、评审、上线和复盘，而不是只追求某一段代码写得更快。

采购和组织流程留给各自团队处理；开发者日常更需要的是一套可执行的 Cursor 使用习惯。

Cursor 适合解决什么问题

Cursor 的核心价值在代码上下文。它能读仓库、找调用链、改文件、跑命令、修测试，也能把一次工程任务拆成多轮 Agent 操作。只要问题的关键材料在代码仓库里，Cursor 就比普通聊天工具更合适。

反过来，问题如果不依赖项目上下文，就不一定要放进 Cursor。普通语法解释、公开 API 怎么用、SQL / 正则 / CSS 小问题、文案润色、翻译、会议摘要，这些内容更适合放到官方文档、搜索、低成本通用模型、办公文档 AI 或设计工具自带 AI 里处理。

日常可以按这个顺序判断：

• 问题是否依赖当前仓库里的真实代码、私有接口、业务调用链、测试失败现场。
• 是否需要 Cursor 读文件、改文件、跑命令、看 diff。
• 是否已经知道入口文件和影响范围；如果不知道，先用 Ask 或 Plan 探索，不要直接让 Agent 扫全仓。
• 是否有明确验收标准，例如测试命令、页面效果、接口返回、PR diff 或 review 重点。

这几项越清楚，Cursor 的效果越稳定。任务越模糊，Agent 就越容易用更多工具、读更多文件、产生更大的 diff，后面人工 review 也越累。

日常问题可以分成三类。

第一类是 必须依赖代码仓库上下文 的任务。比如跨文件改造、复杂重构、测试失败定位、线上 bug 排查、私有业务链路分析、代码评审前的影响范围检查。这些任务需要真实文件、调用链、项目约定和验证命令，Cursor 正好适合。

第二类是 可以先用 Cursor Ask 探索，但不要急着让 Agent 改 的任务。比如第一次理解某个模块、接手陌生项目、确认一个接口从哪里发起、判断某个组件是否还有其他调用方。这个阶段的目标是知道入口、范围和风险，而不是马上生成代码。

第三类是 不应该优先占用 Cursor 的任务。公开 API 怎么用、某个 CSS 属性什么意思、正则怎么写、SQL 语法怎么改、会议纪要怎么润色、设计稿里文案怎么改，这些问题离开当前代码仓库也能解决，放在官方文档、搜索、通用模型、办公文档 AI 或设计工具 AI 里更合适。

这组口径可以作为快速判断：

任务	更合适的工具	原因
跨文件重构、复杂需求开发	Cursor	需要读仓库、改文件、跑验证
疑难 bug、测试失败定位	Cursor	需要源码、日志、命令输出和失败现场
私有模块调用链分析	Cursor Ask	先只读找入口和影响范围
单个公开 API 怎么用	官方文档 / 文档问答	官方资料更直接，也更新
SQL、正则、CSS、TypeScript 小问题	通用模型 / 搜索	不依赖项目上下文
会议纪要、周报、需求摘要	办公文档 AI	材料本来就在办公文档里
设计初稿、交互原型、图层整理	Figma AI / Figma Make	设计工具里处理更顺

Cursor 的位置越清楚，后面的模型选择、上下文控制和 review 才越好做。否则所有问题都丢给 Cursor，最后会变成一个更贵、更重、更容易积累历史噪音的聊天窗口。

模型和模式要跟任务匹配

Cursor 里的模型和模式不是越强越好。模型选择会影响质量、速度和成本，模式选择会影响上下文窗口、工具调用和执行方式。Cursor Models & Pricing 会列出当前模型、费率、Max Mode、usage 和 token breakdown，这类信息变化很快，真正使用时应该看最新官方页面。

日常可以先把任务粗略分成三层：

• 轻量任务：解释一段代码、看一个简单报错、写一个小脚本、问公开 API 用法。优先用 Auto、mini 模型、低成本模型，或者干脆用官方文档和通用模型。
• 日常工程任务：理解模块入口、小范围修改、明确需求下的跨文件改动、补测试。可以优先尝试 Composer 2.5 Standard、Claude Sonnet 类或合适的 GPT / Gemini 日常模型。
• 高复杂任务：疑难 bug、复杂重构、发布前风险评审、测试失败根因分析、大范围迁移。可以使用更强模型、Thinking 或临时 Max Mode，但要先把任务目标和上下文范围讲清楚。

截至 2026-06-01，Cursor 自家的 Composer 2.5 很值得单独提一下。它是 Cursor 针对真实编辑器 Agent 工作优化的编码模型，重点放在长时间读代码、调用工具、改文件、看报错、继续修正这类持续任务。

官方介绍里提到，Composer 2.5 相比前代更适合持续时间更长的任务，也更能遵守复杂指令。它继续基于 Moonshot 的 Kimi K2.5，并通过更大规模训练、更复杂的强化学习环境和新的学习方法提升能力。放在 Cursor 的使用场景里，这些改进对应的就是跨文件修改、测试修复、复杂排障和多轮 Agent 工作。

价格也影响选择。Cursor 当时列出的 Composer 2.5 Standard 是 $0.50 / 1M input、$2.50 / 1M output；Fast 是 $3.00 / 1M input、$15.00 / 1M output。Composer 2.5 Changelog 也说明，Fast 和 Standard 智能能力相同，主要差异是速度。也就是说，不赶时间时先用 Standard 更合理；真的卡在等待速度上，再为 Fast 付更高成本。

几个常见模式容易被混在一起：

• Standard / Fast 更像同一模型的档位选择，主要影响速度、价格和默认使用体验。
• Thinking 更适合复杂推理、方案评审、难 bug 和边界很多的技术判断，普通小改动不需要默认打开。
• Max Mode 解决的是大上下文问题，适合普通上下文放不下关键材料的场景，不适合当日常开关。

最实用的顺序是：先用日常模型和 Standard；问题很复杂但材料不大，再考虑 Thinking；材料大到普通上下文放不下，再临时打开 Max Mode；主要瓶颈是等待速度，再考虑 Fast。

模型选择还要注意一个细节：强模型不等于每次都更划算。强模型在难题上能减少返工，在简单问题上只是在放大成本。一个小组件的样式修改，如果用了高阶模型、Fast、Thinking 和 Max Mode，最后得到的可能还是几行 CSS；而一次复杂重构如果用太弱的模型，可能会产生很多看似合理但不符合项目约定的 diff，人工收拾起来更费时间。

默认选择可以按这张表来定。

任务	默认选择	升级条件
解释简单代码、看一段报错	Auto、mini、低成本模型、通用模型	涉及私有调用链，再切到 Cursor Ask
理解陌生模块入口	Ask + 日常模型	范围复杂、需要方案评审时再用 Thinking
小范围改代码	Composer 2.5 Standard / Sonnet 类 + Agent	连续失败或风险高，再切更强模型
明确需求下的跨文件修改	Composer 2.5 Standard、Sonnet 类、GPT 日常模型	涉及复杂推理或关键发布，再升级
疑难 bug、复杂重构、测试失败根因	高阶 GPT / Claude Opus / Gemini Pro / Thinking	普通上下文放不下时，再开 Max Mode
大仓库、大文件、多模块关联分析	长上下文模型 + 临时 Max Mode	先裁剪材料，确认必要后再开
赶时间、频繁等待返回	Fast / Priority 类模式	明确是在买速度，不是买更高智能

Max Mode 尤其不适合常开。它的价值是让模型在普通上下文放不下关键材料时还能继续工作，例如多个大文件同时比较、跨很多模块串调用链、复杂重构前的全局分析。单文件解释、小组件修改、API 用法查询、文案润色、注释整理，不需要用 Max Mode。

Thinking 也一样。它适合难题拆解和复杂判断，比如架构方案取舍、疑难 bug 根因分析、测试失败背后的边界条件、发布前风险评审。日常明确的小改动不需要默认开 Thinking，否则只是把简单任务变慢、变贵。

Fast 的定位更直接：买速度。Cursor 的 Composer 2.5 资料里已经说明 Fast 和 Standard 智能能力相同，主要差异是速度。交互式排查、线上紧急修复、等待成本很高时，Fast 有价值；普通任务不赶时间时，Standard 更合适。

上下文是一种成本

AI Coding 里最容易被低估的成本，是上下文。

Cursor 的 Prompting Agents 文档说明，chat 会维护自己的上下文窗口，提示、附加文件、模型回答、旧对话和工具结果都会占空间。上下文变大以后，请求会更重，旧任务也可能影响新任务。一个对话里连续处理很多需求，后面的问题就容易带着历史噪音继续跑。

控制上下文有几条很实用的规则。

一个任务结束后，让 Cursor 生成交接摘要，然后开新对话。摘要里保留目标、已确认结论、改过的文件、验证命令、未完成事项和后续约束。新对话只带摘要和必要文件，不把旧对话整段搬过去。

如果任务还没结束，但对话已经很长，可以考虑用 /compress 主动压缩上下文。Cursor Slash Commands 里列出了 /compress，它的作用是总结当前会话并释放上下文空间。压缩不是万能恢复，关键约束、测试命令、业务边界和已经排除过的方案，最好仍然单独写进交接摘要。

给文件时不要一上来把整个目录放进上下文。知道入口就 @ 具体文件，不知道入口就先描述现象、目标和边界，让 Agent 用搜索工具找。大日志裁成关键报错和上下文，大 JSON 保留字段结构和关键样例，构建产物、依赖目录、临时文件和导出文件不要进上下文。

项目还应该维护 .cursorignore 和 .cursorindexingignore。Cursor Ignore File 文档说明了这两类文件的作用。它们不是绝对安全边界，但能减少无关内容进入索引和 AI 上下文，让检索质量更稳定，也降低误带敏感文件的概率。

上下文管理可以拆成四件事。

第一，长对话要及时切分。一个 chat 适合延续同一个任务，不适合混合多个无关需求。任务结束后，让 Cursor 输出交接摘要，再开新对话。摘要可以固定成这样：

请总结当前任务的交接信息：
1. 已确认的结论
2. 修改过的文件
3. 还没完成的事项
4. 后续继续时需要带入的上下文
5. 已运行或需要运行的验证命令

第二，材料要先裁剪。日志保留关键报错和上下 30 行，JSON 保留字段结构和关键样例，截图只保留和问题相关的区域，目录只给入口文件、调用方和相关工具函数。整份日志、整份大 JSON、构建产物、依赖目录和旧聊天全文，通常会把关键材料淹掉。

第三，让 Agent 自己找上下文。知道准确文件时，可以直接 @ 文件；不知道入口时，把现象、目标、边界讲清楚，让 Agent 通过 grep、语义搜索和代码索引自己找。Cursor 官方的 Agent 最佳实践 也强调，不需要手动把所有可能相关的文件都加进上下文。

第四，项目级 ignore 要维护。前端项目里常见的排除项包括这些，具体仍然要按项目调整：

dist/
build/
coverage/
*.log
.env
.env.*
node_modules/
tmp/

如果项目里有大型 mock 数据、导出文件、临时压缩包、自动生成的 API 产物，也可以按情况加进去。ignore 不能替代安全规范，敏感信息本来就不应该随意放进仓库或上下文；它解决的是「减少无关文件干扰」和「降低误带材料的概率」。

第一次接手一个项目时，也应该先看这些基础设置：

• 当前用的是哪个账号和工作区，是否符合组织要求。
• 默认模型是什么，Max Mode 是否被常开。
• 项目有没有 .cursor/rules、.cursorignore、.cursorindexingignore、AGENTS.md。
• 有没有已经沉淀好的 Skills、Commands 或项目排查流程。
• 常用测试命令、lint 命令、类型检查命令在哪里。

这些检查不复杂，但能避免很多后续浪费。Cursor 的效果很大程度取决于它拿到的上下文质量；上下文越干净，模型越容易把注意力放在真正相关的代码上。

先理解，再让 Agent 改

很多低效用法来自一上来就开 Agent。Agent 会搜索代码、读文件、编辑、跑命令、修错误；能力越强，范围失控时消耗越大。

更稳的顺序是：Ask 用来理解，Plan 用来定方案，Agent 用来执行，Review 用来兜底。

理解陌生模块时，先问：

订单详情页保存失败。
请先只读分析页面入口、表单提交、请求封装和对应 API。
不要改代码，先给影响范围、可能原因和下一步建议。

这类提示把现象、范围和动作权限说清楚了。Cursor 不需要从全仓开始猜，也不容易直接改出一大段难以 review 的 diff。

复杂需求可以先用 Plan Mode。Cursor Plan Mode 官方介绍里提到，Plan Mode 会先研究代码、提出澄清问题、生成带文件路径和代码引用的计划，等待确认后再执行。这个模式适合重构、迁移、影响范围不确定的改动。计划本身也能保存下来，方便后续恢复上下文和团队 review。

等方案确认以后，再让 Agent 按明确范围执行：

按已确认的方案修改。
只改 src/pages/order 和 src/api/order 相关文件。
不要改公共请求封装。
改完后运行 pnpm test:order，并列出最终 diff 和风险点。

这类写法比「直接修复这个问题」更像工程任务。目标、边界、禁止事项、验证方式都在提示里，Agent 更容易做出可 review 的结果。

类似经验并不只存在于 Cursor。Anthropic 的 Claude Code Best Practices 也建议先探索、再计划、再编码；GitHub 的 Copilot coding agent 实践 会强调 issue 需要写清问题、验收标准和相关文件；OpenAI 的 Codex 使用经验 也建议大改动先用 Ask Mode 形成计划，再进入 Code Mode。

不同工具叫法不一样，底层习惯是同一件事：先把任务变清楚，再让 Agent 动手。

Cursor 里几个常见模式可以这样理解：

模式	适合场景	使用提醒
Ask	学习代码、找入口、梳理调用链、解释现有逻辑	先只读，不改文件
Plan Mode	复杂需求、重构、影响范围不确定的任务	先生成可审阅计划，再执行
Agent	已经明确要改什么，需要跨文件编辑、跑命令、修测试	给清楚范围、禁止项和验收标准
Manual	已经知道要改哪个文件和哪一段	适合小范围精确修改
Custom Modes	固定的学习、调试、重构、排查流程	适合团队把常见流程固化
Debug Mode	可复现但原因不清楚的复杂 bug	让排查有假设、有证据、有验证

Debug Mode 值得单独说一下。Debug Mode 会让 Agent 围绕 bug 形成多个假设，再结合日志或运行时信息定位问题。它适合可复现、但原因不清楚的故障，例如某个状态只有特定路径下才错、某个测试只在 CI 里失败、某个接口偶发返回异常。

Debug Mode 的价值不是让 Agent 猜得更多，而是让排查更像真实调试：先提出假设，再找证据，再复现，再验证。用它时最好给出复现路径、失败日志、环境差异、相关测试命令和不希望修改的范围。

Agent 执行时，提示词里最好同时写四类信息：

• 目标：这次要解决什么问题，最终效果是什么。
• 范围：可以看哪些目录，可以改哪些文件。
• 限制：不要改什么，不要引入什么，不要碰什么兼容逻辑。
• 验收：要跑什么命令，怎么判断结果正确，最后要输出哪些风险点。

一个更完整的提示可以这样写：

目标：修复订单详情页点击保存后状态没有更新的问题。

范围：
- 可以查看 src/pages/order、src/api/order、src/stores/order。
- 可以修改订单详情页和订单 API 封装。

限制：
- 不要改全局 request wrapper。
- 不要改其他业务页面。
- 不要引入新依赖。

验收：
- 改完运行 pnpm test:order。
- 最后列出改动文件、验证结果、仍需人工确认的风险。

这种写法看起来更啰嗦，但它会显著降低 Agent 自行扩大范围的概率。越是让模型动代码，越要把边界写清楚。

把项目经验写进 Rules、Skills 和 AGENTS.md

模型本身不会天然知道一个项目的历史包袱、目录职责、测试命令、接口约定和 review 重点。这些信息如果只停留在个人对话里，下次别人还要重新解释一遍，Agent 也会重复犯同样的错。

Cursor 的 Rules 适合放持续生效的项目约定，例如常用命令、目录职责、代码风格、不能随便改的兼容逻辑、推荐参考的真实文件。Project Rules 可以进入版本管理，按路径、手动引用或相关性触发；Team Rules 和 User Rules 则适合更大范围或个人习惯。

Skills 更适合放一次性的流程，比如 review 当前 diff、补测试建议、整理 PR 描述、按 bug 描述定位代码、生成项目入门路径。Rules 解决「项目一直是什么样」，Skills 解决「这次任务应该怎么做」。

AGENTS.md 则越来越像跨工具的项目说明文件。只要项目里同时使用 Cursor、Codex、Claude Code、GitHub Copilot 等工具，就不应该把所有约定绑死在某一个工具里。通用项目约定放进 AGENTS.md，Cursor 专属触发规则放进 .cursor/rules，具体流程放进 .cursor/skills，这套分工会更稳。

一个简单结构可以长这样：

.cursor/
  rules/
    project-overview.mdc
    code-style.mdc
    testing.mdc
    review-checklist.mdc
  skills/
    review/
      SKILL.md
    write-tests/
      SKILL.md
    create-pr/
      SKILL.md
.cursorignore
.cursorindexingignore
AGENTS.md

Rules 不要写成口号，也不要复制大段源码。更有价值的是判断标准和入口信息：哪些目录负责什么，哪些命令最可靠，哪些文件能代表项目当前写法，哪些历史逻辑不能轻易改。Skills 也不要只写一句「review 当前 diff」，而应该固定检查 diff、测试、兼容、安全、权限、埋点、异常处理和人工确认点。

第三方的 Cursor Rules 实践 也提醒过一个常见问题：不要把所有规则都设成 always apply。持续进入上下文的规则越多，每次请求越重，真正关键的信息反而更容易被淹没。能按目录、文件类型或任务触发的规则，就不要全局常开。

Rules 可以从最小可用版本开始，不需要一口气写成手册。比如一个前端项目，可以先写这些内容：

# Project Overview

- 业务入口在 src/pages。
- API 封装在 src/api，不要在组件里直接写 fetch。
- 多语言文案放在 src/i18n，新增文案要同步补中英文 key。
- 表单提交前必须走 src/utils/validate.ts 里的校验方法。

# Commands

- 类型检查：pnpm typecheck
- 单测：pnpm test
- lint：pnpm lint

# Review Notes

- 涉及支付、权限、埋点、用户数据删除的改动必须人工 review。
- 不要绕过 request wrapper。
- 不要把后端返回字段直接透传到 UI，先经过 adapter。

这种规则不花哨，但对 Agent 很有用。它告诉模型项目怎么组织、哪些入口可信、哪些地方不能绕开、改完要跑什么命令。真正好的 Rules 通常来自 Agent 反复犯错的地方：它老是找错入口，就补入口说明；它老是绕过 wrapper，就补禁止项；它老是忘记跑测试，就补验证命令。

Skills 则更适合沉淀流程。比如 /review 可以要求 Agent 先读当前 diff，再按权限、兼容、测试、异常处理、埋点和性能列风险；/write-tests 可以要求它根据当前改动列测试场景，再补最小测试；/create-pr 可以整理 PR 标题、变更范围、测试结果和人工确认点。

Rules 和 Skills 的区别可以简单记成一句话：Rules 让 Agent 知道项目长期是什么样，Skills 让 Agent 知道这次任务应该怎么做。

让 Cursor 读最新资料

模型记忆不等于最新资料。框架、云服务、SDK、浏览器 API、AI 工具本身都在快速变化，Cursor 如果只靠模型记忆，很容易给出旧版本答案。

Cursor 支持用 @Docs、@Web 和 MCP 补上下文。Prompting Agents 文档说明了文件、目录、文档、Past Chats 和浏览器上下文等 mention 能力；Cursor MCP 则说明了 Cursor 如何通过 MCP 接入外部系统。

几个常见用法：

• 升级 React、Vue、Vite、Next.js、Chrome Extension API 或支付 SDK 时，先把官方文档加到 @Docs，再让 Cursor 对照当前项目代码判断迁移方式。
• 刚发布的新模型、新框架版本、新浏览器能力，先用 @Web 查官方公告、changelog 和社区反馈，再决定是否采用。
• 内部接口文档、工单、日志、监控和告警，应该走组织允许的 MCP 或内部工具，不要复制到公开网页工具里。

这也是一种成本控制。公开资料的问题先在官方文档里解决，回到 Cursor 时，问题会更具体，Agent 不需要靠猜补旧版本知识。

@Docs、@Web 和 MCP 的边界不一样。

@Docs 更适合稳定的官方资料。比如升级 Vite、Next.js、React、Vue、Chrome Extension API、Stripe SDK、Figma Plugin API 时，先让 Cursor 读官方文档，再结合项目代码判断要怎么改。这样比直接问「这个 API 怎么用」可靠，因为它能同时看到官方资料和当前项目写法。

@Web 更适合变化快的信息。比如新模型刚发布、某个库刚出 breaking change、浏览器刚改权限策略、社区里有人遇到同类坑，可以先看官方公告、changelog、issue 和讨论，再让 Cursor 汇总取舍。它适合补「现在发生了什么」，但不要把随便搜到的社区答案当成事实。

MCP 更适合连接受控系统。它可以理解成一种把外部系统接入 Agent 的协议。内部接口文档、工单、监控、日志、Sentry、Datadog、Slack、数据库查询，都可以通过组织允许的 MCP 暴露给 Agent。这样比复制粘贴材料更稳，因为数据来源、权限、审计和脱敏可以统一控制。

最重要的边界是：公开资料可以走公开工具，私有资料要走组织允许的工具。不要为了省事把内部日志、接口文档、用户数据、密钥、未公开方案贴到公开网页模型里。Cursor 可以作为工程工具使用，但它也不应该变成绕过数据治理的入口。

截图和浏览器证据要用起来

UI 问题、样式问题、设计稿还原问题、报错弹窗和移动端兼容问题，单靠文字很容易讲不清。Cursor 官方的 Agent 最佳实践 提到，可以给 Agent 粘贴截图、拖入设计稿，或者结合浏览器检查页面。

截图适合这些场景：

• 页面布局错位、遮挡、换行、溢出。
• 控制台报错和页面状态需要一起看。
• 设计稿和实现不一致。
• 移动端和桌面端表现不同。
• 某个交互只能通过实际页面状态解释。

给截图时也要写清页面入口、期望效果、实际问题、相关文件和是否允许修改。图片只是证据，不是任务说明本身。真正稳定的 UI 修复应该形成闭环：截图说明问题，Agent 找代码，修改后打开页面验证，再用新的截图或测试结果确认。

对外分享 Cursor 界面截图时，干净 demo 项目截图比真实工作区更安全。真实工作区很容易露出账号、仓库名、分支名、侧边栏文件、最近打开记录和内部路径。需要讲方法论时，自绘 SVG 通常更稳；只有解释按钮位置和具体入口时，才需要少量干净截图。

截图也要控制上下文。一次 UI 问题通常不需要十几张图，更需要一张能说明问题的截图，加上页面入口、复现步骤、期望效果和实际效果。如果移动端和桌面端表现不同，就各给一张；如果 hover、弹窗、滚动后才出现问题，要说明触发状态。

更好的提示是：

这是订单详情页移动端截图。
问题：底部保存按钮遮挡了错误提示。
期望：错误提示完整展示，保存按钮固定在底部但不覆盖内容。
请先定位相关布局和样式文件，不要直接改公共 Button 组件。

不太好的提示是：

页面样式不符合预期，请直接修复。

视觉问题最怕只修表面。按钮被挡住，原因可能是容器高度、固定定位、安全区、键盘弹出、滚动区域、设计稿尺寸或组件复用边界。截图能帮 Agent 看见表象，但仍然要让它回到代码和页面验证里闭环。

设计工具也可以分流一部分工作。Figma 的 AI tools 可以处理设计文件里的文本、图层、图片和交互；Figma Make 更适合 prompt-to-app 或交互原型探索。早期原型、设计文案、图层整理和交互尝试，不一定要放到 Cursor 里解决。

生成代码必须 review

Cursor 可以写代码，也可以跑测试，生成结果仍然需要 review。

Agent Review 可以对本地改动做专门代码评审，支持 Agent 任务结束后自动运行，也支持用 /agent-review 手动触发。它适合做额外检查，尤其是较大 diff、复杂逻辑和重构后的遗漏点。

但 Agent Review 不能替代人工 review。权限、支付、风控、埋点、数据删除、兼容逻辑、性能敏感路径、用户隐私相关代码，仍然要开发者自己看 diff。AI 很容易写出「差一点就对」的代码，这类问题最麻烦，因为它表面能跑，细节会埋在边界条件里。

Stack Overflow 的 2025 Developer Survey AI 章节 里，开发者最常见的挫败感就是 AI 结果接近正确但不完全正确；METR 关于 AI Coding 生产力的随机对照研究 也提醒，在熟悉的大型代码库里，经验开发者使用 AI 工具不一定天然更快，review、清理和上下文偏差都可能吞掉收益。

团队里可以把底线写清楚：

• 重要改动必须看 diff。
• Agent 跑过测试，不代表测试覆盖了风险。
• 新代码要贴合项目现有模式，不要为了「看起来能跑」引入新风格。
• Agent 连续走错方向时及时 Stop，回到计划和上下文边界，不要在错误方向上继续补 prompt。
• 最终合入前，把测试结果、风险点、人工确认项写进 PR 描述。

Cursor 还有并行 Agent、Cloud Agent、Bugbot 这类能力。它们很有价值，但不要把它们理解成「可以少 review」。并行 Agent 会产生多份候选实现，消耗和 review 成本会一起升高；Cloud Agent 涉及仓库、依赖、凭据、构建环境和网络访问；Bugbot 依赖代码托管平台集成和权限配置。越是自动化，越需要清楚边界。

Agent Review 可以放进本地开发习惯里。比如一次 Agent 任务结束后，不要马上接受所有改动，可以先看 Cursor 给出的检查，再自己看最终 diff。Quick 更适合小 diff 和快速检查，Deep 更适合复杂逻辑、安全敏感代码和大范围重构。

Bugbot 更像 PR / MR 场景里的额外 review 机器人，能不能用取决于代码托管平台、权限、付费方案和组织集成方式。它适合了解机制，但不要把它当成所有团队天然可用的流程。

并行 Agent 也要谨慎。Cursor 官方实践里提到，Cursor 会为并行运行的 Agent 管理 git worktrees，让多个 Agent 在隔离工作区里处理任务。这个能力适合两类场景：一类是同题多解，让不同模型或不同 Agent 比较方案；另一类是拆分并行，把大任务拆成互不冲突的子任务，比如一个 Agent 改接口适配，一个 Agent 补测试，一个 Agent 整理文档。

并行的代价也很直接：三份 Agent 就是三份上下文、三份推理、三份输出、三份 diff。没有时间 review 多份结果时，并行只会放大混乱。适合并行的任务通常有高价值、高不确定性和明确验收标准；小文案、小样式、基础问题、需求还没讲清楚的任务，都不适合并行。

Cloud Agent 属于更重的能力。它的思路是让 Agent 在远程开发环境里克隆仓库、安装依赖、写代码、跑测试、提交变更，本机离线时也能继续工作。这个能力对开源项目、云端仓库和标准化环境很有吸引力，但它会涉及仓库权限、依赖安装、凭据、构建系统、网络访问和日志数据。组织内部使用时，需要先经过基础设施和安全评估，不适合个人临时绕过去使用。

越往自动化方向走，越要把这几条写清楚：

• 哪些仓库和文件可以被访问。
• 哪些命令可以运行。
• 哪些数据不能进入上下文。
• 哪些结果必须人工 review。
• 出问题时怎么回滚。

AI Coding 的成熟度，取决于 Agent 产出的结果能不能被人理解、验证、回滚和沉淀，而不取决于它能不能自己一路跑到底。

能分流的问题就不要全放进 Cursor

Cursor 很适合代码仓库上下文，但它不应该承包所有 AI 任务。工具分流有两个价值：一是把 Cursor 留给真正依赖代码上下文的工程任务；二是让问题在最贴近材料的工具里解决。

办公文档里的会议纪要、需求摘要、周报、评审记录，优先用办公文档 AI。设计稿里的文案、图层、原型和交互探索，优先用 Figma AI 或 Figma Make。公开技术资料，优先用官方文档、文档自带问答、搜索和通用模型。回到 Cursor 时，问题应该已经更具体，例如「按这份官方迁移文档，判断当前项目哪些文件需要改」。

免费或低成本通用模型适合公开知识和脱敏材料：

• 概念解释。
• 语法问题。
• SQL、正则、CSS 小问题。
• 脱敏后的报错初步分析。
• 文案和翻译。
• 官方文档片段解释。

不要放过去的内容也要明确：

• 私有仓库源码。
• 密钥、token、cookie。
• 用户数据。
• 未脱敏日志。
• 内部接口文档。
• 未公开产品方案。
• 客户、营收、合同、权限等敏感信息。

Cursor 和免费工具的安全边界也不一样。Cursor 的 Security 和 Data Use 页面会说明 Privacy Mode、数据使用、训练和模型供应商 Zero Data Retention 等口径。组织批准的商业工具和个人随手打开的免费网页工具，在协议、管理、权限、审计和数据处理上通常不是一回事。

这条边界不代表任何东西都能随便贴进 Cursor。密钥、token、cookie、生产用户数据、客户资料、未脱敏日志、合同、营收、权限清单、内部账号、数据库导出等，仍然要按安全规范处理。Cursor 可以读代码，不代表可以把敏感数据当普通上下文粘进去。

可以按这个表判断：

材料类型	Cursor	免费或个人 AI 工具	处理方式
项目源码、业务调用链	适合	不适合	在组织允许的工程工具里处理
线上日志、用户数据、客户资料	先脱敏裁剪	不适合	只保留必要字段和关键报错
密钥、token、cookie	不适合	不适合	不进入任何 AI 上下文
公开 API 文档、官方示例	可以	可以	优先官方文档和 @Docs
脱敏后的通用报错	可以	可以	去掉路径、用户信息、内部接口
SQL、正则、CSS 小问题	可以但不优先	适合	优先分流
文案、翻译、会议摘要	不优先	适合	优先办公文档 AI 或通用模型
设计初稿、原型、图层整理	不优先	不适用	优先 Figma AI / Figma Make

一份日常自查清单

真正开始用 Cursor 之前，可以先问自己几个问题。这些问题不复杂，但能避免大量后续返工。

第一，当前任务到底要不要用 Cursor。只要问题不依赖项目源码、私有调用链、测试环境或真实 diff，就先考虑官方文档、搜索、通用模型、办公文档 AI 或设计工具 AI。Cursor 最擅长的是工程上下文，不是所有知识问答。

第二，这次应该用 Ask、Plan 还是 Agent。还没理解入口和影响范围时，用 Ask；知道目标但不确定方案时，用 Plan；方案已经清楚、文件范围和验收标准也清楚时，再让 Agent 改。不要把 Agent 当成第一步。

第三，模型和模式是否过重。普通解释、小改动、文案和公开 API 查询，不需要高阶模型、Thinking、Fast 和 Max Mode 一起上。复杂重构、疑难 bug、发布前风险评审才值得升级模型或打开更重模式。

第四，上下文是否过大。文件、日志、截图、旧对话、目录、规则都会一起进入上下文。给得越多，模型未必越聪明，反而可能更难抓住关键点。先给最小闭环材料，让 Agent 需要时再补。

第五，当前对话是否已经太长。如果一个 chat 里连续处理多个需求，旧任务会影响新任务。任务结束后生成交接摘要，再开新对话；任务还没结束但上下文已经很重，可以先 /compress，再继续当前任务。

第六，项目规则是否已经沉淀。Agent 反复犯错的地方，不要每次都靠临时 prompt 修。入口找错，就写进 Rules；review 流程重复，就做成 Skill；多个工具都要读的项目说明，就放进 AGENTS.md。

第七，生成代码是否经过 review。Agent 改完以后，至少看 diff、测试结果和风险点。涉及权限、支付、数据删除、埋点、风控、兼容逻辑的代码，要人工重点看。AI 代码最危险的地方不是完全错，而是差一点就对。

可以把这份清单压成一个固定动作：

1. 这件事需要代码上下文吗？
2. 现在是理解、计划，还是执行？
3. 模型和模式有没有过重？
4. 上下文是不是只保留必要材料？
5. 当前对话是否该总结后切新对话？
6. 重复经验有没有写进 Rules / Skills / AGENTS.md？
7. 最终 diff、测试和风险点有没有 review？

这七个问题比任何单个 prompt 都更重要。Prompt 写得再漂亮，如果任务分错、模型选错、上下文乱掉、review 缺失，最后还是会变成「AI 看起来很忙，人类还得收拾」。

几个常见误区

第一个误区是把 Cursor 当搜索引擎。公开 API、框架参数、版本变更、报错含义，官方文档通常更可靠。Cursor 的优势是把这些资料和当前项目代码放到一起判断，而不是替代官方资料本身。

第二个误区是把 Agent 当实习生随便派活。实习生也需要需求、范围、验收标准和 review，Agent 更需要。只说「看看哪里有问题」，它就只能扩大搜索范围；说清页面、现象、相关模块、禁止改动和测试命令，它才更像在做工程任务。

第三个误区是把上下文当保险。很多人会下意识把整个目录、整份日志、整段聊天记录都给模型，觉得这样更安全。实际情况经常相反：模型看到了更多无关信息，关键文件反而不突出。上下文管理的目标不是「多」，而是「刚好够定位问题」。

第四个误区是把强模型当默认安全选项。强模型适合难题，但不能替代清楚的任务说明。一个范围含糊的任务，用更强模型也可能产出更大的错误 diff；一个边界清楚的任务，用日常模型也能完成得很好。

第五个误区是用一次成功经验替代团队沉淀。某个人用 Cursor 排查完一个复杂 bug，如果只留下一个 PR，下次别人还要重新摸索。更好的做法是把排查路径、关键文件、常见坑、测试命令、review 重点写进 Rules、Skills、FAQ 或项目文档。

第六个误区是只看单点编码速度。Cursor 让代码写得更快以后，如果 review、测试、上线、回滚没有跟上，整体风险会变高。真正有价值的提效应该体现在整个链路上：需求理解更快、影响范围更清楚、测试更完整、PR 更好 review、上线风险更可控。

第七个误区是把工具能力当成安全边界。.cursorignore 能减少无关文件进入上下文，但不能替代敏感信息管理；Agent Review 能发现一部分问题，但不能替代人工 review；Cloud Agent 能在远程跑任务，但不能绕过仓库权限、网络访问和数据合规。

这些误区本质上都指向同一件事：Cursor 的定位仍然是工程工具。工程工具需要输入、约束、验证和沉淀；缺了这些，它再聪明也会把复杂度转嫁给后面的人工 review。

从个人提效走向工程链路提效

很多人用 Cursor 后，最先感受到的是写代码更快。这当然有价值，但如果需求拆解、方案评审、测试验证、代码 review、上线回归没有同步变顺，整体交付周期不一定会明显缩短。

Cursor 参与的地方可以更靠前，也可以更靠后：

• 需求阶段：梳理历史逻辑、找相关页面和接口、列影响范围。
• 方案阶段：比较实现路线、列风险点、找类似实现。
• 开发阶段：跨文件修改、补类型、处理重复逻辑、生成辅助代码。
• 自测阶段：生成测试场景、解释失败日志、补测试建议。
• 评审阶段：整理 PR 描述、列人工 review 重点、检查遗漏文件。
• 上线阶段：整理回归点、灰度注意事项和回滚风险。
• 复盘阶段：把排障路径、测试命令和经验写进 Rules、Skills、FAQ 或项目文档。

Google DORA 的 生成式 AI 软件开发研究 有个值得警惕的观察：AI 使用和文档质量、代码质量、code review 速度提升相关，但交付稳定性可能下降。一个可能原因是 AI 让代码产出变快以后，改动批次变大，如果小批量交付、测试、review、发布控制没有跟上，整体链路反而更容易失稳。

BVP 整理的 Shopify AI-first engineering 案例 也能看到类似思路。大团队不会只采购 AI Coding 工具，还会建设 LLM proxy、MCP、prompt library、Hack Days、自动化测试和人工 PR review。工具只是入口，真正的收益来自工程体系一起调整。

更合理的看法是把 Cursor 当成一种工程生产资料。它能显著提高个人局部效率，但更大的价值在于：让任务更清楚，让上下文更干净，让复杂修改更可验证，让团队经验能沉淀下来。

Cursor 用得好，关键习惯是：先判断任务是否真的需要代码上下文，再选择合适模型和模式；先让 Cursor 理解和计划，再让它执行；先控制上下文，再追求长任务；最后把有效经验写进规则、技能、文档和 review 流程里。

这样用，AI Coding 才会从「写代码更快」走向「工程链路更稳」。