# Grok Bots，AI 原生组织的全程业务队友

数智北极 · 深度观察 / 2026 年 9 月 · 结构修订版

**如果 AI 已经能执行工作，为什么一家公司的每一次交接，仍然要靠人亲手推动？**

过去一个月，我一直带着这个问题做一件事：基于 AI 原生企业的理念，使用 SpaceXAI 的 Grok Bot，为数智北极搭建自己的本地 AI 原生组织。我尝试给 Bots 安排岗位、准备知识、设计技能与例程，让它们开始承接一段持续的工作，而不只是回答下一条提示词。这里的“本地组织”指我自己的组织实践与资料体系，不意味着 Grok 模型已经部署在本地。[35][38]

因此，当 Grok Bot Galaxy 的三天活动进行到第二天时，我的感受有些复杂：**现场演示给我的冲击，并没有这一个月亲手实践来得深。**真正让我在意的，是它把一个我正在尝试的问题摆到了公开现场——如果从零开始创建一家公司，AI 能否从第一天起就成为组织的成员，沿着业务链持续接棒？[38]

我把这样的成员称为“全程业务队友”。它们的价值不只在于完成一个动作，而在于按照角色与职责，理解目标、维护上下文、组织执行、交接成果，并在条件允许时继续推进下一步。有些角色更像业务管理者：不亲自包办所有动作，而是调度专业 Agent 和工具，围绕结果组织工作。这是我对产品机制与组织实践的综合判断，不是对当前自治能力的无条件保证。[5–7][38]

我希望人类员工逐步退出逐项催办、搬运上下文和重复执行的位置。在边界清楚、授权充分、结果可验收的工作链里，人不必成为每个执行步骤的必经节点；人的重心转向设计组织、决定目标、分配权力、判断异常与承担责任。**这才是我所说的“组织内生智能”与“组织自主智能”：智能开始进入组织的日常分工和运行，而不仅附着在某个员工的工具栏上。**它是本文提出的方向，尚不是“无人参与也能经营一切”的既成事实。[38]

本文是数智北极基于上述亲手实践，结合 Grok Bot 官方材料、Galaxy 三天已取得的定点回放证据及组织研究所做的一次阶段性总结。Day 3 的材料不是完整观看，而是带回放时间码的有限画面：营销运营的 SAP 匹配图、售后开场的能力投影片、营销计划时段的 Data Scientist / Marketplace / 自动化链线索，以及尾段的用户曲线与游戏/工程蓝图。我们要讨论的，是人与 AI、AI 与 AI 的协作关系，怎样从一次任务的合作走向一支队伍的持续工作。

> 阅读范围：主文纳入 Day 1–Day 3 的官方议程、官方产品说明和回放定点画面；回放时间码与采集时间分别记录，不能替代完整转录。Day 3 已纳入营销运营、售后/客户成功、营销计划时段和尾段成果线索，但未把计划时段自动写成已完成专题。作者实践陈述、产品说明、定点画面、参与者复原摘要与本文设计分别标识，均不等于完整观看或独立业务验证。

> 回放与字幕更新（2026-09-27）：x.ai/galaxy 列出的 10 个 YouTube 分场回放目前均可导出英文自动生成字幕。[40–49] 本文据此补入带时间码的中文分段笔记；自动字幕未经官方审校，可能误识别产品名与人名，不能当作官方逐字稿。原始导出只记录 SHA-256，不公开整份文本；O19–O35 的原图、时间码、canonical locator 与哈希继续独立保留。

> 官方指南更新（2026-09-29）：xAI 指南目录现列出 9 月 24 日发布的 Marketing、Post-Sales、SDRs、Work、Recruiting 与 Legal Ops 页面。[51–56] 上一版把 Marketing 页日期记录为 9 月 18 日，本轮按当前页首更正为 9 月 24 日。本文把 Marketing、Post-Sales 与 SDRs 指南同相应 Galaxy 分场交叉阅读；Work、Recruiting 与 Legal Ops 只作为跨职能岗位与控制边界的补充，不倒填为活动现场内容，也不当作源系统执行或业务效果证据。

## 01 三个人、三天：为什么值得把一家公司的创建过程搬到镜头前

“三个人，能否在三天内建立一家公司？”这是 Galaxy 官方直播页提出的挑战。Matt Palmer、Lauren Tan 与 Roshan Sadanani 计划在 9 月 15—17 日，从一个想法和空白起步，推进商业计划、功能决策与真实工程工作，并穿插不同部门的工作流演示。[18]

这使活动有了一个值得关注的尺度：**观察对象从一次任务，扩大到一家公司的工作链。**写出代码之后，谁定义产品、寻找客户、回应需求、维护服务？一个环节的产出，能否成为下一个角色可直接使用的输入？在本文看来，组织的价值恰恰藏在这些连接处。

三天的议程也对应这种扩展。第一天围绕入门、工程、产品经理与创始人；第二天进入售前、销售、SDR 与支持；第三天安排营销运营、售后、营销和最终展示。回放抽查现在为这条组织叙事补上了有限的现场证据：营销运营画面出现 SAP matches by phase（107 matches），售后开场由姓名条与官方 Post-Sales 讲者相互印证，营销计划时段出现 Data Scientist Bot、Projects Manager 和书签驱动的 demo 链，尾段出现累计用户曲线与 CORE LOOP / ENG FACTORY 蓝图。[17][18][39] 这些画面让“业务运营”不再只是议程想象，但仍不能升级为完整场次、源码交付或业务成效。

放回产品历程，这个时点也有意义。8 月 11 日公测之后，Grok Bot 经历媒体报道、订阅扩围、深圳交流及企业开放，随后在旧金山与线上开展 Galaxy。[20–24] 传播和试用只能说明关注开始积累，不能替代商业成效证据。[21][24][26]

对我而言，Galaxy 值得关注，是因为它将“AI 原生公司如何被组织起来”变成一次公开的连续构建实验：产品承诺开始接受过程的检视。Day 3 的画面把观察对象从“能不能把产品做出来”推进到“能不能把产品运营、支持、增长和工程治理接起来”；但“验证”仍是待完成的工作，不能由一段成功画面提前宣布。[17][18][38][39]

本文不把它写成已经证实的“AI 领域首场”，也不把三天直播当成公司长期经营成功的证明。真正值得追问的是：**人离开屏幕后，事情由谁接住；条件改变后，工作怎样继续；最后凭什么算完成？**

![背景侧栏：从公测到 Galaxy 的产品历程；关注、试用与厂商采用披露不等于商业成效](figures/00-product-journey.png)

## 02 2026 的组织问题：能力已经出现，组织尚未吸收

销售用 AI 写邮件、财务用 AI 分析表格、工程师用 AI 编码，个人能力都增强了。但如果需求仍靠口头转述，方案仍没有统一版本，付款状态仍靠聊天截图确认，那么企业只是加速了旧流程中的几个节点。跨节点的等待和责任空白依然存在。

### 从个人熟练度，转向组织吸收能力

微软于 2026 年 5 月 5 日发布的 Work Trend Index，结合匿名化 Microsoft 365 使用信号与 10 个市场、20,000 名工作中使用 AI 者的调查。其模型中，组织因素与个人因素对自报 AI 影响的相对重要性约为 67% 和 32%。这提示领导者关注文化、经理支持与人才实践；**这些是统计关联，不是组织重构导致业绩提升的因果比例**，样本也不代表全部劳动者。[2]

报告公开页区分委派、协作、询问、探索四种方式，这是定性框架，并非自治成熟度排名。本文据此提出：企业应按任务风险、输入完备性和验收能力选择合作方式，保留人的方向、判断与结果责任。[2]

这里有一个容易忽略的组织问题：员工节省下来的时间，是否允许重新用于客户洞察和流程改进？还是马上被更多重复报告填满？如果公司依旧奖励消息数量、在线时长和文档页数，Agent 很可能只是把旧有忙碌放大。

### 工作流重构、分级自治、结果责任

麦肯锡 2026 年 9 月 14 日的《Stacking the Odds》指出，企业扩张 Agent 的速度可能超过工作重设计的速度；其蓝图强调明确业务问题、权威数据、决策权、升级路径与价值门。这是咨询实践提炼，不能把案例工期改善直接套到另一家企业。[28]

BCG 的讨论把重心放在端到端结果与运营模式重构：人定义目标和约束，工作路径可以在边界内调整。官网日期为 4 月 23 日；评审指出的 PDF 版本日期另记为 4 月 16 日，尚待该原件补核。本文借用组织视角，不迁移其案例 ROI。[3]

PwC Australia 4 月 1 日的报告则强调，将 AI 嵌入核心运营、决策和基础设施，同时保留人的领导作用与责任。这是方向性框架，提醒我们把治理放入工作设计，而不是等系统上线后再加一张合规表。[29]

将这些研究与麦肯锡此前的组织框架放在一起，我们形成一个**本文的工作定义**：AI 原生组织，是把人、Agent 与业务系统共同参与视为正常条件，围绕可验收的结果，重新设计职责、上下文、决策权、工作路径和学习机制的组织。[1–3][28][29]

这一概念尚不构成统一认证。本文也不把 Frontier Firm、AI-first、agentic organization 当成严格同义词。真正可检验的是：一条工作链改变了什么，谁能解释它，谁能叫停它，客户是否获得了更好的结果。

### “队友”有实验依据，也有明确边界

2026 年 6 月 12 日在线发表于《Organization Science》的《The Cybernetic Teammate》，报告了 791 名 P&G 专业人员参与的随机现场实验。在特定产品创新任务中，个人加 AI 的表现达到无 AI 双人组水平；AI 帮助跨越专业视角差异。正式论文进一步指出，提升主要来自创意生成质量，人类在评估和选择中仍有价值。[4]

这是“人机协作可以改变团队分工”的有力证据，却不是无人经营公司的证据，更不是 Grok Bot 的产品评测。一天的创新工作坊没有检验数月运营、权限恢复、合同履行或财务闭环。

它给我们的启发是：可以重新分配创造与执行，但不能因为生成能力增强，就取消评估、判断与责任。

![图1：从个人增强、任务委派到结果负责；三个设计层次可以并存](figures/01-paradigm.png)

## 03 Grok Bot 是什么：持久岗位、例程、工具与编队

Grok Bot 101 描述了持久云端工作环境：桌面、文件、终端和应用可被用于执行任务；聊天、例程及其他 Bot 都能触发工作。产品设计文还区分账号层的工具与 Skills，以及具体 Bot 的记忆和例程。[5][25]

**它的组织价值，在于把“任务”放进一个持续存在的承接关系。**客户资料不会因为一轮聊天结束就失去归属，未决问题也可以在下次触发时被重新接起。但这只是产品机制提供的可能性；企业仍需建立自己的权威记录、授权与验收。

