让 AI 接过工作，
把判断，
留在自己手里。

先说结论：Grok Bot 值得玩的地方，是它能把一句需求变成电脑上的实际工作。再接上 Pi 和你自己的模型服务，就可以尝试把整理、初稿和批量处理分出去，让 Grok Bot 负责调度与复核。

这篇教程从零开始。你不需要先学终端，也不用逐行敲命令。需要你做的，是把需求说清楚，在正确的位置完成登录或填写 Key，再检查它到底交付了什么。

阅读前先记住一句：外部模型可以分担工作，但不会把 Grok Bot 的订阅变成无限额度。 两边的额度、费用和可用性，都要分别看。

作者：莱因哈特 · 小声工作室。核查日期：2026 年 10 月 19 日。封面为 AI 原创概念插画；正文区分原创图解和有署名的参考截图。新增电商数据全部为教学虚构。文中的任务模板、预算和验收方式是本文建议；个人体验来自提供的素材，不代表普遍性能承诺。

CHAPTER 0101｜先看终点：这套东西到底能帮你干什么

这篇文章的起点，是一段很有共鸣的使用记录：30 美元一个月的套餐，玩了两天，周额度已经用了 84%。工具越来越顺手，额度却先开始报警。于是，一个朴素的问题出现了：能不能让它调用自己买的模型？

你仍在 Grok Bot 里说需求。它把明确的部分交给 Pi，Pi 调用你配置的模型并写回文件，再由 Grok Bot 检查。

我会用它整理已有材料、批量处理相似文件，并保存做成功的方法。

科技简报要分清证据和传闻；商场研究要统一客流、销售额和面积口径。工作拆清楚，工具才接得住。

哪条阅读路线适合你

完全没用过 Grok Bot，就从下一章开始，先做一项小任务。已经有可工作的 Bot，可以直接读第 06 到第 10 章。只想复用流程，读第 12、13 章；要做双 Bot 协作和电商晨报，直达第 14、15 章。

CHAPTER 0202｜把五个零件摆好，再谈数字员工

这次补充的金尘马教程，给了我一个更实用的切入点：从一项持续发生的工作出发，再决定需要几个 Bot。岗位名称可以很响亮，但能否按时交出可检查的结果，才是差别。参考原文

我会把工作台拆成五个零件。Bot 负责一项工作，Skill 保存做法，Routine 安排执行时间，群聊呈现交接，连接器接通外部应用。云电脑是它们工作的地方，Pi 是放在这台电脑里的另一件工具。

可以把它想成一家很小的工作室。岗位说明写长期职责；当天的便签写本次任务；项目文件放当前数据。三处各司其职，比把所有东西塞进一个越来越长的聊天窗口好维护。

“模型”与“工具权限”也要分开。MiniMax 或 DeepSeek 能处理文字，不代表自动继承 Grok Bot 的浏览器登录、连接器和搜索能力。Pi 能使用哪些工具，取决于当前环境的配置。

同样，不同产品的名字能出现在一条工作流里，账单却未必是一张。网页聊天会员不自动等于 API 余额。后面每一步，都要能回答“谁在执行、读取什么、消耗哪边的用量”。

CHAPTER 0303｜把 Grok Bot 打开，再建立第一个工作伙伴

从 Grok Bot 官方入口 下载适合系统的客户端。Mac 用户先看“关于本机”，确认是 Apple 芯片还是 Intel；Windows 用户确认系统架构。按官方安装流程完成登录，等云电脑初始化结束。官方入门说明

登录后查看用量与计费页面，确认 Bot 权限、剩余额度与额外付费开关。

当前计费文档并列说明新的 The X Subscription 与旧版订阅路径，部分产品共享周额度。素材中的“30 美元、84%”只是个人当时的记录。套餐与计费

在应用里创建“小声研究助理”。先让它负责一种工作，再根据需要增加岗位。

把下面这段作为它的长期描述。不同版本的入口名称可能变化，寻找创建 Bot、编辑资料或 Edit Profile 对应位置即可。

你的名字是小声研究助理，主要负责公开资料研究和中文整理。
长期规则：结论先行，短段落；事实给出来源，推断明确标注。
只根据当前任务指定的主题、时间范围和材料工作。
把这段描述当作工作规则，等待我提供具体任务后再开始。
来源打不开或没有数据时，写“未核实”或“未披露”。
交付正文、来源清单和待确认问题，说明文件保存在哪里。
公开发布、发送消息、付款、删除原文件前，先展示具体内容并等我确认。

我会再补一张“岗位卡”：负责的结果、长期来源、判断顺序、输出格式、验收标准、可自行操作的范围、需要确认的动作、失败时怎么停。今天的选题和日期仍然放在任务消息里。

比如，把“情报总监”改写成“每次交付最多五条有原始来源的科技动态，并解释排序理由”，职责立刻能检查。长期描述只放稳定规则，避免每次发生小变化都重写岗位。

看这张图，只需抓住三个位置：左边切换工作伙伴，中间处理本次任务，右边维护长期职责。它展示的是作者当时的界面，具体入口以当前客户端为准。创建与管理 Bot

