Elon Musk 转发了一条推文。SpaceXAI 工程师 Lauren Tan 说：

> “我原本是 agent 和浏览器之间的人肉代理，所以我把自己从这份工作里开除了。现在 10 多个 Chief of Staff Bot 24/7 跑我的 agent，我早上只检查结果。”

这条推文附带视频：

她用一小时展示了怎么用 Grok Bot 搭出那座 dark factory：Skills → Verification → Loops → GrokBot → Dark Factory。多数工程师还在给一个 agent 当保姆，她把自己从这份工作里开除了。

distort 的评论更直接：Grok Bot 可能是你第一个该招来上班、而不是用 prompt 调教的东西。它能拥有一个岗位，在你的工具里连续工作几个小时，带着成品回来。他说这场演讲比多数 1500 美元的 agentic engineering 课程值钱。

distort 为此写了一篇完整指南：[Grok Bot: How to Hire Your First AI Employee](https://x.com/i/article/2105262478535847936)。标题看着像工具教学，读完后更像一份管理手册。核心问题落在管理：这个 Bot 到底挣到了多少权限？

## 先招岗位，别招任务

Chatbot 回答问题。Bot 会登录你的工具、跨多个步骤操作、把成品拿回来。所以设置一个 Bot 时，你干的事更像招人，而不是写 prompt。

岗位测试：用一句话写清楚它负责什么。如果这句话需要六个无关动词，说明你让一个人干四个人的活，失败后连责任都分不清。

弱例子：“帮我搞营销。”

强例子：“你负责每周竞品监控，每周五交付一份带来源和日期的变更报告。”

后者告诉你周五该检查什么。前者什么都不告诉你。

然后把这句话扩成五栏：负责、输入、可做、必须请示、完成标准。一个研究岗位可以写成：

- 负责：证据收集与核验

- 输入：简报、批准的来源列表、历史研究存档

- 可做：搜索、阅读、比较、整理、起草摘要

- 必须请示：联系任何人、购买访问权、发布任何内容

- 完成标准：每个事实陈述都有来源，冲突被标出，空白被写下来而不是糊过去

它脱离了 prompt 的范畴，成为可复用的岗位基础设施。六个星期后它仍然应该成立。

## 第一项工作要无聊

别让新 Bot 一上来就碰重要的事。第一项任务是用来产生证据的，不是用来产生价值的。挑一件高频、可逆的事：做砸了一眼能看见，撤销不费劲。

好的第一份工作：把昨天的客服问题去重，按优先级汇总；整理竞品动态，每条都带来源和日期；复现一个 bug，记录步骤、日志和环境。

坏的第一份工作：任何会发送、发布、购买、删除、对客户说话的事。

上线前先在文本里跑一遍。让它把计划写出来，不要执行。这一步能暴露它打算把两周前的邮件一起归档，而代价只是 90 秒。

“做得好”不是一个可检查的标准。把“找到好来源”改成“找 10 个不重复的、过去 90 天内发布的来源，每个都附发布日期、作者、URL 和支持的具体论断”。把“收件箱干净”改成“早上 9 点零未读，每封回信不超过四句话，带截止日期的邮件标出来而不是归档”。

还有一条几乎没人写，但应该写进每个完成标准：不确定时怎么办。默认行为是让 Bot 静默猜测。你想要的恰恰相反：停下来问。慢是免费的，在发件箱里犯错不是。

## 给一把钥匙，不是一整串钥匙

权限画在哪，不看事情重不重要，看能不能撤销。

不用问就可以做：搜索、读取、总结、分类、比较、整理、起草、暂存、模拟。

允许在批准的系统内做：编辑内部文档、更新内部记录、生成交付物、移动已批准文件、运行已测试过的例行程序。

必须问：发送、发布、删除、覆盖、改权限、联系外部、修改生产、动钱、接受条款。

“给 40 个客户起草消息”和“发送”之间，隔着一道完整的审批门。一个好的运行结果应该是：安全的 90% 都做完了，不可逆的部分全部暂存并写清楚，等待批准。

还有一个容易被忽略的细节：同一账号下的 Bot 共享环境、文件、浏览器会话和登录态。给 Bot 取不同名字只是视觉边界，不是安全边界。指令说“不要碰财务”只是建议，不是控制。信任级别不同，就把账号或环境分开。Bot 遇到登录墙时，给它会话，不是密码。

## 试用期至少跑三次

一次成功只说明演示环境没问题。第二次换个同类任务，别手动提醒它昨天的错误，看修正是否生效。第三次放手让它跑，只在需要审批和真正拿不准时介入。

然后量五件事：完成率、你干预的次数、需要多少轮检查、到可接受结果的时间、每个结果的成本。

失败的时候修规则，别修报告。报告错了，手动改掉是十分钟的事，但下星期它还会错。找到放行错误的环节，改掉，重跑，确认失败消失。慢一次，然后不再发生。

循环要有边界。“一直干到完成为止”听起来合理，实际上是无限预算配上未定义的结果。默认值可以设为：工具偶发失败重试两次，输出格式坏了修复一次，证据冲突停下来问，连续三轮修正失败就升级，成本到顶立刻停工。一个知道何时停下的 Bot，比一个永不放弃的 Bot 好信任得多。

## 权限是一级一级挣来的

Level 0 观察。Level 1 准备。Level 2 带审批执行。Level 3 定时触发。Level 4 协调其他 Bot。

晋升不是看 demo 感觉。标准是：连续五次干净运行、每次验证都通过、零未解决副作用、至少测试过一次回滚、审批策略真的拦下过东西。

而且等级可以往下调。输出质量下滑、底层集成变了、连续两周在手动纠错，就降级。自主权是运行期特权，不是一次演示换来的终身职位。

## 每周做一次绩效回顾

无人值守的自动化不会大声崩溃，只会悄悄退化。接口变了、凭证过期、来源要登录、你的优先级换了。它还在按计划产出看起来准时、实际上没用的东西。

每周给每个例行任务一张收据：运行次数、通过几次、人工修复几次、平均耗时、重复失败是什么。自己再抽查一份产物。然后问三个问题：该跑的时候跑了吗？结果真的正确，还是只是存在？明天它消失了我能发现吗？

第三个回答不上来，就删掉。自动化组合不是奖杯架。

什么时候雇第二个 Bot？当真实瓶颈出现的时候。别第一天就搭一个十个 Bot 的部门。先来一个协调者加三个专家，交接时传“工作”，不传“聊天记录”。目标、产物、已做的决定、约束、未决问题、下一个检查点，就够了。把每个上下文窗口都塞满所有历史，系统会又慢又自信地错。

## 管理才是护城河

有网友在回复里说：“护城河是管理。”

已经有人把这套思路用在 NIST/CIS 合规流程里：抓取 AWS 账户、找 remediation、让 Grok Bot 联系资源所有者确认变更、更新 Terraform、理解 CI 流程，最后在 OIDC pipeline 上确认 PR 部署。至少说明这套框架不只在聊天框里成立。

distort 的指南最后也落到这：Grok 4.6 提供推理，常驻计算环境提供工作空间，工具让它能行动。剩下的全是管理：它负责什么，什么算做完，能碰什么，拿不准怎么办，允许重试几次，谁来检查，哪些决定留在你手里。

大多数人接下来六个月会问：Grok 是不是比别的模型聪明。真正拿到产出的人会问另一个问题：这个 Bot 挣到了什么不用我盯着的权利？

答案从一件无聊的小事开始。写岗位，文本试运行，跑三次，周五复盘。然后再雇第二个。