Grok Bot 十条进阶实践：把 AI 当团队成员管理

从工具到团队：Grok Bot 十条进阶实践方法论

@benln 整理的一份来自 Bot 团队内部实践的清单，汇集了多位早期深度用户（@naoufal_elh、@kiaraplds、@johnbai、@shaoruu、@poteto、@pengzheng_、@leerob）的实战经验。

这份清单的核心视角值得注意：它把 AI Bot 当作"团队同事"来管理，而不是当作一次性问答工具来使用。十条技巧本质上是一套"AI 团队协作方法论"。

1. 在 Mac 上配置 Peekaboo，解锁类 OpenClaw 的能力 Peekaboo 是一个让 AI 获取 Mac 屏幕视觉与操作能力的工具。这条建议的本质是：让 Bot 从"只能读写文本"升级为"能看见并操作你的电脑"，从而处理那些必须观察屏幕、点击界面才能完成的任务。这是能力边界的扩展，属于基础设施层面的投入。

2. 按角色使用 Bot（设计师、工程师、项目经理） 每个角色有独立的系统提示词和例程。这对应软件团队的真实分工：不同岗位有不同的上下文、语气和工作方式。把角色固化进系统提示词，比在每次对话中临时说明"你是设计师"要稳定得多。

3. 用频道（channel）组织项目和工作流 同一个 Bot 可以跨多个频道工作。频道即上下文边界——每个频道沉淀一个项目的对话历史与资料，Bot 进入哪个频道就自动获得哪个项目的语境。这解决了"一个 Bot 如何同时服务多个项目而不混淆上下文"的问题。

4. 定时例程不要跑得太频繁 每小时或每天几次通常足够。原因有三：频繁调度消耗算力和费用；大多数信息类任务的变化速度没那么快；过于频繁的输出会造成噪音，让人反而忽略真正重要的结果。

5. 周期性任务交给一个新 Bot，主 Bot 保持对话连续性 这是一个分工策略：主 Bot（如"幕僚长"）承载你长期的、有上下文积累的对话；重复性任务则交给独立的新 Bot 执行。好处是主对话不被任务噪音污染，同时周期性任务的失败也不会影响主 Bot 的状态。

6. 用可定制的规则做权限管控，写操作必须先审批 对连接了 X、Gmail 等外部服务的 Bot，应默认禁止写入和破坏性操作，执行前必须请求人工批准。这是典型的最小权限原则：AI 可以读、可以起草，但"发出去"这个动作必须由人确认。这是把 AI 接入真实账户体系时最关键的一条安全纪律。

7. 用自己过往的手写内容喂养 Bot 提供你真实写过的文字作为范例，Bot 会逐渐逼近你的个人风格。这是低成本的风格迁移：不需要微调模型，只需在上下文中提供足够多有代表性的样本。

8. 设立"首席 Agent"（Chief of Agents） 这是整套方法论中最具组织色彩的一条：创建一个元 Bot，掌握所有 Bot 必须遵守的统一规范——只起草不发送、命名规则、语气风格、可用工具白名单。之后创建任何新 Bot，都让这位"首席 Agent"按同一套规范生成。它相当于 AI 团队的"制度制定者 + HR"，保证团队扩张时规则不稀释。

9. 建例程前先问：真人同事能做这件事吗？ 能，就建；不能，先优化流程本身。并且永远不要设置每 5 分钟跑一次的例程。这条是防止自动化的滥用：AI 例程应该替代的是"人本来就该做但重复枯燥的事"，而不是用机器的频率去制造人类根本不需要的信息刷新。

10. 名字驱动行为（Name-driven behavior） Bot 仅凭创建时起的名字就会表现出相应的主动性——角色从名字中可读，名字本身就在引导行为。这揭示了一个实用规律：命名即提示词。"周报撰写助手"和"小助手"会表现出明显不同的行为倾向，起名时就应该把职责写清楚。

贯穿十条的四个底层原则

· 组织化思维（2、3、5、8、10） 像搭建真实团队一样搭建 AI 团队：有角色、有分工、有制度 · 安全与克制（6、9） 读写分离、人工审批、限制频率，防止 AI 权限失控 · 上下文工程（3、7、10） 频道、范例、命名，都是为 Bot 提供正确语境的手段 · 成本意识（4、9） 频率即成本，自动化要匹配真实需求节奏