面向产品经理的 Grok Bot

产品管理领域有一个公开的秘密：大多数产品经理实际上并不管理任何人。

产品经理通常管理的是产品，并与许多人和团队（设计、工程、数据科学、市场营销、支持）协作以实现目标。“产品的迷你 CEO”这种说法之所以扯淡，是因为没人向这个“迷你 CEO”汇报（也没人必须听他的！）。

到了 2026 年，产品经理的角色正处于快速变化之中，产品工具链也是如此。如今有许多工具，能帮助产品经理从“出主意的人”拓展为全栈的产品、设计、工程和 GTM 构建者。

在 SpaceXSI，我们的产品团队会交付代码、为新想法制作原型，并组成小团队来打造有雄心的产品。我试过许多用于产品经理工作的 AI 编程工具和通用知识工作智能体，而 Grok Bot 无疑是今年对我的工作流程改变最大的工具。

在 Grok Bot 正式推出前的几个月里，我一直在内部使用它来打造产品。它确实需要一段学习时间，但一旦摸清门道，如果你喜欢动手构建，就会发现它用起来很有能量，也很有趣。

什么是 Grok Bot？ Grok Bot 是一支随时在线的智能体团队，每个智能体都有自己的电脑，可以学习并放大你的工作成果。因此，或许这是第一次，作为产品经理的你可以拥有一支直接向你汇报、帮助你交付产品的“团队”（由智能体组成）。

以下简要介绍我作为 SpaceXSI 的产品经理如何使用 Grok Bot。下面会更详细地谈谈哪些做法奏效、哪些没有奏效，以及刚开始使用 Grok Bot 的产品经理可能会考虑的一些设计决策。

一些适合产品经理的 Grok Bot 用例

优先事项 → 关注清单

许多产品经理会制定每周目标或优先事项，但这些内容很快就会过时。我不再创建很快会被一天中的混乱状况淘汰的“优先事项清单”，而是开始让 Grok Bot 跟随我在 Slack、电子邮件以及会议 / Granola 中的注意力轨迹，创建一种不同的东西：“关注清单”。

我是否活跃在一堆事故频道里？我是否正和招聘团队一起争取录用一位候选人？有人是否发来一篇发布博客文章让我审阅？我的幕僚长能看到这些工作正在发生，并在我工作时维护一份隐含的优先事项清单。

产品经理经常需要跨越许多团队和场景开展工作。我发现，相比努力维护一份不断更新的优先事项清单，我一天中实际谈论和处理的事情能更好地实时反映什么才重要。

这像是一种新的工作基本单元：“关注清单”。它不同于一组目标、优先事项或待办事项清单，因为它是从你的工作和注意力中自然显现出来的。我发现它有两方面用途：

1. 智能体可以把关注清单用作筛选条件。一天之中，成千上万条 Slack 消息和电子邮件可能让人分心，或需要我处理，因此智能体可以用这份清单引导我关注与当前工作重点相关的对话串。
2. 你可以对照自己明确表达的优先事项和目标，以及我实际上在关注什么。

设置方法：“创建一份关注清单：每小时检查电子邮件、Slack、Granola 和日历，简洁列出我正在关注的项目及其当前状态，还有接下来需要做什么。”

使用方法：“查看我的关注清单，并归档所有与我的关注列表无关的电子邮件。”“这周我把时间花在哪里了，以后可以交给智能体处理？”

研究新的产品创意

产品团队拥有的数据集不断增长，可用于了解新产品或现有产品中的缺口。每次客户会议都会通过 Granola 和 Gong 录制并转录。我们也在客户的 Slack 频道中，产品反馈源源不断地涌入。

我们出色的用户研究员 Stan 建立了一个数据库，收录了每次访谈、用户洞察和综合分析。使用情况和订阅数据存放在 Databricks。支持工单存放在 Plain 或 Intercom。复杂的产品决策记录在 Notion 中。

跨客户场景开展研究

挑战在于如何让智能体读懂所有这些原始上下文，并用它们来指导和塑造未来的产品方向。我们最近接入的企业客户中，哪些正在使用某项产品功能？我们的客户在转化漏斗的哪个环节遇到了阻碍？智能体现在可以综合多个原始来源的信息，回答这些问题，并以更全面的方式为产品方向提供参考。

设置方法：确保已为所有存放客户上下文的核心工具启用插件，并登录虚拟机上任何尚无 MCP 的系统。

交付软件

最让我意外的是 Grok Bot 在实际交付软件方面的表现有多好。如今，Grok Bot 贡献了我们内部已合并 PR 的两位数百分比。

Grok Bot 智能体可以使用 Cloud Agent，在配备了代码库、依赖项、密钥以及智能体测试工作所需一切的环境中运行。

对产品经理来说，这让你能够在更高的抽象层次上开展工作。你不必管理单独的工作对话串，也不必同时应付许多个智能体；你可以向 Grok Bot 智能体表达复杂得多的目标，由它拆解任务并分配给其他智能体，然后以新的方式审查并整合它们的产出。

借助 Grok Bot、前沿模型和合适的云端智能体环境，产品经理可以承担雄心更大的构建任务。下面会详细介绍我如何组建工程智能体团队。

我的 Grok Bot 团队

• **幕僚长：**日历、Slack、收件箱。唯一的通才。没有变化时保持安静。
• **工程经理（Emily）：**不写代码。拆解工作、委派给一线工程智能体，并根据目标检查产出。
• **工程师（×5）：**工程智能体启动 Cloud Agent，并接收工程经理分配的工作。
• **数据分析师（Ashley）：**数据仓库、图表、目标跟踪。每天早上检查仪表板。
• **产品经理 Pete：**RFC、研究、反馈、文档。亲自参与工作，也负责硬件。
• **招聘专员：**发掘尚未被发现的人才并管理招聘流程。

通才

幕僚长

管理

工程经理

工程

多位工程师

数据

数据科学与分析

产品

产品经理 Pete

为什么不只用一个智能体？

最大的设计问题可能是：究竟应该只用一个全知全能的智能体，还是使用多个专门化智能体。我使用 Grok Bot 的方式与当前的主流模式背道而驰：那种模式提供一个空白文本框，配上一个理论上应该无所不能的通用智能体。

我发现，把工作分配给专门化智能体有几个好处：

• **易于辨认。**你知道谁负责什么。
• **并行处理。**多个智能体同时处理不同任务，并协作处理共同任务。
• **各自限定范围的记忆。**它们会在工作中学到不同的东西。

除此之外，我通常觉得和这些不同的智能体一起工作更有趣。

一些经验

1. **为智能体命名，并分开记忆。**每个智能体都有一个宽泛的目标或使命，但只保留与其工作类型相关的特定范围记忆。幕僚长不应该调试电脑使用评测。评测智能体也不负责归档我的邮件。
2. **智能体会在工作中学习。**智能体可以从你过去的工作中学习，你也可以继续教它们。我发现，最能发挥杠杆效应的一条指令是：“阅读我过去的 Slack 消息，为我制定一份 Slack 风格指南。”
3. **智能体不应该制造噪音。**Grok Bot 智能体倾向于采取行动，但也可能沟通得过多。让它们在没有事情需要你关注时保持安静，以减少干扰和噪音。
4. **重要事项由人来把关。**目前，大多数消息仍由我发送，大多数文档和创意仍由我编辑。一方面是为了去除 AI 味，另一方面是因为我发现，人们希望知道发送者确实花了时间思考所提出的请求。

如果你是使用 Grok Bot 的产品经理，我很想了解你在用哪些智能体，这样我也可以试试看。