初始化迟迟未完成，先查看进度、登录或授权请求。能打开电脑视图、读写工作目录，才算准备就绪。

CHAPTER 0404｜第一条任务，别写成“帮我搞定一切”

第一次可以上传一份公开产品说明或自己的非敏感笔记。先检查文件交付能力，再加入实时搜索和模型接入。

任务写清五件事：交付物、依据、范围、停止条件、验收标准。

请阅读我附上的这份材料，为第一次接触这个主题的人写一份说明。
正文控制在 800 字以内，包含：三条结论、五个关键事实、三项待核实问题。
每个关键事实写出原文页码或章节；没有的内容不要补写。
保留原文件，在 /workspace/grok-lab/ 下保存说明和来源记录。
完成后给我文件，并用两句话说明你检查过什么。
不访问其他账户，不向外部发送消息，不覆盖原材料。

观察它是否读到原文、保留未知信息、实际生成文件。不要第一轮就把搜索、模型接入和发布全部叠加。

抽三条事实回看原文。发现扩大解释时，指出差异并检查同类表述。

第 2 条把“可共享链接”扩写成了“支持团队协作”，原材料没有这么说。
请改回来源能够直接支持的表述，并检查全文是否还有类似扩大解释。
保留已经核实正确的段落，只改受影响的部分。
列出修改前后的三项主要变化。

局部修正比每次全文重写更容易控制。

在电脑视图里看什么

看它打开了哪些文件或页面、是否卡在登录、有没有反复做同一个动作。如果遇到密码、验证码或网站要求人工确认，接管那一步，完成后再交还。不要把密码或一次性验证码贴进普通聊天。审批与敏感输入

文件、连接器和本地电脑，走哪条路

单次整理一份材料，直接上传文件最省事。持续访问某个账户，则优先查看有没有适合的连接器。当前官方入口是侧边栏 Connect apps，选择插件、添加并完成授权后，用 @ 引用；技能用 /，这两个入口别混。电脑与应用

/workspace 指云端工作目录，不是你电脑上的“下载”文件夹。要让它处理本地文件，应明确选择和授权对应路径；本地执行权限与云端工作是两回事。不会因为你写了一句“读我的表格”，就自动获得整台电脑的访问能力。

我会先给一个专门的练习文件夹，里面只有这次需要的副本。任务写清“只读这些输入，另存结果”。连接器也按当前工作范围选择，随后用一次小任务确认实际读取的是哪个账号、哪个文件。权限说明

CHAPTER 0505｜第一份实战：做一份能追溯的科技简报

这一轮升级为寻找并核验材料，用 X 科技热点练习。目标是判断消息是否值得追踪，而非凑满热榜。

练习最多五条，方便逐条检查；这是本文安排，不是产品限制。

整理过去 24 小时值得关注的 AI 与开发工具动态，最多 5 条。
时间以 Asia/Shanghai 为准，在开头写清检索窗口起止时间。
从 X 或公开网页寻找线索，再打开官方公告、项目仓库或产品文档核实。
每条给出：标题、发生时间、发布机构、原始链接、已确认事实、我的读者为什么要关心。
区分“今天发生”和“今天有人转发旧消息”。
同一事件合并处理；只有转述、无法找到原始证据的，放到待核实区。
不要为了凑满 5 条降低标准。交付 Markdown 正文和来源表，不发布。

发帖时间不等于事件时间；十次转发也不等于十份独立证据。

如果要访问你的书签、时间线或私信，通常需要相应的账号连接和授权；公开信息研究与私人数据读取应分开安排。不要因为“整理 X 热点”就顺手开放全部账号能力。应用与 X 访问说明

我会要求它建立一张来源表，最少保留“主张、原始页面、页面日期、核查时间、支持程度”。支持程度用“直接支持、部分支持、未证实”就够了，不必制造复杂评分。

“某模型发布了”可能直接得到公告支持。“它能把所有工作速度提高十倍”通常需要特定测试条件。把后一句改成“官方在某项测试中报告了某个结果”，信息就准确得多。

当它输出“已完成逐条核验”时，再追问一个具体问题：哪条候选被你剔除了，为什么。能给出被拒绝的例子，至少说明筛选规则发生了作用。但这仍然不能替代你对关键结论的抽查。

DataCamp 的参考教程也展示了一个有用的提醒：结果排版整齐，并不代表字段正确。本文借鉴的是“先跑通一次、复核、再保存方法”的顺序，后面的提示词和图解按中文研究场景重新设计。参考教程

CHAPTER 0606｜额度告急时，先拆工作，再接模型

先查工作有没有浪费：重复搜索、重复读文件和没有停止条件的循环，都可能比模型单价更影响成本。

把任务分成四段：取材料、整理材料、核验、交付。需要浏览器和登录的取材，继续交给已有环境；已经准备好的文本，可以尝试交给 Pi；涉及重要数字与结论的核验，单独安排；排版导出尽量交给确定性的工具。

