Grok Bot 从 0 到 1

深色模式

内容更新：2026-10-16

Grok Bot 云电脑重置前，先把配置备份到 GitHub 私有仓库：一篇 X 帖子的复盘

这是「我和 Bot 的实战笔记」里的一篇：Dato 和他的 Bot 读到一条很实用的 X 帖子，对着官方文档核对，再在自己的机器上把关键环节跑一遍。帖子是别人的，观点和实测是我们的；出处只做文字链接。

帖子说了什么

2026 年 10 月 15 日，X 用户 雨哥向前冲（@xiangxiang103）发了一条帖子[1]。核心意思是：Grok Bot 的云电脑万一重置，积累的配置可能一起没了，所以他让 Bot 自己把值得留的东西备份进一个 GitHub 私有仓库。

他描述的做法大致是六件事：

  1. 在 GitHub 新建 Private 仓库，先不要初始化 README；
  2. 生成只限这一个仓库的 fine-grained token，只给仓库内容的读写权限；
  3. 把 token 交给 Bot 的密钥保管功能，不要贴进聊天框；
  4. 备份前先盘点，排除密钥、登录态、聊天记录和能重装的依赖；
  5. 每次推送前扫一遍密钥，命中就中止；推完写一份中文恢复说明；
  6. 设一个每天的定时同步，成功不打扰，失败才通知。

他还给了一段提示词放在评论里，评论区里也有人问“能不能让多个 Grok 共享这份备份”“用 cron 还是 GitHub Actions”“GitHub 仓库安全吗”。下面我们不转述他的提示词原文，而是按这个思路自己写了一套、自己跑了一遍。

帖子里的说法，我们核到哪一步

上表是我们的核对结果：哪些有官方出处、哪些我们自己跑过、哪些只能标「未证实」。

为什么值得备份：官方怎么说

先看官方的说法。排障页写得很清楚：Recover computer 和 Update 会保留持久文件和登录，而 Reset 是回到上一次保存的快照，最近或还没同步的工作可能丢[2]。同一页还提醒：临时目录、手动装的软件包、没提交的应用状态，都应当当作“可以被替换”的东西，重要结果要拷到共享工作区或附到对话里[2]。

官方怎么说：Recover、Update 和 Reset 的区别

上图是我们 2026-10-16 当天抓取官方排障页并搜索关键词的结果。结论很直接：官方设计上平时不会丢，但 Reset 是例外。备份不是为了日常，是为了“最后一步必须点 Reset”的那一天。我们之前也写过恢复顺序（先别点 Reset）和一次完整的撤离包（全量备份），这篇是它们的“自动化版”。

这套流程，我们怎么理解

这套做法的流程，拆成六步

我们的理解是：它的好处是把“要备份什么”和“怎么推”分开，并且把“扫密钥”放在“推送”之前，而不是推完才后悔。下面逐步说我们的核对和实测。

关于 token：只限一个仓库，是对的

GitHub 官方文档的态度是：能用 fine-grained token 就不要用 classic，并且建议给 token 设置过期时间[3]。官方同时提醒，fine-grained token 不是什么都能做，有些操作还得用 classic[3]。对“只往一个私有仓库推文件”这件事，fine-grained 足够，这一点和帖子一致。

两种 GitHub token，该选哪个

两点补充：一是一定要给 token 设过期时间，否则它会一直有效；二是过期之后，每天的同步会悄悄失败，所以“失败要通知”不是可选项。我们没有用真实 token 往真实 GitHub 推过东西（那是 Dato 的账号，也不需要为了写文章去碰），所以“Contents 读写刚好够用”这条我们只对照了文档，未实测。

关于“加密密钥箱”：我们没找到官方说明

帖子说把 token 放进 Grok Bot 的“加密密钥箱”。我们读了官方的安全页和电脑使用页：官方明确写的是密码、两步验证、验证码、付款要由你自己输入，以及“受支持的连接如果出现安全密钥请求，就在那个请求里填”[4][5]；同时写了同一账号的所有 Bot 共用一台电脑，文件和浏览器登录态都是共享的，不想让别的 Bot 用的东西不要放上去[5]。至于一个通用的“密钥箱”能不能存任意 token、怎么取用，我们没有在官方文档里找到，标 未证实。如果你的界面里有这个功能，仍然按“不贴聊天、只限一个仓库”的原则用。

