一天造出3700星开源GrokBot：AI智能体构建与自动维护实录

一位开发者用一天时间构建了开源AI助手Rakazo（被称为开源版GrokBot），项目在GitHub上斩获3700颗星、吸引100位贡献者，合并了超过1200个PR。他最近在B站分享完整方法论，核心不是模型多强，而是验证驱动开发与模拟器测试的组合拳。

为什么GrokBot类产品受人追捧

GrokBot本质上是一个AI助手，用户喜欢它的原因是"简单"——一切都在聊天窗口里完成。相比过去的OpenClaw^广告、Hermes等助手产品，GrokBot和Rakazo把配置复杂度降到了最低。据视频介绍，每个机器人都拥有自己的"电脑"，可以是共享机器或独立机器，并且内置了routine等开箱即用的能力，用户大多数时候只需要对话，无需手动调整设置。

Rakazo完全免费且开源，采用Apache许可证，支持自托管。视频中展示了多条用户评价，其中一条明确提到："Hermes不错，但配置更复杂。Rakazo的多智能体工作流更好，设置更简单。"另一位用户则表示它完全替代了GrokBot，移动端也很流畅。

产品覆盖桌面、移动和Web三端，所有数据云端运行并自动同步。作者形容，这样一个复杂产品在一年前可能需要20人团队花一年时间构建，而他只用了一天。

一天构建的四个关键阶段

阶段一：一小时规划，明确产品边界

作者强调规划依然是核心能力。如果只给AI一句话指令，项目大概率会中途卡住。他用大约一小时与AI讨论，确定了几个不可妥协的原则：

• 三端同步：移动、桌面、Web必须同时工作，这是GrokBot模式的基础。
• 兼容任意模型：ChatGPT订阅、OpenRouter、Claude API Key、本地LLM都要能接入。
• 不绑定任何第三方服务：沙箱提供商（Daytona、E2B、Box）、集成库（Composio、Pipedream）都通过接口抽象，用户可以自由替换。

这些原则被写入项目的agents.md文件，确保后续每位贡献者添加新功能时都遵守同样的架构约束。作者认为，从第一天就设计好接口抽象，远比后期迁移供应商容易。

agents.md 是近年 AI 辅助编程实践中流行起来的一种约定：在代码仓库根目录放置一份纯文本说明文件，向 AI 编程助手声明项目的架构约束、编码规范、目录结构、禁止事项与验收标准。它借鉴了 README.md、CONTRIBUTING.md 的思路，但面向的读者是模型而非人类。因为大语言模型在长会话中容易遗忘早期指令、也倾向于选择最省事的实现路径，把关键原则固化成仓库内的持久文件，可以让每一次新会话、每一位新贡献者（人类或 AI）都自动继承同样的边界条件，避免架构在多次迭代中被逐步侵蚀。类似的还有 CLAUDE.md、.cursorrules 等形式。

阶段二：用规划模式驱动AI持续执行

规划完成后，作者使用Claude进行UI设计——因为GrokBot已经解决了核心UX难题，无需重新发明。随后执行/goal指令，让AI持续工作直到计划中的所有条目被勾选完成。这一步实际运行了两次，第一次跑了一整夜。

阶段三：安全加固

项目初步跑通后，作者运行了DeepSec进行安全漏洞扫描，进一步硬化代码。这个环节在一天构建流程中容易被忽略，但对开源项目尤其重要。

阶段四：模拟器与截图验证

这是整场分享中作者反复强调的"最有价值的技巧"。他认为，验证是让LLM从"差不多能用"走向"真正完成"的分水岭。

具体做法是：要求AI为产品的每一个页面提供截图，没有截图就不算完成目标。AI无法伪造截图，因此这成为判断功能是否真正工作的硬性标准。对于桌面端、Web端和移动端，作者使用Expo、Maestro等工具让AI自行点击、截图、比对。

模拟器：让AI离线自测第三方集成

构建AI助手绕不开第三方服务：Gmail、Slack、GitHub、Stripe、Composio、Daytona……但让AI登录真实服务测试，会遭遇Google封禁、速率限制等问题。公司也不希望自动化流量冲击其API。

