【AI】cursor使用小技巧
一、核心框架:6 段式 Prompt 结构
Cursor 的 Agent 对结构化指令的解析远优于段落式描述。官方推荐的 Prompt 遵循以下 6 段式模板 :
| 模块 | 作用 | 示例写法 |
|---|---|---|
| Goal | 一句话定义产出,可衡量 | Goal: 为 /invoices API 添加分页,保留现有筛选和排序 |
| Context | 指向相关文件/当前行为,用@锚定 | Context: 后端逻辑在 @src/api/invoices.ts,当前无分页参数 |
| Constraints | 必须遵守的边界(库、风格、安全、兼容) | Constraints: 使用现有 Zod 校验,不改数据库 Schema,不引入新依赖 |
| Examples | 给 1-2 个输入/输出示例,消除歧义 | Example: 请求 ?page=2&limit=20 应返回第 21-40 条 |
| Output Format | 明确要 diff / 文件列表 / 计划 / 测试报告 | Output: 每个改动文件提供 unified diff,附测试用例 |
| Verify | 要求自测、边缘 case 覆盖、运行命令 | Verify: 运行 pnpm test,列出 5 个 edge cases 并确认覆盖 |
黄金公式(社区总结版):具体任务 + 技术要求 + 上下文引用(@) + 预期结果
二、上下文工程:@符号体系
Cursor 的上下文精度直接决定输出质量。不要把整段代码贴进聊天框,而是用@精确引用 :
@类型 | 适用场景 | 注意事项 |
|---|---|---|
@file/@folder | 指向具体文件或目录 | 最常用,优先于@codebase |
@codebase | 全局语义搜索 | 高风险——等于把排序交给 Cursor 的 reranker,建议配合具体文件使用 |
@docs | 引用外部文档(如框架官方文档) | 对训练数据少的框架(如 Svelte 5)必用 |
@git | 引用 Git 历史 / diff | 用于对比变更或追溯 |
@notepad | 跨 Composer 共享上下文 | 适合记录项目关键信息、API 约定 |
最佳实践:"这是后端 @/backend.py,这是前端 @/frontend.js,现在去 __________"远比"@codebase,去 __________"精准 。
三、项目级规则:.cursorrules+ Custom Commands
1..cursorrules(项目根目录)
这是 Cursor 的“持久系统提示词”,一次配置,全项目生效。官方建议保持精简,聚焦核心约定 :
# 代码规范 - 新模块放在 src/features/ 下,按功能域组织 - 错误处理统一使用现有 Result<T, E> 模式,不抛裸异常 - 命名:函数 camelCase,类型 PascalCase,常量 SCREAMING_SNAKE_CASE # 安全护栏 - 禁止修改公共函数签名,除非附带迁移方案 - 禁止新增依赖,除非用户明确要求 - 不得记录 secrets,token 必须哈希存储 # 命令手册(完成前必须执行) - 运行 pnpm lint && pnpm test 通过后再标记完成 - 修改后更新相关文档,标注日期,引用代码行号进阶技巧:对训练数据少的框架,先把官方文档喂给 Cursor,让它生成.cursorrules,实现“AI 教 AI” 。
2. Custom Commands(设置 → Commands)
把高频 Prompt 固化为/命令,效率提升约 80% :
| 命令 | Prompt 内容 |
|---|---|
/review | Review selected code, focus on: performance, security, standards, potential bugs. Provide specific fixes. |
/test | Generate unit tests for selected function using existing framework, 80%+ coverage, include edge cases. |
/refactor | Refactor selected code to optimize time complexity and readability. No behavior change. Add tests to prove equivalence. |
/docs | Generate JSDoc for selected function/class: description, params, return value, usage examples. |
四、工作流模式:Plan → Implement → Verify
Cursor 官方支持Plan Mode,对非 trivial 的改动,强制“先计划、后执行” :
Step 1: Plan only. No code. → 输出:步骤清单 + 涉及文件 + 风险点 Step 2: Implement the approved plan. → 输出:按文件组织的 diff + 测试 + 简要验证说明 Step 3: Verify and iterate. → 运行测试、检查集成点、清理临时文件关键原则:
- Chain of Prompts = Chain of Thought:拆成“计划 → 代码 → 测试 → 文档”多轮,比单轮大 Prompt 更稳定
- 任务链闭环:Task A 暴露问题 B → 理解 B → 修复 B → 再标记完成,不要停在第一个问题
- 用词精确:用
"Rewrite"触发全量重写,用"Change"容易得到补丁式修改
五、可复用 Prompt 模板库
以下模板直接复制可用,按场景分类 :
| 场景 | Prompt 模板 | 预期产出 |
|---|---|---|
| 功能规划 | Plan only. Goal: {目标}. Context: @文件 @目录. Constraints: {约束}. Output: 步骤计划 + 改动文件 + 风险点. | 60 秒内可审阅的计划 |
| 功能实现 | Implement the approved plan. Follow existing patterns in @参考文件. Output: unified diffs per file + tests + testing notes. | 可编译、有测试、风格一致 |
| 安全重构 | Refactor @文件 to reduce complexity. Constraints: no behavior change. Add/adjust tests to prove equivalence. Output: diffs + before/after explanation. | 更简洁 + 测试证明等价 |
| Bug 调试 | Reproduce the bug based on: {复现步骤}. Instrument with logs if needed. Propose 2 likely root causes, then implement fix with tests. | 根因明确、修复最小、防回归 |
| 测试生成 | Add tests for @文件. Cover happy path and edge cases: {列表}. Use existing test framework. Output: diffs only. | 聚焦、匹配现有工具链 |
| API 文档 | Generate API docs for @文件. Output: Markdown with endpoints, request/response examples, error cases. | teammate 无需再问 |
六、模型选择策略(成本控制)
Cursor 支持多模型切换,按任务复杂度选择可显著降本 :
| 模型 | 适用场景 | 成本定位 |
|---|---|---|
| GPT-4 | 复杂架构设计、关键 Bug 修复、新功能规划 | 高 |
| Claude Sonnet | 日常编码、Code Review、重构、生成测试 | 中(推荐主力) |
| GPT-3.5 / Cursor-small | 简单修改、代码格式化、生成注释、文本翻译 | 低 |
七、3 周渐进上手路线(社区验证版)
| 周次 | 目标 | 每日动作 |
|---|---|---|
| Week 1 | 快捷键 +@符号 | 用Cmd+I(Composer) 处理至少 1 个多文件任务;练习 8 种@用法,每日 3+ 次 |
| Week 2 | 上下文管理 | 写 1 份.cursorrules;用 Notepad 记录关键约定;复杂任务强制走 Plan Mode |
| Week 3 | Prompt 优化 + 成本控制 | 创建 3-5 个 Custom Commands;按“黄金公式”写 Prompt;简单任务切 GPT-3.5 |
总结:Cursor 的 Prompt 工程是“明确目标 + 精准上下文(@) + 刚性约束 + 计划先行 + 验证闭环”的工程系统。先把.cursorrules和 Custom Commands 配好,再按 6 段式模板写 Prompt,效率和质量会显著区别于“随便聊”的使用方式。
