原文https://x.com/distortgeekin/status/2105275395901726845?s46中文译文没有人会第一天就把公司银行卡交给新员工说一句“帮我打理生意”就算完成了招聘。而这几乎正是大多数人即将招聘自己的第一个 Grok Bot 时所做的事。创建一个 Bot。接上你所有的工具。给它一个庞大又模糊的任务。然后坐等奇迹发生。第一次运行看起来很棒。第二次也不错。可接下来它会归档一封来自你会计的邮件会轻信一个本应被标记出来的来源或者绕一条你绝不会批准的路径得出正确答案。于是那个你本想信任的“队友”现在需要你盯着而盯它所花的时间比你自己动手还多。关于 Grok Bot真正有意思的问题不是 Grok 4.6 是否足够聪明。而是一个每个管理者早就知道该怎么问的问题这东西到底挣得了多少权限聊天机器人只是回答。而 Bot 会登录你的工具、在一台持续运行的计算机里工作、走完多个步骤最后交回做完的成果而不是给你一堆让你自己去完成的指示。这就改变了你设置它时所做的事。你写的不是一条提示词prompt你是在给一个岗位配人。所以像招聘一样对待它岗位说明、枯燥的第一项任务、试用、转正、凭证据晋升以及每周一次复盘。这就是完整的方法论。30 秒版本招的是“岗位”不是“任务”。用一句话说明它负责什么且这句话下个月依然成立。让第一份工作足够枯燥。频率高到能验证代价低到能撤销。用文字先跑一遍试用。让它先说出会怎么做再允许它动手。第一天之前就定义好“完成”。“有用”不是标准一份可勾选的清单才是。只给一把钥匙别给整串钥匙。划线依据是“可逆性”不是“重要性”。试用期是三次运行。一次成功只是事件可靠才是模式。凭证据转正。连续五次干净运行、回滚测试过、零未了结的副作用。每周复盘。并砍掉那些没人会想念的例行流程。下面所有内容都是这八句话的详细版。第 1 部分招的是“岗位”不是“任务”让一个 Bot 变得无用最快的方式是给它“工作”而不是给它“岗位”。“工作”是“总结这五篇文章”。“岗位”是“你负责竞品监测”。前者十分钟就做完什么也教不了你。后者可以被评估、被改进最终被信任。一句话测试。用一句话写下这个 Bot 负责什么。如果这句话需要六个互不相关的动词那你是想用一个人干四份活出了错你根本分不清是哪儿的问题。差的写法“帮我做市场营销。”好的写法“你负责每周竞品监测并在每周五交付一份带引用的变化报告。”后者告诉了你周五该衡量什么前者没有。Bot 真正能用得上的岗位说明。这句话一旦写出来就把它展开成五个字段——它们将决定你和 Bot 未来每一次争论负责Owns它要对之负责的结果。输入Inputs允许它以什么为工作依据。可以做May无需请示即可执行的动作。必须先问Must ask before总是要回到你这里确认的动作。完成条件Done when让这项工作可被接受的条件。一个写好的研究岗研究操作员Research Operator。负责证据的收集与核实。输入任务简报、已批准的来源清单、此前的研究存档。可以做搜索、阅读、比较、整理、起草摘要。必须先问联系任何人、付费获取访问权限、发布任何内容。完成条件每一条事实性论断都有来源冲突被明确列出尚未补齐的空白被写下来而不是被抹平。这不是一条提示词这是可持续的基础设施。它在六周后仍应成立。把“岗位”和“今天的任务”分开。常见的失败是把所有东西塞进一条巨大的指令里角色、历史、工作流、安全策略、质量标准、重试逻辑全挤在一个块里而且每次出错就往里加东西。于是每次失败看起来都像“提示词问题”。通常并不是。如果 Bot 忘了你上周说过的一个偏好那是状态问题。如果它打开了错误的工具那是路由问题。如果它把本该停在草稿的东西发出去了那是权限问题。如果它把同一条坏路径重试了六次那是循环问题。更好的提示词只能改善一次运行把“岗位”拆分开来能改善之后的每一次运行因为你终于能分辨是哪一部分坏了。第 2 部分让第一份工作足够枯燥面对一个新来的、能力很强的 Bot你的本能是给它点重要的事。请忍住一周。你的第一项任务是为了产出证据不是为了产出价值。你要的是这样一份工作犯了错一分钟内就能看出来而且撤销它不花任何代价。高频且可逆。决定第一份工作的只有两条轴仅此两条。频率给你信号。一个每季度才发生一次的任务要到明年一月才教得了你任何东西。可逆性给你空间。一个能撤销的任务让 Bot 可以犯错而不至于让你的整个下午都搭进去。好的第一份工作把昨天的客服问题收集起来、去重整理成一份优先级摘要。从一份竞品清单里挑出五项最重要的变化每条论断都带上来源和日期。复现一个被报告的 bug并记录下步骤、日志和环境。糟糕的第一份工作任何会发送、发布、购买、删除或面向客户发言的事情。诱惑是显而易见的失败的代价同样是。在它碰到任何东西之前先用文字跑一遍试用。第一次真正运行之前先要它的计划而不是结果“先别执行任何操作。按顺序、一步一步告诉我你打算怎么做说出你要打开的每一个工具以及每一个你不确定的判断点。”这花九十秒却是整个搭建过程里最值钱的九十秒。一个即将误读你收件箱的 Bot会在这次空跑里告诉你。它会说它打算把所有超过两周的邮件都归档而你会在文字里发现这里面包含那封你一直故意留着未读的邮件。同样的误解是在一条消息里被发现而不是在你的归档里被发现。第一天之前就定义好“完成”。大多数令人失望的 Bot 产出不是能力失败而是规格失败——而双方都觉得是对方没说清楚。避免那些听起来很具体、其实并不具体的质量词有用、专业、全面、高质量、详尽。把它们换成 Bot 自己能核对的条件不要写“找好来源”而要写“找十个最近 90 天内发布、互不重复的来源每个都带上发布日期、作者、URL以及它所支持的确切论断”。不要写“保持我的收件箱干净”而要写“早上 9 点前零未读每条回复不超过四句话任何带截止日期的事项要标出来而不是归档”。还有一句应该写进每一份“完成定义”、却几乎没人写的话不确定时该怎么办。一个能力强的 agent 面对模糊时默认行为是悄悄用它自己的最佳判断。你要的恰恰相反。把指令写明确停下来问。慢一点不花钱在你的发件箱里出错才花钱。第 3 部分只给一把钥匙别给整串钥匙集成越多Bot 越能干但每一次误解的爆炸半径也越大。一个做竞品监测的 Bot不需要账单、客户消息、生产数据库以及你所有的文件。只连接这份工作需要的。等某个真正被卡住的任务证明了确有必要再追加访问权限而不是因为“以后可能有用”就提前给。划线依据是“可逆性”不是“重要性”。有用的权限策略不取决于一个任务感觉上有多重大而取决于这个动作能否被收回。无需请示即可完成搜索、阅读、总结、分类、比较、整理、起草、暂存、模拟。在已批准的系统内允许编辑内部文档、更新内部记录、创建交付物、移动已批准的文件、运行已经测试过的例程。始终必须先问发送、发布、购买、删除、覆盖、更改权限、对外联系任何人、修改生产环境、转移资金、接受条款。注意“给 40 个潜在客户起草外联内容”属于第一类而“把它发出去”属于第三类。这个划分就是整个设计的核心。把安全的 90% 做完。一个 Bot 因为第九步需要审批就停在 10% 处这不是谨慎这是礼貌地无用。一次好的运行以“所有可逆的事都做完、所有不可逆的事都暂存并描述清楚”结束调研了 42 个账号。排出前 10 名。起草了 10 条消息。核实了联系方式。等待批准发送这批外联。已发送消息0 条。这才是既能省时间、又不消耗你声誉的自主性。“共享的电脑”不是一排各自独立的工位。这是大多数人会搞错的一个细节值得直说。同一个账号下的多个 Bot 共享一个环境文件、浏览器会话和登录状态。这正是它们之间交接如此容易的原因也意味着不同的 Bot 名字只是视觉上的边界不是安全边界。如果那台共享的电脑上存在某个登录就把它视为该账号下每个 Bot 都能用。一条写着“不要打开财务”的指令只能引导行为无法强制执行任何东西。如果两个岗位确实需要不同的信任级别那就把底层的账号或环境分开。不要把一条礼貌的指令误当成一道控制。而当 Bot 撞上登录墙时交给它会话永远不要给密码。它暂停运行你在那个会话里完成认证它从同一个状态继续。聊天是协调的界面不是存放密钥的地方。第 4 部分试用期是三次运行一个 Bot 成功了一次。很好。那只证明在状态好的日子里简单情况能跑通。让它再跑一次然后再跑一次。一次干净运行只是事件可靠是一种模式而模式至少需要三个点。运行 1观察。全程盯着。记下每一条被误读的指令、每一处丢失的上下文、每一个重复的动作、每一次奇怪的工具选择以及每一个它靠猜而不是靠问的时刻。运行 2修正。给它一个不同但可比的任务。不要手动提醒它昨天的错误。你测的不是它能否照着一句提醒去做而是你针对岗位、完成定义或权限所做的修复是否真的站得住。运行 3放行。让它不被打扰地工作。只在需要审批、遇到真正的模糊或触及重试上限时才介入。然后衡量五件事完成率、你介入了几次、它需要几轮审查、到被接受的结果所需的时间以及每个被接受结果的成本。修规则而不是修产物。当报告带着错误回来时最诱人的做法是去修那份报告。十分钟搞定。这么做的结果是下周同样的失败会再次出现因为系统里什么都没变。你不是在管理一名员工你是替它干了活却还留着它的头衔。另一条回路是找出失败的那一步修好允许它发生的规则、例程或交接再跑一次确认这个失败已经消失。慢一次之后永远不再犯。给循环设边界。“一直干到做完为止”听起来很合理其实是把一张无限预算绑在一个未定义的结果上。每一个反复运行的岗位周围都需要五样东西成功的含义是什么、成功如何被核对、究竟哪里失败了、允许尝试几次以及尝试次数用尽后会发生什么。一个可行的默认值工具临时故障重试两次输出格式错误修复一次证据冲突时停下并询问三轮修正都失败后升级触及成本上限时直接停止。一个知道自己何时该停的 Bot远比一个永不放弃的 Bot 更容易被信任。第 5 部分晋升阶梯自主性不是一个开关而是一个等级而等级是靠挣来的。0 级观察。Bot 观察工作流不做任何改动。1 级准备。它做调研、起草、分类并暂存可逆的工作。2 级带审批执行。它走完整条路径并在任何有后果的动作之前暂停。3 级按计划或触发器运行。它无需提示即可启动带着结果和一份回执回来。4 级协调。它把工作路由给其他 Bot只在需要判断或身份时才把你拉进来。晋升不是一种“演示效果如何”的感觉而是一道门槛连续五次干净运行。每一次核对都通过。零未了结的副作用。至少测试过一次回滚。审批策略经过测试——也就是说确实有东西被暂存下来而你亲眼看到了。这道阶梯是双向的而这正是几乎所有人都会跳过的一点。如果产出质量下降把它降一级。如果它底下的某个集成变了把它降一级。如果你连续两周都在手动修正把它降一级。自主性是一种运行时特权不是 Bot 因为在八月让你惊艳过、就永远保留的性格特质。第 6 部分每周绩效复盘常开型自动化不会大声失败它会悄悄退化。接口会变。凭证会过期。某个来源被挪到了登录墙后面。你的优先级会变。而那条例程一直在跑产出的东西技术上按时、却越来越没有价值。给每一个反复运行的岗位一份每周回执例程竞品扫描。运行5 次。通过4 次。人工修复1 次。平均运行时长14 分钟。反复出现的故障有一个来源需要重新认证。状态保留。然后亲自抽查一份产物。Bot 可以总结自己的历史但它不该是这段历史的唯一裁判。并就每条例程问三个让人不舒服的问题它在该运行的时候运行了吗产出是真的正确还是仅仅“存在”如果它明天消失我会注意到吗如果第三个问题的答案是否那就删掉它。自动化组合不是奖杯陈列架。目标是移除工作而不是累积一堆在跑的流程。什么时候招第二个 Bot多 Bot 的配置看起来很唬人于是人们在第一天就建十个主管、研究员、战略家、写手、开发者、设计师、审阅者、操作员、分析师、营销。他们实际造出来的是十个让上下文丢失的地方。等真正的瓶颈出现时再招第二个 Bot并沿着瓶颈真正所在的那条线来切分。当共享上下文开始变得嘈杂时把研究与写作分开。当自我审阅开始走过场时把核对与构建分开。当权限开始分化时把运营与分析分开。真要招的时候从一个协调者加三个专家起步而不是一个部门。一个入口、一个决定接下来跑什么的地方以及一道在所有东西离开“大楼”之前的人类关卡。而且交接的是“工作”不是“对话记录”。偷懒的交接会把整段对话复制给下一个 Bot下一个又再复制一遍直到每个 agent 都在读已经作废的想法和被取代的修正。一份紧凑的交接承载的是目标、产物、已经做出的决定、约束、待解的问题以及下一道关卡。产物承载细节交接承载状态对话线程承载讨论。硬要让一个上下文窗口同时充当这三者就是多 Bot 系统变得又慢又自信地出错的原因。第一份招聘出错的五种方式通才。一个 Bot 什么都管它的记忆里塞满了互不相关的偏好任何一次失败都无法归因到具体某处。没有“完成”的定义。它停在“看起来差不多”就收手而你以为的是“完整”。双方都没有撒谎。把“最佳判断”当作默认。没人写下“停下并询问”这条规则于是每一处模糊都被悄悄解决你三周后才发现。建造者同时是检查者。产出这份工作时所用的同一套假设一路存活到了审阅环节而自信被误当成了证据。把第一次成功自动化。演示跑通了于是它被放上了计划表。现实中的灾难不是某个被禁止的动作而是一个被允许的动作被重复了四百次只因上游有东西变了而没有任何人在盯着。你实际在建的是什么Grok 4.6 提供推理能力。持续运行的计算机给了它一个工作的地方。工具让它能行动。这份清单上其他的一切都是管理Bot 负责什么、“完成”意味着什么、它被允许碰什么、它不确定时怎么办、它有几次机会、谁来核对结果以及哪些决定始终留给你。这是人们会跳过的那部分也是唯一决定这个 Bot 是一个队友、还是一个“有名字的负债”的部分。大多数人会在接下来六个月里追问 Grok 是不是比别的模型更聪明。而真正能从这件事里做出成果的人会问一个管理问题这个 Bot 挣得了在我不在场时做哪些事的权利从一个枯燥的岗位开始。写下角色。用文字跑一遍试用。跑三次然后转正。周五复盘。然后再招第二个。附言P.S.如果你只想从这篇文章里带走一件事那就是——在第一次运行之前先写下“不确定时该怎么办”这句话。它只有一句不花任何成本却能挡掉那一整类、否则你会在几周之后、在自己的发件箱里才发现的失败。