当你花时间调优出一个熟悉特定工作流、挂载了必要插件、能按固定频率自主执行任务的 AI Bot 时，团队成员往往希望能直接复用这个现成的助手。但在日常协作中，如果只是复制粘贴提示词，对方需要从头重新配置技能、插件和自动化触发机制，步骤繁琐且容易遗漏细节。

为了让知识工作流更容易传递，xAI 为 Grok Bot 推出了模板（Templates）机制。官方将模板比喻为“食谱而非做好的菜肴”（a recipe, not a meal）——它并不是原 Bot 运行状态的一对一克隆，而是提供一份让其他人能够据此启动独立 Bot 副本的设计蓝图（blueprint）。xAI 宣称这是“知识工作首次实现广泛可用的共享方式”（first widely available way to share knowledge work）。

协作痛点：为什么只复制提示词跑不通完整工作流

在日常协作中，一个深度调优的 AI Bot 往往不再是一段简单的纯文本提示词，而是融合了指令、技能、插件，以及按设定频率自主运行的例行触发器（Routines）。只复制提示词，会漏掉这些互相关联的部分：

• 结构没有一起过去：接收者拿到文字，却不知道原 Bot 用了哪些技能、插件和触发器，也不知道哪些外部服务需要另行准备。
• 私有内容不能照搬：官方明确说，模板默认排除个人或内部记忆，也不会包含自定义代码和脚本。模板有意留下了一些必须由接收者自己补齐的部分。

Grok Bot 的模板（Templates）机制把 Bot 的一部分工作框架整理成可分享蓝图，让接收者据此创建自己的版本。它减少了从零组装的工作，但不承诺把原 Bot 的全部状态和外部环境原样搬过去。

机制前提：模板是设计蓝图，不是运行状态的一对一克隆

理解模板机制的关键在于厘清它的传递边界。官方明确将模板比喻为“食谱而非做好的菜肴”（a recipe, not a meal）——它传递的是一套包含技能（skills）、记忆（memories）与插件（plugins）设定的设计蓝图（blueprint），而不是原 Bot 的一比一克隆（not a 1:1 clone）。

生成模板时，系统会处理以下几类内容；其中有些会被复制，有些只在打包过程中被读取：

模板包含或在生成时读取的内容：

• Bot 系统指令（Bot Instructions）：复制原 Bot 的指令，作为新副本的工作基准。
• 相关记忆与技能（Relevant Memories & Skills）：相关记忆与技能会被复制到模板中。
• 例行自动化触发器（Routines）：系统生成模板时会读取 Routines。官方把它解释为让 Bot 自行运行的触发器，例如控制运行频率；页面没有进一步说明每条 Routine 如何进入新副本。
• 特定插件（Specific Plugins）：模板会复制特定插件；页面最后进一步概括为第一方插件和技能会包含在模板中。

模板明确排除（不包含）的内容：

• 个人与内部记忆（Personal or Internal Memories）：系统默认排除创建者的个人偏好或内部记忆，避免私密信息流出。
• 自定义代码与脚本（Custom Code & Scripts）：敏感的本地脚本或自定义代码不会被打包进模板。
• 非标准插件与自定义 MCP 服务器（Non-standard plugins & Custom MCP servers）：非标准插件及外部 Model Context Protocol（MCP）服务器不会包含在模板中，无法通过模板直接传输。

发布前准备：对照边界盘点六项关键依赖

基于官方划定的内容边界，在点击打包前，发布者可以先做一次依赖盘点。下面是本文把官方边界转成的操作建议，不代表 Grok Bot 另有一套自动审计或配置界面：

