企业官网建设流程全解析

原文：https://x.com/distortgeekin/status/2105275395901726845?s=46

中文译文

没有人会第一天就把公司银行卡交给新员工，说一句“帮我打理生意”，就算完成了招聘。

而这，几乎正是大多数人即将招聘自己的第一个 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 系统变得又慢又自信地出错的原因。

第一份招聘出错的五种方式

1. 通才。一个 Bot 什么都管，它的记忆里塞满了互不相关的偏好，任何一次失败都无法归因到具体某处。
2. 没有“完成”的定义。它停在“看起来差不多”就收手，而你以为的是“完整”。双方都没有撒谎。
3. 把“最佳判断”当作默认。没人写下“停下并询问”这条规则，于是每一处模糊都被悄悄解决，你三周后才发现。
4. 建造者同时是检查者。产出这份工作时所用的同一套假设，一路存活到了审阅环节，而自信被误当成了证据。
5. 把第一次成功自动化。演示跑通了，于是它被放上了计划表。现实中的灾难不是某个被禁止的动作，而是一个被允许的动作被重复了四百次，只因上游有东西变了，而没有任何人在盯着。

你实际在建的是什么

Grok 4.6 提供推理能力。持续运行的计算机给了它一个工作的地方。工具让它能行动。

这份清单上其他的一切都是管理：Bot 负责什么、“完成”意味着什么、它被允许碰什么、它不确定时怎么办、它有几次机会、谁来核对结果，以及哪些决定始终留给你。

这是人们会跳过的那部分，也是唯一决定这个 Bot 是一个队友、还是一个“有名字的负债”的部分。

大多数人会在接下来六个月里，追问 Grok 是不是比别的模型更聪明。

而真正能从这件事里做出成果的人，会问一个管理问题：这个 Bot 挣得了在我不在场时做哪些事的权利？

从一个枯燥的岗位开始。写下角色。用文字跑一遍试用。跑三次，然后转正。周五复盘。

然后再招第二个。

附言（P.S.）：如果你只想从这篇文章里带走一件事，那就是——在第一次运行之前，先写下“不确定时该怎么办”这句话。它只有一句，不花任何成本，却能挡掉那一整类、否则你会在几周之后、在自己的发件箱里才发现的失败。