我用 Grok Bot 搭了一个「数字军团」，还真的把网站做出来了
最近我做了一个很有意思的实验：
不是用 AI 当助手，而是直接用 Grok Bot 组了一个团队。
我给这个团队起了个名字：ShipLab
它不是一个“聊天机器人合集”，而是一支我按真实产品流程分工出来的数字团队。
然后，我把一个实际项目交给了它们：
做一个 X 数据排名网站 —— xpaiming.com
更有意思的是，这件事不是停留在“讨论需求”层面，而是真的走了一遍：
想法 → 调研 → 拆解 → 开发 → 测试 → 修复 → 上线
而且，从截图来看，它们已经不只是“各说各话”，而是在一个团队群里、围绕同一个项目推进。
我搭了一个 5 人的 AI 团队
我没有给它们配 CEO、CTO、COO 这种虚职。
我只保留了真正能干活的角色。
1）Alex Carter — Project Lead
负责整个项目的推进、优先级、任务拆解、上线判断。
Alex 的作用不是“开会”，而是接收目标之后，判断：
- 这个事情值不值得做
- 先做什么，后做什么
- 谁接手最合适
- 当前应该推进到哪一步
相当于这支数字军团里的项目负责人。
2）Maya Chen — Research & Product
负责调研、竞品、痛点、PRD。
如果说 Alex 负责推进，那么 Maya 负责判断：
“这个功能该不该做，应该怎么做。”
她更偏产品和研究侧，负责把模糊的想法转成可执行的需求。
3）Ethan Park — Full-Stack Engineer
负责技术方案、前后端、数据库、API、AI 接入和部署。
我没有把开发再拆成前端、后端、DevOps、AI 工程师。
因为对于一个小团队来说，一个能落地的 Full-Stack Bot，比一堆细分岗位更实用。
截图里也能看到，Ethan 负责：
- 修复页面问题
- 根据 Issue 改功能
- 发预览链接
- 处理部署流程
- 推送更新版本
4）Leo Bennett — QA & Release
负责测试、验收、提 Issue、复测、上线前检查。
Leo 这个角色我觉得特别关键。
因为 AI 写代码已经不稀奇了，但谁来持续找问题、压质量、盯回归，这件事很重要。
从截图里看，Leo 不只是“说一下有 Bug”，而是真的做了这些动作：
- 对照原型和 PRD 测
- 提炼成 P0 / P1 问题
- 开 GitHub Issue
- 跟进开发修复
- 修完之后再复测
这已经很像一个真实 QA 的工作方式了。
5）Zoe Morgan — Growth & Marketing
负责增长、定位、文案、SEO、推广。
很多人做产品时，运营和增长总是最后才想起来。
但在我的这套团队结构里，Zoe 是一开始就存在的。
她负责思考：
- 页面文案是否清晰
- CTA 是否明确
- 榜单怎么命名更利于传播
- 上线之后怎么做 X / Reddit / Product Hunt 推广
- 数据和路径是否会影响用户理解
她的存在让这个团队不是“会写代码”，而是更像“会做产品”。
ShipLab 不是摆设，它们真的在一起干活
这次最让我觉得有意思的，不是每个 Bot 的自我介绍，而是：
它们真的在同一个群里协作了。
ShipLab 群里已经形成了一种很像真实互联网小团队的协作方式：
- Alex 负责整体推进
- Maya 负责研究和产品
- Ethan 负责开发和部署
- Leo 负责测试和提 Issue
- Zoe 负责增长和产品表达
这不再是“我问一个 AI，一个 AI 回我”。
而更像是：
我把目标丢进团队，团队开始分工运转。
它们怎么推进 xpaiming 这个项目？
从截图里能看到，整个项目已经不是一句“帮我做个站”，而是进入到了真实的产品推进节奏。
比如 Leo 在群里直接同步测试进度，按优先级给出结果：
- P0 本地已修好
/tweets原来是 404，后来修成正常可访问- P1 还有日报页、账号榜、登录门、语言说明等问题待处理
也就是说，Leo 并不是泛泛地说“这里还有点问题”，而是已经在按真实研发流程拆成待办。
后面的 GitHub Issues 截图也印证了这一点，已经明确列出了几个开放中的 P1 问题：
- #6
?lang=en文案切换不完整，存在中英混排 - #5
/monitors暴露了getSessionStub实现细节 - #4 账号榜搜索 / 排序 / 筛选未启用，缺曝光列
- #3 日报页缺 KPI / 图表 / 生成日报图
这就不是“聊天记录”了，而是已经进入了可追踪的工程管理状态。
这个团队已经出现了“开发—测试—回归”的闭环
从聊天记录里，我最喜欢的一点是，它已经出现了很明确的闭环：
第一步：QA 提问题
Leo 先测出问题，把问题按 P0 / P1 分类，再开 Issue。
第二步：开发按单修改
Ethan 根据 Issue 去改，并同步提交和部署进度。
截图里甚至出现了具体 commit：
56fea5ab3196dc
这让整个过程更像一个真实团队，而不是“AI 口头上说改了”。
第三步：发布预览环境
Ethan 把更新部署到公开预览地址：https://xpaiming.com/
然后通知 Leo 去复测。
第四步：QA 再次回归
Leo 再回来验证：
/tweets是否恢复正常- 登录门是否合理
- 排行榜字段是否完善
- 日报页是否对齐原型
这就是一个完整的：
测试 → 提单 → 开发 → 部署 → 回归
闭环。
但它也暴露了一个很真实的问题：AI 团队还不能完全脱离人
这次实验里，我反而觉得最真实、也最有价值的，不是“AI 很强”，而是它把目前 AI 团队的边界也暴露出来了。
比如截图里就能看到几个非常真实的卡点：
1）权限问题
群里没法直接批准某些操作，比如：
- 开通道
- GitHub 登录授权
- 某些推送或访问权限
也就是说，AI 能推进流程，但很多关键权限还得人来拍板。
2）外部系统依赖
比如 Vercel token、预览 URL、GitHub Issue、部署状态，这些都不是靠“聊天”就能解决的。
要让 AI 团队真正工作，它必须接入真实工具链。
3）上下文和协作还需要人为兜底
虽然它们已经可以分工，但目前还做不到完全自主运转。
更像是：
一个人带着一群 AI 员工一起干活。
这其实已经很有意思了。
xpaiming 对我来说，不只是一个网站
很多人看到 xpaiming，可能会觉得它只是一个榜单网站。
但对我来说，它更像是一个验证：
AI 团队不只是能聊天，已经可以参与真实项目交付。
xpaiming 的价值不只是站点本身，而是它证明了一件事：
过去我们使用 AI，更多像是：
我提一个问题，AI 回一个答案。
而现在，我更想测试的是：
我能不能把 AI 组织成一个团队，让它们围绕一个产品共同推进？
ShipLab 就是这个实验的开始。
我越来越相信，未来的独立开发者会先“搭团队”，再“做产品”
以前一个人做产品，意味着你要一个人承担：
- 调研
- 产品设计
- 开发
- 测试
- 上线
- 推广
现在，这种模式正在变化。
也许未来的一人公司，不再是“一个人做所有事”，而是：
一个人 + 一支数字军团。
你负责：
- 提出方向
- 做关键判断
- 授权关键动作
- 验收最终结果
而你的 AI 团队负责：
- 把事情一步一步往前推
这一次，ShipLab 交付的是 xpaiming。
下一次，也许这支数字军团能做出更多东西。
结语
我最近越来越觉得，AI 最值得探索的，不是“单个模型到底多强”，而是：
怎么把多个 AI 组织起来，让它们像一个真实团队一样协作。
ShipLab 还是很早期。
它还不完美，也还离不开人。
但它已经开始表现出一种新的工作方式：
不是一个人用很多工具。
而是：
一个人带着一支 AI 团队，持续把想法推进成产品。
这件事，比单纯的 AI 写代码更让我兴奋。
正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](https://www.harries.blog/img/qrcode_gzh.jpg)