这条路线并没有绕过订阅限制。外部调用使用的是你自己的模型账户。Grok Bot 启动任务、发出工具调用、读取结果或复核时，仍可能产生平台用量。额度彻底耗尽后，不能保证它还能替你启动 Pi。

所以，准确的叫法是额度分流。 是否划算，需要用真实任务比较。本文没有在你的 Grok Bot 账户里实测接入，也不把素材中的速度和成功率写成所有人都能复现的保证。

哪些活适合先分出去

整理已下载文章或来源完整的笔记，适合先交给 Pi。没有配置浏览器工具，就不能假定它能独立登录网站取材。

我会先做一个受控实验：选两份长度接近的非敏感材料，一份走原来的方法，一份走外部模型。记录是否合格、耗时、重试次数和两边用量。别只比较“第一段字什么时候出来”。

CHAPTER 0707｜让 Grok Bot 安装 Pi：你发中文，它做检查

最短的开场白就是“帮我装 Pi Agent”。不过，我更建议多加几句限定，避免装错项目，也让安装过程留下可检查的结果。

Pi 官方项目提供终端代理、多模型接入和扩展机制。项目历史链接 badlogic/pi-mono 可能跳转到当前维护地址，阅读时以官方仓库与官网为准，不要按搜索广告里名字相近的软件安装。Pi 官网 · 官方仓库

请在你的云电脑上安装官方 Pi coding agent。
从 pi.dev 或官方项目文档确认当前安装方式，避免同名项目。
先检查操作系统、所需运行时和是否已安装 Pi；已有安装不要重复覆盖。
安装完成后检查版本和帮助信息，说明使用的是哪个软件包、版本和路径。
为这次实验建立 /workspace/grok-pi-lab/，保留安装记录。
现在不要索取 API Key，不要改动其他项目，也不要开始大任务。

安装验收看版本、可执行位置和操作记录，不能只看一句“装好了”。

这一步只证明工具能启动，还没证明外部模型已经接通。别把安装成功的绿勾当成整套流程完成。

为什么安装记录要放工作目录

官方说明中，持久文件与临时目录、手工安装的软件应区别对待。电脑恢复或更新后，某些软件需要重新安装。把项目材料和恢复说明保存在 /workspace，会比只依赖一段聊天记录更容易继续工作。文件与电脑恢复

恢复说明记录软件来源、版本、配置位置、密钥变量名与测试方式，不包含 Key。

CHAPTER 0808｜MiniMax 还是 DeepSeek：先看账号

先选你已有有效 API 权限的一家，跑通小测试。

API Key 是程序调用服务的凭证。Base URL 是请求发往哪个服务地址。模型 ID 是服务端识别的具体模型名称。Provider 是 Pi 对提供商配置的称呼。四个词第一次看着吓人，其实就是“谁来服务、往哪发送、用哪款、凭什么访问”。

Pi 当前文档区分 MiniMax 与 MiniMax China，环境变量分别为 MINIMAX_API_KEY 和 MINIMAX_CN_API_KEY；DeepSeek 使用 DEEPSEEK_API_KEY。具体内置模型清单随安装版本变化，不应固定写成“永远只有两个”。Pi 提供商文档

我要接 MiniMax 国内平台，请先按我创建 Key 的控制台核对区域和套餐类型。
检查当前 Pi 是否已有对应的中国区 provider。
列出准备使用的 provider、官方 API 域名、模型 ID 和密钥变量名。
区分按量 API Key、Coding Plan 或 M Plan 等不同凭证，不假定它们通用。
此时只做配置计划，不请求或显示 Key。

如果选 DeepSeek，就换成下面这段。这里不需要让读者自己拼接口路径。

我要接 DeepSeek 官方 API。
请根据当前 Pi 文档和 DeepSeek 官方文档配置，不使用第三方中转。
检查已有 provider 和账号当前可用模型。
优先选择已确认可用、适合短文本整理的模型进行最小测试。
说明 API 地址、模型 ID 和使用的密钥变量名，但不要显示密钥值。

DeepSeek 官方文档说明了 API 调用和 OpenAI 兼容格式。兼容意味着客户端可以用相近的调用方式，不代表所有参数、工具行为和模型名称都能原样互换。DeepSeek API 文档

我不建议把“自动试国内和海外”作为默认策略。你在哪个官方控制台创建 Key，就先按那个控制台的说明配置。确实需要测试另一个域名时，先确认它是官方服务，且该凭证允许那样使用。

模型列表能打开但调用失败时，先查余额、套餐权限和请求地址，不要轮番猜模型名。

CHAPTER 0909｜填 Key 与加模型：把最容易踩坑的两步讲透

Key 应该填在哪里

原始素材提到，Grok Bot 会弹出安全输入框，Key 不进入聊天记录，也不会向模型显示明文。官方文档确实描述了受支持连接的 secure secret request。但这不等于你说一句话，任意脚本都必然获得相同的保护。

