Grok Bot 实践：接上 Cursor，做演示、搭开发团队

收藏了一个开源项目，除了留着以后看，还能让 AI 帮你往前做一步吗？

这次，我给 Grok Bot 安排了一件具体的事：读取 X 书签，找一个适合尝试的项目，再交给 Cursor 做成可以预览的小演示。

从分派任务、云端开发，到代码进入私有仓库、打开演示，这条路径已经跑通。最后做出来的是一个地球页面，能看到清晰的大陆点阵，页面上有城市切换和暂停、继续按钮。

演示做出来之后，我又让 dr eggbot 创建了一个六岗开发团队。下面把接入 Cursor、连接仓库、派任务和搭团队的过程放在一起，方便你用自己的小项目试一遍。

先把任务交给合适的助手

这个想法来自 Matt Palmer 在 X 上分享的案例。按他的描述，Grok 会读取书签，调用编程助手做演示，检查后交回链接。

我先试着跑其中一次任务，没有直接设置每天自动执行。

这次用到 Grok Bot 里的两个助手：「我的助手」负责整理信息和分派任务，「Cursor」负责开发。 也可以直接把需求发给 Cursor Bot；保留两个助手，是为了试一遍从获取信息到开发交付的接力。

先让「我的助手」读取最近 10 条 X 书签，返回链接并判断哪些适合做单页演示。读取有了实际结果，但这轮没有选出符合范围的项目，最终使用了预先准备的公开项目 cobe。

cobe 是一个在网页上绘制地球的开源库。它是这次指定的备选，并非 Grok 自动从我的书签中选出来的。想先体验开发部分，也可以直接给 Bot 一个公开项目链接。

在 Grok 里建一个 Cursor Bot

看到别人侧栏里的 Cursor 图标，很容易以为那是一个现成入口。实际配置时，可以把它分成三步。

创建专门写代码的助手

可以直接对现有助手说：

帮我创建一个叫 Cursor 的编程 Bot，专门负责开发、修改和测试项目。仓库任务使用 CloudAgent，也就是 Cursor 的云端编程代理。完成后给我代码位置、预览和测试结果。

这是根据本次配置整理的示例指令。创建后，侧栏会出现对应助手，点进去就能单独派任务。

名称和头像可以在“聊天顶部名称 → 对话详情 → Bot 设置”里调整。头像方便辨认，实际开发能力取决于它能调用什么工具。

按需要添加 Cursor SDK 插件

在 Grok Bot 的「市场」中搜索 Cursor SDK，核对开发者为 Cursor 后安装。

SDK 是软件开发工具包。这个插件提供使用 @cursor/sdk 编写应用、脚本和自动化的技能，本次也安装了它。

Cursor SDK 插件和 CloudAgent 承担不同工作。 前者提供相关开发技能；本次实际修改仓库、运行程序，走的是 CloudAgent。安装插件不会自动完成仓库授权。

开工前检查执行能力

可以先发一句：

确认你能否调用 CloudAgent，以及能访问哪个仓库。先返回检查结果，暂时不要开始开发。

这一步把“助手已经创建”和“助手可以开始干活”区分开来。

先确定代码保存在哪里

仓库是代码和修改记录的存放处。先确定仓库，后续开发、取回源码和继续修改才有固定入口。

这次实际使用的是 Cursor Origin 私有仓库。 Origin 是 Cursor 提供的代码托管服务，准备步骤如下：

1. 登录 Cursor。
2. 首次使用时，按 Get Started（开始使用）引导设置代码空间名称，也就是仓库归属的命名空间。
3. 空间准备好后，创建独立演示仓库，或让 Cursor Bot 在其中新建私有仓库。
4. 让 Bot 回报实际仓库地址，确认这次任务就在该仓库执行。

Origin 仍处于早期测试，是否可用取决于账户方案和开放状态，以实际页面为准。

如果项目已经在 GitHub，也可以连接现有仓库：进入 Cursor 控制台的 Integrations（集成），找到 GitHub，点击 Connect（连接）；已有连接则进入 Manage Connections（管理连接），按页面授权并选择本次要用的仓库。团队仓库需要相应管理权限。

这是官方提供的另一条接入路径，本次演示没有使用它。

仓库连好后，把链接交给 Cursor Bot，确认可访问即可。需要本地源码时，从仓库取最新版本；聊天中保留任务和结果说明。

把需求写成可以验收的任务

