Grok Bot 打法：一个人如何从笔记本上运营整个业务（含完整配置）

Grok Bot 玩法手册：一个人如何用一台笔记本运营整个业务（内含完整搭建）August 24, 2026 · 12 min read · View source ↗ Grok Bot Slack Automation AI 早上 7:00，一个你上周命名的 bot 打开了一个你从未见过的浏览器，用你授权过一次的会话登录你的收件箱，清掉昨夜到账的所有东西，起草九封回复，并把两封提到钱的搁置起来。 你的笔记本是合上的。你在睡觉。没人点击任何东西。 那不是演示录像。那是 2026 年 8 月上线的一款产品的默认行为，而大多数人仍然把它当成一个"图标更好看的聊天窗口"来用。 这是整个搭建，按顺序：Grok Bot 底层到底是什么、怎么进去、怎么写一个"行为像雇员而非提示词"的 bot，以及如何把一个 bot 发展成一个在你睡觉时运营整个业务的班子。 读一遍，然后打开 app 照着做。 提示词是一次请求。bot 是一个角色。 至今为止每一个 AI 工具都在等你。你打开它、你问、它答、你关掉它。工作留在你手里，模型只是旁白。 Grok Bot 把这个倒过来了。你创建的每个 bot，都是一个有名字的队友，带一条持久的线程、自己的记忆，以及对云里一台真实电脑的访问权——有浏览器、文件系统和终端。它打开网站、点击、填表、发送，就像你会做的那样。 所以工作单位不再是一条消息，而是一份工作。你不写一个更好的提示词。你写一份职位描述，而且它会被持续保留。 这是唯一一个决定，把"从这个东西里得到价值的人"和"一周内就弃用的人"分开。用真实的人能担任的职位，给你的第一个 bot 命名。收件箱经理（Inbox Manager）。外联销售（Outbound Rep）。记账员（Bookkeeper）。人才猎头（Talent Scout）。 把它命名成"万能助手"（General Helper），你就得到了一个带额外步骤的聊天机器人，因为一个 bot 只会围绕你反复回来的那个领域建立锐利的记忆。 一个账户，一台电脑，一个共享一切的班子 这里是他们在把 app 交给你之前从不会解释的架构。 你不是每个 bot 一台机器。你是每个账户一台持久的云电脑，而你账户上的每个 bot 都在它上面工作。每个 bot 在那台共享机器上有自己的屏幕，所以几个可以同时驱动工具，但下面的文件柜只有一个。 这意味着浏览器 cookie 和已登录会话是共享的。文件对每个 bot 都可见。命令行凭据是共享的。一个 bot 精确地从另一个停下的地方接手，没有上传、没有重新登录、没有它们之间的胶水代码。 把它想成一间办公室。云电脑是办公室，每个 bot 是有一个自己工位的同事，而文件柜只有一柜、钥匙只有一套。 "交接是免费的"和"班子共享同一套后果"，是同一个事实的两面。一个 bot 不是安全边界。如果你账户上任何一个 bot 都不该拿到某个凭据或文件，就别把它放到那台机器上。 持久化的工作属于共享工作区 /workspace。临时目录和手动安装的包没有任何保证，恢复时会被清掉。 进去大约要四分钟： 还没有独立套餐。访问权限跟 SuperGrok Heavy（约每月三百）、Cursor Ultra（约两百）、或 Cursor Teams Premium（约每席位一百二）捆绑。 在 x.ai/bot 下载 macOS 或 iOS 版 app，用你已经付费的那个账户登录。 Onboarding 只问一个问题：你每天用哪些工具。选你真实的技术栈，因为它会塑造之后每一个队友建议。 打开 Settings，然后 Plugins，各点一下连接 Gmail、Drive、Calendar、Slack、Notion、GitHub、Salesforce、HubSpot。 把"在本地电脑上执行"设为永不允许，直到某个 bot 有一个具体理由需要碰你自己的机器。 连接活在账户级别，不是每个 bot 一个。连接一次 Gmail，你将来创建的第五个 bot 几秒内就有生产力。这也意味着任何连接的触及范围是你将来会建的每一个 bot，这是个好理由，让你在 beta 期间只连你真正需要的，其余一概不管。 对于没有插件的工具，bot 自己驱动浏览器，直到撞上登录墙，然后把屏幕交给你。你打开智能体电脑，接管控制，自己输入密码或双重验证码，交还控制，它就在那个已授权会话里继续。 你绝不把凭据粘进聊天消息。bot 拿到的是一个会话，不是一个秘密。如果有任何工具让你把密码打进对话里，那就是错误的路。 章程就是那次雇用，它作为一个文件持续存在 创建 bot 时，你不是在写提示词，而是在第一天给某人做入职说明。那段文字会变成一个 profile，bot 永久保留并编辑，而不是反复重打。 三部分做完全部工作。 它负责什么，这样它就能在例行工作上自行行动，不用问。 好的输出长什么样，写成检查项而不是形容词，因为"每一条主张都带来源和日期"每次都胜过"让它显得专业"。 它在哪里停下，也就是未经你许可它绝不可采取的那些动作。 最后一部分不是文书工作。它是你能把这东西放着无人值守运行的原因，因为你把线画了一次，而不是每天为它操心。什么都问的 bot 没用。什么都不问的 bot 危险。 把"永远为真"的规则放进 profile，把任务专属指令放进线程。"未经批准绝不外发消息"属于 profile。"为这十二个账户起草跟进"属于对话。 演示一次，而不是解释两遍 这是那个把工具变成员工的功能，也是大多数人从没碰过的那个。 打开一个一对一对话，打开电脑视图，选择"Teach a task（教一个任务）"，描述你想要的结果，然后在它录自己屏幕的同时做一遍工作流。它把整条流程保存成一个命名的技能，之后可以自行重复，边做边修小错误。录制最多捕捉十分钟的可见交互，不录麦克风音频。 吃掉你一周的任务，通常"描述起来乏味、演示起来琐碎"。"从这个仪表盘拉数字，交叉核对掉下去的那些，把它们粘到文档正确的标题下，如果有任何指标移动超过 15 个点就 Slack 一下负责人"——写出来是一段话，演示出来是四十秒。 仔细挑第一个录制。最佳候选是：重复性的、触及两个或更多工具、且步骤很少变化。任何同时满足这三条的，都是等着被从你盘子里端走的工作。 一个录制好的技能是一份草稿，不是一个规程。它捕捉的是你的点击，不是你的判断，所以规则你自己加，否则它在第一个边缘案例上就会做出某件自信而错误的事。任何网站改版、连接器变化或格式变化之后，都要重新测试它。 然后给它一个触发的理由。一条 routine（例行任务）把一个工作流指派给一个 bot，并决定它何时运行：一个时间表（如每个工作日七点），或一个触发器（如匹配邮件或 Slack 消息落地的那一刻）。时间表让它守时。触发器让它显得在场。 一个 bot 是工具。六个 bot 是一家公司。 你不需要一个大队人马。你需要能端到端完成一个任务的最小班子，对大多数运营来说，就是一个协调者加四到六个专才。 不要第一天就建五个 bot。先建一个"Chief of Staff（幕僚长）"，让它整个工作就是协调。给它访问那些已经描述你生意的东西，让它审计运营、并点名三个会最先推动营收的角色，然后在你手把手让一个任务跑通之前，别说"现在建一个正好做这个的 bot"。 你是在证明任务能跑通之后，才赢得每一次新雇用，然后才去规模化它。 一个账户最多容纳 50 个 bot 和群聊的总和，每个 bot 最多拥有 50 条 routine，app 为每个 bot 保留最近 20 条运行记录。群聊容纳二到六个 bot，用于那些需要可见的交接。 给一个群一个目标（objective），而不是一个任务清单。任务清单意味着你已经做完了拆解，bot 只是在把它打出来。一个目标让它们自己分工、决定谁负责每个阶段、并向下一棒交接，只把你拉进来做判断。 那种交接——一个 bot 判定另一个更合适并移交所有权——是此前任何工具里都不存在的东西。 在每个阶段要求一个单一负责人。太多并行交接会产生重复工作和嘈杂的更新，而这正是班子一旦超过四五个 bot 就会出现的失败模式。 按可逆性画批准线，而不是按体量 整个前提，是 bot 端到端地完成工作，只在有东西需要你时才回来。这把负担压在你身上：定义什么需要你，因为 bot 选的默认值可能跟你的不一致。 能行得通的那条线，不关乎任务有多大。它关乎外部世界有没有看到它。 任何 bot 能撤销的——起草、归档、打标签、研究、对账、准备——它自己完成并记录。任何发送、花钱、发布、删除、或同意条款的，都搁置起来。如果它在不到一分钟内无法撤销，就等着。 在可强制执行的地方，产品会在动作运行前评估它们。"Require Approval（要求批准）"规则总是拦下匹配的动作。"Always Allow（始终允许）"规则，只在自动审核找不到其他拦它的理由时，才放行一个动作。两者都匹配时，Require Approval 胜出。那个审核是基于模型的，所以把它当成"最小权限"之上的一层，绝不要当成它的替代。 再往每个 bot 里烙一条规则：如果它无法向你展示它是怎么得出一个数字的，它就把那个数字拿掉。好的 bot 交回完成的工作加上收据：步骤的录制、每个数字背后的来源、任何它猜测过的东西单独列出、以及任何它跳过的东西和原因。 那单独一条线，就干掉了人们抱怨最多的失败：建立在虚无之上的自信报告。 在连接任何东西之前值得知道的局限 这些都不是魔法，假装它是，正是人们被烫伤的原因。 它还是早期 beta，所以一个改版的页面或一个随机弹窗就能让 bot 在任务中途绊倒。地板大约是每月两百，没有独立套餐。每个 bot 共享一台电脑，所以一次错误的爆炸半径是整个班子，这是在提示你把银行和任何敏感东西彻底拿开。批准能在动作发生前拦下它，但不能撤销一个已经发生的，而且还没有完整的审计日志。 自动化还会悄悄腐烂。一个网站改了布局，一条 routine 开始产出垃圾，而因为它在你睡觉时运行，三周都没人注意到。每周在日历上放十五分钟，对每条 routine 问三个问题：它跑了吗，输出真的对吗，如果我杀掉它我会不会想念它。 按时间表交还控制权，而不是等到"感觉准备好"。第一周它只起草，你全部读一遍。第二周你批准每一个动作，但不再读过程。第三周它处理常规案例，把异常升级给你。第四周它按时间表运行，你读摘要。 真正的难点不是技术性的。是训练你自己停止插手，因为你每打断一次运行、去重新问一个 profile 早就知道的东西，你就是在花钱重新学它。上下文只有在你不动它时才会复利。 你的前十分钟 别读完这个就什么都不做。 挑你这一周里最丑的那件重复事务，那件没有任何集成会碰的事。创建一个 bot，给它一个名字和一份四句话的章程，演示一遍教会它任务，把它放到一条批准线后面。然后走开，第二天早上再回来。 你第一次回来看到那份你没做、却已完成的工时，就是整件事豁然开朗的那一刻。你不再做那个在五个聊天之间复制上下文的人类路由器，你也不再是那个逐项苦熬清单的人。 这项技能不再是怎么措辞，而是：我到底在委托什么，它的权限在哪里结束。 那是一个管理问题，不是一个提示词问题。这正是为什么在这件事上赢的人，看起来跟当年在提示词上赢的人完全不像。 关注我并订阅我的 Telegram 频道： https://t.me/+NvTfeqek8qZlMDll Tags: # X # Grok Bot # Slack # Automation # AI # Thread # Guide Related articles Grok Bot: Not a Chat, but an Employee With Its Own Computer. The A-to-Z Breakdown Behind that line sits one detail: every bot inside Grok Bot gets its own computer. A real virtual machine, with a browser, files, a terminal, and your logins. And it keeps working even when your lapt… Grok Bot AI Slack Automation