接下来需要配置 API Key。
请使用当前产品支持的安全密钥请求或秘密管理入口，引导我在那里填写。
不要让我把 Key 粘贴进普通聊天，不要打印到命令、日志、截图或报告。
先说明密钥名称、用途和存储方式；配置文件尽量引用变量名。
如果当前接入不支持安全输入，请停在这一步，告诉我如何通过产品支持的方式手动完成。
不要用普通聊天输入框冒充安全输入框。

只有确认界面属于产品的安全密钥流程，再填写。普通网页表单、聊天消息和带星号的文本框，不会因为看起来“隐藏了字符”，就自动具备同样的安全性质。官方敏感输入说明

“模型看不到明文”和“程序没有使用权”也是两回事。调用外部 API 的进程必须能够使用凭证。不要让脚本把整个环境变量列表打印出来，也不要把包含认证文件的目录一起打包下载。

共享云电脑上的文件、登录和命令行凭证也可能被同账户其他 Bot 使用。新建一个 Bot，并没有建立新的密钥隔离空间。共享电脑边界

列表没有 M3.1，能不能手动加

可以检查自定义模型配置，但“能写入配置”不等于“账号能调用”。Pi 支持通过 ~/.pi/agent/models.json 补充提供商或模型。需要填写哪些字段，应遵循当前版本文档，不能凭空猜上下文长度、协议和能力。Pi 自定义模型文档

截至 2026 年 10 月 19 日，MiniMax 官方模型页写明：MiniMax-M3.1-Flash-Preview 当前仅通过 M Plan 和 MiniMax Code 提供。持有普通按量 Key 的读者，不能因此推定已获得这个模型的调用权限。MiniMax 模型说明

我希望使用 MiniMax-M3.1-Flash-Preview。
先查官方文档，确认我的区域、套餐、Key 类型以及 Pi 使用场景是否受支持。
权限明确可用后，检查 Pi 当前模型目录；已有则直接选择。
目录没有时，按当前 models.json 文档补充模型，参数以官方资料为准。
保留原配置备份，不写入密钥明文；先做最小调用，成功后再设为默认。
如果不可用，明确说明原因，并让我选择账号实际支持的模型，不要偷偷替换后说成功。

官方模型页显示，M2.5、M2.7 系列从 2026 年 10 月 19 日起不再对新用户开放，计划于 11 月 18 日退役；部分套餐旧名称也会改路由。这里引用国际文档，国内账号另核对区域说明，不凭配置名称判断实际服务模型。

怎样才算真的接通

先发一个极小的请求，例如让外部模型回复一句“连接测试完成”。再让 Pi 在实验目录写一个新文件，内容为对一小段公开材料的三句总结。这个测试能区分“聊天能回答”和“工具链能完成交付”。

要求 Grok Bot 给出实际执行状态、请求使用的 provider 和 model 字段、文件位置，以及服务端能提供的调用记录。模型自己说“我是某某模型”，不构成身份验证；模型自报的 token 用量也不能代替账单。

CHAPTER 1010｜给分工立规矩，避免两边重复干活

接入之后，最容易出现的浪费是：Pi 写了一版，Grok Bot 觉得不放心，又完整研究和重写一遍。你增加了一次模型调用，却没有减少任何工作。

交给 Pi 明确的任务说明和材料；让它返回正文文件、缺口和待核实主张。

以后每次开始新的手动任务，先问我选哪条路线：
A. 你直接完成。
B. Pi + 我配置的外部模型完成指定部分，你检查结果。
如果有选择卡片就使用卡片，没有就用两项文字选项。
收到选择后再启动；本任务内的小修订沿用已选路线，不反复询问。
把这条偏好保存到当前 Bot 的长期规则，并告诉我保存在哪里。
已经明确指定路线的任务，直接按指定路线执行。

让它说清规则保存在哪，再开新任务测试一次。没有选择卡片时，用文字选项也可以。

再补上执行规则，防止把完整聊天和无关文件都传给第三方模型。

使用 Pi 时，只传本次任务必要且允许交给该模型服务的材料。
先写 task.md，列出目标、输入文件、输出格式、来源要求和停止条件。
Pi 将结果保存为 draft.md，并另存待核实主张。
你只针对来源、数字、遗漏和格式进行检查；通过的段落不要无故重写。
发现问题时，返回具体差异，最多进行两轮定向修订。
仍不合格就报告原因和已完成部分，等待我决定下一步。

两轮是我给练习设定的限制，不是产品能力上限。它的作用是把无限返工改成一个可以观察的过程。

对于无人值守的例行任务，不能每次都先等你选择。应该事先在例行任务里固定执行路线和预算；如果路线不可用，就停止并报告。手动任务的选择偏好和定时任务的执行规则，需要分别写清。

CHAPTER 1111｜再做一个实战：广州商场研究报告

素材称，科技热点和商场报告几秒到十几秒就能出稿。这里须区分“出稿”与“完成研究”：找数据、统一口径与核验往往更费时间。

这次练习，假设你想比较三家商场，判断哪一家更适合一家新咖啡品牌去实地考察。这里的对象、维度和步骤是教学设计，不是本文已经完成的市场调查。

