AI 助手接下的任务越来越多以后，几个问题会一起冒出来：每天整理的资讯能不能直接送到邮箱？已经反复解决过的问题，能不能留下以后可用的方法？重要报告做完了，过几天还能不能快速找到？
这期继续实测 Grok Bot，重点放在四类日常工作：专属邮箱、技能沉淀、Pages 资料整理，以及视频导演。它们看起来分散，实际都围绕同一个目标：让一次聊天留下可以继续使用的结果。
按创作者保存的字幕稿，本期已经报告了几类产物：收到的资讯邮件、生成的技能、可以找回的页面，以及武侠短片。也有仍停留在任务设置层面的部分，例如每天定时执行和同步到 GitHub。把这两类结果分开，才能判断哪些用法值得马上试，哪些还需要继续观察。
完整视频
如果播放器无法加载，可以前往 YouTube 观看完整视频。
视频于 2026 年 11 月 7 日发布，时长 8 分 6 秒。
先看产品范围：这次研究的是工作流
官方概览把 Grok Bot 定位为能够主动协助工作的 AI 队友。它把对话、电脑、应用连接和任务组织放在一起。因此，评价它是否好用，不能只看一条回答写得漂亮，还要看任务是否完成、产物放在哪里，以及下一次能否继续使用。
本期没有进行基础模型跑分，也没有记录各任务实际调用的模型版本、参数量、完整 Token 消耗或费用。视频标题中出现的其他助手是产品比较背景，并没有对应的同条件对照实验，不能据此给出谁全面胜出的排名。
截至 2026 年 11 月 7 日查询时，官方版本记录顶部的公开条目为 v0.78.1（2026 年 10 月 27 日）。这是产品更新记录，不能反推本次录制客户端一定使用该版本，更不能当作底层模型名称。账号资格、功能开放进度和用量限制也应以当前入门说明及账号界面为准，本期没有做套餐成本比较。
专属邮箱：先把资讯送达，再考虑定时安排
00:57 开始，创作者让 Grok Bot 领取邮箱地址，随后使用它订阅 AI 资讯。负责资讯的 Bot 再从邮件中提取值得关注的内容。
这个用法很适合把信息入口和个人日常邮件分开：订阅内容先进入 Agent 邮箱，再按主题、来源或重要程度整理，最后交付一份便于阅读的结果。不过，邮箱数量和归属需要说清楚。
一个账号共用一个地址
官方邮箱说明给出的地址形式是 @mail.grokbot.com，并明确写着 “Yours, not one Bot’s”。也就是说，这是账号的邮箱，自己的多个 Bot 共用，并非每创建一个角色就会自动得到一个独立邮箱。
视频口播将域名概括为 grokbot.com，实际配置应以产品返回的完整地址为准。官方还说明，领取后的地址不能更名或删除，因此选择名字前就应考虑长期用途。文章不展示演示账号的完整邮箱地址。
另外，收到邮件本身不会自动唤醒 Bot。如果希望某类来信触发处理，需要配置邮件触发的 routine。让它读已有邮件、定时整理资讯、遇到新邮件立即工作，是三种不同的运行方式，不能只凭“邮箱已经领取”就认为后两种也已就绪。
创作者还提出一种用法：在个人邮箱设置转发，把相关邮件送到 Bot 邮箱，再对特定来信发出提醒。这部分没有展示完整设置与触发验收。实际配置时，原邮箱的转发规则和 Bot 一侧的邮件 routine 都需要分别确认，涉及私人内容时也应先限定转发范围。
本期确认的是一次发送与收件
在 01:43 的测试中，创作者要求把当天的 AI 资讯发送到自己的邮箱。记录显示，Bot 整理内容后提示发送成功，创作者随后打开收件箱，确认看到了邮件。
这个结果比只看“发送成功”提示多了一步验证：真正去接收端检查内容。实际使用时，还可以继续检查原文链接能否打开、摘要是否遗漏重要前提，以及多条资讯有没有重复。这些是后续验收建议，并非本期已经完成的逐条事实核查。
随后介绍的是每天晚上 8 点发送资讯的任务设置。这里有一个会直接影响使用预期的限制：当前官方文档明确不支持无人值守外发邮件。 用户在聊天里明确要求发送的邮件需要经过 Auto Review；由 routine 等后台任务产生的邮件会停在草稿，需要用户按下 Send。
因此，本期的一次邮件到账和定时任务配置，不能扩写成“以后每天 8 点一定会自动寄出”。更稳妥的安排是让它按时准备好内容，再完成必要的发送确认，同时查看实际运行记录。长期是否准点、是否会漏信，本期没有连续多日测试。
技能沉淀：把反复发生的工作整理成可复用方法
02:24，创作者为这项工作建立了一个专职 Bot，命名为“skill 沉淀员”。任务要求是每天晚上 8 点检查工作与对话，把方法、过程和经验整理成技能，并同步到 GitHub。
这种组织方式的价值在于，原本散落在聊天里的“下次记得这样做”，可以变成有名称、有适用范围、有具体步骤的工作说明。以后处理同类任务时，就有机会直接复用。
这次具体留下了什么
本期记录中，Bot 报告已经沉淀了两条技能，创作者实际打开介绍的是其中一条“团队文件交付登记”技能。它要求在交付新文件时，把文件放入团队共享文件库并登记，还给出了存放位置。
这个案例很具体。它处理的不是抽象的“提高智能”，而是常见的协作问题：文件生成了，却不知道最后放在哪里；同一份成果重复交付；后来负责检索的角色缺少入口。将交付位置与登记步骤写清楚，可以让后续工作少依赖临时记忆。
但应保留证据范围：本期介绍了一个已打开的技能，另一条技能的完整内容没有在这段记录中展开；同步 GitHub 是任务要求，也没有提供可逐项核对的提交结果。不能将这两点补写成已经验证成功。
Skill 与 routine 各管一件事
官方说明把 skill 定义为完成某类任务的一组可复用指令，而 routine 决定任务何时执行。前者解决“怎么做”，后者解决“什么时候做”。
因此，复盘后更新 skill，改变的是后续工作的流程和约束。本期没有模型训练、权重更新或前后能力测量，不能把它称为底层模型自主进化。视频中“越用越聪明”的体验，更适合解释为工作方法逐渐积累、重复说明减少。
如果要借鉴这套方式，可以先挑一项反复出现的工作，完成并验收一次，再把步骤保存为 skill。官方也建议先验证流程，再添加自动化。对自动整理出的技能，尤其要检查三件事：是否把一次临时选择误当成固定要求，是否与已有流程冲突，是否带入了账号、密钥或不该共享的文件内容。
Pages：把长对话变成可回看的工作成果
03:39 开始，创作者介绍了团队周报、Hugging Face 趋势榜等 Pages。记录中提到表格、图表以及切换标签查看不同模型信息，主观感受是布局清楚、阅读方便。
随后在 04:57 又把视频生产线看板整理成 Pages。它解决的实际问题很简单：当聊天越来越长，重要结论不应只能靠不断向上翻页寻找。整理成有标题、有结构的页面后，用户可以直接回到成果本身。
页面能保存，不等于所有交互状态都会保存
官方文件与结果说明将 Pages 用于报告、备忘录、仪表盘和跟踪器，也允许让 Bot 或 routine 更新内容。但文档同时明确：页面上的交互操作不会保存，筛选、开关等控件主要用于改变当前显示。
例如，一个模型趋势页可以让人切换查看不同内容；这并不能直接推导出它已经具备持久化数据库、多人同步编辑或保存表单输入的能力。需要改动页面内容时，应明确让 Bot 更新，并检查更新后的结果。
视频把它概括为不会随着长对话而丢失的资料入口，这种使用思路是合理的；“永久不会删除”则不应成为无条件承诺。重要交付物仍应保留清楚的名称、版本和适当备份。
官方文档还说明，Pages 默认私有，开启持链接可见后，访问者可能无需登录。分享之前要先看一遍页面有没有私人信息、尚未公开的项目内容或内部链接。交互性和漂亮排版，都不能替代这一步检查。
文件检索员：角色分工要落到能找回正确文件
到了 05:17，创作者又创建了“文件检索员”Bot，专门负责寻找重要文件。测试请求是查找与视频生成相关的 Pages，记录显示它找到了刚才由主 Bot 生成的视频生产线页面。
这段演示的价值是一次具体交接：一个角色负责生成，另一个角色负责找回。前面的文件交付登记技能、这里的 Pages 和检索职责，也就有了实际联系。
不过，找到这一份页面，并不能说明它天然拥有所有 Bot 的全部历史、所有上传文件或所有云端开发产物。当前官方文档就指出，Library 列表并不覆盖用户上传内容和 Cloud Agent 返回的全部文件。
实践中，文件命名、存放位置、访问权限和索引仍然很重要。让检索角色返回标题、用途、版本和可访问入口，比只回复“找到了”更容易验收。若同名文件有多份，应先确定哪一版是当前交付物，再把它交给下一步工作使用。
视频导演：先把创作意图说清楚，再选择生成路线
05:53，创作者建立“视频导演”Bot，并安装 video-director 技能。接下来从一句场景描述出发：南宋临安街巷，一位侠客骑马经过。
这一段最值得借鉴的是需求澄清过程。记录中依次出现了画幅、时长、白天或夜晚、氛围、画风，以及声音处理方式。声音例子包括配乐、马蹄声和集市环境声。
最后形成的方向是侠客骑马穿过酒旗与茶摊，镜头像展开一幅青绿手卷。如果对提示词不满意，可以继续修改，满意后再进入制作。这能把“给我做一个好看的视频”拆成可讨论的具体选择，也减少成片出来后才发现风格完全不对的情况。
代码动画和原生视频模型应分别看待
在 07:05，创作者介绍了代码生成动画与调用内置视频模型两条路线。
当前 video-director 仓库说明明确表示，它是一套指令与质量检查技能，并非内置模型或托管视频生成服务。其 SKILL.md主要面向 HTML、Canvas、SVG、Three.js、GSAP、Remotion 等代码动画，把导演方案、时间线、实际渲染样张、音频、成片检查组织成流程。
这意味着，安装技能本身不会凭空提供一个视频模型。代码动画适合需要精确控制文字、图形和时间节奏的内容；Grok Bot 的原生短视频功能则是另一条产品能力，官方描述的时长范围为 1–15 秒，默认 6 秒。实际调用哪条路线，应该在任务里明确。
视频中建议在担心 Token 不够时考虑代码方式，但本期没有两条路线的相同任务、完整消耗和耗时记录。因此，这只能作为创作者的使用建议，不能据此给出“代码一定更省”“模型一定更好”的普遍结论。代码实现复杂度、渲染成本、修改次数和画面要求，都会影响最终选择。
十五秒武侠短片说明了什么
07:25 的案例要求生成一段 15 秒香港 TVB 风格武侠打斗场景。创作者记录称，这次调用的是内置视频生成模型，并在口播中介绍了生成结果。
这里可以确认的是创作要求和创作者报告的生成路线与结果。15 秒是请求目标，本文没有取得输出文件进行独立时长测量，也没有逐帧核验动作连贯性。记录中未给出具体后台型号、分辨率、帧率、生成次数或费用，不能用仓库当前推荐的模型名称代替本期实际调用信息。
如果要把这段流程用于正式作品，建议检查人物与服装是否连续、手与兵器接触是否合理、动作有没有突然跳变、声音与画面是否同步。对代码动画，还应检查文字清晰度、帧率和时长。仓库提供检查流程，是可用的工具条件；是否真的执行并通过，仍要看具体产物的验收记录。
怎样把这些用法接进自己的工作
本期四类用法可以各自开始，没有必要一次性全部自动化。对个人创作者而言，比较容易落地的顺序是：
- 先做一个能验收的小任务。 例如只整理一次资讯邮件，检查来源与接收结果，再决定是否设置周期任务。
- 把已经奏效的方法存下来。 技能写清输入、步骤、交付位置和失败时如何处理，而不是堆一长串泛化要求。
- 为重要产物建立固定入口。 用 Pages 或文件目录保存结论，保留版本，避免不同角色各自留下难以区分的副本。
- 检索和执行分开验收。 找到正确文件后，再交给负责制作或开发的角色；找到文件不等于后续任务已经完成。
- 创作任务先定方向。 在生成视频前，明确画幅、风格、声音和交付标准，再选择代码动画或原生视频路线。
这期最有参考价值的，不是给 Bot 增加了多少角色名称，而是这些角色开始留下能复用的工作成果。资讯有送达记录，经验有具体技能，资料有固定页面，创作有明确方案。下一步需要持续验证的，则是自动化的运行可靠性、文件版本管理和产物质量。
对于长期使用 AI 助手的人，值得积累的是经过验证的方法和能找回的结果。 当这些基础做好以后，角色分工和定时执行才更容易产生稳定价值。
资料来源
- AI超元域本期完整视频与章节
- Grok Bot 官方概览
- 电脑、应用与专属邮箱
- Skills、routines 与自动化
- Pages、文件与视频结果
- Grok Bot 入门与可用性
- Grok Bot 公开版本记录
- video-director 开源仓库
案例依据与本期章节逐项匹配的作者保存字幕稿整理，覆盖 00:02.700–08:03.133；YouTube 字幕导出不可用，画面播放停在缓冲，本文未独立复跑任务或测量成片。官方资料核对截至 2026 年 11 月 7 日。