Lauren Tan（@poteto，中文社区称“土豆姐”）的 Grok Bot 用法，可以归结为一个问题：怎样让工作不再每走一步都等人搬运上下文、检查结果、下达下一条指令？
本文依据 @kylewmi 对她的演讲、访谈、直播、长文和推文所做的中文整理，梳理从单个 Bot 到完整工作闭环的方法。她提到过一个月提交两千多个 PR，这是本人自述；重要的不是复制这个数量，而是理解支撑这种工作方式的分工与验证机制。
#一、信任先于规模
同时开一到五个对话、每个都要盯着纠错，是最难突破的阶段。增加 Bot 数量无法解决这个问题：产出不可信，开一百个只会多出一百份待返工的结果。
Tan 用“米其林厨房”描述理想状态。主厨负责菜单和出品标准，其他人有清晰的分工、工具和动线。如果每个人都在同一个地方绊倒，就应当调整厨房，而不是逐个训斥厨师。
这也解释了她借用的管理原则“Context, not control”：给足业务背景，让 Bot 理解目标，逐步教会它独立完成。Bot 像能力很强、却不熟悉业务的新员工，首先需要入职培训。
工作可以分为两个循环：外循环负责从邮件、Slack、X、日历等地方收集变化；内循环负责实际执行，例如写代码。Grok Bot 在她的工作方式中承担外循环，把外部上下文交给 Cursor 项目里的执行智能体。检查自己在哪一步仍要复制、转述、催进度，就能找到下一处值得改进的瓶颈。
外循环收集信息并交给内循环执行
图：原作者根据公开分享整理的外循环与内循环，来源 @kylewmi。
她将这套态度概括为三点：愿意为以后省事而提前投入；尽快做出可讨论的结果；即使成果不是亲手完成，也对它负责。“为什么不今天就做？”意味着用可操作的原型推进讨论。
#二、先把一个 Bot 用透
起步时不用急着搭团队。先连接日常应用，介绍自己的职业、工作流程和目标，让主 Bot 复述理解，再列出可以自动化的工作，按节省时间的价值排序。
接下来盘点重复的手动步骤，特别是跨应用搬运信息的环节。工具和访问条件也要配齐：原文建议给 Bot 独立邮箱和必要账号，用保险库管理登录信息，并与个人账号区分。
只有当同一个 Bot 同时处理太多不同事务、上下文开始混杂，才考虑拆分。新增角色的理由是专业化和便于管理，而不是凑齐一张看起来完整的组织架构图。
#三、把目标说清楚，比反复加指令更有效
Tan 最常用的技巧是先用语音把想法完整讲出来，再要求 Bot 用自己的话复述目标、问题和不确定之处。人先校正理解，再授权执行，可以把偏差拦在开工之前。
同样，调查问题时不要过早塞入自己的判断。与其说“这里肯定是某个模块坏了”，不如让 Bot 阅读完整讨论，先解释它认为发生了什么。
上下文要准确，也要克制。做落地页之前可以先收集参考、确定视觉方向，但不必把所有历史资料都塞进任务。一份简短而清晰的业务介绍，往往更方便不同角色复用。
执行中可以直接纠偏；需要拍板时，要求 Bot 把进度和待决事项写成带足背景的执行摘要。Tan 也强调写作是思考：她选择自己写推文和文章，行业经验与准确措辞则帮助她更有效地表达任务。
#四、用四步建立可重复的信任
把任务交出去，可以依次经过四个阶段：
- 看着做。 第一次让 Bot 完成任务，观察过程并即时纠错。
- 存成技能。 把已经做顺的输入、步骤、标准和例外情况固化下来。
- 验证一次完成。 下次只给任务名，检查它能否无需补充说明就做对。
- 设成例行任务。 只有结果已经稳定，才交给定时或事件触发机制。
报销是一个典型例子：先教会 Bot 找收据、整理开支、填写工具，再形成技能；稳定后，才让新收据邮件自动触发处理。
从人工观察到自动运行的信任四步
图：原作者根据 Peter Yang 访谈整理，来源 @kylewmi。
订机票和酒店则体现了另一条边界：Bot 可以收集需求、比较方案、准备执行，但真正下单前先让人确认。原文将花钱、公开发布和对外发消息列为应明确设置审批边界的事情。
#五、好 Bot 要有明确职责和禁止事项
Tan 使用 Dr Eggbot 这个“Bot 设计师”来创建和调整角色。设计重点不是复杂人设，而是四条清晰规则：负责一件事、保持一致的表达方式、写明不能做什么、只配置需要的工具。
她的高质量 Bot 指南进一步强调：少而精；让 Bot 将成功做法保存成技能；补齐工具和业务背景；找出仍由人搬运的步骤；把可机械重复的操作改成脚本；通过团队共享，让同事复用已经维护好的能力。
角色说明可以直接写成：“负责哪些工作、绝对不能做哪些事、需要哪些工具、还缺哪些偏好信息。”有辨识度的名字便于记住分工，但职责与边界必须先清楚。
Dr Eggbot 还被用于回顾聊天中的纠正和误解，检查不再使用或消耗过高的例行任务。技能也应定期精简，而不是每遇到一个问题就永久追加一段说明。
#六、团队靠协调和共同记录运转
团队扩大以后，Tan 大部分时候只和“幕僚长”交互，由它找到相应负责人，再将具体工作派给执行角色。协调者不必承载每项工作的全部细节，人的沟通入口也更集中。
Bot 之间应能直接交换上下文。例如发现问题后，让工程角色去找负责反馈的 Bot 了解情况，再带着修复方案回来；产品、设计、工程也可以在同一讨论中分别给出意见。
原文将这些 Bot 描述为长期角色：工具与技能可以共享，但记忆、偏好和职责有所区分，同一个角色可以参与不同项目。
协作还需要几条具体规则：明确哪里保存当前计划与任务状态；通知和交接使用固定渠道；一次集中推进一条主线；文档管理员可以读取资料，但修改权限另行约定；只有出现完成、PR 或需要决策的变化时才汇报。
#七、主动运行要控制频率和上下文成本
例行任务分为按时间运行与按事件触发两种。Tan 的一般建议是每小时一次或每天几次通常已经足够，避免为了“主动”而让任务每十五分钟启动一遍。
这是一项用量建议，不是产品的技术频率限制。原文也记录过工作时段每三十分钟检查进度的直播示例，不能将不同场景合并成统一硬限制。
控制成本可以从四处入手：降低不必要的运行频率；在唤醒 Bot 前过滤事件；把重复任务交给上下文干净的专用角色；将稳定的机械操作交给脚本。
还有一种节奏值得保留：先积累问题，再集中分析。每发现一个坏模式就立刻修改，可能看不到它们的共同成因；先追加进问题队列，每隔几天复盘，反而更容易找出需要整体修正的流程。
#八、闭环的每一步，都必须能交证据和叫停
完整闭环同时覆盖“第一公里”和“最后一公里”：既能从外部系统发现该做什么，也能执行并交回可核验的成果。
原文介绍了 Tan 的反馈处理流程：监测 Slack 反馈，创建 Linear 工单，派云端智能体复现问题，修复后再让其他智能体模拟用户验证，最后通知她。在这套特定流程中，她保留一小时的否决窗口，没有提出修改才自动合并上线。
它并不意味着任何任务都适合默认放行。分类阶段可以判断“这是正常行为”；复现阶段可以报告“无法复现”；修复阶段可以因改动范围过大而要求人工决策。每一步都应有停止条件。
“已经修好”只是声明，失败与通过的测试、操作录屏、前后截图才是验收依据。她的发版 Bot 还会询问贡献者是否存在阻碍，监控构建，安排多个智能体模拟真实用户操作，再把发现的问题交给工程角色处理。
设计自己的闭环时，需要回答四件事：什么触发任务、每步由谁负责、交付什么证据、哪里保留人的决定权。
#九、重复纠错说明环境需要改变
Tan 为解决重复错误给出了一组优先级：先调整结构，让正确做法最容易发生；再用自动检查拦截错误；然后将方法沉淀为技能；最后才依赖人工逐次检查。
从结构改进到人工检查的优先级
图：原作者将代码库改进思路整理为通用场景，来源 @kylewmi。
例如反复取错日期，可以规定只读取明确的权威记录；发布时经常漏字段，就增加自动检查。比起每次重新提醒，这些改变更容易被未来的运行继承。
人工仍需要抽查结果，尤其是不同 Bot 共同出现的坏模式。已有代码、模板和文档会被持续模仿，一个临时绕过方法也可能迅速扩散。因此需要“园丁”式维护：清除错误示例，补上约束，必要时让 Agent 为反复手动执行的步骤制作工具。
#十、编码场景先搭验证能力
在原文介绍的 pstack 与 Cursor 工作方式中，Grok Bot 负责协调，云端智能体负责写代码；相关任务归入同一项目，再由协调角色分派和监督。
验证能力应先于大规模放手：让 Agent 能启动应用、找到功能入口、点击操作、截图录屏并读取性能信息。支撑它的既有可重复调用的工具，也有描述功能和用户路径的地图，还要随应用变化持续维护。
规划也可以通过几个可运行原型和录屏推进。代码库本身则是执行智能体的重要参考，应持续清理容易被模仿的坏模式，并将反复出现的问题转成自动检查规则。原文中关于减少注释、自动合并的做法属于她的具体实践，其前提仍是足够的验证和后续抽查。
#十一、内容创作者如何迁移这套方法
原文以加密内容创作者为例设计了一支 Bot 团队。这是整理者的应用示例，并非 Tan 本人的工作案例。
可以先用一个主 Bot 处理情报收集、资料整理和评论反馈，逐项存成技能；等任务真正混杂，再拆成情报员、选题编辑、X 管家等角色。人负责选题、判断、表达和发布，Bot 负责收集、整理、核实与反馈归档。
一条内容闭环可以这样安排：发现消息并附来源等级；与已有选题合并；由人决定是否写；形成事实核查包；由人写作；检查数字、名称和链接；由人发布；次日收集提问、纠错和质疑，回流选题库。
核查包应包括时间线、关键数字、相关方原话和未确认清单，每项附可追溯的原始链接。数字存在冲突就并列呈现，关键证据找不到就明确停下，不能为了交付而补出结论。
内容创作者团队中的 Bot 角色与职责
图：@kylewmi 根据方法论设计的应用示例，并非 Lauren Tan 的实际团队。
示例将情报早报作为第一项练习：它每天重复，且不直接执行公开发布。先观察是否漏信息、混淆传言和事实，再固化来源分级与重要性标准，稳定后安排自动运行。加密场景还明确要求 Bot 不做买卖建议，不接触钱包私钥和助记词，可疑邮件与授权请求留给人确认。
可复用的技能说明应写清：何时使用、需要哪些输入、执行步骤、验收证据和必须先询问的情况。每周再回顾一次，找出仍需人工复制和转述的步骤，决定补连接器、授权还是脚本。
#十二、用一周验证一件小事
第一天连接必要工具，说明业务与目标；随后选择一个每天或每周重复的任务，观察并纠错。把成功过程写成技能，再只通过任务名称触发，检验它能否独立交付；确认稳定以后，才启用例行任务，并保留抽查和修改标准的机制。
从起步到例行运行的七天上手计划
图：原作者整理的七天上手计划，来源 @kylewmi。
这套方法的顺序始终一致：先确认一个任务做得对，再让它重复做对；之后才扩大分工、延长运行时间，并用产出证据和环境改进维持质量。
原文附有演讲、访谈和帖子出处，并说明部分视频引文来自自动转写，个别词可能存在误差。本文保留这些来源层级，不将整理者的推演或个人自述当作独立核验后的事实。