Grok Bot 产品最佳实践：用一支 Bot 团队完成研究、PRD、设计与交付

本文作者：meng shao（@shao__meng）。版权归作者所有，未经授权禁止转载。

SpaceXAI 产品团队 @KevinKNeilson 和 @roshan_s 做了一场工作坊，主讲 Grok Bot 产品最佳实践。通过 45 分钟分享，展示一种新的产品团队组织方式：PM 第一次拥有一支真正"向自己汇报"的团队——只不过成员是 Bot。

Grok Bot For Product Best Practices

https://www.youtube.com/watch?v=x5OawRpQxII

开场引用 DHH 的观点作为背景：软件开发正在变成产品管理——"该做什么、怎么做、长什么样、优先级是什么"成了每个人都要回答的问题。Grok Bot 就是为这种"人人都是产品经理"的工作方式设计的。

为什么要做 Grok Bot（设计动机）

归纳了内部使用和客户反馈中浮现的三个痛点：

聊天框不适合"干活"的 Agent。聊天框适合问答，但 PM 的工作是跨职能、面向结果的协调，超出了 Q&A 形态。
Agent 需要自己的工作环境。早期 Cloud Agents 的经验表明：让 Agent 能验证自己的产出，结果质量会大幅提升；自然延伸就是给每个 Agent 一台自己的电脑。
人无法同时盯着几十个 Agent 线程。很多工程师自己搭了"协调者 Agent"去管其他 Agent，但从未被产品化成一等公民。

由此得出的设计纲领：把 Agent 当同事，而不是当软件。同事的四个特征——把工具串起来产出结果、有长期记忆、能独立工作、用即时消息沟通——直接映射为产品功能。

一句话定义：Grok Bot = 一个有自己电脑的 Agent + 一支可以交付真实工作的 AI 同事团队。特点是有行动倾向、边干边学、做完才回来、卡住时才找你。

他们的 Bot 团队配置

| Bot | 角色 | 职责与特点 |
|---|---|---|
| Kora | Chief of Staff | 唯一的通才。管日历、Slack、收件箱；维护"注意力清单"；没变化时保持安静 |
| Emily | 工程经理 | **被明确训练成不写代码**。拆解 PRD 为技术任务、分派给工程师 Bot、按目标验收产出 |
| 5 名工程师 Bot | 工程师 | 接 Emily 的任务，底层调用 Cloud Agents 编码，互相协调、彼此验证 |
| Ashley | 数据分析师 | 接数据湖/数仓和用户研究库；被教会用团队喜欢的图表风格回答；每天早上看 dashboard |
| PM Pete | 产品经理 | 写 RFC/PRD、做研究、汇总反馈、跨 Bot 协调；甚至一起做过硬件（树莓派） |
| Pixel | 设计师 | 接 Figma 和设计系统；灵感来自 Lenny 通讯里一位设计师发布的设计体系 |
| Rey | 招聘 | 找人才、推进面试流程 |

为什么是多个 Bot 而不是一个全能 Bot，给出了四条理由：

可指认性：知道数据问题找谁、设计问题找谁（Roshan 说"只用一个 Agent 时我的大脑处理不过来"）
并行：多个 Bot 同时干不同的事
作用域记忆：每个 Bot 在自己的领域里边干边学，Chief of Staff 不该去调试评测，评测 Bot 也不该去归档邮件
对应现实组织：公司本来就是由专才构成的

补充一个关键机制：所有 Bot 共享同一台云端电脑（文件、浏览器会话、应用登录共享），但每个 Bot 有独立的屏幕、记忆、上下文和例程。这既让交接不需重复配置，也意味着一次登录对所有 Bot 可见（安全边界在账号级而非 Bot 级）。

四个核心工作流（演示部分）

1. 注意力清单（Attention List）—— 一种新的工作原语

这是全场最值得关注的概念。区别于优先级清单或待办清单，它不是你事先写的，是从你的实际行为中涌现的：Bot 观察你在 Slack 回了什么、邮件处理了什么、Notion 改了什么，反推"你的注意力此刻在哪里"。

两种用法：

作为过滤器：每天上千条消息中，只把与当前关注项相关的推给你，其余自动归档
作为对照：把"我说的优先级"与"我实际在花时间的事"做 diff，发现偏离