这次的目标很小：做一个单页地球演示。派给「我的助手」的任务可以整理成下面这段：

请把这项任务交给 Cursor Bot：

基于 cobe 做一个单页地球演示，代码放进本次独立的私有仓库。

页面能看清大陆点阵，提供暂停、继续和城市切换按钮。

在云端实际启动，检查显示和交互。完成后给我预览入口、仓库地址、运行说明、测试结果和未完成项。

这次只做演示，不扩展后台，不公开部署，不接新的付费接口。

读者可以替换其中的项目、预期画面和核心操作。最需要写清的，是要交什么、怎样验收、这次做到哪里结束。

任务启动后，Grok Bot 中出现了 Cursor 云端任务卡片。点「在 Cursor 中打开」，可以查看开发过程和代码改动。本次通过任务页的 Desktop（云端桌面）看到了实际运行画面。

页面上有 New York、Tokyo、London 三个城市按钮，以及 Pause／Resume（暂停／继续）。Cursor 的最终报告称交互已通过自测，后续还要做独立复验和体验调整。

交付时可以按四项检查：预览、最新源码、运行说明、测试结果。本次没有公开部署；要让别人长期访问，还需要另行安排发布。

再组建一个六岗开发团队

跑过演示后，我想到：既然能在 Grok Bot 里建立「深夜内容工作室」，开发项目也可以按职责组织起来。

于是，我让 dr eggbot 创建了「深夜开发工作室」。目前团队群聊已经建立，新增五个 Bot，复用原有的 Cursor，并保存了岗位职责和共享交接规则。

这六个角色分别负责：

• 深夜开发负责人：统一接需求，明确范围、验收标准和预算，派工并汇总结果。
• 架构师：按需设计模块、数据和接口，说明技术方案与取舍。
• Cursor 全栈工程师：兼顾前端页面和后端开发，完成修改、自测与运行说明。
• 代码审查员：独立检查代码，给出问题位置、触发条件和建议。
• 测试验收员：按需求实际操作，保存结果和截图，记录未测项。
• 发布交付员：核对代码与构建版本，整理发布包和运行说明，获得对应授权后部署。

小项目先由 Cursor 兼顾前后端，复杂后再拆岗。六个角色按需参与，不是每次让六个 Bot 一起聊。 简单改动直接开发和验收；涉及数据结构、多个模块时，再安排架构设计。

交接也做了约定：每张任务卡写清目标、范围、仓库与分支、输入资料、验收条件、时间或额度边界。成员之间只传任务卡、版本、证据和未解决项，减少重复讨论。

这次完成的是团队配置，还没有用六岗跑过一个完整项目。下一步，可以从现有演示的一项小调整开始，验证派工、审查和测试能否顺畅衔接。

演示跑通了，细节继续打磨

现在已经有了可预览的演示和一个配置好的开发团队。后续可以围绕按钮反馈、城市定位是否直观、手机显示和运行说明，逐项检查、调整。这些是待检查清单，不代表都已验收通过。

每天自动读取书签、选项目和交付，也需要在单次流程基础上继续验证。团队文档目前保存在 Grok 云端，与本地知识库的自动同步还没接上。

我想继续推进的方向，是让 AI 把已有信息变成实际结果，再把过程、截图和经验留回本地知识库。

先准备一个仓库、一条项目链接和一个明确的小目标，就可以开始尝试。我先踩坑，你少走弯路。关注深夜开发者，后续继续分享实际跑过的流程。

JOTO 企业落地观察

• 企业若采用此类多 Bot 协作模式，需明确各角色的输入输出契约，避免因职责模糊导致任务卡在中间环节；尤其需定义「验收通过」的技术判定标准（如自动化测试覆盖率、手动验证用例集），而非仅依赖 Bot 自述。
• 将开发流程拆解为六岗，本质是把隐性工程实践显性化。企业落地时应优先固化「交接物」（如任务卡模板、运行说明格式、测试截图规范），而非急于堆叠 Bot 数量。
• Cursor Origin 私有仓库的早期测试状态提示：企业在选用 AI 编程平台的托管服务时，须评估其 SLA、审计日志完备性及与内部 DevOps 工具链的兼容性，不可默认等同于成熟 Git 服务商。
• 文中反复强调「本次不扩展后台、不公开部署」，反映出 AI 辅助开发当前的典型边界——聚焦单点可验证交付。企业规划智能体工程时，应将「部署通道」「监控告警」「灰度策略」等生产就绪要素前置纳入任务定义。