Grok Bot产品设计：从聊天记录到Bot名单

Grok Bot 官方的产品设计思考，强烈建议阅读原文： https://t.co/uocbsbJgQr 来自 @bot 团队设计师 @pengzheng_ 阐述了团队如何为跨越单次会话的智能体设计...

Grok Bot 官方的产品设计思考，强烈建议阅读原文： x.ai/news/designing… 来自 @bot 团队设计师 @pengzheng_ 阐述了团队如何为跨越单次会话的智能体设计 Grok Bot：从聊天记录到 Bot 名单、从状态感知到 Bot 专属的电脑，直到无需提示词就自行开始的工作！ # 重新定义产品原语：从十几个概念收敛到五个 AI 产品短时间内积累了大量术语（session、context window、system prompt、connector、sandbox、automation……）。 xAI 认为把每个概念都暴露给用户是负担，于是收敛为五个用户真正需要理解的对象： Bot：持久的代理，拥有独立身份、记忆、运行时和工具 Chat：与 Bot 交互的对话界面 Prompt：给 Bot 的上下文或指令；可一次性使用、保存为 Skill、或自动触发为 Routine Tool：Bot 获取信息和执行动作的能力（API、连接器、shell、computer use） Artifact：Bot 产出或修改的持久成果（文档、代码、数据等） 其余概念全部下沉到界面之下。这是典型的"降低认知负荷"设计思路，也是全文所有后续决策的基础。 # 组织单元从"聊天记录"换成"Bot 名单" 最关键的一步！团队观察到：聊天是一次性的，用户很少回看五条之前的对话。这在"提问—回答"模式下合理，但当对方本应记得你、记得过去的工作、并长期负责时，以对话为中心就显得别扭。 所以 Grok Bot 的侧边栏是Bot 名单而非聊天历史。每个 Bot 有名字、头像、职称、记忆、自己的电脑和工具——明天回来面对的是同一个 Bot。这实际上把心智模型从"工具"切换为"同事"。 # "在场感"即界面：一个头像回答三个问题 Bot 出现在界面上时要同时回答：这是谁？在做什么？我需要知道多少？ 是谁：头像要在侧边栏尺寸下可被"余光识别"，又要保持系统一致性。团队考察了首字母、emoji、像素画、水彩、黏土、线稿、剪影、identicon 等方案，结论是：细节多的（水彩、黏土）个性足但缩小后过载，简洁的又容易千篮一面。最终方案：统一的基础构造（简单形状 + 表情化的眼睛），通过受控的变化和配饰制造区分。 在做什么：不另加状态指示器，而是让头像动画本身承载生命周期——闲置、思考、工作、等待、阻塞、完成。这是"减少一层需要解读的 UI"。 需要知道多少：三个跳动的点信息太少（分不清工作中还是卡住了）；展示完整步骤流又会让用户想看全部。用户研究发现，人们要细节主要是为了确认 Bot 还在正常工作。最终折中：头像动作提供第一层安心感，悬停才显示当前动作。 # "它的电脑，不是你的" 每个 Bot 有独立的计算机（浏览网页、处理文件、运行软件）。设计难题是这台电脑该多显眼。团队试了浮窗、并排、模态框、全屏四种布局，得出一个重要洞察：电脑越显眼，产品就越在鼓励用户去监督它——这与"委派"目标相悖。 最终采用三级访问： 状态：标题栏图标在电脑活跃时变紫 预览：固定侧面板，不离开对话即可跟进 接管：Bot 需要帮助时，用户全屏接管、完成后交还 一个细节：Bot 电脑的壁纸随一天时间变化（早亮晚暗），目的是让它有自己的时间感，与用户桌面区分开。文章的类比很准确：像和同事协作——知道他在干活，需要时看一眼他的屏幕，出问题时坐过去帮一把。 # 信息的形态是答案的一部分 早期版本几乎全用散文回复：描述五天天气而不是展示天气卡，叙述任务列表而不是排成看板，用户得自己重新组织。于是引入内嵌卡片和小组件，让 Bot 在适合时用结构化 UI 回答。 同样的原则用于动作：创建 Routine、修改设置、给另一个 Bot 发消息等事件直接出现在对话流中，可点开查看。结果是一条异构时间线——对话、系统事件、可交互对象、可视化共存。 # 组织多个 Bot：能力共享、上下文按角色隔离 用户创建多个 Bot 后，涌现出一种用法：建一个"幕僚长"Bot 统筹多个专家 Bot，用户只对一个 Bot 下指令，不用自己当调度员。 由此确定了一条清晰的架构边界： Tools 和 Skills 放在账户层（很多 Bot 都需要浏览网页、发邮件） Memory 和 Routines 属于 Bot（反映该角色的专属认知和职责） 即：能力可以广泛共享，上下文留在需要它的角色那里。理由很务实——把法务 Bot 的纠纷历史和财务 Bot 的多年账目混进一个大记忆，只会让各自更难拿到相关信息。 跨角色协作用群聊解决：为项目提供共享上下文，同时每个 Bot 保留专属记忆。团队考虑过仪表盘、任务分配板、显式交接控件，但都被否决——每一个都在给用户增加协调工作。改为由协调型 Bot 处理日常路由，只在需要人判断时把用户拉进来。 # 不需要提示词就开始的工作 多数 Agents 会话由用户发 prompt 启动，即便是持久 Bot 也只是"在等人激活"。Routine 让用户一次性定义长期职责，按日程（每天 8 点、每周一、每 30 分钟）或事件（Issue 创建、PR 合并、CI 失败、Slack 消息、webhook）触发。 一个演进细节：Routine 起初被当作次要配置项，随着自主工作越来越重要而被提到 Bot 主界面。对话流中会显示"运行了什么"，供用户审阅结果或处理异常。这改变了对话的角色：会话的起点可以是 prompt，也可以是日程、事件、或另一个 Bot——越来越多工作会在用户不在场时开始。 # 做减法 项目后期大量工作是删东西：窗口/面板控件、电脑视图选项、代理元数据都被拿掉。还设置了硬性限制——每账户约 50 个 Bot，每群聊最多 6 个。 每个决策都回到同一个问题：这是在帮人委派，还是在给人多一件要管的事？ Peng Zheng @pengzheng_ wrote down some of the design thinking behind Grok Bot. persistent roles, clear state, scoped context, coordinated teams — an interface designed to move you from operating AI to delegating work. x.ai/news/designing… Your browser does not support the video tag. 🔗 View on Twitter 🔗 View Quoted Tweet 💬 0 🔄 0 ❤️ 3 👀 871 📊 2 ⚡