从一个结果，
到一支团队。

先用一个结果，验证这套工作方式

这份指南面向创作者、独立开发者和小团队，研究对象是 xAI 的 Grok Bot 持久代理产品。Bot 拥有持续的工作上下文，能使用云电脑、工具和文件；多个 Bot 可以交换工作。它不同于单纯在 Grok 聊天窗口里问问题。 [01] [04]

阅读标记 官方描述已查到的功能；用户自述描述个体经验；本指南建议是为你的场景设计的操作方案，不是平台承诺。未登录你的 Grok Bot 账号，未实测你的套餐、插件或生产流程。

先分清六个部件

第一次打开：按这六步完成

1. 从官方入口安装

   打开 x.ai/bot，按设备选择下载。Mac 打开安装镜像后拖入 Applications；官方入门还列出 Windows、Linux。用 Cursor 账号登录并等待云电脑就绪。

2. 核对账户和额度

   先看账号当前显示的 Grok Bot 权益，再决定是否需要升级。已有可用账号就先做小任务；不要为“叠加额度”重复买订阅。计费解释见第 10 节。

3. 创建第一个 Bot

   New → Create new agent → Bot actions → Edit Profile。命名“交付负责人”，填入一个明确职责和输出标准。

4. 先交一份无外部写入的任务

   附上一份访谈或需求文档，让它提取问题和证据。核对引用、遗漏与误读。这一步不需要先把全部业务系统接入。

5. 只接这个任务需要的工具

   优先 Settings → Plugins。需要网页登录时打开 Agent Computer，接管并完成登录，再交还控制。密码、验证码不要发到普通聊天。

6. 把第一次验收标准保存下来

   要求修订同一份产物。长期偏好写回角色描述；成功方法另存为技能。验收通过再引入第二种输入。

安装与起步依据 [02]；创建界面依据 [03]；登录与插件依据 [05]。菜单随版本与灰度开放可能不同，优先按功能名称定位。

你是我的交付负责人。
目标：把我附上的客户访谈整理为可评审的需求清单。
输出：问题、用户原话/原文位置、发生场景、影响、待验证假设、建议下一步。
规则：不补造证据；找不到原文就标“待核验”；不要修改原文件或联系客户。
先完成这份材料，返回可下载表格和不超过 5 条关键结论。完成后停在我验收的位置。

用户体验：把好评和失败一起看

这里选取有具体工作情境的公开自述，去掉只有情绪或广告口号的评价。样本不是随机调查，也没有成功率统计；“用户说有效”不等于已证明能在你的业务复现。

额度失控的另一条评论见 [15]。综合判断（推断）：输入明确、输出可检查、外部写入少的流程更适合作为第一轮试点。样本不足以证明哪种行业一定成功。

把公司拆成一个能交付的业务循环

本指南建议｜贯穿示例：为创作者和小团队提供“客户资料整理 → 内容或页面制作 → 交付验收”的 AI 服务工作室。首周只选一个服务包，例如“访谈转需求报告”；下面步骤是实施方案，不是一个已经验证的盈利案例。

项目：AI 服务工作室试点。
客户：[目标客户]；解决：[具体问题]；首个服务包：[交付物]。
本周唯一目标：[一项可验收结果]。
依据：[客户材料/现有资料链接]。没有依据的业务结论列为假设。
请建立业务清单：获客、需求确认、制作、验收、交付、复盘；为每项写负责人、输入、输出和完成标准。
第一轮只完成一份样本，不自动招募多个 Bot，不代我购买、签约或向客户承诺。
我负责商业决策。你每次汇报实际产物、待决策项、阻塞和下一步。

搭建项目：用可检查的文件串起工作

本指南建议｜项目示例：用一份客户访谈，交付需求报告和一个介绍页。先在 Grok Bot 云电脑的 /workspace 下建立项目目录；目录名是约定，不是必须遵守的平台格式。 [07]

