Cursor 与 IDE Agent 深度使用¶

这章不再把 Cursor 当作“会补全代码的编辑器”，而是把它当作 AI4SE 工具链中的一个前端入口。真正重要的不是按钮，而是你能不能把它接进 需求 -> 上下文 -> 计划 -> 变更 -> 测试 -> 审查 -> 交付 的闭环。

这一章解决什么问题¶

2026 到 2028 的 AI Coding 已经明显从 autocomplete 走向 agentic software engineering。你在大厂里真正会被问到的，不是“会不会用 Cursor”，而是：

• 你如何给 agent 提供足够但不过量的上下文
• 你如何让 agent 改动可控、可审查、可回滚
• 你如何设计测试门禁和评测指标
• 你如何把 IDE agent 和 CLI agent、代码仓库、CI/CD、评测平台接起来

如果你只会“打开聊天框问一句”，那不是竞争力。

学习目标¶

• 理解 Cursor 在整条 AI4SE 工具链里的真实位置
• 用仓库感知、规则文件和任务拆解提升 agent 成功率
• 建立 小步提交 + 自动验证 + 人工审查 的安全工作流
• 能把自己的使用经验包装成简历项目和面试素材

先摆正位置¶

Cursor 是什么¶

Cursor 最有价值的地方，不是单点问答，而是把下面几层合在一个交互界面里：

• 文件编辑
• 仓库索引
• 会话上下文
• 多文件修改
• 任务级 agent 执行

它适合做：

• 单仓库内的快速功能开发
• 重构、补测试、补文档
• 结合已有代码风格的增量修改
• 人工主导、agent 辅助的日常研发

它不适合直接替代：

• 企业级评测与治理平台
• 大规模批量代码变更系统
• 无门禁的自动提交流水线
• 复杂多仓库、跨服务发布编排

你要区分的 4 种能力层¶

只会第一层，2028 不够用。至少要能把第二层和第三层讲明白。

让 Cursor 真正好用的 5 个前置条件¶

1. 仓库必须“可解释”¶

如果仓库本身结构混乱、脚本命名不清、测试命令不统一，模型不会 magically 变聪明。

最低要求：

• 根目录有清晰的 README
• 有稳定可运行的 lint、test、build 命令
• 有核心目录说明
• 有明确的环境变量约束

2. 规则文件必须“约束行为”¶

不要把规则文件写成鸡汤。好的规则文件只写三类信息：

• 代码规范
• 任务约束
• 禁止行为

示例：

# 仓库约束

- 只能在 `src/`、`tests/`、`docs/` 下修改
- 先补测试再改实现
- 不允许引入新的运行时依赖，除非明确说明
- 所有 API 变更必须同步更新 OpenAPI 或文档
- 提交前必须运行 `pnpm test` 和 `pnpm lint`

3. 任务描述必须“工程化”¶

差的指令：

把这个功能完善一下

好的指令：

目标：为支付回调接口补充幂等处理
范围：只改 src/payments、tests/payments
约束：不修改数据库 schema，不新增三方依赖
验收：重复回调 10 次只落一条成功记录；现有测试全绿
输出：先给改动计划，再执行修改，再总结风险

4. 必须给 agent 一条“退出机制”¶

任何高价值仓库里，你都应该让 agent 知道什么时候停：

• 找不到确定入口时先提计划
• 涉及 schema、权限、删除数据时必须暂停
• 测试失败要先汇报，不允许盲目继续修

5. 人工必须保留最终控制权¶

2028 年仍然不会消失的能力：

• 读 diff
• 判断风险
• 看测试覆盖
• 问一句“这段改动为什么是对的”

4 个高价值工作流¶

如果把 Cursor 真正放进工程链路里，下面这 4 类工作流最值得优先练熟。

工作流 1：缺陷修复¶

最推荐的流程：

1. 先让 Cursor 总结现象、定位可能文件
2. 要求它写最小复现或失败测试
3. 再要求它做最小改动修复
4. 最后让它解释根因、风险和回归点

推荐提示模板：

请先不要修改代码。

任务：定位用户详情页偶发空白的问题
现象：刷新后概率性白屏，无明确后端错误
范围：`src/pages/user-detail`、`src/router`
要求：
- 先给可能根因列表
- 给出最小复现路径
- 设计一个能复现问题的测试或日志方案
- 等我确认后再改代码

工作流 2：重构¶

重构时最容易翻车，因为 agent 往往会“顺手改很多”。

要点：

• 明确不变的接口
• 明确允许改的目录
• 指定“只做一次重构目标”

推荐指令：

