这篇文章主要复盘了 Grok Bot 的设计过程，包括为什么选择以 Bot 而不是聊天记录作为产品的组织单位，以及围绕这一决定做出的一系列交互设计。Agent 有自己的身份、记忆，甚至拥有一台独立的电脑，这些概念本身并不算新鲜。
我觉得这篇文章真正值得学习的，不只是最终的设计方案，而是设计师如何从具体问题出发，一步步做出取舍，并把这些取舍解释清楚。下面主要从设计、思考方式、设计细节和作品集叙事四个角度，记录一些自己的收获。
01. 设计层面：用户到底需要看到多少？
文章里有一个贯穿始终的问题：用户究竟需要知道多少信息，才能放心地把任务交给 Bot？比如 Bot 的运行状态，他们没有额外增加一个状态指示器，而是直接通过头像动效来表达空闲、思考、工作、等待、阻塞和完成等状态；执行过程也是类似的思路。用户研究发现，用户想查看 Bot 的执行步骤，很多时候并不是想了解每一步具体做了什么，而是想确认它还在正常工作、方向没有出错。所以最终方案默认只展示头像动效，用户悬停时才显示当前正在执行的动作；Bot 的电脑视图也经历了多轮尝试，从浮窗、并排布局到弹窗和全屏。团队发现，电脑视图越显眼，用户就越容易把注意力放在观察 Bot 的操作上，反而没有真正把任务委托出去。因此，最终将电脑的呈现方式分成了三个层级：状态、预览和接管。
这几个设计决策其实都在解决同一个问题：哪些信息是用户必须知道的，哪些信息只需要在用户主动查看或需要介入时出现？我觉得这里有一个很重要的区别：减少信息展示，不等于减少用户的控制权。真正的目标是让用户不需要持续关注任务，但在关键时刻依然能够了解情况、做出判断或接管操作。
这也让我想到之前做的 AI 粘贴录入项目。当时我们的设计目标之一，就是尽量让 AI 自动完成可靠的操作，只在无法准确匹配字段时，才让用户在写入前确认字段关系。我们把它定义为建立信任机制，而不是让用户在写入之后再去纠错。这和文章中 Bot 只在需要帮助时请求用户接管的思路，其实非常接近。但回头来看，我们当时更多是在解决一个具体流程中的问题，并没有进一步把它总结为一套通用的设计原则。我觉得可以改进的地方，是在 AI 相关设计中更明确地定义用户介入的边界。 比如，什么情况下 AI 可以自动执行？什么情况下需要展示过程？又在什么情况下必须等待用户确认？这样一来，设计原则就不只是某个项目的结论，而是可以用来判断后续方案是否合理的标准。
02. 思考层面：先确定产品围绕什么组织，再考虑界面怎么设计
文章里另一个让我印象比较深刻的地方，是他们没有一开始就讨论界面怎么布局，而是先确定了产品最核心的组织单位是什么。传统 AI 产品往往围绕聊天记录来组织信息，但 Grok Bot 选择了 Bot 作为核心对象。因为在他们的设定里，Bot 不是一次性的对话，而是一个能够长期存在、持续执行任务的 Agent。这个决定直接影响了后续的整个信息架构，包括侧边栏如何组织、不同 Bot 之间是什么关系，以及工具、记忆和任务应该如何分配。其中一个很具体的例子是：工具和 Skill 在账号层级共享，而记忆和 Routine 则属于各个 Bot。这个划分并不是单纯从技术架构出发，而是基于一个很容易理解的使用场景：一个负责法务工作的 Bot 和一个负责财务工作的 Bot，可以使用相同的工具，但不应该共享同一套工作记忆。
我觉得这种从具体场景推导设计规则的方式很值得学习。因为我们平时做设计，也经常会提炼一些原则，比如一致性、可扩展性或者降低认知负担。但如果这些原则只是一些比较抽象的描述，就很难真正指导设计决策。这篇文章提供了一个比较清楚的思路：先找到一个能够暴露问题的典型场景，从中推导规则，再用其他场景去检验规则是否成立。
另外，文章中很多看似独立的设计决策，实际上都能回到同一个判断标准：这个设计究竟是在帮助用户更好地委托任务，还是又增加了一件需要用户管理的事情？有了这个标准，不同方案之间的取舍就不再只是个人偏好，而是有了相对统一的依据。
这对作品集的启发也比较直接。以前写项目时，我可能会把设计规则和判断依据整理成几个独立的要点，但读者未必能理解这些规则是怎么来的。之后可以更有意识地展示那个促使我们建立规则的具体场景，再说明这条规则如何帮助我们处理其他类似问题。比起直接告诉读者最终采用了什么规则，让读者看到规则是如何被推导出来的，可能更能体现设计思考。
03. 其他设计细节：一些值得记录的小发现
除了整体的设计思路，文章里还有三个细节让我觉得很有意思。
第一，信息的呈现形式，本身就是答案的一部分。比如用户询问天气，系统应该直接展示天气预报卡片，而不是用一段文字描述天气情况。创建 Routine 也是类似的道理。既然用户完成的是一个创建任务的操作，那么这个结果就应该直接以事件的形式出现在时间线中，而不只是得到一句文字回复。这一点让我想到，AI 产品的输出不一定要始终保持对话形式。关键还是看用户想完成什么任务，以及什么样的信息结构最适合承载这个结果。
第二，设计隐喻需要在细节上保持一致。文章提到，Bot 的电脑壁纸会随着时间变化而变亮或变暗。虽然只是一个很小的细节，但它强化了 Bot 拥有独立工作环境和时间状态的感觉。既然产品希望用户把 Bot 理解为一个能够独立工作的主体，那么不只是功能架构，视觉和交互细节也应该尽量符合这个设定。我觉得这里值得关注的不是壁纸效果本身，而是设计师有没有持续检查：这些细节是否在支持产品最初建立的概念？
第三，限制和删减同样是设计决策。文章中提到，项目后期做了不少减法，比如去掉多余的窗口控件、电脑视图选项和 Agent 元数据。他们还为产品设定了数量上限，例如一个账号大约可以拥有 50 个 Bot，群聊最多支持 6 个 Bot。这些数字并不是简单作为技术规格出现，而是被放在设计决策的语境下讨论。
04. 叙事方式：比起展示最终方案，更重要的是解释为什么这样选
最后一个收获是文章的叙事方式，这也是我觉得最值得参考到作品集里的部分。它没有严格按照常见的「背景—目标—方案—结果」来组织内容，而是围绕一个个具体的设计问题展开。比如，侧边栏应该放什么？Bot 的执行过程应该展示多少？电脑视图应该有多显眼？多个 Bot 之间应该如何协作？每提出一个问题，文章都会介绍团队尝试过哪些方案、遇到了什么问题，最后再说明为什么选择现在的设计。
其中不少篇幅都在讲被放弃的方案。比如电脑视图尝试了四种布局，头像探索了多种视觉风格，多 Bot 协作也考虑过不同协调机制。这些探索并不是简单地展示方案 A、B、C，而是让读者理解：每个方案为什么出现，又为什么最终没有被采用。我觉得这种写法最大的价值，是它展示的不只是设计结果，还有设计师的判断过程。
文章的标题也很值得参考。像 Their computer, not yours、The shape of information、The disappearing interface，都不是单纯在介绍某个功能，而是在表达一个观点，或者提出一个值得讨论的问题。读者即使没有看正文，也大概能够理解这一节想要讨论什么。段落的写法同样比较直接。通常先介绍尝试过的方案，再说明从测试或研究中发现了什么问题，最后解释因此做出了什么决定。整个过程几乎不需要太多抽象的形容词，因为具体的设计事实已经足够支撑结论。
另外一个值得注意的地方是，用户研究并没有被单独放在某个章节里，而是直接成为设计取舍的依据。比如用户为什么想查看 Bot 的执行过程，这个研究发现直接解释了为什么最终没有选择持续展示完整操作步骤。这样处理之后，研究、探索和设计决策之间的关系会更加紧密。
总结：4 个 Key Takeaways
- 让用户在必要时介入，而不是持续管理 AI：AI 产品不需要默认展示所有信息，而应该根据任务的确定性、风险和用户需求，决定哪些操作可以自动完成、哪些过程需要可见，以及什么时候必须请求用户确认。关键是明确用户介入的边界。
- 从具体场景推导规则，再用规则指导设计：不要只在项目结束后总结几个抽象的设计原则。更重要的是找到能够暴露问题的典型场景，解释规则为什么成立，并验证它能否解决其他类似问题。
- 输出形式、交互细节和数量限制，都需要有明确的设计依据：不只是主要交互流程，小到 AI 结果的呈现形式，大到组件的数量上限，都可能影响用户对产品的理解和使用方式。值得关注的是这些设计如何服务于整体目标，以及背后做出了什么取舍。
- 少展示方案的数量，多解释方案的取舍：好的设计复盘不只是展示做了什么，更需要解释为什么这样做。通过具体问题、被否决的方案、研究发现和最终决策，让读者看到设计判断是如何形成的。