Cursor /goal 模式实战：让 AI 自动完成长期开发任务

很多开发者把 Cursor 的 Agent 想象成“交代一个长期目标后，它会持续修改代码、跟踪 PR，并在 CI 失败后自动修复”。但根据目前可核验的资料，Cursor 社区中关于 /goal 的内容仍是功能请求，示例也是希望 Cursor 增加类似 Claude Code 的自主目标模式，并不能证明 Cursor 已经原生提供同名命令。因此，使用前先分清两件事：/goal 是一种工作方式，还是你当前 Cursor 版本中确实存在的内置功能。

先确认：Cursor 是否真的支持原生 /goal

社区中的功能请求把目标模式描述为：用户给出一个目标，Agent 自动进行多轮执行，直到测试通过、构建成功、验收条件满足，或者任务清单完成。类似的目标表达可以写成：

/goal 所有认证相关测试通过，并确保代码检查没有错误

这种写法的重点不在斜杠命令本身，而在于把“完成条件”交代清楚。普通聊天通常是一问一答：你提出一个动作，Agent 完成后等待下一条指令；目标模式则希望 Agent 自己根据结果继续推进，遇到测试失败时回到代码中修复，再次验证。

不过，资料中能确认的是 Cursor 社区对这项能力的讨论和请求，而不是 Cursor 官方已经发布了原生 /goal。因此，不要因为在其他 Agent、教程或第三方项目中看到这个命令，就直接认为它能在 Cursor 中使用。最简单的判断方法是，在当前 Cursor Agent 输入 /，查看是否有明确的 /goal 补全项；如果没有，就应把它当作一种提示词写法或外部工作流，而不是内置功能。

关于 Cursor 中类似 /goal 的功能请求，可以参考社区讨论页面。

一句目标描述应该怎么写

目标不能只写“把这个功能做完”。Agent 需要知道要改什么、什么情况下算完成，以及哪些范围不能碰。一个实用的目标至少应包含三个部分：

• 要完成的功能或问题；




• 需要验证的结果；




• 明确的限制条件。

例如，与其写：

/goal 优化登录功能

不如写成：

/goal 为现有登录流程补充失败重试处理，保持现有接口格式不变；完成后运行相关测试，修复测试暴露的问题，直到测试通过，并在变更完成后整理出一个可提交审查的 PR

前一种描述只有方向，没有验收标准，Agent 很难判断什么时候应该停止。后一种描述则把开发、验证和交付边界连在了一起。

如果任务涉及多个模块，还应补充优先级和禁止事项。例如，先处理核心逻辑，再补测试；只修改相关目录；不要重写无关代码。目标越长不一定越好，但验收条件必须足够明确。

与传统手动指令模式的区别

传统模式更适合短任务。你可以先让 Agent 阅读代码，再让它提出方案，接着要求修改，最后手动运行测试。每一步都由你确认，优点是可控，缺点是需要持续跟进。

目标模式追求的是“围绕结果循环”，而不是“围绕动作对话”。它通常包含这样的过程：

1. 理解目标并拆分任务；




2. 修改代码或补充测试；




3. 执行验证；




4. 根据失败结果继续修复；




5. 重新验证，直到满足完成条件；




6. 停止并汇报结果。

这并不意味着可以完全放任 Agent。长期任务的风险在于目标过于宽泛、修改范围不断扩大，或者测试本身不足以覆盖真实需求。涉及数据库结构、权限、支付、删除数据和生产配置时，最好把“只提出方案，不自动执行”写进限制条件，并在关键节点人工审核。

所以，目标模式更适合边界清楚、验证方式明确的任务，例如补齐测试、处理一组重复迁移、修复已有 CI 报错，或者完成一个有清晰验收标准的功能。它不适合把“重构整个项目”“提升系统稳定性”这类无法快速验证的愿望直接交给 Agent。

PR 和 Slack 订阅：不要把设想当成现成功能

把目标模式延伸到 PR 和 Slack，实际上需要两类能力：

一类是代码代理能力，负责读取任务、修改代码、运行验证并提交变更；另一类是事件订阅能力，负责监听 PR 状态、CI 结果或消息通知，再把新的事件交给代理处理。

目前给出的资料只能确认社区希望 Cursor 具备更强的长期自主执行能力，不能确认 Cursor 已经提供“订阅 PR”“绑定 Slack”或“根据 CI 失败自动继续工作”的统一原生设置。因此，文章或团队文档中不应直接写成“在 Cursor 设置里绑定 PR 和 Slack，然后 Agent 会自动修复”。

更稳妥的设计是先确认你实际使用的产品版本和团队权限是否存在以下入口：

• 是否能把一个目标绑定到某个代码仓库或工作区；




• 是否能接收 PR 状态变化；




• 是否能读取 CI 失败信息；




• 是否能向 Slack 发送进度或失败通知；




• 是否提供自动合并开关，以及合并前是否必须经过人工批准。

