Cursor在需求开发工作中的实际应用

发表于 分类于 阅读次数：

一、引言

很高兴与大家分享现阶段 Cursor 在我的工作中的使用体验。首先是预期管理，本篇文章不会分享 x 个你可能不知道的小技巧，也不会让你拥有无需自行编码的能力，同时不涉及 Cursor 工程化方面内容。仅仅是围绕个人开发流程中的已有问题，分享如何使用 Cursor 来提升这部分的开发体验，在工作中持续保持好的节奏和状态。

文章要点

  • 明确 Cursor 定位：不是开发者的替代品，而是放大开发者能力的工具
  • 分析使用误区：直接根据 PRD 生成代码存在两类典型问题
  • 重构开发流程：将开发分为规划阶段和执行阶段，明确 Cursor 在不同阶段的角色
  • 建立协作机制：通过反馈循环实现开发者与 Cursor 的有效协作
  • 应用场景总结：在现状分析、方案设计、影响评估三大场景中的实际应用

二、就差一个程序员了

最近团队在大力推广 Cursor AI，随着几个版本迭代体验下来，其精准的自动补全深得我心，具体可以体现在 Tab 键的使用率已逐渐高于 Command + C/V。既然这么懂我，那么能否更进一步，根据 PRD 直接输出代码呢？

2.1 从需求到代码

Cursor 能够理解代码上下文，从而根据简短的描述生成符合上下文的代码，于是我尝试直接将 PRD 提供给 Cursor 来生成代码：

1
PRD → Cursor → Code（一步到位）

几个需求尝试下来，总的来说分为两类问题：

问题一：知道 AI 不知道

描述： 你知道 AI 不知道的东西，但你仍然期望它能给出完美答案

示例： 比如直接让 Cursor 写个功能点，但没提供参考项、接口协议和交互方式

分析： 当我们把需求直接丢给 Cursor 时，常常会发现：

  • 输出质量低： 不符合项目的编码规范和架构设计
  • 不符合期望： 解决方案不是我们心中所想的
  • 需要频繁修改： 比起从头开始，修改和适配 AI 的代码可能更费时间

这种情况下，我们明知 AI 缺乏必要的上下文，却仍然期望它能理解我们的意图。结果常常是：大部分时间用在了修正 AI 的输出上，而非解决实际问题。

问题二：不知道 AI 不知道

描述： 更危险的是，你不知道 AI 不知道什么

示例： 比如直接将 PRD 贴给 Cursor，自己却对代码实现现状、需求预期和设计方案没有足够的了解

分析： 当我们对自己的需求和代码现状理解不深时，我们无法有效地：

  • 审查 AI 输出： 是否真的符合业务需求？
  • 评估实现质量： 是否会引入新的问题？
  • 判断边界情况： 是否考虑了所有可能的情况

这就像你去理发店，希望 Tony 老师稍微剪短一点，结果却被剪得稍微短了点。而这需要我们在开始之前对齐认知，补充描述和参照。在这个前置阶段，即使发现对方理解有偏差，也还能及时纠正。俗称”对齐颗粒度”。

2.2 从规划到执行

Cursor 产出的代码由它所接收的上下文决定，如果没有准确描述需求意图，它会通过推断做出假设，导致产出不准确。因此我们在使用 Cursor 时，关键在于区分开发过程中的规划阶段和执行阶段。

阶段 规划阶段 执行阶段
职责 理解业务需求和目标
分析代码现状和约束
设计实现方案和架构
评估潜在影响和风险		 按照规划实现具体功能
处理技术细节和边界情况
编写测试和文档
优化性能和用户体验
流程 共同建立理解，制定方案:
PRD → Cursor → 方案		 提供方案，分步骤实现:
方案 → Cursor → Code
Cursor 角色 协助分析和设计，提供建议 加速代码实现，处理细节

Cursor 在这个过程中，不应该被视为开发者的替代品，而是一面能够放大开发者能力的镜子：

  • 对于已知的部分，Cursor 可以加速实现，减少重复劳动。
  • 对于未知的部分，Cursor 可以协助探索，但不能替代开发者的判断。