资料未齐时，交付案头调研与现场问题清单；租金、铺位和客群未知，暂不能给最终选址结论。

为广州天河城、正佳广场、太古汇制作一份公开资料案头调研。
用途：帮助一家新咖啡品牌筛选实地考察对象，不直接给租赁决策。
采用同一截止日期，比较区位与交通、公开定位、商业体量、品牌组合、公开经营信息。
每个字段保留来源、统计期和口径；缺失写“未披露”，不能用其他字段估算。
区分商场本体、整个综合体和周边商圈，不能混用面积。
先交付资料表和待补问题，待资料口径确认后再让 Pi 整理报告。

资料表保留研究问题、观测值、时间口径、来源、局限。全年销售额与节日销售额不能直接排高低。

然后把已经核对的资料交给 Pi，而不是让它重新发明一份调研。

请用 Pi 读取已确认的资料表，写一份面向咖啡品牌负责人的研究简报。
结构：三条核心发现、三家对象比较、仍缺的信息、实地考察清单。
事实沿用资料表的来源编号，推断必须写出依据和限制。
不得补写租金、客流、营业额或转化率。
结尾给出“优先去现场验证什么”，不把案头调研写成最终选址建议。
交付 draft.md，由 Grok Bot 复核数字、对象名称、日期和每条来源。

我会怎样验收这份报告

抽一项数字检查原页面，再抽一个推断检查证据是否充分，然后选一项“未披露”确认没有在结论里被偷偷写成确定事实。三种抽查分别对应抄错、推过头和前后矛盾。

如果报告把“品牌组合更偏高端”直接推成“任何咖啡品牌都能卖更贵”，就要求它拆掉这一步推论。真正可执行的输出，应当是要验证的客单、时段、竞争和铺位条件。

CHAPTER 1212｜把一次成功，保存成下次能复用的方法

一份简报通过验收，再保存 Skill，让方法先经过一次实际任务。

把返工教训写进技能，例如日期混淆、面积口径混用，比“保持严谨”更有用。

把刚才通过验收的科技简报流程保存为“小声科技简报”技能。
包括适用场景、必需输入、来源优先级、去重规则、日期校验和输出格式。
输入从项目文件读取，每次运行先确认时间范围，不沿用上一期事实。
明确哪些步骤交给 Pi，哪些由你复核；外部模型不可用时停止并说明。
来源缺失就标注，不为凑条数降低标准。
只生成文件和聊天内结果，公开发布或发送到外部平台另行确认。
保存后告诉我技能名称和调用方式。

官方文档把技能定义为可复用的工作说明，把例行任务定义为执行时间安排。保存的技能可被其他 Bot 使用，但依赖的登录或连接器仍需要具备。技能与例行任务

保存后更换主题与时间窗口测试，检查是否重新读输入、是否残留旧事实；再测试一次应当没有结果的窄主题。

找到技能入口，再教它一次真实操作

图中最有用的细节是输入框里的 /：保存的方法有名字，下一次可以明确调用。找不到技能时，按当前文档检查 Connect apps → Your plugins → Manage plugins and skills → Private skills。技能入口

如果你的版本提供 Teach a task，可以在一对一会话中演示一次操作，再审阅生成的方法。演示适合补充“在哪里点、怎样取字段”，却未必能表达“什么情况必须停”。我会在保存前补写缺失字段、登录过期、页面改版三个分支，再换一份输入测试。

项目目录，简单到能手工看懂

/workspace/grok-pi-lab/
  README.md       当前工作方式与恢复步骤
  inputs/         每次任务的原始材料
  task.md         本次目标与限制
  sources.md      来源与核查记录
  drafts/         中间稿与修订说明
  outputs/        按日期保存的交付物
  run-log.md      执行路线、状态与问题

目录名是本文约定，可以按你的习惯修改。不要把这张树当成产品自动生成的标准结构。它的意义是让你一个月后回来，仍然找得到依据、版本和结果。

CHAPTER 1313｜让它定时做事，先给一个明确的下次运行

定时任务创建后，核对下次运行时间、时区、输入与输出位置。

先每周运行一次，稳定后再提高频率。

创建一个例行任务：每周一北京时间 09:00 运行“小声科技简报”技能。
时区使用 Asia/Shanghai。
读取 /workspace/grok-pi-lab/task.md 中当前主题和来源范围。
固定使用已经测试通过的 Pi 路线；如果凭证、模型或来源不可用，停止并报告。
输出保存到 outputs/ 当天日期目录，并在当前会话交付摘要与文件。
不自动发布或发送到其他平台，不覆盖上一期结果。
每次最多两轮定向修订，没有可靠新信息时明确说明。
创建后展示所属 Bot、时区、下次运行时间和管理入口。

将模板中的路径与技能名替换成你实际创建的名称。

创建之后执行一次测试运行。测试会真实调用工具、处理文件，不是只验证文字有没有语法错误。检查输出日期是否正确、是否读取了最新输入，以及失败时会不会明确停下来。例行任务测试说明

