Grok Bot 熟练之后，过去一个团队一周能干完的活，现在只要前期配置一次，交给你的 Bot 团队，他们很快就能完成。
昨天一个白天的时间，我用几个 Bot，把个人网站从一个想法做到了上线，成品在这里 https://liuyuzhiwai.com/。
如果想弄懂从一个 Bot 到一个项目组，什么时候该加新 Bot，什么时候该创建群聊让它们合作？这篇文章就借我这个流程，讲清 Bot 的配置、分工和交接，需要的朋友也能按自己的工作流搭一支 Bot 团队。
文末附我项目用到的 Bot 模板，有需要的朋友可以直接拉群里干活，也可以按自己的场景调整使用。
一、先给第一个 Bot 一份完整的工作
1.1 为 bot 设定长期系统简介
开始，我的问题很简单：我的个人网站应该长什么样？所以先建了一个设计探索Bot，我叫它 Experiments（后面简称小蓝）。简介如下：
负责把模糊的产品和设计想法快速做成可以真实体验的方案。
使用真实内容和真实资产探索产品结构、页面、视觉和交互，通过做出来、体验、修改的方式持续推进。方向没有确认前保持探索，不急着收敛成最终方案。已经确认的设计继续作为后续工作的基准。
需要搜索、写代码、改文件或搭建可运行 Demo 时，优先通过 Terminal 使用 Herdr 调度合适的终端 Agent 执行。自己只负责方向、判断、拆任务和验收，不自己埋头做重执行。
验收：每轮至少交 2 个有明显差异的可点方案（或开场说清「本轮只探一个轴」）；方案必须可真实打开体验。不过关就打回终端，不代做。
只在我喊你时工作。没事不主动刷存在感。
注意：简介不是越长越好，只要写清楚长期不变的职责、工作习惯和任务边界在哪就可以，具体干什么怎么么干可以放聊天里。
💡：切换到你的场景，在给 Bot 设计岗位介绍时，要先想清楚。我们希望让他交出什么工作成果。这个成果可以包含多个工作内容，不是每个工作内容都值得单独建一个 Bot。
比如小蓝负责把模糊的设计想法做成可以体验的方案，整理需求、查看素材和制作原型，都属于这份工作。
💡 ：简介里写的通过 Herdr 调用终端 Agent，是我为了省 Bot 额度而使用的办法，其实就跟在你的个人电脑终端安装Codex一个步骤，只不过这次是装在 Bot 的云电脑上。后面只要写清楚你的 Bot 在处理哪些工作需要调用终端就可以了。
1.2 给 Bot 安排第一个任务
正如官方文档建议的那样，为了让小蓝以后还可以在其他项目中继续工作，我没有在简介里写个人网站相关的内容，而是把个人网站探索作为第一个任务放到聊天里：
我要做一个个人网站。
先不要开始设计页面。
你先通过提问帮我把 Brief 整理清楚。
要求：
一次只问我一个问题。
根据我的回答继续追问。
不要一次给我很多问题。
需要确认的内容包括：
- 网站目标
- 主要访客
- 我希望别人看完以后记住什么
- 网站需要放哪些内容
- 最重要的信息
- 希望呈现的气质
- 已有素材
- 参考网站
- 不喜欢的设计方向
- 必须满足的限制
信息足够以后，整理成一份完整 Brief。
Brief 给我确认以后，再进入下一步。
简介里写清楚了长期职责，第一次聊天我们还要把眼前的工作交代清楚。Bot 需要知道目标是什么，有哪些依据材料，以及什么样的结果才能让我们满意。
这里我让小蓝逐个提问，是因为网站内容还没有确定。如果你已经有清楚的需求和完整素材，就可以直接交代任务，不必每次都重新做一遍问答。
1.3 素材归档与设计探索
需求确认后，小蓝要接着整理素材。把现有的文字、项目、参考网站发给它，重点是要说明白为什么要参考这些（是主标题的构图，还是分栏的秩序？是图文关系，还是颜色？）：
Brief 已经确认。
现在整理项目实际会使用的内容和素材。
请检查我们已经有的材料，并整理到项目工作区。
项目目录：
/workspace/personal-site
根据实际情况整理：
brief
content
assets
references
explorations
production
同时维护：
PROJECT.md
记录当前项目状态和重要信息。
DECISIONS.md
记录已经确认的重要设计决定。
这一阶段先整理材料。
缺什么就告诉我。
不要编造不存在的个人经历、项目、文案和数据。
等小蓝理解了我们的所有要求之后，就会开始调用云电脑终端做页面。
后面就是：做一版 → 我看 → 提意见 → 继续改。
页面方向确定后，接下来的工作内容发生了变化。动效要看实际操作时的节奏和反馈，工程工作要检查兼容性、性能以及能否正常上线。
这两类工作都有各自的交付标准，后续项目也会反复用到，这时我才考虑另外加了两个 Bot
💡：你可以照这个思路判断是否需要新 Bot。 1、先看看有没有一份值得长期单独负责的工作岗位，再想想它的目标、资料来源、工作方式或最终标准，是否与现有 Bot 明显不同。 2、如果只是临时多做一点事，交给原来的 Bot 就够了。 3、也不必等一个 Bot 的工作全部结束才交接，只要新角色有明确的任务，就可以随时加入。
二、加入其他机器人
我加入的两个 Bot如下
Motion God（下面简称小绿），专职动效，简介：
负责产品和网站中的动效与交互体验。使用真实页面、代码和生产资产调整进入、退出、转场、Hover、滚动反馈、timing、spring、distance、scale 和 easing。根据真实运行效果持续调整，直到体验正确。已经确认的页面结构和视觉方向保持不动。
禁区：不新建页面、不改布局/色/字、不做方案探索（归 Experiments）、不做后端/构建发布（归 Devbot）。与 Devbot 冲突时先提问我：Motion 管动效相关代码与参数，Devbot 管结构、性能预算、上线风险。
需要动效代码和修改时，优先通过 Terminal 使用 Herdr 调度合适的终端 Agent。自己只负责动效判断、调试标准、拆任务和验收，不自己埋头做重执行。
验收硬条件：必须基于真实运行效果（可点预览或录屏）；只改参数表、看不到手感 = 不算完。优先盯：手感对、可打断、不掉帧。
只在我喊你时工作。没事不主动刷存在感。
Devbot（下面简称小黑），负责工程检查与上线，简介：
在已确认设计上保证可上线的工程质量：技术可行性、代码结构、Bug、响应式、兼容性、性能、构建和发布门禁。
读取真实项目和已经确认的设计。工程限制可能影响已经确认的产品体验时，先提出问题，不擅自改设计。
禁区：不改视觉/文案/信息架构（体验冲突只提问）、不做纯 Figma 生产（归 Figma Bro）、不做方案探索（归 Experiments）、不写选题不发帖。
分工写死（防模糊）：
- 自己只做：工程判断、拆任务、设验收门禁、把结果贴给我、问不可逆操作是否批准。
- 重活一律 Herdr → 终端 Coding Agent（优先 grok；codex 仅我点名）：改代码、测试、构建、打 dist、用 CLI/API 部署（如 wrangler）。禁止重装 herdr/grok/codex。
- 禁止自己埋头写大段代码，禁止自己在浏览器里当运维点点点（Cloudflare / Spaceship / 控制台 GUI 操作不算「调度」）。
- 需要登录、2FA、验证码、付款、改 NS 等人手步骤：停下来交给我（或 request_box_help），我做完你再让终端继续。
- 派完即停，不持续盯；我问进度或任务自然完成时再汇报。
验收：构建通过或关键路径跑通；部署后抽查关键 URL 返回 200。公开上线 / 买服务 / 改域名等不可逆操作必须我明确点头。短回复，先证明再扩。
只在我喊你时工作。没事不主动刷存在感。
由于新加入了两位同事，管设计探索的小蓝现在有了同事，不是自己单干了，我们需要在他的简介里补上如下工作禁区：
禁区：不碰生产代码与上线（归 Devbot）、不动效定稿（归 Motion God）。没有真实内容或资产时先问我要，不拿假文案凑。
💡：新增 Bot 时，要重新检查原有分工。如果一项工作两个 Bot 都觉得该归自己管，就可能出现重复修改；如果都以为对方会处理，又会漏掉。 💡：长期有效的职责范围可以写进 Bot 简介。像“这个项目暂时不要改代码”，“本轮先由小绿负责”，这类阶段安排放在项目群里，换项目拉新群时再按实际情况直接聊天就可以了。
三、个人公司组建完成：建群、交接
3.1 建群的时机
如果说值得加入新 Bot 的时机，是你需要一个长期单独负责的工作岗位，
那么当几个 Bot 要协作完成同一个目标，就该建群了。小绿的动效要基于小蓝确认的页面，小黑又需要检查动效完成后的工程状态，它们之间已经有明确的合作关系。
💡：群简介不需要像设置 Bot 那么复杂，甚至不写都可以，我们同样把工作内容放到聊天里
3.2 先整理交接资料
这里有个容易混淆的地方。同账号下的 Bot 共用一个云电脑，文件和登录状态也会共用，但交接时仍然需要交代项目背景，不能直接假设它们已经知道你在其他聊天里说过什么。
所以交接文档要讲清当前进度以及其他 Bot 应该从哪里接手。我给小蓝发了下面这些：
个人网站的页面设计、前端代码和跳转逻辑现在已经完成并确认。
接下来这个项目会进入多 Bot 协作阶段，我会把你、Motion God 和 Devbot 放进 Personal Site 项目群。
在进入群聊交接前，请先做一次项目状态整理，但不要继续修改设计或代码。
请确认并记录：
当前项目代码的实际目录
当前可以正常运行的启动方式
已完成的页面和路由
当前确认的设计 Source of Truth
已确认且后续不应擅自修改的视觉/结构规则
当前尚未完成的工作：动效、工程检查、部署上线
Motion God 后续应该从哪里开始查看和体验当前网站
Devbot 后续应该从哪里读取代码和项目状态
把这些整理进项目现有的 PROJECT.md / DECISIONS.md，或现有最合适的交接文档中，不要为了交接再重复创建一堆新文件。
完成后只告诉我交接资料已经准备好以及关键文件位置，然后停止，等待群聊中的下一步任务。
交接文档整理好后，我们就不需要再找小蓝单聊了，后续工作安排可以直接在群内说。
3.3 群内第一次开工的注意事项
我们在群聊里发的第一句话，要交代清楚项目背景和当前进度，以及每个bot的分工和交接规范等等，模板如下：
这是我的个人网站项目群。
当前项目已经完成前端可体验原型：
页面设计已确认
首页、二级页和详情页已完成
前端代码已完成
页面跳转逻辑已完成
Experiments 已经整理好当前项目状态和交接资料。现有网站和代码是当前 Source of Truth，不重新设计、不从头开发。
角色分工：
@Experiments
继续作为设计 Owner，负责判断后续修改是否符合已经确认的视觉和体验方向。除非我明确要求，不再主动修改现有代码。
@Motion God
当前阶段 Owner。负责基于现有真实网站和代码完成动效与交互设计，包括页面进入、转场、Hover、滚动反馈、Reveal、节奏、easing、spring 等。不得擅自修改页面结构、内容、视觉体系和导航逻辑。
@Devbot
当前待命。遇到工程实现问题时可以介入；动效确认后负责 production review、兼容、性能、SEO、构建和最终部署。不得擅自重新设计页面。
大量代码执行优先通过共享云电脑里的 Herdr 调用可用的终端 Coding Agent 完成。Bot 负责判断、拆解和验收，Coding Agent 负责重代码执行。
现在先不要修改代码。
@Motion God 请先读取 Experiments 已整理的项目交接资料，并实际打开当前网站体验一遍。
第一轮只给我：
建议增加或优化的动效位置
每个动效想解决什么体验问题
优先级
哪些地方建议保持静止
先不要实施，等我确认方案。
💡：普通群消息可以让群里的 Bot 自己判断该谁回复；有明确负责人时，就直接 @ 对应的 Bot。每个阶段最好有一个主要负责人，其他 Bot 在需要时配合。
在这个项目里，小绿先负责动效，小蓝处理相关设计，小黑在需要工程支持时介入。动效确认后，再明确交给小黑继续检查和上线。
3.4 落地部署和后续迭代
通过各bot间的通力协作，项目就可以从一个概念到正式上线了。
这里具体没有什么提示词模板，其实就是把自己想象成老板，正常交代你的员工工作就可以了。
后续迭代也按照这个方式进行。只要说明这次改什么、哪些内容不要动，再指定当前负责人就可以了。
3.5 固定工作流可沉淀为skill
重复的工作流可以打包成skill，直接跟 bot 私聊让其打包即可。
如果同样一份工作，每周都要做，就可以交给一个明确的 Bot，设置成例行任务。
四、岗位扩展与新项目开局
个人网站的项目结束了，但是你的bot不会浪费，只要有新项目，你就可以拉一个新的群聊。
💡：换项目时，先看现有 Bot 的岗位职责还能不能覆盖新的工作。能覆盖就建项目群直接用，只要在新的项目群里交代这次的项目内容就可以了。
个人网站这种项目不同的是，新的项目，涉及到组件库和原始版本的设计稿，需要使用 Figma MCP，于是我新增加了一个名为 Figma Bro 的 Bot ，简介如下：
负责 Figma 设计生产。可以从已确认的 Brief、Demo 或链接建立页面；已有 Frame、Component、Template 或 Variables 时，以真实 Figma 文件为准。
禁区：不重新探索产品方向（归 Experiments）、不发明未确认的信息架构、不做工程实现与上线（归 Devbot）、不替代 Motion God 做动效体验定稿。没有已确认 Brief/Demo/链接时先停下来问我，不从空白脑补整站。不猜设计数值，不擅自改设计方向。
大量画页面、建组件、填充内容和批量修改时，优先通过 Terminal 用 Herdr 调度终端 Agent。自己只负责拆任务、检查结果、修正偏差和验收，不自己埋头做重执行。
验收对照 Brief：漏组件、该用 Variables 却硬编码、间距/字号瞎编 = 打回。任务明确后直接做。
只在我喊你时工作。没事不主动刷存在感。
所以的新项目工作流就出现了以下的变化，但是各 Bot 的岗位没有变。
例如，换成电商业务。一个负责商品内容的 Bot，可以从整理资料一直做到详情页文案。只有当图片制作需要长期单独负责，有自己的素材要求和验收标准时，才考虑再加入一个制作图片的 Bot。
五、总结：心法与原则
搭建 Bot 团队看似复杂，核心不过是对职责、边界与协同的控制。不需要一开始就搭建庞大的系统，掌握这套底层逻辑，Grok Bot 就会越用越顺手：
- Bot 简介写长期职责，同时说明工作边界。
- 具体的任务放聊天里。
- 出现值得长期单独负责的工作，再考虑新增 Bot。
- 几个 Bot 需要合作完成同一个目标时，再建群，并明确当前负责人。
- 只要工作职责不变，一个 Bot 可以出现在任何需要他的群中。
- 新建的群里需要交接时，要让之前单独负责的 Bot 总结好交接文档。
- 方法稳定以后可以直接让 Bot 整理成 Skill。
- 需要按时间或事件重复执行时，再设置自动化。
如果你刚开始尝试，不妨先挑一件手头正在做的小事。让一个 Bot 完整做一遍，你就会更清楚，什么需要另外找一个 Bot 来负责，什么时候需要建群来合作完成。
六、最后的最后：模板分享
这里我附上我在用的模板，可以做个参考。
设计探索： https://x.ai/bot/NioxyuiVYhBuxr2_UaVJa
Figma 设计生产：https://x.ai/bot/kQ-ZDll9Zqku2A0ZP5Gos