1. 检查个人与内部内容（Personal/Internal Information）：系统默认排除个人或内部记忆，但如果敏感信息直接写在 Bot 指令或准备分享的说明中，也要在发布前自行检查。
2. 确认插件与技能（Plugins & Skills）：列出工作流依赖的插件和技能，并告诉接收者哪些插件在新 Bot 中需要重新安装。
3. 核对例行触发器（Routines）：列出 Bot 依赖的运行频率或触发条件；官方页面只说明生成模板时会读取 Routines，没有交代迁移细节，因此不要假定它们已经自动恢复。
4. 整理自定义代码与脚本（Custom Code & Scripts）：模板不会打包自定义脚本和代码。若工作流依赖它们，需要另行提供获取与部署方式。
5. 梳理外部凭证（API Keys & Endpoints）：列出工作流所依赖的所有第三方服务 API 密钥及访问端点，明确告知使用者需要自备哪些权限凭据。
6. 说明自定义 MCP 服务器（Custom MCP Servers）：若原 Bot 连接了自定义 MCP 服务器，必须准备好本地部署与连接指导，使用者无法直接通过模板获得现成的服务连接。

对于依赖 API Key、自定义 MCP 或其他外部组件的复杂模板，官方说可以让 Bot 把安装说明（setup instructions）编入模板。以下是一份根据官方边界整理的依赖说明骨架，供发布者在编写 Bot 指令或分发附言时参考：

本文根据官方边界整理的填写骨架（非官方界面字段）

• 工作流用途：简要说明该 Bot 解决什么任务。
• 随模板提供的插件与技能：列出打包包含的官方第一方插件与技能名称。
• 接收者需重新安装的插件：提示接收者在创建副本后需要重新安装哪些组件。
• 未随模板打包的外部依赖：说明需要单独获取的自定义脚本、代码文件或自定义 MCP 服务器地址。
• 需使用者自备的凭证：列出需自行申请并填入的 API Key 或服务鉴权信息。
• 安装后首个验证任务：提供一条用于快速测试端到端链路是否畅通的标准指令。

发布者手把手流程：五步打包并发布模板

将一个成熟的 Bot 转换为模板并分发给团队，可以通过界面中的标准步骤完成。如果想对照动态操作细节，也可以参考官方页面提供的操作演示（walkthrough）；具体分步操作与核验节点如下：

第一步：点击 Share as Template，先生成私有模板

动作：在目标 Bot 的设置界面中，找到右下角的 Share as Template 并点击。

会看到什么：Bot 开始把自己打包成一个匿名化、私有的模板版本。此时模板还没有公开；Share as Template 只是创建可分享版本，不等于发布。

继续前检查：确认你操作的是准备分享的 Bot，而不是仍在临时调试的副本。

第二步：先看 What's included，不要直接发布

动作：查看模板生成后的 What's included 摘要。

会看到什么：页面会列出系统读取的 Memories、Skills、Routines 与 Plugins。

继续前检查：核实工作流离不开的插件和技能是否出现；把页面没有说明如何迁移的 Routines 记入安装说明，不能只看到名称就假定它们已经能在新副本中运行。

第三步：打开 View Details，逐项核对内容

动作：点击 View Details。

会看到什么：详情里会展示模板包含的 context、memories 与 integrations。官方示例还能看到 pstack、GitHub，以及与 Cursor integration 的关联。

继续前检查：确认这些内容符合预期；如果工作流依赖 API Key、自定义 MCP、脚本或代码，确认你已经另外准备好安装说明。官方建议让 Bot 把 setup instructions 编码进去，但没有指定必须使用哪个界面字段。

第四步：选择 Team 或公开链接

动作：根据分享对象选择仅团队可见的 Team，或者选择公开链接。

会看到什么：模板会进入相应的分享范围。官方示例中的 loops Bot 因为用于 SpaceX 内部软件开发，所以选择了 Team。

继续前检查：再次核对接收者范围；只适合组织内部的工作流应选择 Team。

第五步：点击 Publish，再复制链接

动作：确认内容和范围后点击 Publish，发布完成再点击 Copy Link。

会看到什么：模板发布后会获得可分享链接；这个链接会打开模板页面，接收者可以从那里把模板加入 Grok Bot。

继续前检查：确认模板是在点击 Publish 后才真正上线。把复制出的链接和前面整理的外部依赖说明一起交给接收者。

接收者手把手流程：四步安装并补齐外部依赖

作为接收者，获得模板链接后并不是直接盲目添加。官方特别提醒使用者：应当像检查常规软件或第三方技能一样审视模板内容，确认其安全性和集成意图后再完成安装。

