Cursor 怎么自动生成一个功能？先审计划，再检查 diff 与测试

让 Cursor 自动生成功能，最稳妥的做法是把“自动”放在已定义的范围里：人先说明可观察行为和不能改变的内容，Agent 先调查并写计划，确认后再编码，最后由测试、diff 和人工复现共同验收。直接说“做一个完整功能”通常会把需求设计、架构选择和实现风险一起交给模型。

选择适合第一次交给 Agent 的功能

优先选择边界清楚、能在本地验证、失败后容易回退的小功能，例如为已有列表增加空状态、给现有接口补一个可选过滤条件，或在既有表单中增加一条明确校验。涉及付款、权限、数据迁移、生产部署或多个系统契约时，应先拆解并加入对应负责人评审。

选择一个影响范围清楚的小功能，写明输入、预期输出、不应改变的行为和真实测试命令。

• 输入：用户动作、请求参数、测试夹具或已有数据。
• 输出：页面状态、接口响应、数据库变化或日志，但必须能观察。
• 保持不变：公开接口、权限、错误码、其他页面与兼容行为。
• 验证：仓库已有的单元测试、集成测试、类型检查、lint 和手工路径。

用可复制模板写清需求

目标：给现有订单列表增加“无结果”空状态。

当前行为：筛选后无订单时，内容区为空白。
预期行为：无结果时显示项目现有 EmptyState 组件；清除筛选按钮恢复全部订单。
输入：已有筛选条件与后端返回的空数组。
不得改变：订单 API、权限、分页、非空列表样式和其他页面。
验收：
1. 空数组显示空状态；
2. 点击清除筛选后恢复列表；
3. 加载中和请求失败状态不被空状态覆盖；
4. 相关测试、类型检查和 lint 通过。

请先进入 Plan Mode，只调查并给出：相关文件、现有实现模式、测试位置、
计划修改清单、风险和回滚点。不要写代码，发现需求冲突时先提问。

示例只是演示需求结构，不代表你的项目包含这些组件或命令。文件名、状态组件和验收命令必须由 Agent 从当前仓库找到，并由你核对。

第一阶段：先审 Plan Mode 的计划

切换 Plan Mode，让 Agent 找相关文件、现有模式和测试，输出文件清单与风险。

官方文档说明，Plan Mode 会先澄清需求、研究代码库、生成可编辑的实现计划，并在构建前等待确认。它适合跨多个文件、存在多种方案或需要先调查的任务。审计划时逐项检查：

1. 文件是否正确：计划应指向真正的入口、业务逻辑、类型和测试，不应凭空新建平行模块。
2. 模式是否复用：项目已有组件、错误模型、依赖注入或测试夹具时，应沿用现有方式。
3. 边界是否明确：计划要写出加载、空数据、错误、权限和兼容分支，而不只描述成功路径。
4. 改动是否过大：删除与目标无关的重构、新依赖、格式化和生产操作。
5. 验证是否真实：命令必须来自项目配置或文档；“运行测试”不是足够具体的验收步骤。

如果计划研究错了方向，应先修改或重新生成计划。官方 Plan Mode 文档建议，大方向偏离时可以回退改动、完善计划后重来，比在错误实现上连续补丁更清楚。

第二阶段：小步实现并保留回滚点

1. 确认计划后，只批准第一组紧密相关的修改；要求 Agent 每组结束时总结文件和行为变化。
2. 查看实时 diff。若它开始改接口、权限或无关模块，立即停止并回到计划，不要等到任务末尾。
3. 让 Agent 使用现有测试模式添加必要覆盖。测试应验证外部行为，不能只复述实现细节。
4. 运行最小相关测试并查看原始输出；通过后再执行更广的类型检查、lint 或构建。
5. 每个可独立验证的阶段保留清楚的 Git diff 或提交，确保失败时能只回退该步。

第三阶段：检查完整 diff 与 Agent Review

实现完成后，先人工逐文件看改动，再使用 Cursor 的 Agent Review 作为第二层线索。官方文档说明，可以在 Agent Window 输入 /agent-review，或从 Source Control 对全部本地变化运行审查；设置入口会随版本变化。Review 的 Quick 与 Deep 深度适合不同规模，但任何一种都不能替代代码所有者。

可复制下面的自审请求，并用实际文件或分支上下文替换占位内容：

请审查当前完整分支 diff，不要修改代码。
重点检查：
1. 是否逐项满足验收标准；
2. 加载、空数据、错误和权限分支；
3. 是否重复现有逻辑或引入无关依赖；
4. 测试是否可能因错误断言而“虚假通过”；
5. 是否存在超出已批准计划的文件。
每个问题请给出文件、位置、触发条件和最小修复建议；不确定时明确写不确定。

怎样验证功能真的完成

功能通过需要计划与实际文件一致、diff 无无关变化、测试通过并能手工复现目标行为。

失败分支与适用边界

• Agent 不停扩大范围：停止任务，把功能拆为更小行为，回到 Plan Mode 重新限制文件和不变项。
• 测试原本就失败：保存基线输出，区分既有失败与本次引入；无法证明时不能把功能标为通过。
• 功能可用但 diff 巨大：要求去掉无关格式化和重构，或按语义拆成可独立审查的小改动。
• Agent Review 没报问题：仍要人工复现、阅读代码和查看测试。自动审查没有发现不等于没有缺陷。
• 涉及迁移或部署：另外准备备份、回滚、权限和发布审批，不让“功能生成”步骤自动进入生产。

这是开发辅助流程，不应直接自动部署或绕过代码所有者审批。

相关问答

可以一次接受 Agent 的所有修改吗？

即使功能很小，也应查看完整 diff 和检查结果。涉及多文件时按计划阶段接受，更容易发现范围漂移和保留回滚点。

Agent Review 能替代人工审查吗？

不能。它能提示潜在问题，但需求正确性、业务影响、权限边界和是否适合上线仍由人负责；复杂逻辑应选择更深入审查并结合专业负责人。

资料与适用范围

本文根据 2026 年 10 月 1 日核验的 Cursor Plan Mode 官方文档、Agent Review 官方文档 整理。示例流程未在你的设备、账号或仓库中实测，界面、方案、权限和项目命令应以当前环境为准。