核心用法
本 skill 将 Cursor 从「模糊的 AI 编辑器」转化为可预测的操作系统，覆盖 7 大执行表面：编辑器（Agent/Ask/Manual/自定义模式）、CLI 工具 cursor-agent、项目规则系统（.cursor/rules 为主，.cursorrules 为遗留）、上下文塑形（索引、.cursorignore）、背景代理（Background Agent）、Bugbot 代码审查，以及 MCP 远程执行。核心操作范式为「先锁定表面，再建立指令层级，后塑形上下文」—— 避免在规则混乱或边界不清时直接堆叠提示词。
显著优点
1. 表面显式化：强制命名当前执行表面（editor/CLI/remote），从根本上避免「本地交互误启远程执行」的信任边界混淆。
2. 指令层级治理：区分项目规则、用户规则与遗留 .cursorrules，解决「提示词通胀」导致的规则失效。
3. 隐私数据流透明：明确列出哪些数据流向 Cursor 服务、GitHub、用户批准 MCP，哪些保持本地，消除「隐私模式 = 完全本地」的误解。
4. 可审计执行：要求非交互式运行、MCP 调用、背景代理均留下 diff/检查结果/交接轨迹，而非「agent 处理了」的黑箱。
5. 故障模式归档：通过 ~/cursor/incidents.md 记录重复失败，形成组织级 Cursor 操作知识库。
潜在缺点与局限
- 认知负荷：用户需在每次交互前完成「表面识别→规则检查→上下文裁剪」三步，对习惯直接聊天的用户形成摩擦。
- 假设工具链存在：依赖
cursor-agent、git、rg等二进制文件，纯编辑器用户可能无 CLI 环境。 - 规则维护成本：
.cursor/rules需要持续与代码库同步，大型团队可能出现规则版本漂移。 - 隐私文件非绝对屏障：明确声明
.cursorignore不阻断终端/MCP 工具调用，敏感代码仍需人工审查。 - 远程功能需显式授权：Background Agent/Bugbot/MCP 不会自动启用，追求「开箱即用」自动化体验的用户可能觉得保守。
适合人群
- 团队技术负责人：需为团队制定 Cursor 使用规范、审查远程执行权限策略。
- 安全敏感型开发者：处理私有代码、商业机密，必须明确数据流向边界。
- 多仓库维护者：通过
repo-profiles.md管理不同仓库的信任姿态与验证预期。 - 自动化工程师：需安全编排
cursor-agent、MCP 与非交互式 CI 流程。
常规风险
- 非交互式执行失控：
cursor-agent在脚本中运行时缺乏实时确认，可能快速扩大修改范围。 - 远程工作流误授权：Background Agent 的 GitHub 写入权限一旦开启，远端命令执行先于本地审查。
- MCP 范围膨胀：用户批准的 MCP 服务器可能通过工具链调用触及未预期资源。
- 规则冲突导致静默失败：项目规则与用户规则冲突时，Cursor 可能优先执行非预期指令。
- 索引泄露：
.cursorindexingignore配置错误可能导致敏感文件进入 Cursor 服务索引。