### 从基础设施到业务队友：四个层次不能混在一起

在本文的架构语言中，AI Infra 是计算、存储、网络以及云端与本地资源；Harness 是让 Agent 能持续工作的运行支撑，包括工具调用、工作环境、记忆、例程和执行约束；专业 Agent 承担具体执行；业务队友则围绕长期岗位和交付结果组织这些能力。Grok Bot 的官方材料明确描述持久云端环境，工程指南描述调用编码 Agent；本文将相关运行机制统称为“Grok Bot 的 Harness”，不把它当作一个另行发布的官方产品名，也不据此宣称已经实现统一的云地混合调度。[5][7][25]

这些层次仍需共同存在。本文所说的“演进”，是企业采用 AI 的重心开始从搭上下文、搭运行框架和开发 Agent，进一步转向设计岗位、编队与结果责任；不是前面的技术工作已经消失，也不是给 Agent 起一个职位名就完成了组织转型。本文沿用 Grok Bots 表示多 Bot 编队，官方产品主要使用单数 Grok Bot。

### 持久岗位：记住责任，而不仅是历史消息

岗位应回答：为什么存在、长期维护什么、接受谁的委派、交付给谁、遇到什么情况停下。提示词中的角色名只表达意图，不能自动产生隔离身份或业务权限。

官方多团队指南给出实验性项目经理 Bot、项目频道、成员名单和台账的做法。[6] 本文把它概括为四个设计要点：项目有边界、工作有归属、交接有状态、阻塞有去处。这是方法提炼，不是平台已经保证的企业组织模型。

### 稳定角色与临时执行单元分开

官方工程指南描述专业 Bot 管理编码 Agent、检查 PR 与 CI 的实践。[7] 它让编队拥有两种不同节奏：长期角色维护业务上下文；按需启动的执行单元处理一段代码、一份分析或一个验证任务。

迁移到企业，工程 PR 可以换成方案版本、ERP 单号或客户验收记录。可迁移的是交接思路，不是把所有业务都改造成代码仓库，也不是让统筹 Bot 根据执行者一句“完成了”自动关单。

### 例程：让工作重新被接起

GTM 与支持指南展示了客户准备、后续跟进和重复支持任务。[8][9] 例程让工作有节奏，但企业必须进一步定义触发依据、重复事件、超时处理和升级责任。“每天运行”不能回答“昨天已经发过，今天还要不要再发”。

因此，持续执行需要两种记忆：Bot 用于理解任务的工作记忆，以及外部可检查的业务状态。前者可以总结，后者必须保留已批准事实、版本和变更记录。

### 六款产品，回到同一组企业问题

以下沿用 2026-09-17 已归档的公开页面核验；不是同环境测试，也不把未确认事项当成产品缺陷。[10–14][19][24][27]

| 产品 | 已确认的公开表达 | 待验证事项 | 证据日期 |
| --- | --- | --- | --- |
| Grok Bot | 云端电脑、Bot 协作、例程及企业控制 | 角色隔离、恢复、跨系统验收 | 2026-09-17 |
| ChatGPT Work | 应用、文件、浏览器与工作交付物，重复任务 | 长期责任、交接及业务状态接续 | 2026-09-17 |
| Claude Cowork | 云端持续工作、定时、并行任务 | 长周期恢复、证据及组织治理 | 2026-09-17 |
| WorkBuddy | 多专家、多模型、IM、MCP、Skills | 跨专家验收、企业授权与故障恢复 | 2026-09-17 |
| 豆包工作 | 目标拆解、调研、内容、数据及应用搭建 | 仅官方摘要与入口证据；企业控制待核 | 2026-09-17 |
| 千问办公 QwenWork | 桌面、云端协同方向与可编辑成果 | 已交付与计划集成的边界 | 发布08-03；核验09-17 |

Grok Bot 的观察价值，是其公开指南和活动集中展示了多个持久角色怎样共同做事。它没有因此获得“唯一能持续工作”的头衔。企业应拿同一份脱敏任务、相同预算和验收条件，比较合格交付率、审查负担及恢复能力。

### 认识这支 Bots 编队：头像让角色可辨认，交接让责任可追踪

KF01 / 00:34:10 可见 Sales Outbound 的粉色团块头像、左栏不同颜色的角色，以及浅暖色聊天、Profile 和例程界面；KF04 / 00:52:39 可见 Email Ethan 的蓝色圆形头像。它们把同事式消息、岗位身份与工作状态放在一起。原图足以辨认轮廓和配色，却不足以确认官方默认头像全套、定制规则或模糊的五官细节。因此，我们保留原像素裁切，不补画，也不把“截图中使用的头像”直接叫作“官方默认素材库”。[35]

![界面证据：KF01 / 00:34:10 原像素裁切；来源为参与者保存的官方视频画面，原件和裁切SHA-256见证据索引](../evidence/grok-bots-galaxy-2026-09-17/crops/KF01-avatar-interface.png)

下面是一套**数智北极原创设计转译，非官方头像**。统一圆形 head 与角色色标识谁在工作；状态点必须配“执行中、待审稿、待补依据”等文字。所有状态都是文章设计示意，不是产品实时状态；Human Approver 是最终负责的人，不是另一个 Bot。[37]

![认识这支Bots编队：七种原创非官方角色徽章与示意状态](avatar-contact-sheet.png)

Chief Bot 承接统筹，Research 管理来源，Sales/SDR 维护客户上下文，Support 处理知识与工单，Engineering 回传工程证据，Creative/Remotion 提交创意与 proof cut，Human Approver 掌握批准与停止权。它们是本文便于追踪故事的角色标签，不是厂商承诺的一套预装编队；制造业里的订单、交付等专岗仍应按真实业务定义。头像帮助记住责任，不能替代身份认证或访问授权。[37]

9 月 24 日的《Grok Bot for Work》把这种编队压缩为一个更容易理解的结构：Inbox Manager、Calendar EA 与 Intel Scout 保持专业分工，由 Bot Boss 充当单一入口；示例岗位规则使用“只读”“草稿后确认”“启用前保持停用”等约束。[54] 这是官方作者给出的工作方法，不是 Galaxy 演示证据，更不是权限机制已被本站验证。它真正强化的是一个组织原则：**统一入口可以减少人的协调负担，但不能抹平专业岗位、动作权限和最终责任。**

## 04 Galaxy 现场：从岗位设置到业务运营，回到原始画面

> 本章使用参与者上传的两份 Day 1 文档、14 张关键帧及实践回执。本轮已读取文档，并重点检查 KF01、KF03–06、KF10–11；19项文件与清单哈希一致，只证明包内一致性。笔记中的连续过程与单帧可见内容分开陈述；未重新运行参与者本地子站。[35]

### Profile 是岗位契约

参与者记录将 **00:34:03–00:34:16** 定位到 Sales Outbound 的 Profile；本轮复核 **KF01 / 00:34:10**，可见岗位、输出、数据源、例程和登录状态。Salesforce 尚未登录，而其他工具已有登录信息；一个岗位的执行条件，在上岗时就已经出现差异。[35]

这比给 Bot 起一个“销售专家”的名字多走了一步。长期工作需要可解释的职责与节奏，还需要知道数据来自哪里、账号是否具备执行条件。它支持岗位契约的设计思路，不能证明线索已经转化、邮件已经送达，或销售闭环已经完成。

企业复用时，可以把 Profile 分成意图、依赖和权限三部分：为什么做、依据什么做、哪些动作被允许。三者互相联系，但不能互相替代。

### Bot-to-Bot 交接，必须带上下文

参与者连续笔记将 **00:56:30–00:59:15** 记为 Email Ethan 向 Data Dan 索取咖啡统计的过程。复核后需要区分：**KF05 / 00:57:00** 实际显示 Slide Sonya 的例程与协作信息，不能独立证明该交接；**KF06 / 01:02:47** 则明确显示 Email Ethan 的邮件草稿和 Send email 按钮。现有材料分别支持过程笔记与草稿画面，不支持邮件已经送达。[35]

这个片段把“多 Agent 协作”变成了具体问题：统计数据来自哪次调查？统计口径是什么？邮件写给谁？哪些不确定性应一并传递？如果只传一个数字，接收方很容易把一个局部样本说成客户总体偏好。

本文的组织推导是：交接对象应包含任务、来源、版本、限制与接受条件。增加 Bot 数量不会自动降低沟通成本，合格交接才可能做到。

### 审批，是执行路径中的一个正式状态

**KF03 / 00:48:04** 显示 Data Dan 的 Google Form 任务与 **Auto-review Paused This Action** 记录；旁侧还可见单次允许的状态。本轮可以确认暂停提示存在，但不能从这一帧还原全部审批顺序或原因。参与者笔记另描述后续 QR Code 工作，不能把不同阶段的动作合并成一个已验收结果。[35]

这条记录支持“动作可能被暂停”的有限观察。它不能证明全部高风险动作均已治理，更不能说明自动审查等同业务审批。企业要继续追问：谁有权恢复？批准针对哪个具体动作和版本？恢复后是否只执行一次？

对业务团队而言，“待批准”应有可见负责人和待补材料。没有这些信息，安全暂停就可能变成无人认领的长期阻塞。

### 完成，需要用户路径与验收证据

参与者笔记记录了 venue-finder 对 PR、截图、视频以及 **Search → Pin → Call** 用户路径的要求。**KF10 / 05:10:00** 可见先处理 proof 再合并的对话及 Bot 自报 PR 状态；**KF11 / 05:32:00** 可见 OSM venue finder 原型的 草稿 PR #14 差异页。另一个容易被标题掩盖的片段是 **KF09 / 04:45:00**：画面显示仓库授权缺失、push 404，以及 Cursor 无法访问仓库。Bot 自报本地构建，不代表代码已经推送。上述图片支持工程过程与证据要求的观察，不能替代仓库、CI和真实用户路径测试。[35]

本研究另有独立归档：Day 1 **05:44:57** 可见范围变化、Overpass timeout 和待完成截图，**05:59:55** 可见 “Agents as colleagues”。这是定点画面，不是讲者发言转录。[16]

两类材料相互提示一个验收原则：生成代码、打开页面、走通关键路径、满足客户要求，是不同层次。Agent 的完成报告必须能落到相应证据；缺少截图只是显性的缺口，更深的缺口可能是需求版本已经变化，而测试仍在验证旧目标。

### Day 3：业务运营被放进同一条证据链

Day 3 的新增材料改变了本文的阅读范围，但没有改变证据纪律。营销运营定点画面（O35，回放 **01:59:03 / 07:58:22**）显示 “Signed-in SAP matches by phase”、107 matches 以及 result / battle / shop 分段；它证明图表曾经呈现，不证明 SAP 数据源、匹配规则、指标口径或营销结果。相邻的 Cupcake Launch KPI 图（O19）同样只能作为画面证据。[39]

