用了Cursor大半年，身边很多工程师还是把它当"装了Copilot的VSCode"来用——只用Tab补全，遇到问题还是开浏览器搜。这种用法只发挥了Cursor 20%的能力。
这篇文章从实际使用角度拆解Cursor各个功能的正确打开方式，重点放在DevOps/运维工程师的实际场景上。
Cursor vs VSCode：不是插件，是重新设计#
很多人问：Cursor和"VSCode + GitHub Copilot插件"有什么区别？
区别在于交互模型不同。Copilot是在现有编辑器里加了一个AI旁路；Cursor是以AI协作为第一公民重新设计的IDE。
具体差异：
| 维度 | VSCode + Copilot | Cursor |
|---|---|---|
| 代码补全 | 基于当前文件上下文 | 可引用整个代码库 |
| 对话 | 侧边Chat，上下文需手动添加 | Chat/Composer直接感知项目结构 |
| 多文件编辑 | 不支持 | Composer可同时修改多个文件 |
| 自定义规则 | 无 | .cursorrules注入全局上下文 |
| Agent模式 | 无 | 可自动循环执行+验证 |
| 模型选择 | 只用Copilot模型 | 可切换Claude Sonnet 4.6/GPT-5.4/Gemini 2.5 Pro |
| JetBrains支持 | 原生支持 | 支持（2026年新增） |
Cursor基于VSCode fork开发，所有VSCode插件都兼容，迁移成本几乎为零。
2026年更新：Cursor已支持JetBrains IDE（IntelliJ IDEA、PyCharm、GoLand等），不再局限于VS Code体系。JetBrains用户可以直接在原有IDE里使用Cursor的AI能力，无需切换编辑器。
Tab补全：不是"等它写完"#
Tab补全是Cursor用得最频繁的功能，但大多数人用法是被动的——写一行，等AI补，Tab接受。
正确姿势是主动驾驶：
写注释驱动补全#
# 从环境变量读取配置，如果不存在则使用默认值
# 配置项：DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD
# 返回dict格式
def load_db_config():
写完注释后，Cursor会基于注释意图补全整个函数体。注释写得越精确，补全越准确。
函数签名驱动补全#
// CheckNodeHealth 检查K8s节点健康状态，返回不健康节点列表
// nodeList: 节点名称列表
// threshold: CPU使用率阈值（百分比）
func CheckNodeHealth(clientset *kubernetes.Clientset, nodeList []string, threshold float64) ([]string, error) {
只写好函数签名和注释，光标放在函数体内，Cursor通常能补全80%以上的逻辑。
接受部分补全#
Cursor补全的内容不一定全对，不用全接受：
Tab：接受整个补全Ctrl+→（Windows/Linux）/Cmd+→（Mac）：逐词接受Escape：拒绝补全
对于长代码块，逐词接受是常见操作——接受结构，修改细节。
@上下文引用：让AI真正理解你的项目#
Chat和Composer窗口里，@符号是引入上下文的核心机制。
@Codebase#
@Codebase 我们项目里有没有现成的重试装饰器？找一个最完整的实现
Cursor会搜索整个代码库，找到相关实现并返回文件路径和代码片段。适合：
- 找已有实现，避免重复造轮子
- 了解项目里某个模式的用法
- 找出某个函数被哪些地方调用
@file#
精确引入某个文件：
@file:k8s/deployment.yaml 帮我分析这个Deployment配置，resource limits设置是否合理
@folder#
引入整个目录：
@folder:scripts/ 这些脚本都在做什么？帮我整理一下功能清单
@web#
引入网络搜索结果：
@web kubernetes 1.29 deprecated APIs 我需要知道哪些API在1.29被废弃了
适合需要最新文档的场景，比如查某个工具的最新参数、API变化。
@docs#
引入特定文档：
@docs https://kubernetes.io/docs/reference/kubectl/cheatsheet/ 帮我写一个脚本，实现这个cheatsheet里的资源监控命令集合
上下文引用的组合用法#
多个@可以组合：
@file:Dockerfile @file:docker-compose.yaml @web docker multi-stage build best practices
帮我优化这两个文件，减少镜像体积
Composer：多文件编辑工作流#
Composer（快捷键Ctrl+I/Cmd+I）是Cursor最强的功能，专门处理需要修改多个文件的任务。
基本用法#
打开Composer后，描述你想要做的事：
我需要给项目加一个健康检查HTTP接口：
- 路径：/healthz
- 返回：JSON格式，包含服务版本、数据库连接状态、当前时间
- 在 cmd/server/main.go 里注册路由
- 在 internal/handlers/ 里新建 health.go 实现handler
- 在 internal/db/ 里加一个 Ping() 方法检查连接
Composer会：
- 分析需要改动的文件
- 列出修改计划
- 逐文件展示diff
- 等你确认后写入
审查Composer的修改#
Composer给出每个文件的修改后，不要直接全Accept。正确流程：
- 先看文件列表：确认它没有修改你不想动的文件
- 逐文件看diff：检查逻辑是否符合预期
- 对有疑问的文件，在Chat里追问
- 确认无误后Accept
多轮迭代#
Composer支持多轮对话。发现某个文件改错了：
health.go里的数据库检查逻辑有问题，它每次都创建新连接，
应该用已有的db连接池，连接池对象在 internal/db/db.go 的 DB变量里
Composer会基于上一轮的上下文继续修改，不需要重新描述整个需求。
.cursorrules：项目级AI配置#
.cursorrules文件放在项目根目录，里面的内容会自动注入到所有Chat和Composer的上下文里。
一个运维工具项目的.cursorrules示例：
# 项目：运维自动化工具集
## 技术栈
- Python 3.11+
- 使用 structlog 做结构化日志，不用 print
- 使用 typer 做CLI接口
- K8s操作使用 kubernetes-client 库，不直接调用kubectl subprocess
- 配置通过环境变量读取，用 pydantic BaseSettings 管理
## 代码规范
- 所有函数必须有类型注解
- 错误处理：用自定义Exception类，继承自 BaseOpsError
- 日志格式：{"event": "...", "level": "...", "timestamp": "...", ...}
- 敏感信息（API Key、密码）不能出现在日志里
## 命名规范
- 文件名：snake_case
- 类名：PascalCase
- 常量：UPPER_SNAKE_CASE
- K8s相关变量：带k8s_前缀，如 k8s_client, k8s_namespace
## 禁止事项
- 不使用 os.system() 或 subprocess.run() 执行K8s命令，统一用kubernetes client
- 不硬编码任何IP、域名、端口
- 不在代码里写TODO注释，改成GitHub Issue
## 项目结构
- scripts/：一次性脚本，不追求复用性
- tools/：可复用的工具模块
- tests/：单元测试，pytest
有了这个文件，Cursor生成的代码会自动遵守这些规范，不需要每次都在prompt里重复说明。
Computer Use / Agentic模式：AI接管操作#
2026年Cursor新增了computer use功能：AI不只是写代码，还可以直接操控电脑界面——打开终端执行命令、在浏览器里查文档、运行测试、截录进度视频供开发者事后review。
这把AI的角色从"代码助手"升级成了"自动化执行者"：你描述目标，Cursor自主完成整个任务流，包括调试运行结果、修正错误、验证通过。进度视频让你可以像review异步任务一样查看AI做了什么。
适合场景：
- 端到端的功能实现（从写代码到跑通测试）
- 需要在浏览器查阅最新文档然后写代码的任务
- 定时跑的批量代码改造任务
Agent模式：自动循环执行#
Agent模式（在Chat里切换到Agent）和普通Chat的区别：Agent会主动执行命令验证结果，而不是只给代码。
开启Agent模式后，你可以说：
帮我检查一下项目里所有Python脚本的语法，
找出有问题的文件并修复
Agent会：
- 运行
python -m py_compile对每个文件检查语法 - 找出有问题的文件
- 修复错误
- 再次运行验证
整个过程自动循环，直到所有文件都通过检查。
Agent模式的边界#
Agent模式不是万能的，需要注意：
- 别让它自动执行破坏性操作：
rm -rf、数据库写操作等要手动确认 - 循环次数有上限：默认25次工具调用，超过会停止
- 文件修改要checkpoints：Agent改了多个文件后，用git diff看全貌
模型切换#
Cursor支持在不同模型之间切换，每种模型有不同的适用场景：
| 模型 | 适用场景 |
|---|---|
| Claude Sonnet 4.6 | 复杂逻辑、大文件分析、需要推理的问题 |
| GPT-5.4 | 通用编程，速度快 |
| Gemini 2.5 Pro | 长上下文、跨文件分析 |
| cursor-small | 简单补全、快速回答，节省token |
切换位置：Chat窗口右上角的模型下拉菜单，或在设置里设置默认模型。
对于DevOps工作，我的经验：
- 写Terraform/K8s YAML：Claude Sonnet 4.6，理解上下文能力更强
- 写Python/Shell脚本：GPT-5.4，速度够快，质量也够用
- 排查复杂问题、理解大型代码库：Claude Sonnet 4.6
实战：用Cursor重构运维脚本#
下面是一个实际案例：把一堆杂乱的运维Shell脚本重构成结构化的Python工具。
初始状态#
scripts/
├── check_disk.sh # 检查磁盘使用率
├── restart_service.sh # 重启服务
├── collect_logs.sh # 收集日志
├── alert_slack.sh # 发Slack告警
└── daily_report.sh # 每日报告（调用上面几个）
这些脚本各自为政，参数靠位置参数，没有日志，错误处理靠set -e。
重构过程#
第一步：让Cursor理解现有代码
@folder:scripts/
分析这5个脚本，告诉我：
1. 每个脚本的功能
2. 它们之间的依赖关系
3. 公共逻辑在哪里（可以抽取的部分）
Cursor分析后给出了功能清单和依赖图，确认理解正确后继续。
第二步：设计新结构
基于刚才的分析，我想把这些脚本重构成Python项目：
- 用typer做CLI
- 用structlog记日志
- 公共的告警逻辑抽成单独模块
- 每个功能作为子命令
给我一个项目结构方案，不需要写代码，先讨论架构
第三步：Composer多文件实现
确认了架构后，打开Composer：
按照刚才讨论的架构，帮我实现这个Python工具：
项目名：ops-toolkit
结构：
- ops_toolkit/__init__.py
- ops_toolkit/cli.py # typer入口，注册所有子命令
- ops_toolkit/disk.py # 磁盘检查逻辑，移植自check_disk.sh
- ops_toolkit/services.py # 服务管理，移植自restart_service.sh
- ops_toolkit/logs.py # 日志收集，移植自collect_logs.sh
- ops_toolkit/notify.py # Slack通知，移植自alert_slack.sh
- ops_toolkit/report.py # 日报，移植自daily_report.sh
原始Shell脚本在@folder:scripts/
要求：
- 所有函数有类型注解
- structlog记录操作日志
- 错误用自定义异常，不要直接raise Exception
第四步：验证和迭代
Composer生成后，在Chat里验证：
ops_toolkit/disk.py 里，原来的Shell脚本会检查每个挂载点的inode使用率，
但新版本只检查了磁盘容量，遗漏了inode检查，帮我补上
整个过程大约40分钟，完成了原本需要半天的重构工作。关键不是Cursor"自动写了所有代码"，而是它承担了大量的机械性工作（结构转换、样板代码），让我把注意力集中在逻辑正确性上。
几个实用技巧#
用Cursor理解陌生代码库#
接手一个不熟悉的项目时：
@Codebase 这个项目的整体架构是什么？主要的数据流是怎样的？
从入口点开始梳理一下
比看README更快，因为它是基于实际代码而不是文档（文档经常过时）。
快速写测试#
@file:internal/handlers/health.go
给这个handler写单元测试，用testify，
覆盖：正常情况、数据库连接失败、返回格式验证
代码Review辅助#
@file:deploy/kubernetes/deployment.yaml
从安全和最佳实践角度review这个Deployment：
1. 是否有安全配置缺失
2. resource limits是否合理
3. 是否有可靠性隐患
写文档#
@file:ops_toolkit/disk.py
给这个模块的每个公开函数写docstring，
格式用Google style，中文
付费计划选择#
Cursor目前的定价（2026年）：
- Free：每月500次快速请求，无限慢速请求，基本够个人学习用
- Pro（$20/月）：无限快速请求，可用Claude Sonnet 4.6、GPT-5.4、Gemini 2.5 Pro，适合日常开发主力工具
- Business（$40/用户/月）：团队功能、隐私模式（代码不用于训练）
对DevOps工程师来说，Pro计划够用。如果公司对代码安全有要求，考虑Business或者Private模式。
常见坑#
坑1：Composer改了不该改的文件
Composer有时会"自作主张"修改范围外的文件。养成习惯：每次Composer完成后，先看文件列表，再看diff。
坑2：@Codebase在大型仓库里效果差
超过10万行代码的仓库，@Codebase的质量会下降。解决方法：用@folder精确指定范围，或用@file明确指定相关文件。
坑3：Tab补全接受了错误代码
AI补全的代码语法正确但逻辑可能有bug，尤其是涉及业务逻辑的部分。Tab接受后不等于完成，还需要review。
坑4：.cursorrules写太长
.cursorrules超过500行后，AI很难全部遵守。保持简洁，只写最重要的规则，细节靠具体prompt说明。