我们动手做了什么

我们没有碰真实的云电脑和真实的 GitHub，而是在自己的机器上，用一个本地裸仓库代替 GitHub，把帖子里的逻辑做成两个小脚本：一个盘点，一个同步（拷贝、扫描、提交、推送）。所有密钥都是我们现编的假字符串。

第一步：盘点。 先按排除清单算出会备份什么、排除了什么。

第一步：盘点会备份什么

排除清单是一个独立文件，写明了依赖目录、聊天记录、.env、cookie、私钥这些。把排除规则写成文件，比“口头告诉 Bot 别备份密钥”可靠。

第二步：推送前扫描。 我们故意在一篇笔记里写了一个假的 token，同步被拦了下来，没有提交也没有推送。

第二步：笔记里夹了一个 token，同步被拦下

注意它拦下的不是 .env 文件，而是一份看似无害的笔记。真实场景里，密钥最常出现在草稿和笔记里，而不是配置文件里。

第三步：去掉 token 后同步成功。

第三步：去掉 token 后同步成功

这里推到的是本地裸仓库，不是 GitHub，所以只能证明“盘点、扫描、提交、推送”这条链路是通的，不能证明 GitHub 那一侧的权限设置。

一个容易漏的地方：token 可能写进 remote 地址。 有人为了省事，把 token 直接写进 https://用户:token@… 形式的 remote 地址，它会被存进仓库的 .git/config。如果扫描只扫工作区文件，会漏掉它。我们把 .git 也一起扫，就能抓到。

容易漏的一处：token 写进了 remote 地址

第四步：演练恢复。 备份能不能用，要到恢复那天才知道，所以我们从远端克隆了一份，再和原目录对比。

第四步：演练恢复，才算备份有效

对比结果里，只在原目录有的就是我们故意排除的：依赖目录、聊天记录、带密钥的配置。这说明恢复出来的东西是预期中的那一份，而且 RESTORE.md 也一起恢复出来了。真实恢复时，这些被排除的内容要重新填写，所以恢复说明里要写清楚。

“每天凌晨 3:17”要小心时区

“每天 3:17”到底是几点

官方文档写明：Bot 设置里有时区，routine 的计划按这个时区跑[6]。云电脑自己的时区、你手机的时区、你说的“凌晨”，可能是三回事。我们这台机器的时区是上海，但你的云电脑不一定。设定时同步前，先在设置里确认时区，再看一次 routine 的运行记录[6]。至于帖子里的同步是用 routine 还是电脑上的 cron，帖子没说，我们 未证实。

另外官方有按 Bot 的通知开关，可以在 Bot 完成或需要你时通知你[7]。“成功不打扰、失败才通知”能不能完全用它实现，我们没有在真实账号里试，未证实；稳妥做法是让同步脚本在失败时自己明确地报告，并定期看一眼运行记录。

我们照着做时，加的六条

我们照着做时加的六条

  1. 备份清单写成文件。 排除规则放进 excludes.txt，别只靠口头约定。
  2. 扫描连 .git 一起扫。 remote 地址里的 token 最容易漏。
  3. 给 token 设过期时间。 过期后同步会悄悄失败，所以失败通知很关键。
  4. 每月演练一次恢复。 克隆下来再对比，别只看推送成功。
  5. 敏感内容先加密。 私有仓库不等于加密，客户资料、财务数据别直接放。
  6. 确认时区。 routine 用设置里的时区，3:17 是谁的 3:17。

可直接复制的提示词（我们自己的版本）

text
帮我把这台云电脑上值得保留的东西备份到我指定的 GitHub 私有仓库。要求：
1. 先盘点，列出会备份的文件数和总大小，等我确认。
2. 排除清单写进一个文件：API key、登录态和 cookie、聊天记录、可重新安装的依赖。
3. 每次推送前扫描整个暂存目录（包含 .git），发现疑似密钥就中止并告诉我。
4. 我会自己把只限这一个仓库的 token 放到安全的地方，你不要让我把它贴在聊天里。
5. 推送后生成一份中文 RESTORE.md，写明怎么在新机器上恢复，哪些要重新填写。
6. 设置每日同步，并告诉我它按哪个时区运行；失败时必须通知我。