为了验证失败分支，你可以让它在单独的测试任务中引用一个不存在的测试文件。它应该报告缺失，不能擅自拿上一期文件凑数。测试完成后恢复正确输入，再确认正式任务的下次运行时间。

暂停任务时，要进入 Routine 管理界面明确暂停或删除。把 Bot 从侧边栏隐藏，并不等于停止它的例行任务。查看近期运行历史，确认没有遗漏的旧安排。官方常见问题

没做完，也要交一份能接着做的记录

运行历史里最有价值的不是一句“失败了”，而是剩下什么。本文约定给每期任务一个编号，例如 2026-10-19-tech-brief，将已完成步骤、输出路径和未完成原因写进记录。编号是我们设计的防重规则，不是产品自动保证。

为本期任务记录任务编号、输入版本和运行状态。
状态只能是：完成、部分完成、失败。
重试前检查同一编号的输出；已通过核验的部分直接复用。
列出尚未完成的步骤、阻塞原因和下一步负责人。
如果发现已有同名交付，先比较版本，不重复生成或重复外发。

例如五条消息核验了三条，另外两条打不开，应交出三条与缺口说明。重试只补剩余部分。页面结构、表格字段或技能规则变了，也要重新测试一次，不能把上周成功当成这周的证据。

CHAPTER 1414｜什么时候值得加第二位 Bot

我不会为了凑一张“AI 公司组织架构图”就创建十个岗位。值得拆开的信号是：工作已经反复发生，而且两段工作的输入、判断标准和交付物明显不同。

拿科技简报来说，研究助理关注“有没有证据、是不是新消息”；选题编辑关注“读者为什么关心、五条怎样排序”。两种标准可以由两位 Bot 长期维护。只有一份偶发短稿时，一个 Bot 分两轮做通常就够了。

先让两个人交一次接力棒

当前官方支持在 New chat 里选择两到六位 Bot 建群。点名 @ 下一步负责人，比每次通知全员更明确。群内可以看交接过程，但 Bot 发给群的交接消息目前只支持文本；需要另一位 Bot 看图时，应直接把图交给它。群聊与交接说明

下面是本文设计的两阶段练习。先按第 03 章方式建立“资料研究员”和“选题编辑”，再在群里选择对应的实际 Bot。复制文本中的称呼需要与你的名字一致。

这次共同交付一份五条以内的科技简报，先不安排定时运行。
资料研究员：整理 sources.md，每条包含主张、日期、原始链接和支持程度。
完成后在群里给选题编辑一张交接单：任务编号、文件路径、版本、未解决问题。
选题编辑：读取这份资料表，另写 draft.md，不改 sources.md。
按“影响谁、发生了什么变化、读者下一步做什么”排序；不补资料表外的事实。
资料研究员只复核稿件里的事实与链接，最多返修一轮。
有争议就把分歧交给我，不继续互相催稿；选题编辑汇总最终文件。

交接单可以只有六行：任务编号、当前版本、输入路径、已完成内容、遗留问题、下一步负责人。我最看重的是“谁可以改哪个文件”。两位 Bot 同时重写同一份稿，常常比单人工作更难追责。

这里没有新增一套权限隔离。按当前官方说明，同一账户下的 Bots 共用电脑环境、文件与登录。分成两个岗位，不会自动把两份客户资料隔开。需要另一位读取材料时，也要确认这属于已经允许的数据范围。共享电脑说明

如果群聊里等不到密钥或审批卡，切回负责执行的 Bot 的一对一会话处理；当前官方说明这些请求不在群里展示。完成后再回群同步状态，不把密钥当成交接内容。

Pi 放在团队的哪一层

先把多 Bot 协作与多模型分工分开看。两位 Bot 解决的是职责和上下文；Pi 解决的是某个明确步骤用哪家模型执行。它们可以组合，但每多一层，就多一次读取和交接。

我的起步配置是：研究员找证据，编辑通过 Pi 整理已批准的材料，研究员核验事实，编辑交付。若两位 Bot 都重新搜索、都调用外部模型全文重写，分工就失去了意义。先保留一条清晰路径，再比较实际成本。

CHAPTER 1515｜电商晨报：让异常比漂亮日报更早出现

把“数字员工”落到经营场景，我会从只读晨报开始。每天已有销量、库存和售后记录，问题在于这些信息分散，直到缺货才有人把它们连起来。

这里提供一个可复算的练习。下面三个 SKU、数字、日期和补货参数全部为教学虚构，不代表任何真实店铺。下载 电商晨报练习包，解压后把 inventory.csv 与 README.md 交给 Bot；expected-output.md 留给自己验收。

一份表格，先找三种不同的问题

覆盖天数的练习公式是“可售库存 ÷ 近七天日均净销量”。A 的日均为 42 ÷ 7＝6 件，18 ÷ 6＝3 天。教学预警线采用“补货提前期＋两天缓冲”，所以 A 的 3 天低于 7 天，差 4 天。