会后又出现了一条可以追溯、但身份不同的材料。Hiten Shah 在 LinkedIn 以第一人称称自己观看了 Matthew Silberman 的 Marketing Operations 展示，并将工作链概括为：一个 Bot 观察多个收件箱、判断真正需要处理的事项；另一个把事项变成任务；专业 Bot 再接棒执行。帖子把它称为 **self-completing to-do list**，并转述一个内部 lead-review app 从想法到实现用了两周、实际构建约 10 小时，推出后 lead-review rate 达到新高。[50] 这段材料让“注意力分流 → 任务化 → 专业接棒”的组织机制更具体，却仍是参与者摘要和对讲者说法的二手转述，不是字幕、代码、工时记录、指标口径或独立效果验证。

售后/客户成功片段（O21）先出现 **Blake Schuller** 姓名条，随后投影片列出 Easy as iMessage、Always-on agents、Uses your tools like you、Finishes the work、Shareable Templates。姓名条与官方 Post-Sales 议程能够相互印证“专题开场”的有限判断；投影片属于产品说明，不等于客户工单已被处理、健康信号已更新或客户已收到回复。[39]

9 月 24 日发布的 Post-Sales 指南补足了“岗位怎样组织”的官方方法说明：Gus 作为 Chief of Staff，把账户专员、写作、知识与观察角色收拢到一个入口；日程或事件触发的例程用于准备会议、追踪未完成承诺、监测风险和更新看板；人继续负责客户关系、账户策略和最终发送。[52] 这与分场字幕中的客户信号、会前/会后材料和人工编辑草稿相互印证，但仍不是同一次现场操作的逐字还原，也没有客户账户、健康模型、CRM 写入或消息送达可供独立核验。

第二天的 SDR 场次也出现了同类边界。全日回放只给出 prospecting CSV 定点画面，分场机器字幕补出账户研究和草稿队列；新发布的 SDR 指南进一步把工作拆成研究、找人、起草、分流和最终确认，并用 **CLEAR / FLAG** 区分可进入未发送队列的记录与必须由人判断的边缘情况。[45][53] 指南明确不自动发送。由此可以讨论“研究包如何交给运营 Bot、异常如何停下”，却不能证明名单取得合法、联系人同意、邮件已发出或会议已预约；本站也没有执行外联。

营销计划时段的 O25–O27 把组织设计的另一面露出来：What we learned 投影片强调岗位范围、工具/访问/上下文与持续反馈；Data Scientist Bot 汇总游戏运营信号；Marketplace 的 Projects Manager 以 Notion 项目行、频道和专业 Bot 分工；屏幕还展示了“书签 → Cursor Agent → 验证 → Cloudflare 预览 → 链接回传”的工作链。这些是参与者展示的机制线索，不是本站执行日志，也没有提交 SHA、源数据、计算公式、预览回执或营销转化证据。[39]

尾段 O28–O29 出现累计 X 用户曲线（当前值 1,902）以及 CORE LOOP / ENG FACTORY 蓝图。它们使“结果指标”和“工程治理”同时进入同一帧观察：产品循环、修复 PR、Play test、Review / APPROVE 被画在一起。但没有指标字典、去重规则、PR、测试日志、人工批准或部署回执，本文将其称为成果复盘线索，而不是完整 Final Showcase 或上线证明。[39]

因此，Day 3 对组织设计的真正贡献不是证明“营销 Bot 已经完成增长”，而是让北极星蓝图必须同时容纳四类状态：运营指标待核、客户工作待批、创意/工程交接运行中、尾段成果待验收。角色可以接棒，证据必须跟上；任何一类缺口都应回到阻塞和人工责任人。

分场字幕使四类状态的来路更清楚。Marketing Operations 从多个收件箱识别事项，由统筹角色形成任务，再交给 territory 或工程 Bot；视频在 lead-review 应用段明确使用 fake data，随后出现的两周、约十小时和审核率变化仍只是讲者陈述。[47] Post Sales 以客户信号、会前/会后材料和账户专员组织行动草稿；Marketing 则把研究、定位、落地页、广告变体、分析和项目管理串起来，并明确没有在现场真正 launch。[48][49] 因此，最值得保留的不是“全自动增长”的故事，而是**研究—任务—执行—批准—回写**每一步都需要不同证据。

9 月 24 日发布的官方 Marketing 指南把这条链拆成六个长期岗位：Market Researcher 读取产品页与竞品，Product Marketer 在 Google Docs 形成定位与素材，Performance Marketer 只把已批准文案装入 Google Ads campaign shell，Website Ops 借助 Cursor 写页面并开 GitHub PR，Marketing Analyst 读取实验数据但不直接改 live ad、bid 或 budget，Project Manager 则承担跨线程交接。[51] 这与分场自动字幕中的岗位结构一致，却更清楚地画出治理边界：模板不携带登录和历史，权限应从小开始，花钱与对外发布仍由人批准。它仍是 Josh Kim 的官方作者方法和 X-Air 虚构案例，不是本站拿到的 Docs、Ads、PR、部署或转化回执。

## 05 从现场到组织设计：什么被展示，什么仍未被证明

要让一篇有故事性的文章保持可信，关键不是反复强调谨慎，而是让每个结论停在它的证据能够到达的位置。

| 证据层 | 本文实际材料 | 可以支持 | 不能支持 |
| --- | --- | --- | --- |
| 产品展示与说明 | 官方指南、产品页、会前议程 | 产品与作者宣称的机制、计划目标 | 实际效果、完整实施和普遍收益 |
| 画面观察与参与者摘要 | 本研究 Day 1–Day 3 回放时间码、定点抽查；另列参与者公开观看摘要 | 指定时刻可见内容；摘要作者实际报告了什么 | 完整转录、全部操作顺序、源系统成功或摘要中数字的独立真实性 |
| 本地复原 | 已取得14张关键帧、两份说明和实践JSON；本轮逐图检查全部14帧与包内哈希 | 图片实际可见内容、参与者记录的本地验证状态 | 本轮重新运行本地子站、官方认可、客户业务成功 |
| 业务验证 | 本文尚无客户业务系统及验收结果 | 当前只能列待验证项目 | 持续自治、真实收益、端到端成功 |

参与者将本地子站状态明确记为 **local-candidate、publication=not-executed**。[35] 这与本研究网站已经发布是两件不同的事：一个是其本地子站候选稿的状态，一个是本站与证据包的发布状态。实践 JSON 另记录了 X 文章的 published 回执，那又是第三个交付对象。它们不能相互替代。

![图2：产品说明、画面观察、本地复原与业务验证的四层证据](figures/02-evidence.png)

斯坦福数字经济实验室 2026 年 4 月 2 日发布的 Enterprise AI Playbook，研究了 51 个筛选后的成功部署案例。其方法与限制明确说明，访谈结果存在自报和成功样本选择偏差。它适合帮助我们思考组织准备、监督方式和错误可恢复性，不适合计算“企业采用 AI 的普遍成功率”。[30]

这一点也适用于 Galaxy：展示成功案例，是理解机制的入口；要判断自己的企业是否适合，仍需相同业务口径的基线、失败样本、审查成本与一段足够长的观察窗口。

**从演示到组织，不缺一个更响亮的结论，缺的是证据连续性。**每次推进都应知道前提是否仍然成立；每次交接都应保留接收方可以复核的材料；每次结束都应知道结果由谁接受。

## 06 一笔订单如何交给编队

![制造业交接示意：Sales/SDR → Chief Bot → Engineering → Human Approver；与角色条复用同一原创头像，非实际运行](avatars/handoff-order.png)

下面进入一个完整的设计演绎。**企业、客户、金额和任务均为虚构，输入应使用合成数据；它不是 Galaxy 演示，也不是已经完成的 Grok Bot 实验。**

假设一家工业设备企业“北辰制造”，正在推进客户“海岚工厂”的升级项目。拟议订单金额 120 万元，示例商务条件为 30% 预付款后安排发货。客户提出一项接口适配需求，同时希望提前交付。

销售最初想让 AI 做三件事：整理会议、写方案、准备报价。但总经理的问题更直接：“这笔业务，谁来盯到最后？”

“最后”不是报价发出去，也不是演示站点能打开。对这个示例，业务负责人把结果定义为：范围与条件已经批准，合同和订单版本一致，满足约定放行条件后交付，验收问题有记录，款项状态经过财务核对。每一项都必须有能够复查的证据。

### 先给编队一份共同的业务契约

项目启动时，人类负责人先明确四件事：结果、范围、权力、完成证据。然后才给 Bot 分配角色。

我们设计一位项目统筹 Bot 与五位专业队友。这个数量只是本场景的设计选择，不是 Grok Bot 的最优规模，也不是越多越好。

| 队友 | 长期负责的事情 | 交接时必须提供的证据 |
| --- | --- | --- |
| 项目统筹 Bot | 维护目标、依赖、状态与阻塞；请求人工决策 | 当前计划、风险、待批事项、来源索引 |
| 客户 Bot | 维护客户事实、需求变化与沟通准备 | 带来源的需求基线、确认记录、待澄清问题 |
| 方案 Bot | 把需求转成范围、假设与验收条件 | 方案版本、差异清单、适用与不适用范围 |
| 工程 Bot | 在隔离环境组织适配、测试和修复 | 代码版本、测试条件、结果、已知缺陷 |
| 交付 Bot | 对齐交付计划、准备度和客户验收 | 放行依据、交付清单、验收与遗留项 |
| 订单与回款 Bot | 对照批准条件核对订单与款项状态 | 系统单号、读取时间、差异与待财务确认事项 |

Bot 名称帮助我们理解职责，但名称本身不能创造系统权限。项目经理也不能替代销售经理、技术负责人或财务负责人的授权。实际工作中，一人可以兼任多个批准角色，独立复核要求则应按业务风险设计。

![图3：一个业务结果、人类责任人、六个 Bot 与共享证据底座](figures/03-crew.png)

### 第一幕：客户需求进入系统，先形成问题，而不是抢着形成答案

客户 Bot 收到合成会议纪要、产品目录与既有方案，提取出三个事实：需要接口适配、希望缩短交期、付款条款尚待确认。它为每个判断附上原始材料位置，把“客户明确说过”与“我们推测客户想要”分开。

若销售邮件与会议纪要发生冲突，它不选择更顺耳的版本，而是将差异提交负责人。项目统筹 Bot 把任务标记为“待澄清”，而非“方案生成中”。

这一幕的输出是一份可审核的需求基线，不是一封自动发送给客户的承诺。未经明确授权，队伍只准备对外沟通草稿。

失败条件也很具体：来源无法读取、产品目录过期、同一名词有两种解释，都会阻止需求进入已确认状态。这里的价值是减少错误假设向下游传播，而不是让系统更早显示绿色。