第一步：打开链接，确认模板身份

动作：在浏览器中打开发布者给你的模板链接，确认它就是你准备安装的模板。

会看到什么：链接会进入模板页面，并提供 Add to Grok Bot 入口。

继续前检查：先核对链接来源和模板用途，不要因为安装入口只有一次点击就跳过后面的内容审核。

第二步：点击 Add to Grok Bot，查看将要加入的内容

动作：点击 Add to Grok Bot，在 Grok Bot 打开的审核界面中查看模板。

会看到什么：界面会展示模板包含的 context 与 integrations。

继续前检查：像检查 skill 或软件一样，确认这些上下文和集成正是你预期安装的内容。

第三步：确认后点击 Add Bot

动作：确认 context 与 integrations 后，点击 Add Bot。

会看到什么：Grok Bot 会创建一个 distinct new copy，也就是基于同一“食谱”生成的另一个版本。

继续前检查：确认新副本已经创建。官方指南没有进一步定义它的运行空间或记忆隔离机制，因此不要从“distinct new copy”推导出页面没有承诺的技术保证。

第四步：按安装说明补齐模板没有带来的依赖

动作：对照发布者提供的 setup instructions，逐项准备工作流所需的外部依赖。

会看到什么：新 Bot 已经创建，但插件可能仍需重新安装；自定义 MCP、脚本或代码不会随模板出现。

继续前检查：

• 重新安装插件：第一方插件和技能会随模板提供，但官方提醒新 Bot 仍可能需要重新安装插件。
• 迁移代码与脚本：自定义代码与脚本不会随模板带来，需要按作者说明另行取得和部署。
• 准备自定义 MCP：非标准插件与自定义 MCP 服务器不包含在模板内，需要按作者说明自行准备。
• 准备 API Key：如果流程依赖 API Key，使用者需要拥有自己的可用凭证；官方页面没有说明具体凭证输入界面。

官方公开展示的例子是用于 SpaceX 软件开发的 loops Bot。页面展示了 pstack 与 GitHub，并说明这个 Bot 与 Cursor integration 紧密耦合。这个例子提醒接收者：看到 integrations 不等于所有相关环境已经迁移完成，仍要按模板作者的说明核对缺失依赖。

用前验收：用最小代表任务验证副本可用性

完成安装与依赖配置后，可以先用一个代表性的最小任务检查新副本。这是本文根据官方边界整理的使用建议；官方页面没有描述平台内置的自动测试功能：

• 发起基准测试任务：向新 Bot 发送一条能够触发核心插件或外部集成的代表性指令（例如要求其调用 GitHub 插件检索仓库，或执行一次标准化分析任务）。
• 验证插件调用：观察 Bot 是否能调用预期插件；如果提示插件缺失或需要重新安装，先补齐再继续。
• 验证外部连接：如果工作流涉及 MCP、脚本或第三方 API，检查代表性任务能否拿到预期输入并返回结果；失败时回到依赖说明逐项排查。
• 核对 Routines：如果工作流依赖 Routines，确认新副本中的触发方式与预期一致。由于官方页面没有解释其迁移细节，不要只看到模板安装成功就认定 Routine 已可运行。

必须厘清的三个机制边界

使用 Grok Bot 模板时，至少要分清三个边界：

1. “一键添加”不等于“零配置开箱即用”： 点击 Add Bot 只完成蓝图副本的创建。插件仍可能需要重新安装；自定义 MCP、脚本和代码不会随模板提供。如果流程依赖 API Key，也需要接收者自己准备。
2. “默认排除个人记忆”不等于“公布了脱敏算法”： 这篇官方指南只说明系统默认排除个人与内部记忆，没有解释具体如何筛选。发布者仍应查看 View Details 中的 context、memories 与 integrations，确认要分享的内容符合预期。
3. 官方材料未说明凭据存储与权限审计机制： 页面提醒复杂模板可能需要 API Key 或自定义 MCP，却没有解释凭证保存、权限审计或沙盒机制。遇到这类外部依赖，仍要按组织现有的软件与权限审查方式处理，不能从模板指南推导出额外安全保证。