Vibe coding - Cursor 工作模式与上下文

Cursor 不只是一个带聊天窗口的编辑器. 它把补全、问答、代码编辑、任务规划和工具调用放在同一个开发环境中. 用好这些模式的关键不是让 Agent 承担所有工作, 而是根据任务规模选择合适的交互方式.

Tab: 高频的小步修改

Tab 补全适合局部、明确和高频的修改. 它能根据当前文件和最近改动预测下一步代码, 对补全重复逻辑、补充参数和同步相邻代码非常高效.

Tab 的优势是快, 但上下文范围有限. 当修改涉及多个模块或需要理解复杂业务约束时, 应切换到 Agent, 并主动提供相关文件.

Ask 适合阅读代码、解释逻辑和排查思路. 当自己还没有确认问题边界时, 先让模型梳理调用链和可能原因, 通常比直接要求修改更稳妥.

例如:

请从接口入口开始梳理这段认证逻辑的调用链.
只分析问题并列出证据, 暂时不要修改代码.

这一步能够避免 Agent 在信息不足时过早进入实现.

Agent 适合跨文件任务, 可以搜索代码、编辑文件并执行命令. 对于更复杂的任务, Plan 模式会先形成修改计划, 用户确认方向之后再进入实施.

Plan 的价值不只是列清单, 而是提前暴露理解偏差. 一个计划如果没有说清楚修改边界、验证方式和不应触碰的模块, 直接实施往往只会更快地走向错误方向.

对于大型任务, 可以明确要求:

Debug 模式与普通 Agent 类似, 但会更主动地围绕问题补充调试信息、观察运行结果并迭代假设. 它适合“现象明确但原因不明”的问题.

不过调试信息也会改变程序行为. 对并发、时序或性能问题, 仍然需要关注新增日志与断点是否影响了原始现象.

模型见过很多通用代码, 但并不了解项目的特殊约束. 提升输出质量最直接的方法, 是明确告诉它应该参考哪些实现.

不需要精确到函数名. 提供类似功能、相关模型、接口入口和测试文件, 已经能够明显提升结果:

请参考 @service.ts、@authentication.py 和现有认证测试,
为当前模块增加同样的登录流程.

对话持续太久后, 上下文中会混入已经失效的尝试和旧结论. 此时继续追加 Prompt 的效果可能越来越差. 更好的做法是整理当前结论, 开启新的上下文, 并只携带仍然有效的信息.

MCP 可以让 Agent 使用数据库、浏览器、监控平台或内部工具. 它的价值不在于“工具越多越好”, 而在于让 Agent 获得完成任务所需的真实证据与操作能力.

在引入 MCP 前需要确认:

对生产环境工具尤其需要谨慎. 让 Agent 查询日志与指标通常很有价值, 但写入、删除或修改配置应当保留明确的人工确认.

可以用任务的不确定性和影响范围来选择模式:

工具模式只是交互形式. 最终效果仍然取决于是否给出了清晰目标、正确上下文和可验证的完成标准.