从 Claude Code 到 Grok Bot：我搭了一套 24 小时 AI 编程 Agent

Magpie 是一个装在电脑上的开源小工具，可以让 Claude Code 这类编程助手随时切换模型，目前 GitHub 上已经拿下一万六千颗星。

前阵子，作者 yetone 在 X 上公开了自己维护这个项目的方式，开口第一句就挺让人意外：没有任何魔法，甚至特别简陋。

简陋到什么程度？就是 Claude Code 加上官方的 Opus 模型，再开三个 /loop 定时任务。他自己每天晚上只花一点点时间调整界面和交互体验，剩下全丢给 AI，自己反倒没活儿干了。

这里的 /loop 是 Claude Code 自带的小命令，作用是让同一句话在对话框里定时重跑。比如输入 /loop 5m 看看部署完了没，五分钟后它就会自动再问一次。不写时间间隔也行，模型会自己判断节奏。缺点同样明显：关掉终端就停了；就算一直开着，过几天也会自动失效。

其实吧，我觉得这已经是“在公开环境中开发”的雏形。一边开发、一边接收反馈、立即优化，这大概率就是未来的常态。超级个体尤其需要这个。

三个定时任务，各管一摊事

第一个任务，专门盯着 GitHub 和 Discord。有 issue 进来，AI 先判断值不值得修：值得修就动手改代码、跑测试、打包发版，再回来回复；不值得修也会礼貌回一句，说明原因。

碰到 PR 更较真：AI 会一行一行审代码，然后把代码拉到本地真跑一遍，确认没问题才会合并。作者这么设计不是没有理由——现在太多人用 AI 乱写一通就交上来，自己压根儿没跑过。

第二个任务，盯着 X（推特）上的用户反馈。不过他在最前面加了一个极其便宜的小模型 Jev，一百万字（token）才三毛钱人民币，专门干脏活：只做“是或不是”的判断，不写一个字。

为什么要多这一道工序？因为 Magpie 在英文里就是“喜鹊”的意思。如果直接按关键词抓推文，会捞回来一堆真的鸟。让便宜模型在门口把这些噪声拦掉，后面昂贵的 Opus 模型就只需要对付真正的用户反馈。

第三个任务，负责“清屎山”。每隔一段时间，AI 就去收拾项目里的烂代码、总结经验教训，顺便把反复提交垃圾代码的账号拉黑。

错题本，才是真正的秘密武器

这套流程里最核心的“错题本”，反而是 10 月 6 日才加上去的。

同一天，他还给发布加了道死规矩：不准为了赶时间跳过检查，每次正式发版前所有测试必须全部通过。有人翻了他的发版记录，自从立了这条规矩之后，Magpie 从最高一天狂发 170 个版本，直接降到每天稳定发 15 到 26 个版本。

为什么要搞错题本？因为提示词只能管这一次，错题本才能管下一次。

每次 AI 犯了错，就写成文件存进代码仓库，下一轮启动前必须先读一遍。这个本子不需要多复杂，一个普通文档就够，一行记一条：哪次代码合错了、为什么错、下次怎么避坑。

这样一来，留给人类的活儿就只剩两件了。

第一件是提供真机环境。作者准备了一台 Mac、一台 Windows，还在 Windows 里开了个 Linux 虚拟机。AI 只物理安装在一台电脑上，其他机器全靠 SSH 远程连接过去操作。因为在模拟环境里能跑通的代码，放到真机上未必不出毛病。

第二件是审美和拍板。界面好不好看、功能该不该加，AI 会翻看之前的聊天记录和设计文档，去猜作者会怎么选，拿不准的再留给人来定。

怎么把这套玩法搬到 Grok Bot 上？

如果觉得一直开着自己电脑太麻烦，可以把它搬到 Grok Bot 上。它 24 小时在线，自带云端电脑、浏览器和定时任务。

第一步，建个 Bot，立下规矩。

先新建一个 Bot，起名叫“项目维护”。第一次对话时，把下面这段话发过去，让它死死记住（方括号里的内容换成你自己的）：

你是【仓库名】的维护 Bot，这个项目只有我一个人管。

下面三条铁律，任何时候都不能破：

一、合并别人的代码（PR）之前，必须把代码拉下来跑一遍测试，没跑通绝对不许合。

二、.github/ 文件夹里的工作流、密钥和依赖配置，只有我能改，你碰到就停下来问我。

三、拿不准的事，先写进 LESSONS.md（错题本）里，再来问我，不要自己拍板。

我的习惯是：界面改动宁少勿多，加新功能之前先问我。

把这三条记进脑子里，每次干活前先读一遍。

第二步，连上 GitHub。

建议给 AI 单独注册一个 GitHub 小号，别用你自己的主号。否则它到处回帖、关闭别人的 PR，用的都是你的名字。

第三步，设个自动任务，盯紧代码仓库。

在 Grok Bot 的 定时任务（Routines） 里新建一条，绑定你的 GitHub。指令可以直接抄这段：

看看有没有新的问题（issue）。值得修就修，修完提交代码；不值得修也回一句，说明原因。

看看有没有新提交的代码（PR）。一行行读代码，然后拉下来跑测试，没通过就告诉对方错在哪，不许合并。

遇到明显是用 AI 乱写、自己根本没跑过的代码，直接关掉并说明理由。

干完活后，往 LESSONS.md 错题本里加一条记录：这次哪个代码不该合，哪个测试没跑够。

只有需要我拍板的时候才通知我，平时别来烦我。

第四步，再设个定时任务，每两小时去刷一次 X。

Grok Bot 默认就免费支持这个。顺便提一嘴，Grok Bot 不能像前面那样换用小模型来省钱，想控制成本，只能逼它“少看、少想、少废话”。

去搜一下最近提到咱们项目的推文。

先自己筛一遍：这条推文是在说咱们产品吗？是在提意见或者报 bug 吗？

如果不是，直接跳过，只简单记一行就行，别展开分析。

如果是真反馈：能复现的 bug 就直接修；有价值的建议就记下来。等新版本上线后，去那条推文下面回复人家。

拿不准的，记下来留给我看，不要自己动手。

第五步，锁好最后一道安全门。

把自动审查（Auto Review）打开，在规则里补上三条死命令：改核心配置要问我、删文件要问我、改自动化规则要问我。这三把钥匙，绝对不能交到 AI 自己手上。

还是需要盯一下

用云端 Bot 也有局限。它的电脑在云上，有些只在 Windows 真机上才会出现的怪毛病，它是试不出来的。而且它脑子里的“记忆”锁在平台黑盒里，你打不开，也没法检查它到底学到了什么歪理。

所以，错题本一定要落成实实在在的文档，存进你自己的代码仓库里，千万别指望平台自带的记忆功能。

说到底，AI 能替你熬夜值班，但替不了你做最后的把关。

这套玩法里最值得借鉴的，其实不是那几段提示词，也不是具体工具，而是两件事：先把“什么才算把活干完”的标准定死；再给 AI 配一本能不断升级的错题本。

前者让你跑得快，后者让你跑得久。

请在公开环境中开始编程吧。一个月迭代 300 个版本，这样的时代已经到来。在 云栈社区，每天都有不少开发者在探索类似的自动化玩法。