### 第二幕：方案与工程并行，但交期承诺仍需有人负责

方案 Bot 依据已确认需求形成范围、排除项、验收条件和待确认假设。工程 Bot 根据其中的接口要求，在隔离环境启动一个小型验证任务。

输入包括合成接口报文、目标版本与明确测试条件。执行 Agent 可以准备代码和报告；工程 Bot 检查产物是否对应同一需求版本，必要时追问失败原因。

假设验证遇到超时。它需要说明的是：哪个接口、什么输入、发生在什么环境、可复现到哪一步。若没有观察到真实返回，就不能用一份格式正确的 JSON 冒充接口已接通。

技术负责人据此决定调整范围、增加条件，或拒绝过早承诺。项目统筹 Bot 同步更新报价与交付风险，确保销售不会继续使用旧交期。

这一幕的关键，是**变化可以沿着依赖关系传播**。好的编队并不只是并行做事，还知道上游条件改变后，哪些已经做完的事情需要重新打开。

### 第三幕：订单不是聊天中的一个“好的”，而是系统中的受控状态

销售经理批准报价后，订单与回款 Bot 对照批准版本检查订单草稿。金额、币种、客户主体、产品范围和付款条件，都要能与相应来源对应。

假设客户接受 120 万元报价，30% 的示例预付款为 36 万元。Bot 可以检查算式和记录一致性，但它不能据此推断钱已到账。客户发来一张“付款成功”截图，也不能直接等同于公司财务确认。

此时，Bot 的输出应是一份待审核记录：批准条件是什么、系统显示什么、证据更新时间是什么、还缺谁的确认。财务在授权系统中核实后，才能更新相应业务状态。

创建或修改正式订单、释放信用冻结、接受特殊付款条件，都应通过获授权的业务入口完成。模型层面的“我认为可以”，不构成授权。

### 第四幕：交付可以准备，放行必须等待正确条件

交付 Bot 可以提前检查物料、文档、接口验证和人员安排。但它读取到“客户声称已付款”，不能自动推进到“发货条件已满足”。

在这个示例设计中，放行需要匹配三类证据：获批准的订单版本、相关付款状态的财务确认、交付准备度的负责人确认。如果其中一项过期、缺失或冲突，任务进入阻塞队列。

阻塞不是失败后的尴尬附注，而是一个正式状态。它应有原因、责任人、下一次检查时间和升级条件。这样，人不必反复追问“为什么还没动”，Bot 也不必为了显得积极而绕过条件。

### 第五幕：客户验收之后，队伍还要收尾

交付完成后，客户可能提出一个不影响使用的小缺陷，也可能拒绝一项关键验收。交付 Bot 应分别记录，不能把两者都归入“客户反馈已处理”。

工程 Bot 处理缺陷，方案 Bot 判断是否属于批准范围，订单与回款 Bot 继续对照合同中的款项节点，项目统筹 Bot 维护尚未关闭的事项。

直到指定责任人确认约定结果，项目才进入已验收状态。关单后再出现新问题，应生成关联的新任务或按规则重新打开旧任务，而不是悄悄改写已经验收的历史。

这个故事的终点不是一个 Bot 回复“全部搞定”。终点是任何授权同事打开项目，都能知道：完成了什么，依据是什么，还欠什么，谁对此负责。

![图4：从需求到验收与回款，每次交接携带状态、证据和批准](figures/04-value-stream.png)

## 07 北极星蓝图：围绕业务结果，建立可持续工作的组织

如果把 Grok Bots 与 Day 1–Day 3 放在一起看，AI 原生企业的北极星不该是一幅“每个部门配几个 Bot”的组织图。Day 3 把指标图、客户支持说明、增长/创意链和工程审批蓝图放到同一条观察线上，提醒我们北极星必须回答：**一个被授权的业务意图，怎样转为可执行工作；执行结果怎样回到权威系统；组织怎样根据证据决定继续、停止和学习。**

> 蓝图证据范围：本文同时使用 Day 2 O12–O15、Day 3 O19–O29/O35 的回放定点记录，以及 10 个官方分场视频的 YouTube 自动生成英文字幕。[36][39][40–49] 自动字幕只支持分段释义，不是官方审校逐字稿；蓝图仍是数智北极的目标设计，不是 xAI 发布的企业架构，也不表示已经实现。

[打开完整 HTML 北极星蓝图](../north-star.html)：可以逐层查看职责、接口、现有证据与待建能力，并切换制造业订单和客户支持两个设计场景。

![图6：AI 原生企业北极星架构；七层承接结果，控制与证据贯穿全程，属于本文目标设计](figures/06-north-star.png)

![客户支持恢复示意：Support → Research → Human Approver → Support；依据O14启发的目标设计，不是直播操作复原](avatars/handoff-support.png)

在第二条故事里，同一个 Support 头像先带回“知识缺失”的阻塞，再由 Research 准备可复核的来源；Human Approver 判断是否允许继续，最后 Support 执行获授权回复并取回回执。O14只支持知识缺失、等待批准和开始回复的可见片段；Research岗位、回执核验与完整恢复链是本文设计。Day 3 的 O21 又提醒我们，产品能力说明不能替代客户对象、健康信号和送达回执。相同头像让读者追踪接棒者，文字和证据决定接棒是否成立。[36][37][39]

### 新画面带来的三个架构提示

**管理角色与执行单元之间，需要明确交接。**Day 2 北京时间 05:28 的 O12 画面显示 Remotion Ads Bot 将任务交给 Cursor Cloud Agent，限定仓库主分支和 Remotion skills，并约定回传 proof cut；状态为 Running。它支持“委派关系已经可见”，不能支持代码已经提交或成片已经验收。[36]

**协作界面之外，还要检查源系统。**06:32 的 O13 画面中，Chief Bot 报告整理 Cupcake 的 Notion 看板并经 Slack 通知；专业 Bot 汇总 PR、CI、登录测试及人工检查项。这呈现了管理与专业角色的分工，但没有提供相应源系统回执，不能把自报完成当成独立核验。[36]

**知识缺失应成为明确阻塞。**07:28 的 O14 画面中，处理 Elena 的 T-56 工单时，Bot 因 Pass Sharing FAQ 缺失而停止客户回复；随后界面称知识恢复，仍等待明确批准，获重试指令才开始继续。没有最终回复、知识版本和送达回执，因此只能确认展示了门禁逻辑。[36]

**指标和成果也必须有证据契约。**Day 3 O35 的 SAP 匹配图、O28 的累计用户曲线和 O29 的工程蓝图，分别提示数据血缘、口径、执行日志和批准回执必须成为交接字段。图表与流程图可以帮助人理解方向，却不能替代源数据、PR、测试和权威系统状态。[39]

Day 2 X 入口提供长度 **08:23:19**、Day 3 X 入口提供长度 **07:58:22** 的可从头播放视频；两者仍只有 id3 元数据轨道。2026-09-27 复核的 10 个 YouTube 分场视频另有英文自动字幕，本文按分场抽取时间定位和中文释义，不声称人工审校、逐字准确或完整观看。[36][39][40–49]

### 七层架构，三个不能混淆的中心

本文建议采用七层逻辑架构。层次表达责任和接口，不要求采购七套平台；一个产品可以承担多个层次，同一层也可能由多个系统共同实现。

| 层次 | 承担什么 | 关键产物或接口 | 谁最终负责 |
| --- | --- | --- | --- |
| 1 结果与价值流 | 定义客户结果、范围、基线、预算、风险约束 | 结果契约、价值指标、停止条件 | 端到端业务所有者 |
| 2 人机队伍与决策权 | 组织长期岗位、临时执行单元与人工批准 | 岗位契约、委派关系、决策矩阵 | 业务负责人及授权审批人 |
| 3 工作编排与状态 | 受理、依赖、交接、等待、恢复、重开 | 可持久化任务状态与事件 | 流程负责人 |
| 4 业务上下文 | 关联客户、订单、规则、来源、记忆与当前版本 | 带来源和权限的上下文包 | 业务数据责任人与领域专家 |
| 5 执行与工具 | 使用云端电脑、模型、Skills、编码 Agent 与连接器 | 受控动作请求、工具结果 | 平台与集成团队 |
| 6 权威业务系统 | 保有合同、订单、库存、应收及正式业务状态 | ERP、CRM、PLM、MES、工单系统回执 | 各系统与业务责任人 |
| 7 证据、验收与学习 | 核对实际结果，记录失败，批准改进 | 验收决定、审计链、版本化修订 | 独立复核人及最终责任人 |

三个中心需要分清：**业务记录中心**保存已发生的事实；**业务上下文中心**解释这些事实与当前目标的关系；**行动中心**在授权下推进下一步。三者可以协同，但不能让一段 Bot 记忆覆盖 ERP 已批准订单，也不能把检索到一份合同等同于理解了该合同的全部履约条件。

这里的“业务上下文中心”是本文的逻辑职责名称，不宣称它是某家厂商已实现的统一产品。可以从一条价值流所需的客户、合同、订单、付款和交付对象开始，为每个概念指定权威来源、有效期和负责人，再逐步扩大。

### 控制面应贯穿全程，不能只放在聊天入口

结果负责人决定能否接受风险；身份与权限系统决定动作是否允许；运行平台决定任务如何执行；验收角色决定证据是否足够。**统筹 Bot 可以协调，却不能自授权限，也不能同时代表所有批准者。**

控制面至少要覆盖身份、租户和项目边界，工具许可，预算与时限，审批策略，审计和暂停能力。Grok 官方已描述部分访问、网络、审批和日志控制；新一批 Work、Recruiting 与 Legal Ops 指南又给出只读、草稿后确认、写入前预览和人工发送等岗位规则。[24][27][54–56] 这些是可用方法的起点，并不证明本蓝图的所有业务门禁已在企业环境正确配置；尤其是候选人和法律材料，真实运行还需要合法基础、保密、最小权限与责任人复核。

岗位提示词负责表达职责。强制约束还需落实到真实账号、执行环境、业务系统和动作接口。官方指南提示同一环境中的网站登录可能为其他 Bot 所用，因此 Bot 名称不能被当成安全边界。[5]

对于服务多个客户的顾问或 FDE 团队，这一点尤其关键：行业方法可以复用，客户上下文、身份凭据、运行状态、预算和证据必须分别绑定。客户 A 的一次审批不能被带进客户 B 的流程；一个跨客户学习到的技巧，也不能附带原客户数据进入共享 Skill。

### 分级自治，按动作授予，不给整个 Bot 一张通行证

本文建议按具体动作划分：可以自主读取和准备；可以在可逆范围内执行；必须事前批准；必须停止并由人接管。这四种安排是设计选择，不是本文测得的产品成熟度等级。

