Cursor开发实战应用
文章目录
模型
OpenAI系列
GPT-4 Turbo：最新的GPT-4版本，128K上下文，知识截止到2024年4月
GPT-4o：Omni模型，多模态能力强，响应速度快
o1系列：你提到的推理优化模型
Anthropic（Claude系列）
Claude 3.5 Sonnet：你已提到，目前综合能力很强
Claude 3 Opus：更高阶版本，适合复杂任务
Claude 3 Haiku：轻量快速版本
Google系列
Gemini 1.5 Pro：100万token上下文，多模态能力强
Gemini 1.5 Flash：更快更经济的版本
开源/其他商业模型
DeepSeek：有不错的推理能力
Qwen系列：阿里通义千问，Qwen2.5表现不错
Llama系列：Meta的开源模型，Llama 3.1值得关注
Mistral系列：法国的Mistral AI，性能很好
模型选择建议：
日常对话/写作：GPT-4o、Claude 3.5 Sonnet
复杂推理：o1系列、Claude 3 Opus
长文档处理：Claude/Gemini（长上下文优势）
多模态：GPT-4o、Gemini 1.5 Pro
成本敏感：GPT-4o、Claude Haiku、开源模型
使用技巧
通过Cursor Rules、Skills 等机制实现人机协作、可控可追溯与安全优先的开发模式，结合 Subagents 与多代理工作流提升质量与效率，最终形成可维护、高安全、持续优化的 AI 辅助开发体系。
| 配置类型 | 本质 | 内容特点 | 加载时机 |
|---|---|---|---|
| AGENTS.md | 项目名片 | 项目概览、工作流程 | 始终加载 |
| Rules | 精炼的规范 | 禁止规则 + 简洁指导 | 始终加载 |
| Skills | 详细最佳实践 | 完整流程、示例代码、脚本 | 按需加载 |
| Commands | 快捷操作 | 固定流程、快速响应 | 用户调用 |
| Subagents | 专业代理 | 独立任务、结构化输出 | 按需调用 |
| Hooks | 自动化触发器 | Shell 命令、强制执行 | 事件触发 |
| MCP | 外部能力接口 | 数据源、外部服务 | 按需连接 |
AI 开始任务
↓
读取 AGENTS.md → 了解项目是什么、结构如何
↓
读取 Rules → 知道精炼的规范和约束
↓
遇到特定任务时 → 按需加载相关 Skill / 调用 Subagent / 连接 MCP
↓
执行操作时 → Hooks 自动触发检查和格式化Rules
精炼的编码规范，始终加载到上下文中对ai的编码行为进行指导。精炼的规范包含禁止规则、简洁的指导原则和关键约定：
- rules保持精炼，始终被加载到上下文中，内容过多会占用token
- 详细的最佳实践和完整的工作流程应该放到skills中
- 应该包含的内容：
- 禁止规则：明确的红线约束
- 简洁的指导：命名规范表格、类型选择指南
- 关键约定：如测试覆盖率要求
Skill vs Rules：
- Rules (
.cursor/rules)：永远在后台生效的宪法，用于定义项目全局的编码规范、技术栈等- Skills (
SKILL.md)：按需加载的工具书，用于封装特定领域的专业知识和工作流程
Skills
skills是为agent动态加载的操作手册、或领域知识包。与始终生效的rules不同，Skills 只在需要时才被激活，这让 Agent 在面对特定任务时能瞬间变身专家，同时不会在平时增加上下文的负担。skills是最佳实践的载体，用于存放详细的、内容丰富的编码规范和工作流程：
设计原则：
- 输入输出：清晰定义skill的输入参数与输出格式
- 领域完整性：包含详细说明、代码示例、工作流程，每个Skill应包含某个领域的完整最佳实践
- 领域隔离：不同领域的最佳实践互相独立，便于维护，每个Skill只解决一类问题
- 独立更新：可以独立更新某个领域的最佳实践，不影响其他部分
创建与使用：
-
创建文件夹：在项目根目录下创建
.cursor/skills/my-first-skill/，如果想让所有项目都能用则在用户目录下创建~/.cursor/skills/ -
编写SKILL.md：在文件夹内创建SKILL.md文件，这是Skill的核心
-
使用Skill：创建后重启Cursor，在设置的Rules中可以看到，
- 之后在Agent模式下AI会根据描述自动调用
- 或者可以手动输入
/skill-name来强制激活使用
skills/
├── skill-name/
│ ├── SKILL.md # Skill 主文件（必需）
│ ├── references/ # 参考文档
│ │ └── patterns.md
│ └── scripts/ # 辅助脚本
│ └── helper.ts
markdown
---
name: skill-name
description: 这是一个用于代码审查的技能，当用户要求审查代码或PR时使用。
category: 'Development'
keywords: ['keyword1', 'keyword2']
---
# Skill 名称
[详细描述]
## 适用场景
- 场景 1
- 场景 2
## 工作流程
1. 步骤 1
2. 步骤 2
## 输入
- 参数 1: 说明
- 参数 2: 说明
## 输出
- 输出格式说明
## 示例
[使用示例]skills触发机制：
| 触发方式 | 说明 | 示例 |
|---|---|---|
| 自动触发 | AI 根据任务上下文自动识别并调用 | 收到 Figma 链接时触发 figma 技能 |
| 手动触发 | 用户明确请求时才调用 | /i18n-prepare 处理国际化 |
| 关键词触发 | 检测到特定关键词时触发 | 提到"设计稿"时触发 figma 技能 |
Subagents
subagents是cursor实现复杂任务并行处理的工具，可以认为是一个项目主管，手下多个领域的专家。
主Agent接到一个庞大任务，会将任务拆解，并派生出多个 Subagents。它们并行工作 ，各自负责一个子任务。（如一个分析数据库模型，另一个修改前端路由），最终将结果汇总。这能极大提升复杂任务的执行速度，并保持主对话上下文的简洁。 Cursor 内置用于代码库分析、执行终端命令的默认 Subagents，也可以创建自定义的 Subagents，为特定领域配置专属的提示词、工具权限和模型。（如React 组件测试专家）
prompt
prompt编写原则：
- 明确具体：清晰说明任务目标和期望输出
- 提供上下文：给出必要的背景信息和约束条件
- 分步指导：复杂任务拆分为多个步骤
- 示例驱动：提供输入输出实例
上下文管理：
- 精选文件：使用@引用相关文件，避免信息过载
- 渐进式提供：先给概要，按需补充细节
- 及时清理：长对话中定期总结，减少冗余上下文
- 使用注释：在代码中使用注释说明意图
实际场景应用
日常的工作场景：业务需求代码开发、老代码项目结构重构、以及新项目架构设计，利用Cursor的Agent、Subagents、Skills的威力发挥到极致。针对这三个场景做实战组合策略：
日常业务开发 Skill
核心工作流：新需求 → Plan模式拆解 → Agent模式实现 → Code Review Skill检查
-
plan模式理清需求：
Plan 模式会输出一个任务清单，确认后可以直接让它开始执行
需求：用户个人中心增加"收货地址管理"功能，支持增删改查，最多10个地址。 请帮我： 1. 分析需要改动哪些文件 2. 拆解成可独立交付的子任务 3. 指出可能的技术风险和边界情况 -
创建业务开发专属skill：
在
.cursor/skills/cpp-business/SKILL.mdmarkdown--- name: cpp-business description: C++ 业务代码开发规范，重点关注内存安全和 RAII --- # C++ 业务开发规范 ## 代码生成要求 - 优先使用 `std::unique_ptr` / `std::shared_ptr`，禁止裸指针管理资源 - 类的 5 大特殊成员函数（构造/析构/拷贝/移动/赋值）要么默认、要么显式 - 头文件中只放声明，实现放 .cpp，减少编译依赖 - 使用 `#pragma once` 或 include guard ## 错误处理 - 不使用异常？用 `std::expected<T, E>` (C++23) 或 `tl::expected` - 资源泄漏检查：每条 `new` 必须有对应的 `delete`（或用智能指针） ## 性能要求 - 避免不必要的拷贝：参数用 `const&`，返回值用移动语义 - 循环中不要频繁构造临时对象 - 热路径代码禁用 RTTI 和 dynamic_cast ## 测试要求 - 核心逻辑生成对应的单元测试 - 边界情况：空值、极限值、网络异常 ## 完成后自查 1. 有没有内存泄漏风险？ 2. const 正确性是否保证？ 3. 头文件依赖是否最小化？// 在 Cursor 中输入： 使用 cpp-business skill，实现一个线程安全的用户会话管理器 SessionManager， 支持： - 创建会话（返回 session_id） - 根据 session_id 获取会话数据 - 销毁过期会话 要求： - 使用 shared_ptr 管理会话生命周期 - 使用 std::shared_mutex 实现读写锁 - 会话过期时间可配置
项目架构设计 Skill
核心工作流：需求分析 → 架构方案对比 → 脚手架生成 → 架构文档固化
创建架构师Skill：.cursor/skills/architect/SKILL.md
markdown
---
name: cpp-architect
description: C++ 项目架构设计专家，负责技术选型和模块划分
---
# C++ 架构设计规范
## 技术选型决策表
必须包含：
- 编译器版本（C++17/20/23）
- 构建系统（CMake/Bazel）
- 包管理（vcpkg/Conan）
- 测试框架（GoogleTest/Catch2）
- 日志库（spdlog）
- 序列化（protobuf/nlohmann/json）
## 模块划分原则
1. **按编译单元组织**：每个模块有独立的 include/ 和 src/ 目录
2. **接口与实现分离**：公开接口放 include/，实现放 src/
3. **最小头文件原则**：头文件只包含必要的依赖
## ABI 稳定性策略
- 需要跨版本兼容的库使用 PIMPL 模式
- 导出接口只使用纯虚类 + 工厂函数
- 禁用内联函数在导出类中使用 cpp-architect skill，设计一个"实时数据采集与处理系统"：
需求：
- 从多个传感器采集数据（1000 Hz）
- 实时处理（滤波、特征提取）
- 数据存储和回放
- 提供查询 API
约束：
- 延迟要求 < 1ms
- 运行在 ARM Linux 上
- 内存受限（1GB）
- 团队熟悉 C++17
请输出：
1. 技术选型决策表
2. 模块划分图（Mermaid）
3. 关键接口定义
4. CMake 项目结构
基于上面的架构方案，生成 CMakeLists.txt：
- 支持交叉编译（ARM）
- 分离 Debug/Release 配置
- 集成 GoogleTest 和 benchmark
- 可选组件（根据传感器类型启用）代码重构 Skill
老代码
依赖分析 Subagent
内存安全检查 Subagent
头文件优化 Subagent
重构计划
小步执行
回归测试
创建三个专用subagent，在 .cursor/agents/ 下创建：
依赖分析Agent（cpp-dependency-analyzer.md）：
name: cpp-dependency-analyzer
description: 分析 C++ 项目的头文件依赖、循环依赖、编译时间瓶颈
tools: [read_file, grep, bash]
prompt: |
你是 C++ 依赖分析专家。给定一个模块，分析：
1. **头文件依赖图**：哪些头文件被包含，是否有循环包含
2. **编译时间杀手**：找出在 .h 中包含了重量级头文件（如 <windows.h>、<boost/multi_index.hpp>）
3. **前向声明机会**：哪些 #include 可以替换为前向声明
4. **PIMPL 适用场景**：识别可以通过 PIMPL 隐藏实现的类
输出格式：Mermaid 依赖图 + 优化建议列表内存安全审计 Agent (cpp-memory-auditor.md)：
name: cpp-memory-auditor
description: 审计 C++ 代码的内存安全问题
tools: [read_file, grep]
prompt: |
你是 C++ 内存安全专家，检查：
1. 裸指针管理资源的地方（new/delete 未配对）
2. 悬空指针风险（返回局部变量的地址、迭代器失效）
3. 异常不安全代码（资源泄漏路径）
4. 未初始化的变量
5. 数组越界风险
对每个问题，给出修复建议和代码示例。重构影响评估 Agent (cpp-impact-analyzer.md)
name: cpp-impact-analyzer
description: 评估 C++ 代码改动的影响范围
tools: [read_file, grep, bash]
prompt: |
分析修改特定函数/类的影响：
1. 直接调用方（包括模板实例化的隐式调用）
2. 间接依赖（通过虚函数、回调函数）
3. 头文件传递依赖（改 A.h → 所有 include A.h 的文件需要重新编译）
4. ABI 兼容性影响（如果这是动态库接口）
输出：影响文件列表 + 预估重编译成本使用方案：
# 第一步：让 Subagents 并行分析
@cpp-dependency-analyzer 分析 src/legacy/network/ 模块的依赖关系
@cpp-memory-auditor 审计 src/legacy/network/TcpConnection.cpp
@cpp-impact-analyzer 评估把 TcpConnection 改成智能指针管理的影响
# 第二步：用 Plan 模式制定重构计划
切换到 Plan 模式：
基于分析结果，制定渐进式重构计划，要求：
- 每一步都能编译通过
- 不改变公有接口（保持 ABI 兼容）
- 优先解决内存泄漏问题
# 第三步：执行重构
使用 cpp-business skill，按计划执行第一步：将裸指针改成 unique_ptr目录设计方案
teamtalk-项目根目录/
├── .cursor/
│ ├── rules/ # 全局规则（始终生效）
│ │ ├── general.mdc # 通用编码规范
│ │ ├── cpp-standards.mdc # C++ 标准规范
│ │ ├── teamtalk-specific.mdc # TeamTalk 专属规则
│ │ └── security.mdc # 安全规范
│ │
│ ├── skills/ # 按需加载的技能包
│ │ ├── teamtalk-client/ # Windows 客户端开发技能
│ │ │ ├── SKILL.md
│ │ │ └── references/
│ │ ├── teamtalk-server/ # 服务器开发技能
│ │ │ ├── SKILL.md
│ │ │ └── references/
│ │ ├── db-schema/ # 数据库设计技能
│ │ │ └── SKILL.md
│ │ ├── protocol-analyzer/ # 协议分析技能
│ │ │ └── SKILL.md
│ │ └── performance-tuner/ # 性能调优技能
│ │ └── SKILL.md
│ │
│ ├── agents/ # 专用 Subagents
│ │ ├── dependency-analyzer.md
│ │ ├── memory-auditor.md
│ │ ├── protocol-debugger.md
│ │ ├── db-optimizer.md
│ │ └── windows-specific.md # Windows 特有（COM、Win32 API）
│ │
│ ├── templates/ # 代码模板
│ │ ├── module.h.tmpl
│ │ ├── module.cpp.tmpl
│ │ ├── service.h.tmpl
│ │ ├── unit-test.cpp.tmpl
│ │ └── cmake-module.txt.tmpl
│ │
│ ├── scripts/ # 辅助脚本
│ │ ├── analyze_deps.py # 依赖分析
│ │ ├── find_circular.py # 循环依赖检测
│ │ └── proto_gen.sh # protobuf 生成
│ │
│ ├── context/ # 项目上下文知识库
│ │ ├── architecture.md # 架构文档
│ │ ├── known-issues.md # 已知问题和 workaround
│ │ ├── module-index.md # 模块索引
│ │ └── refactoring-notes.md # 重构笔记
│ │
│ └── config.json # Cursor 配置文件
│
├── .cursorrules # 根规则文件（最简单方式）
└── .vscode/ # VS Code 配置（可选）
├── settings.json
└── tasks.json