实战

用 Cursor Agent 把开发工作流自动延伸到办公：邮件 / 工单 / PR 一站式

2026.07.15· 6 个步骤 · 20 分钟阅读· ⌨️ Cursor Agent

2026 年 7 月，多家媒体曝光 Cursor 正在研发一款代号 Sand 的通用办公智能体——它不再只帮程序员写代码，而是把同一份上下文直接延伸到邮件、短信、表格、工单这些「绕着代码转的零碎工作」上。这个思路其实你现在就能用现有的 Cursor Agent 跑通。本教程教你一套可落地的「代码 → PR → 工单 → 邮件」自动化回路，提前体验 Sand 的工作方式。

⌨️ 本教程适合：已经在用 Cursor 写代码的开发者、技术负责人、想把自己从重复事务里解放出来的工程师。你不需要等 Sand 正式发布，用 Cursor Agent + 几个集成就能做到 80% 的效果。

先搞懂：Sand 的核心不是「多一个功能」，而是「上下文延续」

很多人误以为办公自动化就是「再装个 Bot」。Sand 真正的价值在于：你写完一个函数后，紧接着的需求一定是「顺手把 PR 描述写了、更新一下工单、再草拟一封通知邮件」。如果工具能沿用同一份代码上下文，这些动作几乎没有摩擦。我们把这套回路拆成四个环节：

环节	传统做法	上下文延续做法
写代码	在编辑器里改	在编辑器里改（同一上下文）
提 PR	切到 GitHub 手动写描述	Agent 读 diff 自动起草 PR 描述
更工单	去 Jira/飞书手动更新状态	Agent 按 commit 自动同步工单
发邮件	打开邮箱重新解释一遍	Agent 沿用上下文草拟通知邮件

关键认知：差异化的不是「又多一个 AI」，而是「谁掌握了开发者一天里所有零碎决策的上下文所有权」。你今天就可以通过 Cursor 的集成把这条链路接起来。

Step 1：确认 Cursor 版本并开启 Agent 模式

1 让 Cursor 拥有「端到端执行」的能力

Cursor 的 Agent 模式可以自主运行、并行处理任务，并在终端、Slack、GitHub 里协作。先确认你处在 Agent 模式：

1. 打开 Cursor，顶部切换到 「Agent」 而非普通的 Chat / Cmd+K
2. 确认已登录账号，且模型选 GPT-5.5 / Claude 等支持 Agent 的模型
3. 在设置里允许 Agent 访问：终端(Terminal)、Git、以及你的 Issue 平台
4. 测试：输入「帮我看下当前分支改了什么」，它应能读 git diff

💡 Cursor 的 Agent 可以在你的终端里运行命令、在 Slack 里协作、在 GitHub 里审查 PR。这意味着「改完代码后自动做周边动作」在技术上已经成立，只是需要你显式授权和编排。

Step 2：接上 GitHub，让 Agent 自动起草 PR 描述

2 从 diff 到一份像样的 PR

改完代码后，不要切到浏览器手敲 PR 描述。直接在 Cursor 里下指令，让它读 diff、总结改动、生成描述并创建 PR：

帮我基于当前分支创建一个 Pull Request：
1. 读 git diff main...当前分支，归纳本次改动点
2. 用中文写 PR 标题和描述（含：背景 / 改动 / 测试方式 / 风险）
3. 关联到对应的 issue 编号（如 fix #123）
4. 直接推送到远程并创建 PR，把链接返回给我

务必开启「人工审查」：Cursor 可以端到端完成「构建、测试、演示」供你审查，但 PR 描述里涉及的需求理解仍建议你快速过一眼。把 Agent 当实习生——它交活，你签字。

Step 3：接上工单系统，让 commit 自动同步状态

3 代码动了，工单也该动

无论是 Jira、飞书项目还是 GitHub Issues，都可以让 Agent 在你提交时自动更新状态。把规则写进项目根目录的 AGENTS.md：

# AGENTS.md（放在仓库根目录，Cursor Agent 会自动读取）
## 工单同步规则
- 每次 commit 若关联 issue（如 fix #123），提交后：
  1. 在 issue 下评论本次改动摘要
  2. 若改动已通过本地测试，将 issue 状态置为「待评审 / In Review」
- 禁止私自关闭 issue，关闭动作必须我自己确认

🔑 AGENTS.md 是给 Agent 的「岗位手册」。把「能做什么、不能做什么」写清楚，它就会在每次任务里遵守。这是把 Sand 思路落地的关键一步。

Step 4：接上 Slack / 邮箱，自动草拟通知

4 让「通知」也沿用同一份上下文

PR 创建后，往往需要通知相关同学。让 Agent 在 Slack 频道发一条摘要，或草拟一封邮件（注意：先让 Agent 生成草稿，由你点发送，避免误发）：

PR 已创建（链接：xxx）。请帮我：
1. 在 #dev-team Slack 频道发一条中文摘要：做了什么、需要谁 review、预计影响
2. 给产品同学 drake@company.com 草拟一封邮件，说明本次改动对业务的影响
   注意：邮件只生成草稿，不要自动发送，等我确认

安全边界：涉及对外发送的邮件、短信，务必加「只生成草稿、不自动发送」的约束。Sand 的教训之一正是——自动化越深，一次误动作的传播面越大。

Step 5：用 @ 文件把「周边文档」拉进上下文

5 让 Agent 知道「这份代码服务于什么业务」

Sand 的卖点是「还是那份上下文，只是范围变宽」。你可以通过 @ 引用，把需求文档、API 文档、历史邮件拉进同一轮对话：

@README.md @docs/order-api.md @emails/客户反馈.md
基于以上背景，写一封给客户的「本次升级说明」邮件草稿，
重点讲清：延迟优化了多少、有哪些不兼容变更、迁移步骤

💡 上下文越完整，Agent 生成的邮件/工单/PR 越不需要你返工。这就是 Sand 想抢占的「生产力入口」——你现在用 @ 引用就能拥有。

Step 6：固化成「复用指令」，每天省 30 分钟

6 把回路变成一条命令

把上面这套流程沉淀成 Cursor 的自定义命令（Command）或常用 Prompt，以后一键触发：

// 在 Cursor Settings → Commands 里新建「ship-and-notify」
文案：
「按 AGENTS.md 的规则：1) 基于当前分支创建 PR 并关联 issue；
2) 在 Slack #dev-team 发摘要；3) 给相关人草拟通知邮件（仅草稿）。
每一步做完向我汇报，不要自动执行有外部影响的发送动作。」

🎉 到这里，你已经用现有的 Cursor 跑通了 Sand 的核心思路：同一个上下文，从写代码延伸到 PR、工单、邮件。等 Sand 正式发布，你只是把这套回路换了个更顺手的壳。

常见问题速查

你遇到的现象	大概率原因 & 解决
Agent 读不到 git diff	没切到 Agent 模式，或仓库不在当前工作区根目录
PR 描述理解偏差	AGENTS.md 里没写清需求背景，补充业务上下文
误发了消息到 Slack	指令里少了「仅草稿 / 等我确认」约束，补上即可
工单状态没同步	没给 Agent 配置对应平台的访问令牌

📚 更多教程 📰 智能体资讯