在理解了 AI 的角色后，我们需要重构目前的开发工作流，让 AI 成为真正有效的助手。最关键的转变是：不再试图让 AI 替代开发流程中的任何环节，而是让它协助完成每个环节。这意味着不是把 PRD 扔给 AI，等待完整代码，而是和 AI 一起理解 PRD 和代码现状，共同设计方案，明确步骤，然后分步实现。

三、现有问题

作为前端开发，我们的日常工作流程中大多围绕需求文档进行代码产出。这需要：

  1. 我们对业务需求的理解
  2. 对所属业务和项目现状的认知

从而进行方案设计和决策，整理思路将复杂问题分解成可执行的粒度。

但同时，这导致我们不得不面临着一个矛盾：方案设计对效率的影响。一方面，方案设计是保证质量的必要环节；另一方面，生成和维护这些产物又会显著降低开发效率。尤其是在快速迭代的项目需求中，这种矛盾更为突出。有时即使是一个小需求，可能也需要经过大量前置分析，才能进入开发。

传统解决方案

传统的解决方案通常是：

  • 模板化方案设计，减少重复工作
  • 简化方案设计，减少不必要的细节描述
  • 提高团队熟练度，使得方案设计生成更加高效

作为附加项，现在我们能在这些基础上借助 Cursor 进一步提升效能。

四、协作流程

4.1 反馈循环

在协作时，关键在于对 Cursor 补充上下文，并对 Cursor 提供的结论进行人工核验，两者构成反馈循环。前者是希望 Cursor 知道，后者是需要我们自己知道，从而保障产出的结果符合预期。

整体的 Cursor 协作流程分为规划和执行两个阶段。规划阶段专注于产出方案，执行阶段根据方案产出代码，两者交替执行。

4.2 流程对比

相较于以往，在使用 Cursor 后的工作模式差异如下：

流程对比

绿色部分是原有流程，乍一看使用 Cursor 后流程更加繁琐，而实际上也确实如此。

所以这里更推荐换一个心态来看待流程上的变化，不必为了使用工具而使用。过去我们面向 Google / GitHub / Stack Overflow 编程也并不是因为我们为了搜索而搜索，是因为在具体开发中遇到了不明确的信息需要确认，现在这个角色可以渐进地由 Cursor 替代，比起搜索引擎，Cursor 能充分地根据项目现状分析出更贴切的答案，比如文件的下载和分片下载，为此不必有太多的心理负担。

五、场景应用

重新回到在需求开发工作中的问题，占据我代码之外的主要工作是”现状分析”、”改动方案”和”影响评估”，因此主要分享这三个场景中的 Cursor 使用体验。

关于提示词：可根据实际需要使用 notepads 或 rules 降低单次使用成本。

5.1 现状分析

在需求开发过程中，我们时常会接触到陌生的业务模块，如何理解现状往往是最耗时也最容易被忽视的部分。如果对现状不够了解，当需求相对复杂或者项目本身存在较多的历史债务时，我们很难输出符合预期的方案，更难以保证最终代码的质量。对于新接手项目的开发者而言，这一阶段常常伴随着无数次的”代码考古”和”问询前人”。

Cursor 离代码上下文更近，我们可以在它的协助下抽丝剥茧，快速了解业务主线。这是一个学习的过程，当知道的越多，在后续的设计和开发中就越能正确地引导 Cursor。

具体可以从需求的目标改动点开始，梳理其所属功能和实现方式，包含交互流程、数据管理和条件渲染等：

目标 了解业务功能 了解代码实现 了解字段依赖
提示词参考 当前功能如何运作，用户交互有哪些路径，具体数据流向是怎样的，请整理成 mermaid 时序图。 当前代码如何组织，核心模块有哪些，组件间如何通信，梳理组件关系图。 梳理当前表单字段的显隐关系、联动逻辑以及数据源。

通过对上述三个层面的不断往复，Cursor 提供的直观输入能帮助我们摆脱掉一知半解的状态，消除不确定性也就消除了焦虑。

5.2 改动方案

在了解了现状后，开始面向需求进行改动方案设计。