评论区里有什么

我们在 2026-10-16 通过 X 的 API 读完了这条帖子下面整个对话（conversation）：共 55 条帖子，包括原帖 1 条、作者补发的提示词 1 条、作者的回复 8 条、官方 @bot 的确认回复 7 条，和其他用户的 38 条。另外有 4 条引用转发（只有正文，没有账号名可引）。读取时每页最多返回 25 条，我们翻了 4 页，最后一页是空的，所以这个数字是完整的，但只能读到公开内容，被删除或被作者限制的回复读不到。

评论区话题分布

下面按话题讲。每一点都标了账号并链接到原回复，用我们自己的话转述；凡是官方文档写了的我们核对了，没写的标「未证实」，能在这台机器上跑的我们跑了。

一、大家在问什么（8 条帖子，7 个问题）

1. 自动同步用 cron 还是 GitHub Actions？ @wuzhu_ 问了这个，作者只回了“自动同步”，没有展开。我们的判断见上文和 FAQ：备份对象在云电脑上，应由云电脑去推。作者具体用的是 Routine 还是系统 cron，未证实。

2. 同步失败了会怎样？会不会自己重试？ @wuzhu_ 和 @lwkfFiki9496664 都问到了失败告警和重试，作者没有回答。官方文档只写了：Routine 可以看最近的成功和失败记录，每个 Bot 有单独的通知开关[7]。“失败自动重试”“只在失败时通知”文档里都没有承诺，未证实。我们的做法是让脚本自己在失败时写一个醒目的结果，并且给 token 设过期时间，否则 token 过期以后，最危险的情况是“一直静默失败”。

3. 哪些文件该排除？ @ranger_escape 问大家备份时排除什么。作者的提示词里已经列了：密钥文件、凭证、登录态和 cookie、聊天记录、能重装的依赖。我们的补充见下面“额外技巧”。

4. 两个或多个 Grok 能共用这份备份吗？ @jackaiwison 问，作者回复“可以，别的账号的 Grok Bot 也能拉下来用”（@xiangxiang103）。同一个账号下的多个 Bot，官方说它们共用同一台电脑和 /workspace[5]，所以不需要经过 GitHub。跨账号则是普通的 git 权限问题：对方有仓库权限就能克隆，同时也能看到仓库里的全部内容。这是从 git 原理推出的，官方没有专门写，我们也没有试，未证实。

5. 真的这么智能吗，这样也能发指令？ @FuluoluoQAQ 问在评论里 @bot 能不能下指令。官方文档确实有这个功能：在帖子或回复里 @bot，它会把你的帖子、你回复的那条帖子和被引用的帖子交给你自己的 Bot，由你的 Bot 在云电脑上干活，结果留在 App 里，@bot 在 X 上只回一句确认[8]。

6. 我现在的备份方式和这个一样吗？ @DL851113 带着 @bot 问这个。要对比，得先有清单：对照上面“我们加的六条”逐条看即可。

7. GitHub 仓库不也不安全吗？ @arito_si 担心这个，作者回应是再在本地留一份，一周一次。我们同意“私有不等于加密”，下面“质疑”里有实测。

二、额外技巧（5 条，其中路径白名单一条来自上面的提问帖）

  • @Sogapp1：把 .gitignore 写死，排除 .env、.ssh、*.pem、cookies.json；同步前只传增量；出事后 clone 下来再跑一遍初始化提示词。
  • @FootballAnt247：把提示词模板和常用工作流单独放一个目录，排除凭证后体积更小，恢复更快。
  • @xueyu1125：自己的 skill 也是用私有仓库备份的。
  • @yueke：云电脑要当成自己是 SRE 来管，重置一次就全没了，所以每天自动同步值得抄。
  • @wuzhu_：把备份脚本的路径白名单写死，避免脚本有一天扫到密钥目录。