1. 立项：先把 brief 写到能验收

   确定读者、目标、交付形式、资料范围、截止时间。对介绍页明确：关键文案齐全、表单真实可用或明确标示演示、移动端可读。

2. 拆任务：按产物分工

   研究员交需求证据；制作者交文案与页面；复核者交问题列表。指定台账由协调人维护，其他 Bot 只提交更新请求。

3. 制作：一项任务只给必要资料

   要求引用当前资料，保留关键版本。若授权修改共享系统，先展示目标记录与变更范围，避免整表重建。

4. 验收：复核者打开实际产物

   报告逐条抽查来源；页面检查 390px 和 1280px、链接、按钮、表单状态。软件项目额外运行与功能匹配的测试，把失败如实记录。

5. 交付：到接收者能打开为止

   要求提供附件或明确链接，说明已完成、待审批和未验证部分。下载一份本地副本；云电脑路径不等于你本机桌面的路径。

6. 复盘：只固化确实有效的步骤

   记录返工原因，修订操作方法和验收标准。不要把偶然成功的长对话原封不动当作流程。

在 /workspace/studio-pilot/ 建立试点项目。先读取我提供的资料。
交付：需求报告 + 介绍页草稿。时间：[截止时间，Asia/Shanghai]。
创建 brief.md、tasks.csv、decisions.md、review.md 和 deliverables/。
任务台账字段：ID、负责人、输入、输出、验收条件、状态、更新时间。由你独占维护台账；不要覆盖已有任务或重建整表。
每个产物返回文件或链接。外部发布、购买服务、客户消息由我审批。
先完成 brief 和第一份需求报告；材料不足列出具体缺口，不编造客户要求。

搭建团队：按交接关系增加岗位

官方支持不同 Bot 独立负责岗位并相互协作；下面是建议编制，不是必须创建的数量。先用“交付负责人”，有稳定分工再扩为三人，复核需求增加后再配第四名。 [03] [04]

建立协作的实际操作

按第 3 节的方法分别创建岗位，编辑 Profile；请协调 Bot 建立项目群聊并加入指定 Bots，再核对实际成员。用 @ 指向接收者；若当前版本不能按消息创建群，使用 New 中可用的群聊入口。官方公开页确认群聊协作，未提供适用于所有版本的固定建群点击路径。

请在本项目中协调研究员、制作者、复核者；只使用已存在且我指定的 Bots。
每次交接包含：任务 ID、交付物路径、来源、已完成、未完成、接收者、验收条件。
接收者必须先检查输入是否齐全，再执行；缺失则回报具体阻塞。
同一个文件只有一个写入负责人；不要相互覆盖，不要反复互相派发同一任务。
研究员写 sources/，制作者写 deliverables/，复核者写 review.md；你维护 tasks.csv 和 decisions.md。
仅协调人向我汇总；需要我决定的事情集中列出。发现重复外发风险或任务循环时停止受影响任务并说明已执行动作。

真人团队加入时，权限按人管理

每位成员使用自己的 Cursor 身份与云电脑。给别人分享 Bot 是让对方复制配置，不会共享你的登录或对话；同一账号内多个 Bot 却能访问共享电脑上的状态。

团队控制按专门团队文档判断 [09]。设置页对 Team Setup 的文字更宽泛，与团队页有差异；本文不据此承诺普通 Teams 可配置该功能。 [11]

从一次任务，变成可持续流程

在输入框用 / 引用技能；若找不到，检查 Settings → Plugins → Yours 中是否为当前 Bot 启用。Teach a task 可用时，在一对一对话的电脑视图中示范，再检查生成的技能；未开放则用文字步骤加已完成样本。 [06]

把刚才通过验收的流程保存为“客户需求整理”。
技能包括：适用场景、输入格式、资料来源、处理步骤、证据引用、验收清单、输出位置、缺数据时的行为。
加入反例：不得把自己的建议写成客户原话；不得把旧访谈当作最新决定。
用我给的第二份资料再做一遍，返回差异和失败点。未经我批准，不安排定时，不外发。