这四天是覆盖缺口，不是应该采购四天销量的结论。真实采购还需要在途量、起订量、实际交期、退货与促销计划。C 的分母为零，写“无法按本公式计算”，不能显示零天，也不能装作卖得越慢越健康。

请用我上传的 inventory.csv 制作一份只读电商晨报。
先读取 README.md 的字段定义，确认统计期与库存快照时间。
用可复算的计算处理覆盖天数，净销量为零时标为“不适用”。
按“提前期加两天缓冲”比较库存覆盖，仅作为本次练习预警。
交付：三条以内的优先问题、逐 SKU 计算表、需要负责人补充的信息。
保留输入，不改库存、不下采购单、不调广告，也不发客户消息。
区分表中事实、计算结果和你的建议；缺少在途量等信息时列出，不自行估计。

拿到结果后，用练习包的答案对照三个值：A 是 3 天，B 是 21 天，C 不适用。再检查 A 的预警依据是否写成 3＜7。能把这两项检查跑通，才值得换上真实的脱敏数据。

库存吃紧，为什么内容还在推

假设运营今天准备推广 A，客服又发现有人询问发货时间。这两个新条件也是练习假设，并不藏在 CSV 里。应把它们作为附加输入明确交给 Bot，不能让模型自己“发现”表中不存在的事实。

晨报的价值，是把三个信号接起来：库存可能不足，推广可能放大需求，履约承诺需要核实。合适的输出是“请运营负责人确认是否暂缓该 SKU 推广，并向供应链核对到货”，而不是自动停广告或随口向客户保证明天发货。

补充两个假设条件：运营计划今天推广 A；有客户询问 A 的发货时间。
把这两项标记为我提供的情景输入，不当成 CSV 里的数据。
更新晨报中的待决策事项，分别注明运营、库存、客服负责人要确认什么。
给我一份内部提醒草稿，不执行投放变更，不向客户发送，不承诺发货日期。

当这类晨报稳定出现三种判断标准，再考虑拆成库存助理、内容助理和售后助理。由一个负责人汇总异常，其他岗位只提交各自的事实、建议和缺口。新增岗位的理由应该是持续的专业分工，不能只是文章里的头衔看起来热闹。

我的验收标准很具体：计算能复算，输入日期对得上，缺失项被看见，负责人知道下一步。一天没有异常，也应该给出“本次规则下没有触发预警”和检查范围，而不是硬造三个经营风险。

CHAPTER 1616｜怎么判断省没省：记两本账，也记返工

比较同类任务的平台用量、外部费用、总耗时与人工返工，才知道分流是否划算。

用量从 84% 到 86%，不能换算成月费的 2%。共享周池、刷新时间与计量规则会影响显示。

建立一张小记录表就够了。

如果供应商提供按 token 计费，粗略计算可以使用“输入量乘输入单价，加输出量乘输出单价”。但缓存命中、套餐抵扣和其他费用要按供应商账单另看，不能从模型自己生成的一段文字推算。

为这次任务写一条运行记录。
包含任务范围、开始结束时间、执行路线、请求模型、输出文件和重试次数。
若 API 返回 token usage，记录原字段；拿不到就写“不可得”。
费用只能引用服务商账单或明确标注的估算，不要自报一个精确金额。
说明哪些内容通过检查、哪些仍需要我确认。
不在记录里包含 Key、认证头或敏感原文。

三个最容易立刻改善的习惯

一次讲清交付格式，减少来回改版。把已经整理好的资料保存成文件，减少每轮重新搜索。让确定性的计算、去重和排版交给脚本，避免反复用大模型猜一个可以直接算出的答案。

CHAPTER 1717｜遇到问题，按层检查，别一上来重装

排查五层：产品权限、云电脑、Pi 程序、API 调用、交付质量。每次只改当前失败的一层。

云电脑一直转圈

先看是否仍在初始化或更新，查看有没有待处理的登录、问题或审批。若确实无法连接，按产品文档从重试、重启应用、恢复或更新电脑逐步处理。Reset 可能丢失最近尚未同步的工作，不应成为第一反应。故障排查

Pi 装好了，但没有任何外部回复

让 Bot 区分“程序退出报错”和“请求等待超时”。前者查安装、参数和工作目录；后者再看网络、服务状态、认证与额度。不要只接受“可能网络不好”这样的泛泛解释。

认证失败或者提示没权限

常见原因包括 Key 无效、区域不匹配、套餐凭证类型不对或模型不可用。具体状态码含义要以服务商返回为准，401、403 等不能在所有服务上机械地套同一种解释。

让它只展示脱敏后的错误摘要、目标域名、provider、model 和状态码。你不需要把完整认证头发给另一个模型帮忙看。

模型名存在，实际仍然报错

检查模型 ID 大小写、预览版后缀、套餐权限和当前退役公告。模型目录更新慢，可以按文档补配置；服务端没有授权，补一行 JSON 也解决不了。

可以聊天，但不会读文件或完成任务