如果缺少其中任何一环，就不要用“订阅”描述它已经具备的能力。可以先把 Slack 当作通知渠道，把 PR 当作人工审核边界，再由开发者决定是否继续下一轮 Agent 操作。

一个安全的完整案例：从目标到 PR 合并

下面用“为现有接口补充错误处理和测试”说明一套可落地的目标型工作流。这里的关键不是证明 Cursor 已经拥有原生 /goal，而是展示如何把长期任务拆成可验证的执行闭环。

第一步：先写清楚目标和边界

在 Cursor Agent 中输入一条完整目标。如果当前环境支持 /goal，可以使用斜杠命令；如果不支持，就直接把同样的内容作为普通 Agent 指令发送：

/goal 为现有接口补充统一的错误处理和相关测试。

要求：
1. 先检查现有实现和测试结构，再决定修改范围；
2. 保持现有接口格式和调用方式不变；
3. 只修改与该功能直接相关的代码和测试；
4. 先完成实现，再运行相关测试；
5. 如果测试失败，分析失败原因并继续修复；
6. 完成后汇报修改文件、验证结果和仍需人工确认的风险；
7. 不要修改生产配置，不要执行不可逆操作。

这条目标同时规定了任务、限制和完成条件。尤其是“保持接口格式不变”和“不要修改生产配置”，可以减少 Agent 为了追求通过测试而扩大修改范围的风险。

第二步：让 Agent 先建立任务状态

Agent 开始工作后，不要只看它是否生成了代码，还要观察它是否能回答三个问题：

• 当前已经理解了哪些文件和依赖关系；




• 接下来准备修改什么；




• 用什么方式判断任务完成。

如果它直接修改大量无关文件，说明目标边界还不够清楚，应立即暂停并缩小范围。长期任务最怕“看起来一直在工作”，但每一轮都没有接近明确的验收条件。

第三步：把 CI 失败当作反馈，而不是新目标

当 PR 创建后，如果 CI 失败，先区分失败类型。测试失败通常对应实现或测试问题，构建失败可能与依赖或编译过程有关，而环境问题未必应该由 Agent 修改代码解决。

可以把失败信息作为下一轮目标输入：

根据当前 PR 的 CI 失败结果继续处理。

要求：
1. 先定位失败发生在哪个检查阶段；
2. 只修复能够由本次代码变更直接导致的问题；
3. 不要为了绕过检查而删除测试或降低验证要求；
4. 修复后重新运行相关验证；
5. 如果失败原因属于环境、权限或外部服务，请停止修改并说明原因。

这里的“如果无法由代码变更解决就停止”很重要。否则，Agent 可能尝试修改流水线、跳过测试或改变配置，只为了让结果显示为通过。

第四步：绑定通知时保留人工闸门

如果你使用的 Cursor 版本或配套工作流确实支持 PR、CI 和 Slack 订阅，可以按“事件—动作—权限”来设计：

• PR 创建或更新时，发送进度通知；




• CI 失败时，把失败阶段和日志摘要交给 Agent 分析；




• Agent 产生新提交后，再触发一次验证；




• 所有检查通过后通知开发者；




• 自动合并前保留人工批准，或者只允许合并满足明确条件的 PR。

Slack 通知的作用是让开发者知道工作流走到了哪一步，不应被当成授权信号。收到“测试通过”的消息，也要确认它对应的是最新提交，而不是旧版本的检查结果。

如果当前环境没有原生订阅功能，可以先采用人工触发：开发者看到 PR 或 CI 状态变化后，把相关信息复制给 Agent。虽然这不是真正的无人值守，但已经能利用目标式指令减少重复沟通，而且风险更容易控制。

第五步：合并前进行最后审查

只有在以下内容都明确后，才考虑合并 PR：

• 变更文件确实属于目标范围；




• 相关测试已经执行并通过；




• CI 通过的是最新提交；




• 没有为了通过检查而删除验证、隐藏错误或修改无关配置；




• PR 描述说明了修改内容和已知风险；




• 涉及权限、数据、接口兼容性或生产行为的部分已经人工确认。

如果团队确实允许 Agent 自动合并，也建议只对满足固定条件的 PR 开放，例如修改范围受限、检查项完整通过、没有冲突、没有高风险文件变更。不要把“自动合并”作为目标模式的默认结果，它应该是最后一步单独授权的动作。

使用目标模式时最容易忽略的三点

第一，目标必须可验证。“继续优化”“做到最好”都不是好的停止条件。应该改成测试通过、指定问题解决、某项清单完成，或者输出一份等待人工确认的结果。

第二，自动循环不等于自动负责。Agent 可以重复执行工具调用，却不能替你判断业务风险。涉及数据删除、权限变化和生产发布时，必须设置人工检查点。

第三，先确认功能是否真实存在。当前资料显示，Cursor 社区正在讨论类似 /goal 的自主工作模式，但不能据此断言 Cursor 已经支持原生命令、PR 订阅、Slack 绑定或自动合并。实践中最稳妥的方式，是先用完整目标提示词建立工作闭环，再根据你实际账户中可见的功能逐步增加自动化权限。