同一个订单 Bot 可以自动核对字段，却不能自动更改价格；可以起草催收邮件，却未必被授权对外发送；可以发现信用冻结，却不能自行解除。自治边界随着证据、风险和恢复能力调整，任何扩大都应可撤销。

附件指定的 Gartner 报告提供了控制面、分级自治、失败指标和 Fusion Team 的研究线索。[31–34] 本轮仅核实同名 Part 2 的公开摘要，其重心是技术供应商如何把软件效率转为可验证的工作能力；其余指定报告原文尚未取得。因此，**这里的控制面与跨职能团队是本文方案，不伪装成对四份受限报告的全文转述。**

具体落地可以由业务负责人、领域专家、平台工程师和风险复核人组成一支跨职能小队，共用验收标准。它不是在原部门之间再增加一个协调层，而是让有权改变流程的人和有能力改变系统的人共同对结果负责。

### 记忆、幂等和验收，决定能否跨过第二天

记忆要区分事实、假设和经验：事实引用权威来源与版本；假设带验证状态；经验只有经复核才能进入共享 Skill 或例程。客户变更不能只“被记住”，还要使旧方案、报价和测试结论按依赖关系失效。

幂等是重复触发不重复产生业务效果。创建订单超时后，先按请求标识查询是否已受理，再决定重试。不能在没有确认结果时反复写入。一个运行记录也不能同时冒充银行、仓库或客户的最终回执。

验收应分四层：结构完整、来源可追溯、业务含义与规则成立、责任人接受约定结果。字段和哈希检查只覆盖其中很小的一部分。生产动作可在权威系统生效后才返回成功，业务关单还需满足验收合同。

![图5：事件、授权、执行和验收形成循环；字段、来源、业务、结果分别检查](figures/05-control-loop.png)

用一个简短的反事实来检验蓝图：如果主力 Bot 明天不可用，另一位授权同事能否接手今天的订单？他应能找到结果契约、当前状态、已执行动作、原始回执、未决批准和下一步条件。如果只能翻找几百条聊天消息，持续工作仍然依赖个人记忆，组织能力尚未沉淀。

## 08 四周试点与高管仪表盘

试点从一条业务线开始：例如客户会议结束后，形成有来源的需求基线、方案草稿和内部审核记录。它已经跨角色，足以检验交接；正式订单、客户承诺和资金动作仍按现有授权机制处理。

以下是本文设计的四周学习路径，不是交付周期承诺。麦肯锡关于价值门的讨论和斯坦福案例中的监督差异提供参考，具体门槛仍需企业自己确定。[28][30]

| 周次 | 主要工作 | 进入下一步的条件 |
| --- | --- | --- |
| 第一周：定义 | 固定结果、范围、基线、业务所有者和风险预算 | 有真实流程基线；有权改变流程的人签认 |
| 第二周：搭建 | 统筹、业务、执行的最小编队；使用合成数据跑正常与异常路径 | 缺失来源、冲突、过期凭证均能阻塞并升级 |
| 第三周：影子运行 | 在获授权业务节奏旁准备建议，由人执行关键动作 | 保留退回、人工接管和成本；没有把失败移出样本 |
| 第四周：有限放权 | 只扩大已验证、可恢复步骤的执行权 | 质量与风险达标；暂停、恢复和回滚责任明确 |

### 五个指标，围绕合格交付

| 指标 | 建议口径 | 防止的错觉 |
| --- | --- | --- |
| 首次验收通过率 | 首次提交通过数 ÷ 已首次提交数 | 生成数量代替质量 |
| 端到端周期 | 从受理到业务验收，观察中位数与 P90 | 只统计模型运行时间 |
| 人工审查投入 | 人工审查与纠正分钟数 ÷ 合格交付数 | 把执行成本转嫁给审核者 |
| 异常恢复率 | 时限内恢复并验收数 ÷ 到期应处理异常数 | 重复重试代替恢复 |
| 单位合格交付成本 | 模型、工具、运行、人工及返工总成本 ÷ 合格交付数 | 低 Token 价格代替经济性 |

统一观察窗口、任务复杂度和取消口径；没有合格交付时，成本指标应显示“尚无合格交付”，不能显示零成本。未经授权动作、证据缺失、错误外发等应作为独立失败指标，不被平均通过率稀释。

### 高管必须回答的八个问题

| 高管问题 | 必须形成的答案 |
| --- | --- |
| 业务结果 | 改善哪个客户、运营或财务结果；与什么基线比较 |
| 工作流所有者 | 谁对端到端结果负责，谁有权改流程 |
| 人机分工 | 哪些步骤由人主导、AI辅助或AI执行；依据何在 |
| 决策权 | 哪些动作可建议、可执行、须批准、必须停止 |
| 证据合同 | 每次交接和最终验收需要什么来源、版本、回执 |
| 风险预算 | 哪些错误可恢复；允许频率、影响和损失上限 |
| 学习闭环 | 纠正如何进入规则、数据、Skill、例程和岗位设计 |
| 停止条件 | 哪些质量、成本、权限或业务异常触发降级与停机 |

四道高管门贯穿全程：价值假设有可比基线，风险预算有明确上限，决策权能在系统中执行，停止条件有人承接。任何一道缺失，都不应靠“再多跑几轮”掩盖。

比如，合成订单试点可以把“无授权写入正式系统”设为立即停止条件；是否容忍分析草稿返工，则按业务后果决定。**失败指标的作用，是告诉管理者何时收回执行权，而不是让项目组做一张漂亮的故障报表。**

每周复盘应回答两类不同问题：本次交付是否通过；工作方法是否值得改变。一次异常不应直接让 Bot 自行改写公共规则。改进建议须有样本、责任人、版本、验证与撤回方式，然后才进入下一轮运行。

## 09 每个结果拥有一支队伍，也拥有一个最终责任人

回到开场那个问题：为什么每次交接仍然要靠人亲手推动？一个月的实践与 Galaxy 的公开构建，让我更愿意把答案放在组织设计里。队友需要持续的职责、可信的上下文、明确的接棒条件，也要能暴露阻塞，把需要人判断的事项带回来。

Grok Bot 的产品机制、Galaxy 的工作片段，以及新一轮组织研究，共同提供了值得认真探索的方向。持续环境让任务不必随一次对话消失；岗位与例程让责任具备节奏；编队可以跨越技能边界。企业还要补上权威上下文、决策权、交易控制、验收与学习。

### 把这张蓝图，也用来审视自己的实践

在数智北极的本地实践中，我围绕 Grok Bots 留下了岗位档案、Vault 知识材料、Skill 与 Routine 设计、舰队快照及部分配置回执。这些材料让“队友”逐渐有了职责、上下文和运行节奏，也帮助我看清，配置完成只是起点。一组岗位说明不能自动形成可接棒的组织，一份运行回执也未必代表客户结果已经验收。

目前，“计划—执行—回执—写回—学习”的统一闭环仍未完成端到端验证。Day 3 让闭环的缺口更具体：指标图没有口径，客户能力说明没有工单回执，营销链没有预览/发布回执，尾段工程蓝图没有 PR/CI/部署记录。下一步应选择一条有明确责任人、低外部风险的工作链，固定输入与版本，保留异常、人工接管和恢复记录，再检查纠正是否真正进入下一轮工作。编辑本轮已取得实践索引 JSON 和本地交付说明，但未取得 JSON 所列全部 Vault 配置与运行日志，因此这段是有回执索引的作者实践摘要，尚不是独立业务审计。我的目标也不是证明自己拥有多少 Bot，而是让一个真实结果能够被持续承接、核实和改进。[35][39]

**AI 原生企业的北极星，是让每项重要工作都拥有可持续的承接机制，让每个结果都有人最终负责。**Bot 可以越来越能干，人的责任不应因此越来越模糊。

---

## 资料与方法

本文为数智北极独立研究与设计文章，非厂商官方稿。主文活动证据覆盖 Day 1–Day 3；回放定点与本地关键帧沿用截至北京时间 **2026-09-19 11:43** 的复核，官方分场回放、自动字幕与公开参与者来源继续核验至 **2026-09-27**，官方指南目录与 9 月 24 日新增页面继续核验至 **2026-09-29 12:23 CST**。Day 3 纳入 O19–O29、O35 等有限画面、一条 Marketing Operations 参与者摘要、三个官方分场的机器字幕分段笔记和相应官方产品方法指南，但不是三天人工审校转录，也没有依据计划议程虚构实际演示。Day 2 O12–O15 仍单列为截至 08:40 的追加记录。

开场“一个月实践”、对现场演示的个人感受与组织自主智能判断，来自作者2026-09-17的第一人称补充[38]；已上传材料能支持部分岗位与配置整理，不能独立证实持续无人运营或全部业务结果。未核实“行业首场”排名，不作该事实断言。

研究文献本轮核验日为2026-09-17；早期 Day 1–2 记录曾以北京时间 2026-09-17 00:30 为主文截点，本次已由 Day 3 回放定点更新阅读范围。2026-09-24 发现官方活动页新增 10 个分场 YouTube 回放入口；2026-09-27 逐一导出其英文自动字幕，并记录各自 SHA-256、选择性时间定位与中文释义。[40–49] 原始字幕不随包发布，自动识别错误仍可能存在；哈希不能证明语义正确。2026-09-26 补入的 Marketing Operations 公开观看摘要只支持作者所报告的机制与转述，不能核验讲者原话、构建工时或审核率。[50] 2026-09-29 重新读取官方指南目录及 Marketing、Post-Sales、SDRs、Work、Recruiting、Legal Ops 六页；当前页首均显示 2026-09-24，故更正上一版对 Marketing 的日期记录。[51–56] 前三页与相应 Galaxy 分场交叉阅读，后三页只补充跨职能岗位和控制边界；全部属于官方产品方法，不是现场逐字稿、本站执行结果或独立成效审计。2026 WTI 使用官方网页的四种协作名称；正式团队实验以期刊2026-06-12版本及791人统计为准。BCG PDF日期保留“评审提供、原件待补核”标记。Gartner四份指定研究中，本轮只取得Part 2公开摘要，其余以文档ID列为待核线索；不复制授权全文，不将其细节包装为已读取结论。

参与者四片段与个人实践使用已上传的两个本地Markdown、14张关键帧和article-evidence.json。本轮读取文档、逐图检查全部14张图片，并校正KF05/KF06的文件标签与实际画面差异；KF09的访问阻塞、KF11的草稿PR状态也按画面补明。Day 3 定点证据继续使用 O19–O29、O35，保留回放时间码、采集时间、原图和 SHA-256；部分旧播放器时间码未独立校准到连续场次。YouTube 自动字幕是另一条机器转写证据，不覆盖关键帧，也不等于完整音频转录。原文件与canonical定位不覆盖。19项文件哈希与清单一致不代表语义或业务验证，本轮也未重跑原本地子站。部分产品比较沿用本项目已归档的9月17日页面核验，未进行六产品统一基准测试。