这说明基础调用与代理工具链不是同一项测试。检查所选 API 协议、模型工具调用支持和 Pi 配置，再做“读一小段材料、写一个新文件”的小实验。不要直接换成百页报告测试。

它说检查了来源，但链接打不开

要求逐条说明来源访问状态。链接失效、需要登录、页面内容不支持主张，应当分别处理。确实无法访问就标注未核实，不能把搜索摘要换个说法当作原文。

同一错误不停重试

让它停止当前循环，保留已完成文件，列出最近一次可复现错误和已尝试的修复。检查重试上限是否生效，再决定是否换路线。不断重复同一个失败请求，不会因为次数更多就变得可靠。

暂停当前重试，保留已经完成的工作。
请按“权限、云电脑、Pi、API、结果”五层定位问题。
只给出已验证的现象、最近一次脱敏错误和你已经尝试过的措施。
提出一个最小修复动作，说明如何确认它有效。
不要重装全部环境，不要删除配置，不要回显密钥。

CHAPTER 1818｜走完这张清单，再把它当成日常工具

网页清单可以勾选，进度仅保存在当前浏览器。按你启用的功能逐项检查。

• 我知道当前账户的 Grok Bot 权限、额度刷新与额外付费设置。
• 我已经让一个 Bot 完成过小任务，并打开检查了交付文件。
• 我能区分 Bot 描述、任务消息、技能与例行任务。
• Pi 的来源、版本、安装位置和恢复步骤有记录。
• 模型区域、API 地址、Key 类型和模型权限已经核对。
• Key 没有写进普通聊天、公开配置、截图或交付文件。
• 最小调用与文件写入测试通过，有脱敏执行证据。
• 手动任务与定时任务的执行路线分别写清楚。
• 来源表和复核规则可以找到，缺失信息不会被补写。
• 我知道如何暂停例行任务、停止重试和找回项目文件。

诚实降温：现在还不能替你保证什么

它不能保证外部模型永远可用，不能保证预览模型不调整，也不能保证一句长期规则在任何情境下都执行无误。你仍然需要使用平台提供的权限控制，而不是只靠一段提示词。

它也不能因为多调用一个模型就自动减少幻觉。两个模型可能认同同一个错误。来源原文、可复现计算和人工抽查，才是验证事实的依据。

对外部模型的数据流也要心里有数。你批准交给 Pi 的文本可能会发送到所配置的服务商。普通公开新闻与公司未公开材料，不能默认采用同样的处理方式。

CHAPTER 1919｜最后说两句

这套玩法最吸引我的，是你可以用大白话安排工作，同时逐渐看清背后的结构。Bot 负责理解和协调，工具负责执行，模型处理合适的材料，来源和检查决定什么可以交付。

从“帮我装 Pi Agent”开始并不难。难的是不要把“能回复”当成“已接通”，不要把“已接通”当成“能稳定交付”，更不要把一次成功直接改成无人值守运行。

把模型接进来只是开始，把结果验明白才算完成。

CHAPTER 2020｜资料与版本说明

本文参考 DataCamp 教程、个人体验文案，以及金尘马 @jinchenma_ai 的《万字长文｜Grok Bot 从入门到精通》。新增的岗位、协作与电商章节按本站练习重新设计，截图仅用于解释相关操作。价格、权限、按钮名称和模型可用性会变化；以下链接是复核入口。本文没有登录你的 Grok Bot 或 MiniMax / DeepSeek 账户进行端到端接入实测。

1. Grok Bot 官方入口：下载与产品入口。

2. 官方入门：安装、登录与首个任务。

3. Bot 概览：产品概念。

4. 电脑与应用：共享环境、文件和敏感操作接管。

5. 套餐与计费：新旧账户路径、周额度与计费。

6. 审批与隐私：安全密钥输入与权限控制。

7. 技能与例行任务：保存流程、测试和管理。

8. 故障排查：登录、电脑、插件与停止状态。

9. 常见问题：共享电脑、记忆和例行任务边界。

10. Pi 官方项目：安装与使用说明，历史项目名为 pi-mono。

11. Pi 提供商配置：内置提供商与凭证变量。

12. Pi 自定义模型：models.json 配置。

13. MiniMax 官方模型页：M3.1-Flash-Preview 可用渠道与模型生命周期；国内账号另核对国内控制台。

14. MiniMax 国内平台：账号、凭证和区域对应文档。

15. DeepSeek 官方 API 文档：API 入口与兼容格式。

16. DataCamp 参考教程：研究、核验、技能与例行任务的参考案例。

17. 金尘马参考文章：用户提供网页存档，采用三张原始截图并逐图署名；不转引图中未经核实的传播量、旧套餐或旧模型结论。

18. 创建与管理 Bot：岗位描述与团队规模。

19. 群聊与交接：群聊、负责人和消息形式。

版本 2.0 · 2026.10.19。新增岗位与数据路径、三张参考截图、双 Bot 交接、电商练习包和失败记录；更新网页大图与阅读路线。未在读者账户执行接入测试，电商例子不涉及真实店铺操作。

莱因哈特 / 小声工作室。