用过云端 AI 助手之后，一个很实际的问题会浮现：手机上想到的任务，能不能直接交给家里的电脑？研究、编码和资料整理，能不能分别交给不同的助手？它们讨论出的结果，又能不能接着进入开发流程？
这期 Grok Bot 体验围绕这些问题展开。流程从手机检查 Mac mini 开始，延伸到持久云电脑、定时资讯、专职记忆管理、多 Bot 群聊，最后把沙盒游戏的开发任务从本地交接到 Cursor Cloud Agents。本期最值得关注的是任务如何衔接，以及每一步有没有留下可检查的结果。 游戏开发在视频结束时仍在推进，不能把任务启动写成作品已经完成。
完整视频
如果播放器无法加载，可以前往 YouTube 观看完整视频。
先分清：聊天入口、专职 Bot 和执行电脑
Grok Bot 的产品定位是可以持续工作的 AI 队友。官方文档说明，Bot 能使用云电脑上的浏览器、文件系统与终端，也能通过群聊交换上下文、移交任务。用户从桌面或手机发出需求，实际工作可以在云端继续。Grok Bot 官方概览
这里有一个很容易混淆的细节：同一账号下的多个 Bot 共享一台持久云电脑，并共享文件、浏览器会话与登录状态。 为不同工作创建不同 Bot，可以组织职责和对话；它并不自动把各 Bot 变成安全隔离的独立机器。官方明确说明，分别使用的屏幕也不是独立安全边界。云电脑与应用说明
本期还有一台独立的本地 Mac mini，以及作为主力设备的 MacBook。后面出现的“在 Mac mini 上开发”和“交给 Cursor 云端 Agent”，指的是不同执行环境。理清这些对象，才不会把跨设备发送任务、云端持续运行和多 Bot 协作混为一谈。
手机检查 Mac mini，同时给主力设备设边界
00:59 开始的演示，把手机作为任务入口。创作者要求检查 Mac mini 上的 Grok CLI 是否启动，随后收到“没有在运行”的结果。这个例子说明，远程检查设备状态可以成为一个具体任务，而不只是同步聊天记录。
同一段还提到，创作者此前尝试从其他设备检查主力 MacBook 上的 Codex，但已经给 MacBook 上的 Grok Bot 设置了不执行其他设备发来指令的规则。这里的使用思路值得借鉴：让实验设备承担远程任务，主力电脑采用更严格的限制。
不过，视频中的规则配置不能证明主力设备已经能够抵御其他设备被入侵后的所有攻击。自然语言规则的预期、一次交互结果和完整安全测试，是不同层次的证据。 官方文档也把本地电脑权限与云端操作审批分开说明；本地操作需要启用相应能力，并遵循本地权限策略。本地电脑权限说明
如果要把这种用法放进日常工作，建议从只读检查开始：明确目标设备、要检查的程序，以及结果需要包含什么。涉及写文件、终止进程或执行开发命令时，再单独说明范围。这是使用建议，不是本期额外完成的安全测试。
定时资讯的价值，在于能回到原始结果
02:08，创作者在手机上打开已生成的 AI 资讯文件，查看排版后的内容、中文翻译和核验边界。到 02:59，又进入云电脑，查看浏览器中的资讯来源与抓取结果。
这两段连起来，展示了一种实用安排：把信息采集放在云电脑执行，再把结果整理为手机、电脑都便于阅读的 HTML 页面。页面里的索引帮助定位内容，结果不必一直埋在长对话中。
这里可以确认的是本期展示了已经产出的资讯页面和相关工作入口。至于定时任务是否连续多日准点运行、是否遗漏重要信息、翻译是否准确，仍需要运行记录和抽样核查。好看的排版有助于阅读，但不能替代来源与事实检查。
03:56 左右，创作者查询到的云电脑配置为 8 核 CPU、16GB 内存、128GB 硬盘。这些数字是本期环境返回的信息，并非所有账号的固定资源承诺，也没有对应编译速度、吞吐量或负载测试。它们适合帮助理解演示环境，不适合直接用于性能排名。
主 Bot 分派工作：先划清职责，再增加数量
04:19，创作者介绍了自己的组织方式：一个主 Bot 接收需求，再把工作分派给编码助手、文件检索员、资讯整理等专职 Bot。
这种安排的价值很直观。用户不必每次都决定该进入哪个对话，主 Bot 可以充当统一入口；专职 Bot 则围绕一类工作积累上下文。创作者认为，这样能够减少主 Bot 对话里不同任务混杂的问题。
但本期没有测量上下文消耗，也没有进行同条件的单 Bot、多 Bot 对照。因此，更稳妥的判断是：角色分工让工作组织更清楚，是否减少 Token、提高速度或降低错误率，还需要另外记录。
一个可操作的起点是给每个角色写清三件事：负责什么、交付到哪里、遇到什么必须停下来。先让少量角色完成一条工作链，通常比一开始堆出很多名字更容易发现重复劳动和交接遗漏。
创建记忆管理员：首轮新增 5 条，长期效果仍需观察
05:09 开始，创作者通过主 Bot 提出需求：创建一个记忆管理 Bot，每天从会话中提取值得长期保留的内容。随后出现了名为“记忆管理员”的专职 Bot，并开始整理会话与设置例行任务。
本期的任务说明包含几类内容：偏好、规则、设备与项目变化、重要决定；写入前去重，保留既有约束，不记忆密码、密钥等秘密。这里应把它理解成这次记忆整理任务设定的工作范围，而不是对产品所有存储路径的统一保证。
到 06:51，首轮整理返回“新增 5 条记忆，没有做修改”。创作者还介绍了长期事实与带日期事件的分类方式。这是一个比“已经创建了 Bot”更具体的结果：任务确实推进到了首轮整理反馈。
5 条新增记忆只说明本轮输出数量，不能证明记忆已经完整、准确，也不能直接证明模型变聪明了。 后续更值得检查的是：重要信息是否遗漏，临时选择是否被误记为长期偏好，过期信息能否及时更新，以及新旧记录冲突时保留了什么。
官方概览还区分了各 Bot 自己的对话与学习上下文，以及通过共享文件和直接交接传递的信息。因此，本期人为设置的共享记忆工作流，不宜扩写为“所有 Bot 天然能读取全部历史会话”。官方记忆说明
群聊头脑风暴：讨论结束后，谁负责形成文件
07:22，创作者打开已有的规格文档交流群，介绍研究员、编码助手、实验员等角色，再演示创建新的头脑风暴群。
08:30 的任务很具体：想开发一款 Minecraft 风格的沙盒游戏，希望找到更吸引人的设计。研究员提出侏罗纪题材，文件检索员和编码助手补充想法，主 Bot 则讨论成本。
群聊的关键并不是回复数量，而是讨论最后有没有明确产物。创作者接着要求把最终结果整理成文档并存入 Notion。主 Bot 接下整理职责，并说明其他角色不必重复执行；随后创作者打开 Notion 查看讨论结果。
这段体现了一个值得保留的协作习惯：多人参与讨论，但最终交付有单一负责人。 否则，多个 Bot 都去创建同一份文档，很容易产生重复版本。至于这些游戏创意是否真正更有吸引力，本期没有玩家测试或市场验证，不能把创意丰富程度直接写成产品成功率。
跨群生成规格，再送到 Mac mini 开发
09:45，创作者把头脑风暴结果交给规格文档交流群，请它们继续形成开发规格。随后又从主 Bot 对话中检索群内生成的规格文档。
这一步让群聊有了不同职责：前一个群发散想法，后一个群负责把想法变成开发输入。讨论记录、整理结果和规格文档可以沿着同一条链路继续使用，减少用户手动复制与重新说明的步骤。
10:18，任务被派发到 Mac mini，要求使用 Grok CLI 开发。Bot 的反馈提到已开工、建立本地 Git 仓库，并计划分阶段编写、编译、测试和提交。这里的分阶段验收是任务安排，视频没有逐一展示所有阶段的测试日志或提交结果。
后续交流还出现了很有价值的不同意见：主 Bot 说初稿已完成但仍有待办，编码助手给出正式版本，实验员指出五处需要修改，并报告 Mac mini 上已有开发任务运行。多个角色能互相提出修改意见，是协作过程的一部分；这些意见是否全部落实，还要回到最终文档和代码检查。
这也提醒使用者，开发开始后仍可能有规格变化。应指定当前有效版本和变更处理方式，避免开发端按旧稿继续实现，而讨论群已经换成另一版。
交接 Cursor Cloud Agents：先停止旧任务，再继续开发
11:40，创作者要求把 Mac mini 上的开发任务交给 Cursor Cloud Agents。随后 Bot 报告本地任务已经停下，开始整理交接内容，并转给云端 Agent 调度员。
这次流程中仍有人工步骤：创建仓库由创作者完成，再把仓库名称交回调度员。之后出现开发进度入口，可以进入 Cursor 查看任务。
因此，本期支持的结论是：从本地开发到云端继续推进的任务交接链已经启动，包含了一次人工建仓库的配合。 它没有证明整个游戏已完成，也没有展示最终代码、构建产物、完整测试通过或可玩的验收结果。不能把“已开始开发”替换成“全自动交付”。
Cursor 官方文档说明，Cloud Agents 在隔离的云端虚拟机和开发环境中工作，可以构建、测试并操作软件。能否真正完成任务，仍依赖仓库、依赖与运行环境准备是否充分。Cursor Cloud Agents 文档
对这种交接，建议保留一份简短清单：当前规格版本、代码所在分支与提交、已经完成的步骤、失败的测试、下一步目标，以及哪个执行端已经停止。这样才能判断云端是在接着做，还是从头重做。这些是后续验收建议，不是本期已展示的额外产物。
怎样判断这套工作流是否值得长期使用
本期的亮点，是把设备、角色、文档和开发环境串了起来。但要判断长期价值，还可以继续跟踪几个明确问题：
- 远程任务是否找对设备。 结果应写清执行环境，不能只回一句“完成了”。
- 定时工作是否留下运行记录。 缺失来源、运行失败和延迟都应可见。
- 记忆是否可检查、可修正。 尤其要区分长期偏好、临时安排和过期事实。
- 群聊是否避免重复交付。 每个产物应有负责人和当前版本。
- 开发交接是否保留进度。 旧执行端是否停止，云端是否读到正确代码，测试是否实际通过。
发送消息、发布内容、修改权限或删除数据等操作，也应设置明确的停点。官方审批文档建议在请求中说明允许做什么、在哪里等待确认，并检查目标、范围与输入。审批与安全说明
原视频对 Grok Bot 的灵活性给出了积极评价，但本期没有在相同任务、相同预算和相同验收标准下系统比较 OpenAI Dots、Meta Muse 与 Claude Duet。这里更有价值的是具体工作链，而不是据此宣布一个覆盖所有场景的产品排名。
结论
Grok Bot 在这期体验中展示的使用方式，是让手机成为入口、让专职 Bot 分担工作、让文档连接讨论与开发，再把任务送到合适的执行环境。记忆管理员完成首轮整理，群聊结果进入 Notion，开发工作从 Mac mini 延伸到 Cursor Cloud Agents，这些都是可以继续追踪的具体节点。
下一步最值得验证的，是这些节点能否稳定重复：记忆有没有记错，规格有没有同步，交接有没有丢进度，代码最后能否通过测试。把验收标准放进工作流，才能从一次顺畅演示，逐步判断它是否适合承担真实的长期任务。
参考资料
- AI超元域：Grok Bot 高级玩法教程，YouTube 页面显示发布于 2026 年 11 月 3 日，频道卡片标示 13:03，播放器标示 13:02。
- Grok Bot 官方概览。
- Grok Bot：云电脑与应用。
- Grok Bot：审批、安全与隐私。
- Cursor Cloud Agents。
官方说明核查日期：2026 年 11 月 3 日。本文中的硬件配置与任务反馈对应本期环境；产品能力、访问资格和资源安排应以实际账号与最新文档为准。