Cursor 的价值不是替你写完所有代码，而是帮你更快理解上下文、生成候选方案和补齐验证步骤。

使用方式

  • 先让模型解释目录结构。
  • 再定位关键文件。
  • 修改前先看现有模式。
  • 修改后必须运行验证。

一次最小修改流程

第一次使用 Cursor 时，选择一个影响范围很小、结果容易检查的任务，例如修改一段文案、补一个字段或修复一个明确报错。不要把“重构整个项目”作为第一次练习。

1. 让模型建立项目地图

先询问入口文件、主要目录和与目标功能相关的文件。要求它引用真实路径，并说明判断依据。目录地图不需要覆盖全部代码，只要能解释本次修改的调用路径。

2. 阅读现有实现

让模型指出项目已经采用的命名、组件和数据模式。新增代码应优先沿用这些模式。看到相邻代码可以优化时，先记下来，不要顺手扩大本次修改范围。

3. 明确完成条件

可以使用下面的任务格式：

目标：在首页增加一个指向教程页的入口。
范围：只修改首页和必要样式。
保持：现有颜色、侧栏和移动端导航不变。
完成条件：桌面和移动端可见，链接正确，构建通过。

4. 审查差异

不要只看模型的文字总结。逐个文件检查实际 diff，确认没有无关格式化、依赖变化或配置修改。代码越短，越应该能解释每一行为什么存在。

5. 运行验证

至少执行项目已有的构建或测试命令。界面修改还要在浏览器检查关键断点，交互功能要验证正常状态和空状态。

常见误区

  • 在没有读取仓库说明前直接生成新结构。
  • 接受模型声称“已经测试”，却没有查看命令输出。
  • 一次提交混入多个不相关目标，后续难以回滚。
  • 为一个只使用一次的逻辑创建复杂抽象。

Cursor 的优势来自项目上下文，但上下文越多也越需要边界。把任务、范围和验证写清楚，通常比更换模型更能提高成功率。