在问答中，Cursor 倾向于直接满足表面的需求，但可能会忽略一些深层的系统设计考虑。当遇到复杂的问题时，建议先让 Cursor 分析问题本身，而不是直接要求它给出解决方案。通过引导它进行更全面的思考，能防止 Cursor 胡编乱造，确保它理解需求，同时也能暴露自身的思考局限，减少返工。

具体做法可以先提示：

  • “在我让你写代码之前不要生成代码”
  • “先逐步分析需求再说明你打算怎么做”

另一方面，由于 Cursor 背后 LLM 的 Context Window 存在上下文长度限制，意味着 Cursor 跟我们一样都存在”短期记忆”，这体现在当对话超出范围后，Cursor 会在输出方案和代码时，遗忘此前的要求和结论，造成不准确。

因此，为了将短期记忆转换成长期记忆，需要我们对复杂任务进行必要的拆解，每次只专注于单个粒度下的问答，当确认方案后，再让 Cursor 汇总并记录到外置文档，以便在后续的对话中补充上下文（也可以借助 @Summarized Composers 实现）。在面对下一个任务时，开启新的会话进行问答，多轮下来形成由不同模块组装而成的方案设计。

这样一来，在生成代码阶段，Cursor 所需要面对的只是局部复杂度中的改动，这能很大程度上减缓我们在代码审核和验证上的投入成本。Cursor 也能始终保持在长度限制范围内，面对精炼后的方案设计进行决策和产出。

整体流程

  1. 拆解需求，缩小关注范围
  2. 明确目标，清晰表达需求描述
  3. Cursor 提供方案
  4. 检查是否有理解偏差，并不断调整提示
  5. 在确认方案后，最终由 Cursor 汇总成果
  6. 渐进开发，分模块由 Cursor 生成代码，及时验证效果和审核代码

提示词参考

方案设计：

1
2
3
我们先探讨方案，在我让你写代码之前不要生成代码
如果此处要加个 xxx 该怎么做，请先逐步分析需求
在想明白后向我说明为什么要这么设计

代码产出：（在功能之外，留意识别边界场景以及控制影响面）

1
2
在写代码时遵循最小改动原则，避免影响原先的功能
即使识别到历史问题也不要自行优化，可以先告知我问题描述和对当前需求的影响，不要直接改跟本次需求无关的代码

5.3 影响评估

除去开发之前的方案耗时，在完成开发后，我们所要解决的是如何保障自测质量的问题。对于研发而言，需要关注的是在这个需求迭代内，改动点所关联的调用链路，而在这个路径依赖下不断冒泡所涉及到的具体功能就是影响面。

因此可以从两个方面提高自测可信度：

  1. 自下而上：基于改动代码和依赖项进行白盒测试，这需要研发自身投入必要的时间进行代码审核
  2. 自上而下：识别改动最终涉及到的页面和功能进行黑盒测试，逐个回归和确认功能是否符合预期

借助 Cursor 可以很低成本地分析改动，并按需产出测试用例，通过 @git 指令让 Cursor 参与到对当前功能分支或具体 commit 的评估：

目标 代码审查 功能验证
提示词 @git 逐个文件分析并总结改动点，评估是否引入了新的问题。 @git 基于代码变更输出自测用例清单。

六、小结

过去，成为一名优秀开发者需要经历漫长的积累：从反复查阅文档、在搜索引擎中筛选有效信息，到系统掌握编程语言、算法与网络原理，每一步都在构建扎实的「知识护城河」。而 AI 时代颠覆了这一逻辑 —— 当大模型能快速生成代码、解析技术方案时，开发者的核心能力似乎从”记忆与执行”转向成了”正确地提问，让 AI 提供答案”。

客观来看，AI 降低了信息获取的门槛，能更快地落地想法、验证思路。不变的是，好的答案源于好的问题，而提出好问题依旧需要积累专业领域下的知识，知道的越清楚才能在提问时描述得越清晰。

所有事都有吃力不讨好的部分，随着 Cursor 等 AI 工具在工程中的应用，我们可以逐渐将这部分职能分配出去，利用我们的知识储备，描述问题，引导过程，审核结果。工具的使用始终是为了节省人类体力和脑力的开销，从而在提升体验的同时提升生产力，以更充沛的精力聚焦在工作成果和个人成长上。

转载地址

最后更新: 2025-08-01