Today for AI
ALL INTELLIGENCE
Yetone Reveals Fully Automated Magpie Maintenance Workflow Using Three Parallel Claude Code Loops for Issues, PRs, and Community Feedback宝玉 (@dotey)T2Agents & Workflows

宝玉 (@dotey) · 10/14/2026, 03:04:57

Yetone Reveals Fully Automated Magpie Maintenance Workflow Using Three Parallel Claude Code Loops for Issues, PRs, and Community Feedback

By 宝玉 (@dotey)Original title: 前一段 Loop Engineering 不是很火么，不过真做好的也不多。
68AI Score
Executive Summary

Developer yetone shared an automated maintenance workflow for the open-source project Magpie using Claude Code and Opus 5.5, running three parallel loops to handle GitHub/Discord issues, Twitter feedback, and code cleanup. The system uses a low-cost model to pre-filter irrelevant tweets to save tokens and relies on documented design preferences in memory to minimize human intervention beyond minor UI tweaks.

SOURCE COVERAGEFull Original Report

前一段 Loop Engineering 不是很火么，不过真做好的也不多。

知名开源开发者 yetone 在 X 上公开了他维护 Magpie 的工作流：用 Claude Code 加官方的 Opus 5.5 模型，同时开 3 个 /loop 循环任务，让 AI 自己盯 GitHub issue 和 PR、Discord 社区和推特反馈，修 bug、加功能、发版、回复用户。他自己每晚抽一点时间“铲铲屎”，主要处理 UI/UX 问题，“然后就没活儿了”。

他自己说这套流程“没有任何的魔法，甚至还特别简陋”。

【3 个循环任务分别干什么】

/loop 是 Claude Code 自带的命令，让同一段提示词反复执行；不写间隔时，由模型自己决定多久跑一次。这个命令 Codex 也支持，其他的我没测试，估计也差不多。

yetone 截图里的 3 段提示词都没写时间间隔，我自己去 Codex 跑了一下，默认是 1 小时。

简单解释一下他这三个循环。

第一个循环：管 GitHub 和 Discord。

指令要求 AI 盯 GitHub issue，判断哪些值得修、值得做；修完要发版并回复提问的人，不值得做的也要回复。有一类 issue 单独规定了统一话术：如果是“中转站”来打广告，统一回复“感谢关注，日后会出相关合作方案，敬请期待”，不能直接把第三方中转站加进产品。

对 PR，指令要求逐行看代码、看逻辑，再把代码拉下来实际跑一遍，确认没有 bug 才能合并，否则回复或关掉。指令里写了原因：“我怕有的人提的 PR，是无脑用 Coding Agent 乱写的，自己都没测过。”

指令还要求 AI 实时盯 Magpie 的 Discord 服务器，所有频道一个不漏，有价值的反馈就去修或加功能，值得讨论就继续讨论。最后专门叮嘱：在 Discord 里要真正 @ 到人，只写名字对方收不到通知。

第二个循环：管 X/推特 的用户反馈。

盯推特上关于 Magpie 的反馈，有价值的建议或能复现的 bug 就去做，上线后回复那条推文。这段指令要求先用便宜的“决策模型”，比如 Jev，判断推文是不是在说 Magpie、是不是反馈，不相关的直接丢掉，别转给主模型，“不然太浪费 Token 了”。

【注：Jev 是 TypeSafe AI 推出的模型，只做判断题、选择题和打分，输出概率或分数，不生成文字。官方定价是每百万输入 Token 0.042 美元，输出免费。】

顺便说一下，如果你的产品名或者要关注的事比较稀有，不一定需要 Jev，他之所以加，是因为 magpie 在英文里是“喜鹊”，按关键词抓推文会抓到大量无关内容，全丢给 Opus 判断很费钱。

第三个循环：清理和总结。

这段指令开头写着“现在 magpie 完全是自动化更改代码和合并社区里的 PR”，要求 AI 定期清理“屎山代码”和恶意代码，防止项目变得难以维护；同时把经验教训写下来，比如哪些 PR 不该合、哪些验证不够严密，留给以后的 AI 参考，避免重复犯错；还要把总提交低质量代码的人拉进黑名单。

【作者补充的两点】

发完截图后，他在两条回复里补了两点。

一是给 AI 真实的运行环境。他准备了一台 Mac 和一台 Windows 电脑，再在 Windows 上开一个 Linux 虚拟机，三个系统的复现环境就齐了。AI 每次都要在这三端真实复现 bug，再去修。

二是 AI 怎么做出符合他心意的决策。他说靠的是 Claude Code 的记忆系统和仓库里的设计文档。开发 Magpie 之初，他和 Claude Code 讨论、头脑风暴了很多内容，这些都被记进了记忆文件。之后遇到要拍板的事，或者涉及审美偏好的设计，AI 会参考这些记录，做出跟他比较一致的选择。

【总结下】

他把维护项目的日常活拆成了 3 条流水线，每条只管一个入口（GitHub、推特、代码库本身），各自循环。人只留下 AI 做不好的部分，也就是 UI/UX 的审美判断。

当然要跑起来得有几个前提：

  1. AI 能在真实的三端环境里跑代码，验证结果靠实际运行；
  2. AI 手里有他早期写下的偏好和设计文档，知道他会怎么选；
  3. 犯过的错被写成经验，下一轮的 AI 能读到。

提示词都是大白话，篇幅主要花在边界情况上：不值得修也要回复，中转站广告怎么回，Discord 要真 @，不相关的推文别浪费 Token。

有几个特别要注意的点：

  1. 先把验证环境搭好，再让 AI 干活。AI 改完代码说“修好了”没用，要能在出问题的那个系统上跑一遍。你的项目只跑在网页或服务器上，一个容器可能就够；要多端的，就像他一样把每一端都备齐。

  2. 在提示词里写清楚“遇到这种情况怎么办”。他的三段指令里，大部分字数花在例外处理上。你让 AI 自动回复用户之前，先想想会有哪些奇怪的来信，提前定好处理办法。

  3. 用便宜模型挡在前面。先用一个几乎不要钱的分类模型过滤一遍，只把真正的反馈交给贵模型，这个做法几乎任何监听类任务都能用。

  4. 让 AI 自己总结教训。第三个循环要求把“不该合的 PR”“验证不严的地方”记下来，下次的 AI 读到就会更谨慎。这相当于给 AI 建立了一个自我迭代优化的循环。

  5. 项目早期多花时间和 AI 聊设计。他说 AI 后来能按他的偏好做决策，依赖的是开发初期那些讨论被记进了记忆和设计文档。想让 AI 少问你，就先把你的想法写下来让它记住。

仅供参考，重要的是学习思路，不必一模一样的照搬。

↳ 引用 @yetone (yetone): 很多人想让我分享一下工作流，我一直没想好怎么分享，因为其实我没有任何的魔法，甚至还特别简陋，总觉得分享出来毫无意义。其实我就是用 Claude Code，然后用官方的 Opus 5.5 模型执行 loop 就可以了。

我会并行执行图里的 3 个 loop，然后每晚抽一点时间铲铲屎（主要是 UI/UX 的问题），然后就没活儿了。