Grok Bot 两位核心成员公开 14 个私藏 Bot
Grok Bot 团队成员 Peng Zheng 和 Lauren Tan 在专访里首次系统展示自己的真实配置：从生活采购、订机票到设计、写代码、自动合 PR，并总结出从手动指挥到信任放权的方法论。
Grok Bot 两位核心成员的 14 个私藏 Bot 与全自动工作流 Grok Bot 两位核心成员 @poteto 和 @pengzheng_ 在 @petergyang 的专访中，首次系统性公开自己的真实使用配置：从生活采购、订机票，到设计、写代码、自动合并 PR，他们已经把 Grok Bot 当作“一群可托付的虚拟员工”在每天使用。在访谈中，他们总结出了从“手动指挥”到“信任放权”的渐进方法论。 Youtube 视频：https://www.youtube.com/watch?v=xZ5TEaleUdg 1. Peng Zheng 的配置：个人生活的“总智能体 + 专家群” Peng 把所有数字世界的事务分为工作与生活两类，最常用三个 bot： Chief of Staff（首席智能体）：兜底入口。不知道该派给谁的任务就发给她。典型例子：买 3D 打印耗材，不只下单，还自动更新他的 Notion 库存清单（按颜色追踪）。卖二手 DJI 麦克风更典型：一条指令串起查官网价格、调研同城竞争报价、学习他过去的文案风格、上架、以及无人问津时每周自动降价 5 美元。执行中它还会主动去“咨询”Writer bot 怎么写文案，bot 之间的自主协作已经发生。 Designer / Writer bot：Designer 通过 Figma MCP 直接改设计稿、用他的 design token；他的新工作流是“我做前 5%”，定好系统、画一个关键帧，然后让 bot 扩展成完整端到端流程。Writer bot 负责润色邮件和 Slack 消息（英语非母语），在 Slack/邮件小窗里内联出稿、他审后发送。 多角色群聊：把 PM bot、Designer bot、Engineer bot 拉进一个群，扔进一个想法（比如“粤语邮件翻译 App”），看它们互相辩论、各自从职能视角给意见。想指定谁回答就 @ 谁，否则它们自行判断是否接话，像真人群聊一样。 两个有趣的延伸：播客 bot 把任意文章链接转成播客供开车时听（“格式的终极翻译器”）；以及他把旧金山唐人街拍的一张照片，做成自动化的“打卡 App” pipeline，发照片 + 同行人的社交账号，bot 自动生成日间/夜间两版黏土风图片、抠图、发布到个人网站，而整个“playbook”存在私有 repo 里由 bot 拉取执行。Grok Bot 在这里变成了个人网站的发布后台。 2. Lauren Tan 的配置：工程向的“米其林厨房” Lauren 展示的是硬核工程用法： 控制虚拟机：为了给 Omachi（DHH 等人做的 Linux 发行版）做适配，她让 Grok Bot 直接操控跑在 Mac 上的 Linux 虚拟机，Grok Bot 有自己的电脑，同时通过本机执行守护进程控制她的电脑。核心逻辑是：agent 必须能自己验证自己的工作。 P-Stack 技能栈 + 自动化评测：改一个 skill 前先跑 eval，bot 会拉起多个不同模型的子 agent 试跑 prompt，确认目标达成才允许合 PR。 “米其林厨房”：她对“软件工厂”这个说法的修正是本场金句之一，工厂让人联想到 slop，她要的是 quality at scale，像米其林餐厅一样既有工艺又有规模。 最激进的信任：因为 Grok 代码库架构本身是 agent-friendly 的，她经常在 PR 合入之后才去看，看完觉得“哦，挺好”。 Dr. Eggbot（造 bot 的 bot）：bot 设计师，负责以工程严谨度生产新 bot，取名全是食物系（大福、饺子、抹茶）。它还会定期巡检所有 bot 的对话记录，提出改进建议，并优化 routines 的执行频率，因为 routine 跑太频繁会持续唤醒 agent、烧掉大量用量。 Tsuki（个人助理）：完成了她最大金额的自主操作，只给了一条含会议信息的 Slack 链接，就通过公司差旅系统订好橙县→丹佛→伦敦→阿姆斯特丹的多段航班和会场附近酒店，只在最后点“确认”前请示了一次。Tsuki 甚至有自己的第三方手机号，会发短信提醒她吃午饭（她开着勿扰模式经常看不到 App 通知），并会用 DoorDash 直接下单。 Potato（社交 bot）：每 30 分钟轮询 X 上的提及（她在 X 有个梗：连打三次 potato 就会触发通知），聚合同类 bug 反馈。关键设计：她可以直接对工程师 bot 说“去找 Potato 了解情况，回来给我修复方案”，上下文在 bot 之间自动传递，不需要人类复制粘贴。这把社交渠道变成了产品反馈的“外环”，直接接入工程师“内环”。 3. 产品设计哲学：为什么是“有名字的常驻 agent” 访谈后半段是全场最有思想密度的部分。Peng 的框架： 三层工作形态演进： ① 过去人直接操作工具（Figma 里画框、Slack 里打字）； ② 现在是 prompt AI 代劳； ③ 未来是人设计系统，让 bot 与 bot、bot 与人自主协作。 多数 AI 产品仍停留在“以模型为中心”（围绕模型造 harness 再包一层产品 UI，满屏技术黑话），而 Grok Bot 的实验是让系统模型对齐用户的心理模型：现实中你不需要懂保险公司怎么运作，你只需要知道该给谁打电话。把 agent 人格化、命名、常驻，正是复用了这个直觉。 两个关键架构决策： · 聊天是易耗品，bot 是资产。AI 产品里的会话大多一次性、两周后再也不回看；而把可复用的能力、记忆、工具沉淀到“角色”里，临时项目再开专门会话，就兼顾了沉淀与灵活。同一个 Designer bot 可以同时服务多个项目的不同会话，身份与记忆仍是同一个。 · 能力共享，记忆私有。工具、连接器、技能是全局共享的，但记忆和偏好归属每个 bot 本身，这就是为什么“你的助理和我的助理注定长成不同的样子”，使用过程本身就是个性化过程。 团队内部也是如此：Lauren 开源为 potato mode 的技能，内部叫 Lauren mode；Peng 有 Peng mode；让工程师以外的人（设计师、PM）也能给代码库做高层贡献，是重构 Grok Bot 代码库的核心动机。 4. 方法论提炼：从下载到放权的路径 面对 Peter “我总怀疑‘睡觉让 bot 干完一切’的宣传” 的追问，两人的回答构成了本视频对普通用户最有用的部分： 1. 从一个简单任务开始，刻意“过度拉伸”它；Peng 至今仍在测试边界：凡是碰到键盘鼠标的事都试着委派出去，看看极限在哪。 2. 观察 + 纠偏 → 固化为 skill。Lauren 的核心论点：一切归结于信任（trust）。没有捷径，先花时间看着 bot 干活、随时纠正；一轮跑顺后把流程沉淀成可复用的 skill，做到一条命令（如 /expense-report）一次成型。 3. skill 稳定后才升级为 routine（如“收到含收据的邮件就自动报销”），这时才真正可以走开。跳过前两步直接放权必然翻车。 4. 注意成本：routine 频率过高会持续唤醒 agent、消耗配额，需要调优（Dr. Eggbot 会帮忙做这件事）。 5. 心智模型：像 onboard 新员工。信任随观察逐步建立，先带着做、再盯着做、最后放手。终点是“人人都能当产品的 CEO”：你做高层战略决策，执行层全部委派。
这条是引用着另一条写的：x.com/petergyang/status/2104213287353356531