Grok Bot 熟练之后，过去一个团队一周能干完的活，现在只要前期配置一次，交给你的 Bot 团队，他们很快就能完成。昨天一个白天的时间，我用几个 Bot，把个人网站从一个想法做到了上线，成品在这里

。如果想弄懂从一个 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。公开上线 / 买服务 / 改域名等不可逆操作必须我明确点头。短回复，先证明再扩。

只在我喊你时工作。没事不主动刷存在感。

由于新加入了两位同事，管设计探索的小蓝现在有了同事，不是自己单干了，我们需要在他的简介里补上如下工作禁区：

1	禁区：不碰生产代码与上线（归 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。