我们的判断。 路径白名单和提示词模板单独放，都是好办法，和我们“排除规则写成文件”是一个方向。但有两点要纠正：

  1. .gitignore 不是保险。 我们实测：.gitignore 确实挡住了 git add -A，但有人手动 git add -f 就能把 .env 加进去；更常见的是文件已经提交过，之后才写进 .gitignore，它照样被跟踪（见下图）。所以“白名单 + 推送前扫描”比“黑名单”更稳。
  2. “只传增量，几十 k”是 git 本来就有的行为，但数字不能照抄。 我们造了 414 个文件、共 19M 的假数据，第一次推送后远端是 14M；改 2 个文件后再推送，远端只新增约 120 KB。可见增量大小取决于你改了多少，并不是固定的“几十 k”。

评论区说只传增量：实测

三、质疑和风险（3 条，外加 1 条与官方不一致的说法）

1. 云电脑只有 15G，很快就满。 @cielfr 说自己的 Bot 云电脑只有 15G。官方文档没有给出磁盘大小，所以 15G 这个数字未证实，也不知道是否随套餐变化。我们的建议不变：备份前先盘点大小，node_modules、虚拟环境这类能重装的东西不要进仓库，GitHub 会拦截超过 100 MiB 的单个文件（GitHub 文档，2026-10-16 核验），大文件不要往里放。

2. 备份会把 token 账单推高吗？ @YunTechX 调侃这是“把上下文窗口当网盘”。这要分情况：如果让模型把每个文件读一遍再复述，确实贵；如果让它写一个脚本，再由脚本去拷贝和推送，文件内容不会经过对话，模型只看到几行输出。官方说明订阅包含每周用量，超出部分按模型和 token 成本计费[9]，定时任务属于无人值守的用量，Bot 可能会问你要不要继续跑[6]。每次同步具体花多少用量，文档没写，未证实；想省，就用脚本，别让模型逐个文件读。

3. GitHub 是模型预训练的来源，私有仓库放心吗？ @leeorso 半开玩笑地说了这点。这是个调侃，没有可核实的事实依据，我们不下结论。可以确定的是：私有仓库是访问控制，不是加密。我们实测了加密的做法：把敏感目录先打包，再用对称加密，仓库里只放密文。在密文里搜不到 key，用口令能还原（见下图）。口令本身当然不能放进同一个仓库。

.gitignore 和加密的实测

4. “Reset 并不丢东西，丢的只是安装的软件。” @yummysoosu 回复说他查了官方文档，Update 和 Reset 都会保留文件和登录，所以他只备份安装清单。这条和官方排障页对不上：官方写的是 Recover 和 Update 保留持久文件和登录，而 Reset 回到上一次保存的快照，最近或还没同步的工作可能丢[2]。他的结论对 Update 成立，对 Reset 不成立。这条值得特别注意，因为它会让人觉得不用备份。我们没看到他后续线程的全文，只读到了这一条回复和他引用的开头帖子，所以他在别处是否另有说明，未证实。

四、替代方案（2 条）

这两个我们没有测。官方把 Bot 连接外部服务的方式讲得比较克制：需要输入密钥时，Bot 只对受支持的连接发起安全请求[4]，我们没有在文档里找到网盘或 Notion 的备份用法。判断标准还是那三条：能不能做版本管理，能不能在推送前扫描，能不能演练恢复。网盘和 Notion 的优势是上手简单，劣势是难以看出“这次到底改了什么”，也不好做自动扫描。作者自己的补充是本地再留一份，一周一次，我们认为这条值得做。

五、@bot 代办：8 条

有 8 位用户在评论里直接写“@bot 帮我备份”“@bot 按这个方案做”之类的话（比如 @YuchunLuo93529、@evoLU53450063、@ShunpuTang），官方 @bot 账号逐一回复了确认。我们的提醒有三点：

  1. 自动开始并计入用量。 官方说第一次成功后，X 会通知你：被 @ 的请求会自动开始，并消耗你的 Grok Bot 用量[8]。
  2. Bot 收到的是什么。 文档写的是你的帖子、你回复的那条帖子，以及它们引用的帖子[8]。提示词在作者补发的第二条回复里，在根帖上 @bot 时，Bot 是否能读到那条提示词，我们未证实。
  3. 别人写的帖子是不可信输入。 让 Bot 去“学习”“照做”一条公开帖子，等于让它读一段陌生人写的文字。涉及动手改文件、推送的步骤，请先让它出方案，你确认后再执行。