制造业企业、客户、120万元订单、30%预付款和六角色编队均为**合成设计推演**；未连接真实ERP、未创建业务订单、未执行Grok Bot产品实验、CRM写入、外联或客户回复。北极星七层、控制面和试点门槛为本文综合设计，不能视为厂商功能保证或架构已经获批。Day 3 的指标、用户曲线、营销链和工程蓝图均未取得源数据、指标字典、提交/测试/部署回执或客户成效。官方能力、画面、用户摘要、研究观点和作者推导均在来源索引中标明身份、日期、用途及边界。

[本地证据索引](../evidence/grok-bots-galaxy-2026-09-17/) · [Canonical Source 证据包](../evidence/grok-bots-galaxy-canonical-resources-2026-09-17.zip)

[1] [McKinsey · The agentic organization](https://www.mckinsey.com/capabilities/people-and-organization/our-insights/the-agentic-organization-contours-of-the-next-paradigm-for-the-ai-era)

来源身份：组织研究。日期：2025-09-26；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：五个组织维度；作为组织框架，不作为产品效果验证。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[2] [Microsoft · 2026 Work Trend Index: Agents, human agency, and the opportunity for every organization](https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization)

来源身份：AI 使用者调查、匿名使用信号与概念框架。日期：2026-05-05；核验日：2026-09-17 Asia/Shanghai。使用点：第2章：组织吸收、四种协作方式；第8章学习机制。边界：调查为10个市场20,000名工作中使用AI者；67%与32%为模型相对重要性，不是因果效应。网页模式为delegation/collaboration/asking/exploration，不采用评审中的其他名称。。核验状态：本轮读取官方网页、方法与注释；PDF下载未成功。

[3] [BCG · Design Your Company for AI, Not AI for Your Company](https://www.bcg.com/publications/2026/design-your-company-for-ai-not-ai-for-your-company)

来源身份：咨询研究。日期：官网 2026-04-23；评审提供的 PDF 版本日期 2026-04-16（原 PDF 待补核）；核验日：2026-09-17 Asia/Shanghai。使用点：第2、6章：以端到端结果重设运营模式。边界：咨询框架与案例，不外推ROI；官网日期与PDF版本日期分别记录，后者尚待原件核验。。核验状态：本轮核实官网发布日期；未取得评审所指 PDF。

[4] [Dell’Acqua et al. · The Cybernetic Teammate: A Field Experiment on Generative AI and Teamwork](https://pubsonline.informs.org/doi/10.1287/orsc.2025.20702)

来源身份：Organization Science 正式随机现场实验；期刊页面标注 Open Access。日期：2026-06-12（Published Online）；核验日：2026-09-17 Asia/Shanghai。使用点：第2章：791名P&G专业人员、创意生成与人工评估边界。边界：DOI 10.1287/orsc.2025.20702。特定一天创新工作坊，不能证明长期自治或Grok Bot优越性；开放访问不等于无限转载，页面未明确显示许可版本，本文只作简短释义。。核验状态：本轮读取正式期刊摘要、方法与发表信息。

[5] [xAI · Grok Bot 101](https://x.ai/bot/guides/grok-bot-101)

来源身份：官方指南。日期：2026-09-11；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：环境、触发、协作与权限；包含跨 Bot 网站登录可达性说明。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[6] [xAI · How I run multiple teams of Grok Bots](https://x.ai/bot/guides/how-i-run-multiple-teams-of-grok-bots)

来源身份：官方作者实践。日期：2026-08-27；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：实验性项目经理、频道、台账与团队方法；不是统一产品规格。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[7] [xAI · Grok Bot for Engineering](https://x.ai/bot/guides/grok-bot-for-engineering)

来源身份：官方作者实践。日期：2026-09-10；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：专业 Bot、编码 Agent、PR 台账；未独立验证其规模与效果。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[8] [xAI · Grok Bot for GTM](https://x.ai/bot/guides/grok-bot-for-gtm)

来源身份：官方指南。日期：2026-08-16；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：客户角色、准备与跟进；不等于真实业务收益证明。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[9] [xAI · Grok Bot for Support](https://x.ai/bot/guides/grok-bot-for-support)

来源身份：官方指南。日期：2026-09-09；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：重复支持流程；指南数字和细节为示例。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[10] [OpenAI · ChatGPT Work](https://chatgpt.com/work/)

来源身份：官方产品页。日期：持续更新页面；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：应用、文件、浏览器与交付物、重复任务；未作跨产品基准实测。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[11] [Anthropic · Claude Cowork](https://claude.com/product/cowork)

来源身份：官方产品页。日期：持续更新页面；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：云端持续执行、定时与并行工作；不能写成仅 Grok 支持。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[12] [腾讯 · WorkBuddy](https://www.codebuddy.cn/work/)

来源身份：官方产品页 / 浏览器读取。日期：持续更新页面；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：多专家、多模型、IM、MCP、Skills；已读取页面，未运行产品。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[13] [豆包 · 豆包工作](https://www.doubao.com/)

来源身份：官方网页检索摘要。日期：持续更新页面；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：目标拆解、工具、调研与应用搭建；完整说明未被文本读取，浏览器仅确认工作入口。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[14] [阿里巴巴 · 千问办公 QwenWork 发布](https://ali-home.alibaba.com/document-2021039099929952256)

来源身份：官方发布。日期：2026-08-03；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：桌面、云端与企业协同方向；计划集成不当作已实现功能。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[15] [Grok Bot Galaxy · Day 2 官方直播](https://x.com/i/broadcasts/1PKqrNyvmYwGb)

来源身份：本研究画面观察。日期：2026-09-16；核验日：2026-09-17 Asia/Shanghai。使用点：正文活动截止2026-09-17 00:30 CST：O09，Day3未纳入。第7章北极星增补单列后续O12–O15。。边界：O09：2026-09-16T16:29:30Z；Marketplace 连接器状态。内部播放时间未校准为回放时间戳。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[16] [Grok Bot Galaxy · Day 1 官方回放](https://x.com/i/broadcasts/1AxRnZbVpjaxl)

来源身份：本研究画面观察。日期：2026-09-15；核验日：2026-09-17 Asia/Shanghai。使用点：Day1定点抽查；新增参与者片段另见[35]，不混成此次复核原件。。边界：O05/O06：04:00:12、05:44:57、05:59:55；定点画面抽查，无可引用字幕。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[17] [xAI · Galaxy 官方议程](https://x.ai/galaxy)

来源身份：官方活动页。日期：2026-09；核验日：2026-09-17 Asia/Shanghai。使用点：第1章活动背景与公开构建目标；日程仅作计划信息。。边界：活动安排和官方直播链接；会前说明不作为现场事实。。核验状态：2026-09-17再次读取官方公开页面，核对活动目标、三天计划与分日议程；目标和议程不等于全部演示已实现。。

[18] [Luma · Galaxy 线上活动](https://luma.com/3ifrgttw)

来源身份：官方活动页。日期：2026-09；核验日：2026-09-17 Asia/Shanghai。使用点：第1章活动背景与公开构建目标；日程仅作计划信息。。边界：报名与时间；本研究不声称已完成注册。。核验状态：2026-09-17再次读取官方公开页面，核对活动目标、三天计划与分日议程；目标和议程不等于全部演示已实现。。

[19] [千问办公 · QwenWork 产品页](https://qwenwork.cn/)

来源身份：官方产品页。日期：持续更新页面；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：可编辑交付物与多类工作能力；不是业务成效实测。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[20] [xAI · Introducing Grok Bot](https://x.ai/news/introducing-grok-bot)

来源身份：官方发布。日期：2026-08-11；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：定位、内部原型来源及公测日期；当前页面的套餐文字可能随产品更新，首发日期另由 8 月 26 日公告交叉确认。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[21] [MacRumors · Grok Bot Brings Always-On AI Agents to macOS and iOS](https://www.macrumors.com/2026/08/11/grok-bot-macos-ios/)

来源身份：媒体报道与页面评论。日期：2026-08-11；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：发布当日报道及隐私、信任评论，仅作传播和意见样本，不代表总体市场情绪或采用率。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[22] [xAI · Grok Bot is now included with more plans](https://x.ai/news/grok-bot-more-plans)

来源身份：官方发布。日期：2026-08-26；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：确认 8 月 11 日公测及 8 月 26 日扩大订阅覆盖；扩围不等于活跃或付费增长。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[23] [Grok Bot Meetup Shenzhen · Luma](https://luma.com/5vkzzvqk)

来源身份：主办方活动记录。日期：2026-08-30；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：About Event：8 月 30 日下午分享与 Workshop；“中国首场”为活动方自述，未现场核验人数或出席。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[24] [xAI · Grok Bot for Enterprise](https://x.ai/news/grok-bot-for-enterprise)

来源身份：官方发布与采用披露。日期：2026-09-03；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：How customers use Grok Bot：数千组织、列举客户均为厂商披露，无统一付费、留存与业务成效口径。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[25] [xAI · Designing Grok Bot for a world of persistent agents](https://x.ai/news/designing-grok-bot)

来源身份：官方产品设计。日期：2026-09-03；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：From chat history to a Bot roster；Organizing intelligence：账号层工具/Skills，与 Bot 层记忆/例程；不是独立安全或效果测试。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[26] [Cursor 社区 · Grok Bot 0.30.0 初始化问题讨论](https://forum.cursor.com/t/grok-bot-0-30-0-stuck-on-setting-up-your-grok-bot-on-macos/169981)

来源身份：用户报告与支持回复。日期：2026-08-30；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：8 月 30 日至 9 月 1 日帖子；排查涉及权益、初始化及网络，不能仅取首帖推定普遍故障或最终原因。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[27] [Cursor Docs · Grok Bot security](https://cursor.com/docs/grok-bot/security)

来源身份：官方安全文档。日期：持续更新页面；核验日：2026-09-17 Asia/Shanghai。使用点：参见正文编号引用；用于其自身身份范围内的说明。。边界：Network policy；Approvals and Auto Review；Logging and audit。区分 Enterprise 控制、模型审核与业务系统权限，未独立测验。。核验状态：沿用上一版已归档来源，本轮未逐页重测。

[28] [McKinsey · Stacking the Odds: A Blueprint for Successfully Scaling Agentic AI](https://www.mckinsey.com/capabilities/operations/our-insights/stacking-the-odds-a-blueprint-for-successfully-scaling-agentic-ai)

来源身份：咨询实践与案例。日期：2026-09-14；核验日：2026-09-17 Asia/Shanghai。使用点：第2、8章：问题、流程、决策权与价值门。边界：不能把客户案例收益推广到制造业合成情境。。核验状态：本轮读取官方文章。

[29] [PwC Australia · AI in 2026: The AI-Native Enterprise](https://www.pwc.com.au/services/artificial-intelligence/the-ai-native-enterprise.html)

来源身份：方向性报告与专家讨论。日期：2026-04-01；核验日：2026-09-17 Asia/Shanghai。使用点：第2、7章：核心运营、人本分工与嵌入治理。边界：不是企业普遍效果的随机试验，不将其数字当作本文收益。。核验状态：本轮读取官方报告页。

[30] [Stanford Digital Economy Lab · The Enterprise AI Playbook: Lessons from 51 Successful Developments](https://digitaleconomy.stanford.edu/publication/enterprise-ai-playbook/)

来源身份：51个筛选成功案例的访谈研究。日期：2026-04-02；核验日：2026-09-17 Asia/Shanghai。使用点：第5、8章：组织准备、监督方式、可恢复错误。边界：成功案例选择偏差；自报结果并非全部企业项目的成功率。。核验状态：本轮读取官方页与官方PDF方法摘要。

[31] Gartner G00843398 · Part One: The New Agentic AI Operating Model

来源身份：评审指定的受限研究线索。日期：评审提供：2025-12-15；2026-01-16修订（未独立核验）；核验日：2026-09-17 Asia/Shanghai。使用点：第7章：作为控制面与分级自治的待核研究线索。边界：未取得授权原文或匹配公开摘要，不据此断言具体建议或产品能力。。核验状态：仅取得用户提供的文档ID、标题、日期。

[32] [Gartner G00818537 · Part 2: How to Reinvent Roles, KPIs, and Workflows With the Agentic Operating Model](https://www.gartner.com/en/documents/7732657)

来源身份：官方公开摘要；全文受限。日期：2026-04-16；核验日：2026-09-17 Asia/Shanghai。使用点：第7、8章：从软件效率转向可验证劳动力能力的供应商运营框架。边界：摘要面向技术供应商；不能把它等同通用企业实证或完整治理规范。评审提供的G号与公开页对应关系待授权原文复核。。核验状态：本轮核实同名官方摘要与日期；未读取付费全文。

[33] Gartner G00853569 · Fusion Teams: How to Design for Speed, Scale and Control in the Agentic AI Era

来源身份：评审指定的受限研究线索。日期：评审提供：2026-05-25（未独立核验）；核验日：2026-09-17 Asia/Shanghai。使用点：第7章：跨业务、平台与风险职责的待核研究线索。边界：未取得授权原文，不能声称本文团队架构为该报告的原文框架。。核验状态：仅取得用户提供的文档ID、标题、日期。

[34] Gartner G00859820 · Business Process Reengineering for AI-Native Operating Model: A Framework for CIOs

来源身份：评审指定的受限研究线索。日期：评审提供：2026-07-13（未独立核验）；核验日：2026-09-17 Asia/Shanghai。使用点：第7章：流程重构的待核研究线索。边界：未取得匹配原文，不援引行业百分比，也不声称Grok具备全部框架能力。。核验状态：仅取得用户提供的文档ID、标题、日期。

[35] [活动参与者 · Day 1 Canonical Source 证据包与修订说明](../evidence/grok-bots-galaxy-2026-09-17/)

来源身份：参与者原始关键帧、复原笔记、本地交付说明与实践索引回执。日期：2026-09-17；核验日：2026-09-17 Asia/Shanghai。使用点：第4章四片段、第5章本地成果、第9章个人实践；包含两个Day1时间区间；第3章可见头像与界面风格。边界：KF05/KF06原文件标签与画面存在差异，编辑说明已校正；不从静态图片推断完整过程。未重跑参与者子站，未取得全部Vault配置，不是客户业务验证。。核验状态：本轮取得两份Markdown、14帧及JSON；KF01–KF14已逐图检查；19项原件哈希一致。另提取KF01/KF04原像素裁切，记录坐标及原件/裁切哈希。。

[36] [Galaxy Lab · Day 2 定点画面观察 O12–O15](../index.html#evidence)

来源身份：本项目画面采样与播放器检查。日期：2026-09-17 05:28–08:40 CST；核验日：2026-09-17 Asia/Shanghai。使用点：第7章北极星增补：任务交接、管理Bot、知识缺失门禁；回放入口状态。边界：直播内部进度未校准为正式回放时间；无可引用字幕。界面自报完成不是源系统回执，回放长度不证明全场覆盖。。核验状态：O12–O14沿用本项目已归档观察；O15为本轮回放起始播放检查。

[37] [数智北极原创角色徽章与交接视觉系统 v1](avatars/)

来源身份：作者原创设计转译，非官方素材。日期：2026-09-17；核验日：2026-09-17 Asia/Shanghai。使用点：角色条、制造业与客户支持故事、HTML北极星蓝图、公众号静态图。边界：不是xAI官方头像或商标；角色、配色与状态为示意，不证明产品当前运行、默认配置或安全权限。Human Approver为人类。。核验状态：确定性几何图标代码、PNG与来源清单；截图裁切独立标注，未补画模糊细节。。

[38] 数智北极作者 · 一个月本地组织实践与文章立意补充

来源身份：作者第一人称实践陈述与观点，非独立审计。日期：2026-09-17；核验日：2026-09-17 Asia/Shanghai。使用点：开场Hook、第1章活动意义、第3章架构语言、第9章实践反思。边界：一个月实践时长与主观感受由作者陈述；未提供全部持续运行日志，不证明无人经营、全部执行自治或行业首场。组织内生智能与组织自主智能为本文提出的方向。。核验状态：依据作者本轮原始补充；部分实践索引另见[35]。未将作者陈述提升为独立验证。。

[39] [Grok Bot Galaxy · Day 3 官方回放与定点画面](https://x.com/i/broadcasts/1YGNrbXEeazGw)

来源身份：官方视频回放 + 本研究定点画面观察。日期：2026-09-17；核验日：2026-09-24 Asia/Shanghai。使用点：第1、4、5、7、9章：Day 3 营销运营、售后/客户成功、营销计划时段与尾段成果线索；O19–O29、O35 的回放时间码、采集时间与原图索引。边界：回放固定为 07:58:22，文本轨道仅见 id3 metadata，无可读字幕或官方章节。关键帧不等于完整场次；图表不证明指标口径、源数据或业务结果，流程图不证明 PR、测试、批准、部署或客户成效。部分画面没有专题标题或讲者姓名条，场次映射明确标为暂定。。核验状态：2026-09-19 Asia/Shanghai 复核官方回放可从头播放；浏览器读取到 duration 07:58:22、readyState=4，textTracks 仅 id3 metadata。O19–O29、O35 的原图、定位和 SHA-256 已在本地证据索引保留。2026-09-24 发现官方活动页新增分场 YouTube 回放入口，另以 40–49 记录，暂不把其页面存在升级为字幕、章节或内容已复核。。

[40] [xAI · Grok Bot for Engineers 分场回放](https://youtu.be/zCqmTSF2ctg)

来源身份：官方分场视频 · YouTube 自动生成英文字幕。日期：2026-09-24 页面核验；2026-09-27 字幕复核；核验日：2026-09-27 Asia/Shanghai。使用点：工程场次分段笔记：自主 agents、Cursor Cloud Agents、验证回路、例程与升级。边界：自动字幕未经官方审校，可能误识别产品名与人名；本轮只做带时间码的中文释义，不发布整份字幕。演示与讲者主张不等于源码、PR、CI、Vercel 回执或独立业务验证。。核验状态：2026-09-27 Asia/Shanghai 导出 en auto-generated 字幕，约45:08；原始导出 SHA-256 73967b531a287a86fa299d7de0750e4d66233d3298a360d00d67164e34a5d86e。哈希只标识所读字节，不证明语义准确。。

[41] [xAI · Grok Bot for Product Managers 分场回放](https://youtu.be/gNysgEu-lew)

来源身份：官方分场视频 · YouTube 自动生成英文字幕。日期：2026-09-24 页面核验；2026-09-27 字幕复核；核验日：2026-09-27 Asia/Shanghai。使用点：产品经理场次分段笔记：数据洞察、PRD、设计、工程分工与验证链。边界：自动字幕未经官方审校；Fly Low Airlines 为演示/合成公司。讲者关于合并 PR 占比等说法未独立核验；未取得仓库、PR URL、真实数据仓库或测试回执。。核验状态：2026-09-27 Asia/Shanghai 导出 en auto-generated 字幕，约35:08；SHA-256 b5aed6f5e308bb84d099c0a883ef342822cc8f8a600ba6ecf5dfe5e1a34696cc。。

[42] [xAI · Grok Bot for Founders 分场回放](https://youtu.be/hPE3A4Smkxc)

来源身份：官方分场视频 · YouTube 自动生成英文字幕。日期：2026-09-24 页面核验；2026-09-27 字幕复核；核验日：2026-09-27 Asia/Shanghai。使用点：创始人场次分段笔记：客户、产品、竞争情报、原型与沟通角色。边界：自动字幕未经官方审校；角色与工作链为演示内容，未取得经营 KPI、客户回执或独立效果验证。。核验状态：2026-09-27 Asia/Shanghai 导出 en auto-generated 字幕；SHA-256 7961b7d6f60f70a96382322e408db7a0b7ca5f9edd0037a1dbe086ea707fda24。。

[43] [xAI · Grok Bot for Sales Engineers 分场回放](https://youtu.be/tpDfoh5qPF8)

来源身份：官方分场视频 · YouTube 自动生成英文字幕。日期：2026-09-24 页面核验；2026-09-27 字幕复核；核验日：2026-09-27 Asia/Shanghai。使用点：售前工程分段笔记：证据幻灯片、技术专家、竞品体验与人类接管登录。边界：自动字幕未经官方审校；Flyo 为演示公司。未取得 Salesforce 回执、代码库、deck 文件或登录日志；10–15 分钟等为现场说法而非基准。。核验状态：2026-09-27 Asia/Shanghai 导出 en auto-generated 字幕，约45:44；SHA-256 f52c50d76c7333a13a4f890268b5ed366642af24ab79e82433580a70eaa8638f。。

[44] [xAI · Grok Bot for Sales 分场回放](https://youtu.be/SVZe46xaVTg)

来源身份：官方分场视频 · YouTube 自动生成英文字幕。日期：2026-09-24 页面核验；2026-09-27 字幕复核；核验日：2026-09-27 Asia/Shanghai。使用点：销售场次分段笔记：日程准备、邮件草稿、账户研究、会后行动与 CRM 差异。边界：自动字幕未经官方审校；客户与效率成效为讲者经验陈述。未取得 Salesforce/Gmail 写入、发送回执、账户数据或预测结果。。核验状态：2026-09-27 Asia/Shanghai 导出 en auto-generated 字幕，约21:05；SHA-256 fe0df996369b507e397f85cabe8d38d290ccc7fb3fa205cecaba7b288e3f5cde。。

[45] [xAI · Grok Bot for SDRs 分场回放](https://youtu.be/Iia8EF7niiA)

来源身份：官方分场视频 · YouTube 自动生成英文字幕。日期：2026-09-24 页面核验；2026-09-27 字幕复核；核验日：2026-09-27 Asia/Shanghai。使用点：SDR 分段笔记：账户研究、信号例程、草稿队列与人工批准边界。边界：自动字幕未经官方审校；研究、草稿与实际发送必须区分。未取得名单授权、联系人同意、发送回执、预约或转化结果。。核验状态：2026-09-27 Asia/Shanghai 导出 en auto-generated 字幕；SHA-256 f1fe406b517f2dcf4b1c24759ffdd70a743cac634a899d145dfc673b0d20c7d3。。

[46] [xAI · Grok Bot for Customer Support 分场回放](https://youtu.be/BSB--jUnx9U)

来源身份：官方分场视频 · YouTube 自动生成英文字幕。日期：2026-09-24 页面核验；2026-09-27 字幕复核；核验日：2026-09-27 Asia/Shanghai。使用点：客户支持分段笔记：工单、知识检索、阻断、升级与获批后回复。边界：自动字幕未经官方审校；演示中的工单与知识状态不等于客户系统回执。未取得最终回复、知识版本、送达或 CSAT。。核验状态：2026-09-27 Asia/Shanghai 导出 en auto-generated 字幕；SHA-256 8c6600f8f28f06a2d1adfa3121339256bc0fce4b5003e28b0590d03c9283a7a7。。

[47] [xAI · Grok Bot for Marketing Operations 分场回放](https://youtu.be/EA-sxwWK0Vs)

来源身份：官方分场视频 · YouTube 自动生成英文字幕。日期：2026-09-24 页面核验；2026-09-27 字幕复核；核验日：2026-09-27 Asia/Shanghai。使用点：营销运营分段笔记：跨收件箱受理、任务化、territory bot 与 lead-review 内部应用。边界：自动字幕未经官方审校；视频明确使用 fake data。两周、约10小时和审核率提升为讲者说法，未取得代码、工时、指标口径或 CRM 回执。。核验状态：2026-09-27 Asia/Shanghai 导出 en auto-generated 字幕，约21:41；SHA-256 d7042e3cb8f3742fd06d972b85d04c95b8eccce8418ecc2ec57636804cc98ce1。。

[48] [xAI · Grok Bot for Post Sales 分场回放](https://youtu.be/EGt8FfTmTMY)

来源身份：官方分场视频 · YouTube 自动生成英文字幕。日期：2026-09-24 页面核验；2026-09-27 字幕复核；核验日：2026-09-27 Asia/Shanghai。使用点：售后分段笔记：客户信号、会前/会后材料、账户专员与行动草稿。边界：自动字幕未经官方审校；未取得客户账户、健康模型、消息发送、CRM 写入或客户成效。。核验状态：2026-09-27 Asia/Shanghai 导出 en auto-generated 字幕；SHA-256 c24858ce652b02b9a469dc373057f259f1b25539fafe763eb811a5a550234c72。。

[49] [xAI · Grok Bot for Marketing 分场回放](https://youtu.be/db38-FgdaGQ)

来源身份：官方分场视频 · YouTube 自动生成英文字幕。日期：2026-09-24 页面核验；2026-09-27 字幕复核；核验日：2026-09-27 Asia/Shanghai。使用点：营销分段笔记：研究、定位、落地页、广告变体、分析与项目管理交接。边界：自动字幕未经官方审校；视频明确没有现场 launch。未取得广告花费、部署、发送回执、转化或营销成效。。核验状态：2026-09-27 Asia/Shanghai 导出 en auto-generated 字幕；SHA-256 6b535c7e7aa0ebf136a0a3eef6d4d29e1279b62e6c6481bf47971f322d66263e。。

[50] [Hiten Shah · Marketing Operations 现场观看摘要](https://www.linkedin.com/posts/hnshah_i-watched-matthew-silberman-show-how-he-uses-activity-7506402306267955200-mzOa)

来源身份：公开参与者摘要 · 非官方逐字稿 · 非独立审计。日期：LinkedIn 页面于 2026-09-26 显示 6d（约 2026-09-20；精确发布时间未取得）；核验日：2026-09-26 Asia/Shanghai。使用点：第4、5章：补充 Marketing Operations 的收件箱分流、任务化、专业 Bot 接棒与内部 lead-review app 叙述。边界：作者称自己观看了 Matthew Silberman 的现场展示；正文是作者对所见与讲者说法的摘要，不是视频字幕、连续操作记录或源系统回执。两周、约10小时与审核率创新高均为二手转述，未取得代码、工时记录、指标字典、基线或独立验证。。核验状态：2026-09-26 Asia/Shanghai 公开读取 LinkedIn 页面正文及作者名；页面显示相对时间 6d。只按参与者摘要引用，不把转述升级为 xAI 官方说明或已验证业务结果。。

[51] [xAI · Grok Bot for Marketing 官方指南](https://x.ai/bot/guides/grok-bot-for-marketing)

来源身份：官方产品指南 · 作者工作方法 · 非 Galaxy 逐字稿。日期：2026-09-24；2026-09-29 页面复核（更正上一版记录的 09-18）；核验日：2026-09-29 Asia/Shanghai。使用点：第4、5、7章：六个营销岗位、跨 Bot 交接、Google Docs / Google Ads / Cursor / GitHub 工具链与人工批准边界。边界：指南以 Josh Kim 第一人称描述 X-Air 虚构案例及其工作方式；不是 Galaxy 分场逐字稿，也不是本站产品实验。Google Ads shell、网站 PR、分析 scoreboard 与工具连接均未由本站读取源系统回执；指南没有给出可独立复核的广告花费、部署、转化或客户成效。核验状态：2026-09-29 12:23 CST 重新公开读取页面；当前页首明确显示 Sep 24, 2026。定位 Meet the marketing bots、X-Air, start to finish、Pages, ads, analyst、The handoff tax、Templates, permissions, memory、So what does this change。与来源[49]的官方分场自动字幕交叉核对角色与流程，但不据此推定现场每一步已经执行。

[52] [xAI · Grok Bot for Post-Sales 官方指南](https://x.ai/bot/guides/grok-bot-for-post-sales)

来源身份：官方产品指南 · 作者工作方法 · 非 Galaxy 逐字稿。日期：2026-09-24；核验日：2026-09-29 Asia/Shanghai。使用点：第4、5、7章：Chief of Staff、账户专员、例程、会前准备、承诺追踪及人工发送边界。边界：Blake Schuller 的第一人称工作法与产品说明；不是 Galaxy 分场逐字稿，也不是本站运行记录。账户健康、消息草稿、客户关系与时间节省均未由本站读取源系统或客户回执；指南中的日常时间线不能当作独立业务审计。。核验状态：2026-09-29 12:23 CST 公开读取页面；定位 I only manage one bot、Bot's own computer、The routines、When an account has me underwater、A day in the life、More time in the rooms。与来源[48]的机器字幕分段笔记交叉阅读，不把指南叙事倒填为现场逐步执行。。

[53] [xAI · Grok Bot for SDRs 官方指南](https://x.ai/bot/guides/grok-bot-for-sdrs)

来源身份：官方产品指南 · 作者工作方法 · 非 Galaxy 逐字稿。日期：2026-09-24；核验日：2026-09-29 Asia/Shanghai。使用点：第4、5、7章：研究包、CLEAR/FLAG 分流、专业 Bot 编队、未发送队列与最终人工发送。边界：官方作者描述 Cursor 与 Grok Bot 的 SDR 工作法；不是 Galaxy 分场逐字稿或本站外联实验。未取得原始名单、联系人同意、Nooks/LinkedIn/Salesforce 回执、邮件发送、预约或转化结果。。核验状态：2026-09-29 12:23 CST 公开读取页面；定位 The five-step SDR process、One job per bot、A morning with Grok Bot、Rules that keep the team healthy。页面明确区分 CLEAR 与 FLAG，并写明 Nothing auto-sends / Never auto-send；本站未执行任何外联。。

[54] [xAI · Grok Bot for Work 官方指南](https://x.ai/bot/guides/grok-bot-for-work)

来源身份：官方产品指南 · 作者工作方法 · 非 Galaxy 场次材料。日期：2026-09-24；核验日：2026-09-29 Asia/Shanghai。使用点：第3、5、7章：Inbox Manager、Calendar EA、Intel Scout 与 Bot Boss 单一入口的角色编队和只读/确认边界。边界：作者第一人称产品实践，不是 Galaxy 场次内容或通用安全保证。页面中的 read-only、draft-then-confirm、disabled-until-enabled 是示例岗位规则；本站没有验证其运行、权限强制或漏报率。。核验状态：2026-09-29 12:23 CST 公开读取页面；定位 Communication、Time、Information、Putting it together。Bot Boss 被描述为专业 Bot 的单一入口，但不据此推定组织级隔离或可靠性已经验证。。

[55] [xAI · Grok Bot for Recruiting 官方指南](https://x.ai/bot/guides/grok-bot-for-recruiting)

来源身份：官方产品指南 · 招聘团队作者实践 · 非 Galaxy 场次材料。日期：2026-09-24；核验日：2026-09-29 Asia/Shanghai。使用点：资料与方法：记录官方指南目录扩展；作为角色链、人工追问和批准发送的跨职能例证。边界：不是 Galaxy 议程场次，也不是本站招聘实验。候选人数据、ATS 更新、评分卡、触达及采用速度均未独立核验；涉及个人数据的真实使用还需合法基础、最小权限与人工复核。。核验状态：2026-09-29 12:23 CST 公开读取页面；定位 Fast adoption、Recruiting bots、Getting the most out of Grok Bot。仅记录公开方法，不复制模板全文，不执行 ATS 或候选人动作。。

[56] [xAI · Grok Bot for Legal Ops 官方指南](https://x.ai/bot/guides/grok-bot-for-legal-ops)

来源身份：官方产品指南 · Legal Ops 工作方法 · 非 Galaxy 场次材料。日期：2026-09-24；核验日：2026-09-29 Asia/Shanghai。使用点：资料与方法：记录官方指南目录扩展；作为预览确认、人工发送与证据化流程的跨职能例证。边界：不是 Galaxy 议程场次，也不是法律意见或本站法律流程实验。指南的 tracker、合同系统、Salesforce 与审计式检查均未读取源系统回执；真实使用需权限、保密、监督与法律责任人。。核验状态：2026-09-29 12:23 CST 公开读取页面；定位 Counsel 1:1 prep、Legal Slack triage、Contract lifecycle / Ironclad support、More workflows、Pros of moving to Grok Bot。页面强调外发由人审阅、写入前预览确认。。