目标：把订单状态判断逻辑从控制器提取到独立 service
不变：API 入参出参、数据库 schema、埋点字段
允许修改：`src/controllers/order.ts`、`src/services/order-status.ts`、相关测试
禁止：改 UI、改接口协议、改日志格式
请按以下顺序执行：
1. 先列出将被移动的函数
2. 给出改动计划
3. 完成重构
4. 补齐测试

工作流 3：新功能开发¶

新功能不要直接让 Cursor “一把梭”。更稳的做法是三段式：

1. spec
2. plan
3. patch

示例：

你先扮演 tech lead，不要写代码。

需求：为内部知识库增加“按标签过滤 + 最近更新排序”
请输出：
- 需求澄清问题
- 数据流
- 涉及文件
- 测试策略
- 风险点

确认后再继续：

基于刚才确认的方案开始实现。
要求：
- 每完成一个子步骤就说明改了哪些文件
- 先实现后端和测试，再改前端
- 如果测试失败先停下来汇报

工作流 4：补测试和补文档¶

这是最容易形成“实习/项目成果”的环节，因为可量化。

你可以把 agent 用在：

• 补单元测试
• 生成回归用例
• 更新接口文档
• 产出迁移说明

面试里更容易讲清楚的成果：

• 接口回归测试覆盖率从 32% 提到 71%
• PR 模板标准化后缺失测试的提交占比下降
• 新人接手时间缩短

上下文工程：决定 Cursor 上限的核心能力¶

更高质量的结果，通常不是来自更长的提示词，而是来自更干净的上下文包。

上下文包建议结构¶

每次复杂任务前，尽量把上下文压到这 6 类：

• 目标文件
• 相邻依赖文件
• 接口定义
• 现有测试
• 运行命令
• 风险约束

一个可复用的上下文模板¶

## 任务
为推荐服务增加 query rewrite 开关

## 相关文件
- `src/rewrite/service.ts`
- `src/search/router.ts`
- `tests/search/rewrite.test.ts`

## 现状
- 当前 rewrite 默认强制开启
- 某些运营查询会被过度改写

## 约束
- 不修改现有请求协议
- 兼容旧配置
- 不新增外部依赖

## 验收
- 开关关闭时完全跳过 rewrite
- 默认行为不变
- 测试通过

常见错误¶

• 一口气塞整个仓库给 agent
• 给大量无关文档
• 不告诉它运行命令
• 不告诉它哪些文件不能动

你应该怎么评估 Cursor 的产出¶

不要问“它聪不聪明”，要问“它产出是否可上线”。

建议至少看 6 个指标：

• 任务完成率
• 一次通过率
• 生成 patch 的可读性
• 测试通过率
• 人工返工比例
• 高风险误改率

如果你在团队里推动 AI Coding，这 6 个指标比“主观感觉好不好用”重要得多。

2028 面试里怎么讲这部分¶

只会说“我会用 Cursor”没意义。你要能讲成下面这种表达：

我在项目里把 IDE agent 用于增量开发和测试补齐，不直接放开自动提交。
我给它补了仓库规则、任务模板和测试门禁，把复杂任务拆成 spec/plan/patch 三步。
最终我们把回归测试补齐速度提高了，人工 review 的返工率下降，而且高风险改动会自动停下来走人工确认。

面试官真正想听的是：

• 你有没有工程控制意识
• 你知不知道 agent 什么时候会失控
• 你能不能把 AI 用法沉淀成团队流程

高频误区¶

误区 1：把 Cursor 当“外包程序员”¶

错。它更像高吞吐的初级到中级协作体，擅长加速，不擅长替你承担责任。

误区 2：先写提示词，后想需求¶

错。没有清晰需求，提示词再华丽也没用。

误区 3：看到能跑就接受¶

错。能跑不等于可维护，不等于可回滚，更不等于适合生产。

误区 4：只追求模型强弱¶

错。2028 更关键的是：

• 仓库结构
• 任务模板
• 评测方法
• 风险门禁
• 成本与延迟

建议的练习顺序¶

1. 先用 Cursor 做 3 次缺陷修复
2. 再做 2 次“补测试 + 补文档”
3. 再做 1 次小型重构
4. 最后做 1 次完整的 spec -> plan -> patch -> verify

每次都记录：

• 输入任务
• 给了哪些上下文
• 失败在哪里
• 如何修正提示和规则

这就是你的第一版 AI Coding 方法论资产。

本章小结¶

• Cursor 不是能力本身，只是能力入口
• 决定效果的关键是 仓库质量 + 上下文工程 + 任务拆解 + 测试门禁
• 2028 竞争力来自“把 agent 用法工程化”，不是“会点几个快捷键”

下一步¶

• 继续看 12-上下文工程与仓库感知
• 再看 13-MCP-Skills与Agent控制面
• 配合 09-Agentic软件工程项目交付模板 做可写进简历的项目