评论区里还有什么

另外 12 条是致谢、点赞和玩笑，比如 @CloudDogx 说自己也吃过云电脑重置的亏，还有几位对“凌晨 3:17”这个时间点的感叹（@Isoldegwow）。这些我们不逐条展开。时区要小心，我们前面已经单独写了。

常见问题

Q：这个做法一定能防止 Reset 丢东西吗？

A：不能保证。它只备份你选中的文件，不备份聊天记录和登录态；恢复也要你自己演练。我们只在本地验证了流程，没有在真实云电脑上验证。

Q：2 分钟、414 个文件、约 14M，这些数字我也能做到吗？

A：那是作者自己的一次结果，未证实。你的文件多少、网速和仓库状态都会影响。

Q：多个账号的 Bot 能共用这份备份吗？

A：作者在回复里说可以，因为备份在 GitHub 私有仓库里，别的账号拉下来就行。我们没有试，但从原理上看，只要对方有访问权限就能克隆。注意共享意味着对方也能看到仓库里的所有文件。

Q：用 cron 还是 GitHub Actions？

A：评论区有人问，帖子没有答。我们的看法：备份的目标是“这台云电脑上的文件”，所以应当由这台电脑去推，Actions 是在 GitHub 那边跑，拿不到电脑上的文件。这是我们的推理，未实测。

Q：私有仓库安全吗？

A：私有只是别人看不到，不是加密。含客户资料或财务数据的内容请先加密，再备份。

Q：我没有 GitHub，怎么办？

A：思路一样：换成任何你信任的、能存版本的地方。关键是排除清单、推送前扫描和恢复演练这三件事。

Q：评论区里说 .gitignore 写好就安全了，对吗？

A：不对。.gitignore 只管还没被跟踪的文件，git add -f 能绕过，已经提交过的文件事后写进去也没用。我们的实测见上文。建议用白名单加推送前扫描。

Q：Reset 到底会不会丢文件和登录？

A：官方排障页的说法是：Recover 和 Update 保留持久文件和登录，Reset 回到上一次保存的快照，最近或还没同步的工作可能丢。评论区里有人说 Reset 也保留文件，这和官方不一致。

Q：每次同步会很耗用量吗？

A：官方没有写每次同步的用量，未证实。用脚本去拷贝和推送，比让模型逐个文件读取要省。

Q：在评论里 @bot 能直接让 Bot 备份吗？

A：官方支持 @bot 把帖子交给你自己的 Bot，请求会自动开始并计入用量。涉及改文件和推送的步骤，建议先让它出方案。

想直接开通？

需要代充，请联系站长，微信 siuserxiaowei（备注“Grok Bot 教程”）。首单报优惠码 xiaowei 立减 20 元。更多免费教程在 grokguide.si。

风险提示

官方定价页写明，订阅只通过官网直接销售，不授权第三方卖家，从其他渠道买的订阅可能被暂停（cursor.com/pricing）。站长提供的是个人代充服务，与官方无关，购买前请自行评估风险。

参考来源

  1. https://x.com/xiangxiang103/status/2110638131720700149（雨哥向前冲，2026-10-15，核验 2026-10-16；评论区的提示词和问答也已阅读） ↩︎

  2. https://docs.x.ai/grok-bot/troubleshooting（核验 2026-10-16） ↩︎ ↩︎ ↩︎

  3. https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens（核验 2026-10-16） ↩︎ ↩︎

  4. https://docs.x.ai/grok-bot/approvals-security-and-privacy（核验 2026-10-16） ↩︎ ↩︎

  5. https://docs.x.ai/grok-bot/computer-and-apps（核验 2026-10-16） ↩︎ ↩︎ ↩︎

  6. https://docs.x.ai/grok-bot/skills-routines-and-automations（核验 2026-10-16） ↩︎ ↩︎ ↩︎

  7. https://docs.x.ai/grok-bot/settings-and-notifications（核验 2026-10-16） ↩︎ ↩︎

  8. https://docs.x.ai/grok-bot/tag-on-x（核验 2026-10-16） ↩︎ ↩︎ ↩︎

  9. https://docs.x.ai/grok-bot/faq（核验 2026-10-16） ↩︎