文章目录 / 点击展开
Cursor 的价值在于理解代码库并在编辑器内完成修改，但效果取决于上下文、任务边界和验证流程。最可靠的方式是把它当成结对工程师：一次处理一个明确目标，每个阶段都由测试和 diff 验证。
开始前先建立项目规则
在项目根目录准备规则文档，说明技术栈、目录职责、代码风格、测试命令和禁止事项。例如：不修改生成文件、不新增未经批准的依赖、不在客户端保存密钥。
让 Cursor 先阅读规则和相关入口文件，再回答“这个需求涉及哪些模块”。此时不要立即允许它修改代码。
从需求生成实施计划
将需求、验收标准和限制条件放在同一条消息中，要求它输出修改文件、实现顺序、测试方案和风险。
请分析以下需求并生成最小实施计划：
需求：{{需求}}
验收标准：{{标准}}
限制：不得修改接口结构，不新增依赖
输出：涉及文件、修改目的、执行顺序、测试命令、风险。
暂时不要写代码。检查计划是否遗漏数据迁移、权限、错误状态和移动端行为。计划正确后再进入实施。
小步修改而不是一次生成全部
优先让 Cursor 修改最小垂直切片：一项数据逻辑、一个接口或一个组件。完成后查看 diff，确认没有无关格式化和重命名。
每完成一个切片就运行对应测试。若修改涉及多个模块，先确保底层逻辑通过，再接入上层界面。
使用代码库上下文的正确方式
- 引用具体文件和符号，而不是只描述“那个用户模块”。
- 对复杂调用链，先让它解释数据从入口到存储的过程。
- 对旧代码，提供现有测试作为行为契约。
- 如果上下文冲突，要求它指出冲突，不要自行猜测。
不要把整个仓库无限加入上下文。无关文件会降低模型注意力，也增加错误修改的概率。
测试、审查与 PR
提交前至少完成：目标测试、相关测试、lint 或类型检查、构建检查。然后让 Cursor 根据实际 diff 生成 PR 摘要，而不是根据最初计划生成。
根据当前 git diff 生成 PR 描述：
- 解决的问题
- 关键实现
- 测试证据
- 风险与回滚
- 评审者需要重点查看的文件
不得写入未实际完成的内容。可以配合 ChatGPT 开发工作流 进行方案讨论与独立代码审查。
常见错误
- 任务过大，导致一次修改十几个文件。
- 没有先读取项目规则，生成不符合现有风格的代码。
- 接受“已修复”结论，却没有运行测试。
- 为了让代码更漂亮而顺手重构无关模块。
- 把密钥、生产日志和用户数据加入上下文。
常见问题
Cursor 适合新项目还是旧项目
两者都适合。新项目需要明确架构和边界，旧项目则更依赖现有测试和项目规则。没有测试的旧项目应先补行为测试，再进行较大修改。
Cursor 可以自动完成整个 PR 吗
可以辅助生成改动、测试和描述，但不能替代人工确认。最终 PR 应以实际 diff、测试结果和风险评估为准。
如何减少 Cursor 修改无关代码
明确允许修改的文件、禁止事项和验收标准；每次只分配一个小任务；修改后立即审查 diff。发现范围扩大时应回退并重新拆分任务。