模拟器（emulator）解决了这个矛盾。以Vercel Labs的emulate.dev为例，它提供一个Slack的克隆版本，拥有独立的内存数据库，运行在localhost上。AI向模拟Slack发送消息会得到与真实API一致的200响应，消息状态在多次请求间持久化。

作者本人就是emulate.dev中Gmail API和Microsoft API的贡献者。他总结了模拟器带来的能力：有状态操作（创建仓库、推送提交、发邮件、Stripe扣款均可跨请求保持）、真实协议兼容、离线可运行、CI就绪、零配置。类似工具还有LocalStack（本地AWS）和Floci（零成本本地AWS）。

当现有模拟器不覆盖Composio或Daytona时，作者直接让AI去官网抓取API文档，自行构建模拟版本。他认为模仿一个API并配上小型内存数据库并不困难，AI完全能胜任。

LocalStack 是一个在本地模拟 AWS 服务的开源工具，它在单机上提供 S3、SQS、Lambda、DynamoDB 等数十种服务的兼容实现，开发者无需真实云账号即可跑通集成测试。其价值在于三点：一是测试不产生云费用、不受配额与速率限制；二是测试可在 CI 中离线、确定性地重复执行；三是可以人为制造故障与边界条件，而真实服务很难按需复现。文中提到的 emulate.dev 与 Floci 思路相近，只是把目标从 AWS 换成了 Slack、Gmail、Stripe 等 SaaS API。这类工具的共同前提是保持与真实服务一致的协议与响应格式，从而让被测代码不做任何修改即可切换。

如何维护100人贡献的开源项目

项目上线后，作者的角色从开发者变成PR管理者。他目前的策略有两层：

第一层：每个PR附带截图。 项目早期就配置了GitHub Actions，每次PR运行Playwright测试并生成全站截图，累计已有350张。作者不需要亲自运行项目，只需浏览变更部分的截图即可判断是否有UI问题。开源项目的GitHub Actions免费额度在这里帮了大忙。

第二层：自动合并机器人。 一个基于GrokBot/Rakazo的智能体每隔几小时唤醒，审查新的开放PR，自行决定哪些可以合并。简单bug修复直接合入；大型功能则等待作者批准，并附上截图供审阅。作者强调这不是盲目合并——恶意PR依然会被拦截，所有变更都经过审查和清理。

此外还有cron任务自动清理冗余的UI文案、执行安全检查和代码清理，这些可以跑在Rakazo、GrokBot或GitHub Actions上，复用已有的Claude、Cursor或Codex订阅。

Playwright 是微软开源的无头浏览器自动化框架，支持 Chromium、Firefox、WebKit 三大内核，常用于端到端测试与网页抓取。与早期的 Selenium 相比，它自带自动等待、网络拦截、多标签页与多浏览器上下文管理，并且可以直接对页面元素或整页截图。在本文的流程中，Playwright 承担的是“可验证性基础设施”的角色：AI 修改代码后，由它启动应用、遍历页面、生成截图工件，人工只需比对视觉差异即可判断变更是否破坏了界面。配合 GitHub Actions，这些截图会作为 PR 的附件留存，形成可追溯的验收证据链。

模型选择与时效性观察

作者在规划阶段使用了GPT-5.6，构建阶段使用Grok 4.6——选择理由仅仅是它当天刚发布。他在视频中提到，录制时模型已迭代到Grok 4.7和GPT-6.1，但强调"几个月前的模型也完全够用"。真正拉开差距的不是模型版本，而是验证体系和信任程度。

给开发者的三条启示

1. 验证优先于生成。 让AI证明功能可用，而不是相信它说完成了。截图和模拟器是低成本、高回报的验证手段。
2. 接口抽象要在第一天完成。 不绑定沙箱商、不绑定集成库、不绑定模型提供商，这种灵活性是开源项目长期生命力的来源。
3. 维护可以自动化，但不能放任。 自动合并的前提是完整的测试、截图和安全审查流水线。

作者最后说，现在推动AI走得最远的人，是那些最信任AI、也最有想象力的人。一年前看似不可能的事，今天已经可以一个人完成。