设置方式非常简单，一句自然语言："每小时看邮件、Slack、Granola、日历，生成一份我正在关注的项目、当前状态和下一步。"

2. 例程（Routines）—— 让 Bot 从被动变主动

演示中一句"每小时帮我清理收件箱"就让 Kora 自动创建了一个定时任务。要点：

Bot 看到你反复做同一件事时会主动建议或创建例程
例程保留对所有已连接工具的访问权
Bot 还可以通过观看你在它电脑上的一次操作演示来学会流程并固化为例程
典型用例：X MCP 上线后，让 Ashley 每小时推送安装量脉搏，取代了"开着 dashboard 反复刷新"

3. 研究到 PRD —— 并行、引用、Bot 之间互相协作

现场以"双向语音模式"为例（观众实时投票选出的需求），完整走了一遍：

PM Pete 抓 Reddit、X、内部 Slack 反馈频道、用户研究库，汇总需求
Pete 同时去查语音转语音的模型 benchmark，确定技术选型
Ashley 并行计算市场规模（TAM/SAM）和现有语音功能的周活渗透率，输出品牌风格的图表
Pete 用团队的 PRD 模板把这些写进 Notion RFC（含机会、用户痛点、方案、TLDR、范围外事项）
用户对 Pete 说"顺便叫上 Pixel 做设计"，Pete 自己把上下文（种子文案、视觉简报）打包发给 Pixel，Pixel 在 Figma 出图后交回，直接填进 RFC 的 mock 占位区

两个被反复强调的实践细节：要求 Bot 附带引用来源以便核查；以及"Agent 非常擅长给其他 Agent 写提示"，人不需要手动搬运上下文。

4. 交付 —— 群聊 + Cloud Agents

把 Pete 和 Emily 拉进一个群聊，一句"Pete 写好了 PRD，你们对一下，Emily 开始建"。随后：

Emily 与 Pete 确认需求源头和 V1/MVP 范围
Emily 把 PRD 拆成工单，分派给工程师 Bot（Eileen、Larry 等自动被拉入）
工程师 Bot 各自启动 Cloud Agents 编码（Cloud Agents 环境预装了代码库、依赖、密钥、测试能力）
遇到需要登录或审批时，Emily 会暂停并 @ 人类来解锁

这套"任务分派 + 审核"的模式不是现场指令，是 Emily 在过去的工作中学到的行为。演讲者提到内部两位数百分比的合并 PR 现在来自 Grok Bot 发起的 Cloud Agents。

人的位置在哪里

对边界的表述很清晰：

卸载给 Bot 的是苦活和低复杂度的工作（收集、汇总、初稿、分派）
人保留最后一公里的审核与精炼：研究结论的判断、PRD 的战略层面、代码审查、任何对外发送的邮件、采购、删除类操作
文档里另有两点值得注意：仍由人亲自发消息和改文档，一是为了"去 AI 味"，二是因为"收信人想知道发信人真的思考过"

Roshan 的总结："我能发起的工作量、能管理的工作量都比以前多得多，因此我反而有更多时间花在审核和思考下一步上——这正是产品人该花时间的地方。"

问答环节的关键信息

上下文管理：目标是"你永远不需要担心上下文"。Bot 是超长运行的（与 Chief of Staff 的对话已持续数月），最近的事记得清，很久没提的事会自然淡出，不再打扰你。已有的 Agent 上下文体系和 skills 可直接迁移。
学习方式：除了文字纠正，还能录制你在它电脑上的操作让它学；"读我过去的 Slack，写一份我的写作风格指南"被认为是杠杆最高的一条指令。
内部采用：最早在 GTM 团队（销售、财务、售后）出现产品市场契合；产品和工程团队的高度采用是意外之喜。Linear 工单很多由 Bot 发起。
路线图：两个方向——扩展接触面（当天刚发布 Android 版）和扩展能力（更多连接器和工具）。多账号支持"在考虑，暂无承诺"。
快速复刻：把任何一个 Bot 指向 Kevin 那篇 X 帖子，它会自动搭出同样的团队并询问你的工作习惯。

一句话概括这场工作坊：它展示的不再又一个更强的聊天助手，是把"管理一支团队"这件事本身产品化——PM 的核心技能从亲手做变成了定义目标、配置团队、审核结果。