Cursor 真实项目工作流：从需求说明、代码修改到 Review 验收

很多 Cursor 教程停留在“能聊天、能补全、能生成代码”，但真实项目里更重要的问题是：如何让它在不破坏工程秩序的情况下参与交付。

一个可用的 Cursor 工作流，至少要回答五件事：

1. 需求怎么写，AI 才不会猜错
2. 文件怎么定位，才不会改偏
3. 修改怎么分步，才方便回滚
4. 验证怎么设计，才不只靠肉眼
5. Review 怎么做，才不会漏掉副作用

如果你刚开始使用，可以先看 Cursor 使用教程 和 Cursor 项目级提示词模板，再用本文建立真实项目流程。

先给结论：Cursor 最适合做“小步可验证”的工程协作

Cursor 不适合被当成“一句话重写项目”的魔法按钮。它更适合做一类明确、边界清楚、能验证的任务：

核心原则是：让 Cursor 参与工程链路，而不是替代工程链路。

一、需求说明要写成任务单，不要写成愿望

“帮我优化页面”太泛，“把首页首屏 CTA 文案改得更清楚，并保持现有布局不变”才是任务。

推荐模板：

目标：要解决的具体问题是什么。
范围：只允许查看和修改哪些目录或文件。
约束：不新增依赖，不改公共接口，不做无关重构。
验收：完成后我如何确认它是对的。
输出：先给文件清单和修改计划，再改代码。

这个模板的价值不在格式漂亮，而在减少 AI 自行脑补。

二、先做文件定位，再让它修改

真实项目里，改错文件比写错代码更常见。一个稳妥流程是：

1. 让 Cursor 只读分析相关文件
2. 要求列出候选文件和判断理由
3. 人工确认范围
4. 再进入修改阶段

示例提示词：

请定位“保存按钮点击后没有提示”的相关代码。只列出文件、函数和数据流，不要修改。请说明每个候选文件为什么相关。

这一步能把大量风险挡在改动之前。

三、小步修改：每轮只解决一个可验证问题

一次让 Cursor 做太多事，会让 Review 变成灾难。更好的方式是把任务拆成小步：

小步并不慢。它减少的是返工、回滚和“看不懂 AI 到底改了什么”的时间。

四、验证要前置，不要等改完才想怎么测

Cursor 生成代码后最常见的问题，是看起来合理，但没有覆盖边界。每个任务开始前就应该写验收标准：

• 正常路径是否成功
• 空数据是否有表现
• 错误返回是否可见
• 移动端或小屏是否破坏布局
• 类型、lint、测试是否通过

对于前端页面，手动验收可以写成：

验收步骤：
1. 打开页面 A
2. 输入有效内容并提交，应出现成功提示
3. 输入空内容并提交，应出现字段错误
4. 刷新页面后状态不应错误保留
5. 移动端宽度下按钮和提示不应重叠

Cursor 能根据这些标准写代码，也能根据这些标准帮助你检查。

五、Review 时重点看 6 类副作用

不要只看“功能能不能跑”。AI 修改最容易带来的副作用包括：

1. 顺手改了无关命名
2. 新增了不必要依赖
3. 把局部逻辑提升成过度抽象
4. 忽略了异常状态
5. 修改了公共组件默认行为
6. 删除了看似无用但实际被依赖的兼容代码

Review 时可以直接问 Cursor：

请基于当前 diff 列出潜在副作用，重点检查公共组件、类型定义、路由、接口参数和样式影响范围。

但最终判断仍然应该由人完成。

六、失败案例：一句“帮我优化表单”为什么会失控

某个团队让 AI 优化一个报名表单，结果它同时改了字段结构、校验规则、按钮样式和提交接口。页面看起来更完整，但后端接收字段变了，线上提交失败。

根因不是 Cursor 不能用，而是任务没有边界：

• 没有限定只改前端提示
• 没有禁止接口参数变更
• 没有给出验收用例
• 没有先看 diff 里的公共影响

修复方式是把任务拆成两轮：先只改错误提示文案和字段状态，再单独评估是否要调整接口。

七、Cursor 真实项目 Checklist

• 需求已写成目标、范围、约束、验收
• 修改前已完成文件定位
• 每轮只处理一个可验证问题
• 多文件改动已拆分阶段
• 关键逻辑有测试或手动验收步骤
• diff 中没有无关重构
• 公共组件和接口参数已重点审查

结语

Cursor 真正提升效率的地方，不是让你少思考，而是把定位、修改、验证和 Review 的循环压缩得更快。只要你用任务单、边界、小步改动和验收标准管理它，它就会更像工程协作者，而不是不可控的代码生成器。

延伸阅读：

• Cursor 项目级提示词模板
• Cursor 多文件改动安全策略
• Cursor 代码审查提示词
• Cursor 生成 bug 的定位方法