为交付负责人建立一个例程：每个工作日 09:00，时区 Asia/Shanghai。
读取 /workspace/studio-pilot/tasks.csv 和最新交付记录。
在本对话返回：逾期、阻塞、今日交付、需要我决定的事项；每项附任务 ID 和产物链接。
只汇总，不联系客户、不改截止时间、不覆盖原表。若资料不存在或不是当前版本，明确报错，不用旧数据补齐。
展示下一次运行时间，先用安全样本 Test run；验收后再启用正式执行。

在 View conversation details → Routines 查看、暂停和测试。事件触发依赖受支持的账号 integration，不能把安装 Slack/GitHub 插件等同于事件已接通。限定来源和匹配条件，别监听所有消息。 [06]

用清楚的边界，换取稳定运行

同账号的 Bots 共用电脑，给“财务 Bot”换一个名称不会隔离财务资料。把长期规则写进角色描述，并在系统可用的审批设置里设置对应范围。 [08]

Settings → General → Auto-review 可配置 Require Approval / Always Allow，冲突时前者优先。自动审核是模型机制，不代替源系统权限；本地电脑执行另有设置，和云电脑能力分开。 [08]

写给 Bot 的结果回执

1. 已完成：可打开的产物或实际记录链接。
2. 证据：来源、检查动作和发现。
3. 待审批：具体目标、内容和影响。
4. 未完成：失败、缺数据与未验证项。
5. 下一步：由谁在什么时候完成什么。
不要把计划当成已执行；不要用“全部完成”掩盖剩余阻塞。

这份回执是建议模板；官方结果文档也建议区分事实、假设、已执行与待审批，并保存可独立检查的证据。 [07]

别按 Bot 数量衡量收益

官方计费要点：付费 Cursor 个人计划与 Teams 可获得使用权，也有个人 SuperGrok / X Premium+ 关联路径；已有 Cursor 权益与关联权益不叠加。用正确账号关联，官方称关联后不能解绑或移到另一账号。计费以 Cursor 账户为中心。 [10]

包含额度按周重置。按需用量开启后，耗尽周额度仍可能继续计费；月上限不是运行中立即截断，已有任务可能执行超出上限。试用也受用量和时间窗口限制。先检查账户实际显示，不把厂商首页价格或用户报告的套餐名当成你的账单。 [10]

本指南建议：每周只记录四项

验收通过数量、人工净省时、返工时间、实际增量支出。少量高价值交付比大量无人验收的产物更有意义。

计算方式：（节省时间 − 复核返工）× 小时估值 − 增量支出。默认数字只是演示，不是实测、财务收益预测或套餐报价。若连续两周为负，先收缩任务和返工，再考虑增加 Bot。

出问题时，按症状恢复

排障依据 [12]，技能启用依据 [06]。建议：失败报告保存产品版本、错误原文、发生时间与时区、任务名及 request ID；隐藏 Bot 不等于暂停它，停止相关例程需单独处理。 [03]

七天上线清单

本地勾选只记录你阅读和实施的进度，不会连接 Grok Bot，也不会自动创建公司、账号或代理。

请读取本周任务与交付记录，返回：
哪些产物通过验收；哪些失败或返工；主要原因；有证据的省时估计；实际使用或支出记录。
给每个流程提出“保留 / 缩小 / 暂停 / 扩大”的建议和依据。
只建议一个下周最值得改进的环节，不自行新增 Bot、订阅或例程。

来源与核验边界

检索与阅读日期：2026 年 9 月 12 日。官方功能以文档为依据；用户原帖只用于呈现体验。搜索发现的转载“搭公司”文章未作为功能证据；不明来源、宣称“官方”的第三方安装仓库未作为下载入口。没有独立复现用户案例，也没有验证其收入、效率倍数或用量数字。