← Grok Bot 实战案例总览 · 成果库

官方 guide《Grok Bot for PMs》专题(Kevin Niparko):“注意力清单”、多专职 Bot 团队与出货

作者是 SpaceXSI 的产品经理,说 Grok Bot 是他今年工作流里最大的变化。重点:用“注意力清单”替代会过期的优先级清单,并让专职 Bot 各管一摊。

说明:本专题于 2026-10-17 根据公开资料整理,没有编造内容:提示词、步骤和数字都来自下方列出的来源;整理者的推断用“推”标签标出,没能访问或没法核实的放在最后一节。数字多为作者自述,未经验证。
引逐字引用或忠实转述原文 推整理者推断
24

官方 guide《Grok Bot for PMs》专题(Kevin Niparko):“注意力清单”、多专职 Bot 团队与出货

来源类型:x.ai 官方 guide(作者 Kevin Niparko,2026-08-15);页面为静态文本,已完整读取

引作者的出发点:“产品经理圈的公开秘密是,大多数 PM 其实不管任何人”;“产品的迷你 CEO”之说是胡扯,因为没人向这位迷你 CEO 汇报。而 Grok Bot 是“一队有自己电脑、会学习并放大你工作的 agent”,所以“也许是第一次,PM 可以拥有一个向自己汇报、帮自己出货的(agent)团队”。

引他承认有学习曲线,“但弄明白之后,如果你爱造东西,会非常有力量且好玩”。

本专题目录

24.1

优先级 → “注意力清单”(attention list)

一个新的工作原语

引PM 的每周目标或优先级很快过期。他不再维护“优先级清单”,而是让 Grok Bot 跟随他在 Slack、邮件、会议/Granola 上的注意力,维护一份“注意力清单”:他是否在一堆事故频道里活跃?是否在跟招聘团队敲定候选人?有人是否发来待审的发布博文?总管看到这些工作在发生,就能一边看着他工作一边隐含地维护优先级。

  • 引它和目标、优先级、待办清单的区别:它是从你的工作和注意力里“涌现”的。
  • 引两个用处:(1) agent 可以把它当作过滤器——一天里有上千条 Slack 和邮件会分散你的注意力,agent 用它把你的注意力引到与你当前关注相关的线程上;(2) 可以对比“声明的优先级和目标”与“我实际关注的东西”。
展开查看:建立注意力清单的提示词(官方原文)(约 185 字符)
Create an attention list: every hour, review email, Slack, Granola, and calendar and create a succinct set of projects I'm focused on and their current state, what needs to happen next.

引原文写作 “To set this up:” 后面的引号内容。

展开查看:使用方式 1(官方原文)(约 87 字符)
Review my attention list and archive any emails that are not relevant to my focus list.

引原文 “To use:” 后的第一句。

展开查看:使用方式 2(官方原文)(约 78 字符)
Where did I spend time this week that I can offload to an agent going forward?

引原文 “To use:” 后的第二句。

来源

24.2

研究新产品想法、以及“真的出货”

作者说最让他意外的是出货

研究新产品点子

  • 引产品团队的数据集越来越大:每次客户会议都被 Granola 和 Gong 录制转写;他们在客户 Slack 频道里;用户研究员 Stan 建了含每次访谈、用户洞察与综合的数据库;使用与订阅数据在 Databricks;支持工单在 Plain 或 Intercom;复杂的产品决策记录在 Notion。
  • 引挑战是让这些原始上下文对 agent “可读”。例如:“最近新接入的企业客户里谁在用某个功能?”“漏斗里客户卡在哪?”agent 能跨原始来源综合回答。
  • 引搭法:确保为所有核心客户上下文工具启用了插件,并在没有 MCP 的系统上,在 VM 里完成认证。

出货

  • 引他说最让他意外的是 Grok Bot 出货软件的能力:Grok Bot 现在占了他们内部合并 PR 的两位数百分比。
  • 引Grok Bot agent 能使用 Cloud Agents,在装有代码库、依赖、密钥、测试所需一切的环境里工作;对 PM 来说意味着可以“在更高的抽象层级操作”——不是管理一个个线程,而是向一个 agent 表达更复杂的目标,由它拆解并分配给其他 agent,再审阅和整合产出。

来源

24.3

“My Grok Bot team”:总管、工程经理、5 个工程 Bot、数据分析、PM Pete、招聘

总管是唯一的通才

Bot职责(原文转述)
Chief of Staff日历、Slack、收件箱;唯一的通才;拥有注意力清单;没有变化就保持安静。例:每小时归档 Gmail,除非线程点了他的名字且对应清单;上周它发了日程占位并请他选开始时间,他说 10 点,它就移了占位
Eng mgr(Emily)不写代码:拆解技术工作,委派给 IC 工程 agent,对照目标验证产出。入职时读了一位同事(@danielstjules)的全部 Slack,学习“什么是好”
Eng ×5工程 agent 起 Cloud Agents,从 EM 接活;能同时管很多个云 agent、验证测试它们的产出、彼此协调——“一路都是 agent”
Data analyst(Ashley)接数据仓库、出图、追踪目标,每天早上看仪表盘。他用得最多:让它“主要用综合好的图表和我说话”;以前这类问题因摩擦太高会无人回答;他不认为这会取代传统数据团队,困难、模糊、需要品味的问题仍归人
PM PeteRFC、调研、反馈、文档,“就在工作里”,也包括硬件。例:把一个频道/线程/私信里关于功能拆分的讨论变成带引用的 RFC(P0–P2);甚至一起折腾硬件:它查到一个缺的 Raspberry Pi 配件并在 Amazon 下了单,然后教他接线
Recruiter寻找未被发现的人才并管理招聘环节

引总管的“小技巧”:LLM 最大的抱怨之一是写作差,所以让它根据你的发件箱和 Slack 写一份个人风格指南,起草前再抽样对应线程,让它像你而不是像机器人。外部邮件发送、购买、删除等破坏性动作,他自己保留最终复核。

来源

24.4

“Why not one agent?”与四条经验

他的做法违背了“空白文本框 + 万能 agent”的范式

分给专职 agent 的三个理由

  • 引Referenceability:知道谁做什么。
  • 引Parallelism:许多个同时做离散任务、在共享任务上协调。
  • 引Scoped memory:它们在工作中学到不同的东西。另外,他觉得和这些不同的 agent 打交道更有趣。

四条经验

  1. 引Named agents, separate memory:每个 agent 有宽泛使命但记忆范围限定;“总管不该去调试 computer-use eval,eval agent 也不该归档我的邮件”。
  2. 引Agents learn on the job:可以从你过去的工作里学,也可以持续教。他认为最有杠杆的一句指令是:
展开查看:他说“杠杆最高的指令”(官方原文)(约 66 字符)
Read my past Slack messages and develop a Slack style guide for me
  1. 引Agents shouldn't be noisy:Grok Bot agent 偏向行动,但也可能过度沟通;让它们“除非有事需要你注意,否则保持安静”。
  2. 引Human on the important stuff:目前他仍亲自发大多数消息、改大多数文档和想法——既为“去 AI 味”,也因为对方想知道发消息的人为这个请求花了心思。

来源

§

来源汇总与没能访问的

没能访问的

  • 页面里每个 Bot 下方的 “View more” 展开内容和配图没有读取;除了三条 “To set up / To use” 的提示词,没有其他逐字提示词。
  • “Grok Bot 占内部合并 PR 的两位数百分比”是作者自述,没有具体数字。

来源

其他专题

↑