小宇资源库📄长图文-V1
万星项目magpie的作者让AI跑了三条命令，就让这个项目完全自动维护、升级，短短20天，迭代了1248个版本。
今年的AI圈，用AI写代码、剪视频、逆向软件，已经是相当前卫的应用了。
但现在，就连维护大型热门项目，AI都可以完全接管了。
Github开发者「yetone」最近开发了一个项目「magpie」，是一个给 AI 编程工具统一管理「模型、账号和接口」的软件，和大名鼎鼎的ccswitch同属一个赛道，热度每天都在迅速上涨。
magpie相比ccswitch，可以直接接入其他程序里的模型，比如Workbuddy海外版的DeepSeek-V4.1-Flash模型是免费的，通过magpie就可以让Codex用上Workbuddy里免费的DeepSeek-V4.1-Flash。
最近小宇也在测试，成熟的话会做一个详细的教程分享给大家。
项目非常火爆，短短3个星期，Github上已经有了12.9k的star。
软件功能已经很离谱了，但是这并不是这个程序的最大特色，它的维护方式才是最离谱的。
从编写代码、审查改动，到合并代码、发布版本，能想象到的大部分流程，都是AI完全代管的。
更离谱的是，短短20天，就迭代、发布了1248个版本。
而yetone自己，每天抽一点时间，刷刷推特，处理处理界面和使用体验上的问题，就完事儿了。
小宇原本以为，这背后怎么说也得有一套复杂的Agent编排，那种耗费了相当多时间的工作结晶。
结果后来yetone直接把自己的工作流公开展示出来了，简洁的有点超出常理。
yetone说他就是用Claude Code，加官方Opus 5.5模型，然后加上三条循环任务的提示词（也叫做「/loop」），就完成了。
嗯？就这样完成了？？？
但是这么一个高热度的项目绝对没有这么简单。
小宇仔细研究了一下yetone分享的工作流和yetone上传到Github上的commit，发现了很多地方可以吸纳、学习的超级干货，整理下来写成了一篇文章分享给大家。
首先是yetone自述的三条自动的循环指令loop。
1、三条loop
第一条loop：盯Github和Discord社区
Github上有用户提交的bug和需求，也有其他开发者贡献的代码，Discord是国外的交流社区，有着十分活跃且反馈速度极快的反馈平台。
yetone告诉他的Claude，有人反馈bug、提需求的时候，首先进行判断要不要做，要做的话就及时修复，修完、做完，然后发版并在原帖回复用户。就算决定不做，也会给用户一个回复，非常贴心。
对于网友在PR上提交过来的代码，yetone也要求Claude不能直接无脑收取应用。要逐行检查，再拉下来实际运行，验证提交的PR没问题之后，才能考虑合并。
yetone甚至还专门叮嘱了在Discord回复用户的时候，需要@到对方才行，只写名字的话就收不到通知了，而且都用的感叹号，看样子Claude犯过不少小错。
原文：
/loop盯一下Github issues，仔细分析，看看哪些是值得修复和实现的，修复或者实现后记得发版和回复，如果不值得修复或者实现也要回复，如果是中转站的广告商，就统一回复：感谢关注，日后会出相关合作方案，敬请期待。而不能一股脑地把第三方中转站直接加到我们产品里面。也要盯一下Github的PR，然后你要认真的去reviewPR的每行代码、每个逻辑，你要把代码拉下来实际跑一下，验证一下是否没有bug。因为我怕有的人提的PR，是无脑用Coding Agent乱写的，自己都没测过。所以你要看一下他这个PR，是否有问题，确保一切都没有问题，且实际验证过之后乜没有问题的话，你才能够去合并，否则你就去回复一下这个PR或者关掉PR。 另外还要监控一下MagpieDiscordServer里用户的反馈，实时的加入讨论，如果有有价值的反馈和建议，就去做修复跟添加新的功能。如果值得进一步讨论，那就继续讨论。记得查看MagpieDiscord Server里所有的channel，一个都不能漏掉！记得在Discord里要真实地at人，而不是只叫名字，不然对方收不到你的消息！
小宇简单介绍一下里面的名词：
issues：
类似于Github项目里的「评论区」，用户可以在项目issues里提交遇到的bug、使用反馈等等，作者修好和采纳后还可以点击「处理完毕」的记号，你对项目有任何bug提交或者使用反馈，都可以提交到issues里。
PR：
是 Pull Request 的缩写，可以理解为「代码合并申请」，也是Github里的功能。
就比如，有人帮 magpie 修了一个 bug，就可以提交一个 PR，请项目维护者检查然后采纳这次修改。维护者确认没问题了，再把改动合并到项目里。
第二条loop：盯X上关于magpie的反馈
这一条其实和第一条的作用是类似的，不过x上的多以讨论、吹水为主，yetone也主要是用来让Claude发现有价值的建议，或者能复现的bug，就去实现、修复，上线之后再回原帖告诉用户。
而且yetone还结合了前段时间爆火的判断模型jev，这是一个速度非常快、价格非常低、只做yes或no判断的判断模型（其实现在已经没什么人提了，小宇感觉已经凉了。。。）
yetone让Claude利用jev来做简单的判断，便宜模型jev发现帖子有价值或者相关之后，才会调用昂贵的模型进行针对性的处理。
毕竟要是用OPSP 5.5长期盯着社交平台，什么都让贵模型读一遍，对于这个完全免费的项目来说，价格未免就太高了。
原文：
/1oop盯一下推特上关于magpie的反馈，如果是有价值的反馈，或者是真实可复现的bug，那么就去做实现或者修复。完毕后记得上线，上线后记得回复推特 你应该先用便宜的决策模型比如jev 去判断推文是不是与magpie相关，是不是magpie的反馈，如果不是直接忽略不要把内容转发给你，不然太浪费Token了
第三条loop：检查代码，然后复盘教训
众所周知，虽然ai已经非常强大了，但写出的代码还是很容易变成一堆一堆的「屎山」。
小宇有点意外的是，yetone对这一方面的要求甚至只用了一小段提示词，只是略加提示要注意屎山代码和垃圾代码而已，顺带要求了claude把经常提交低质量代码的人拉到黑名单。
原文：
/loop 现在magpie 完全是自动化更改代码和合并社区里的PR 你要定时清理一下屎山代码和恶意代码防止项目变得难以维护以至于变废，并总结出经验教训，比如哪些是不应该合并的哪些是验证不缜密的等等放到经验中防止以后的agent犯同样的错误，以及要把老是提低质量代码的人拉入黑名单
但想让这个Github万星项目持续跑下去，还有几个关键条件需要搞定。
2、yetone做的其他事
比如维护项目还有一类麻烦就是：很多项目上的决定，根本没有标准答案，全都是人类的经验来判断的。
一个功能能做，但要不要加？设置页加几个按钮，会不会越来越乱？AI怎么知道开发者想把产品做成什么样？如果AI把产品越写越烂了怎么办？
yetone的做法，正好是小宇觉得最值得学的地方。
1️⃣保留记忆文件：
他在开发magpie之初，就和Claude Code讨论了很多想法。这些讨论被记录在记忆文件里，再结合仓库中的设计文档，AI后来做决策、选设计时，就能参考这些材料，做出相对符合他偏好的选择。
2️⃣提供真实环境：
yetone还补充了另一个关键条件：要把真实的运行环境提供给Agent。
比如用户小帅说Windows上打不开，那要是AI只在Mac上看了看代码，就宣布修好了，回过头了再让AI修，还是在没有bug的Mac上修，结果越修越乱，就出大问题了。
yetone的做法是，配置一台Mac电脑、一台Windows电脑，再在Windows上创建一个Linux虚拟机。三端环境都准备好，再让Agent在两台设备、三个操作系统上依次真实复现bug，能够真实复现之后再去进一步修复bug。（不用Mac创建虚拟机是因为yetone本人觉得他使用的mac性能太差了）
3️⃣「AI错题本」：
有时候AI会在同一错误上犯好几次问题，yetone也对这方面做了一定的调教，他告诉Claude，同一条教训，如果在三个不同日期的复盘里重复出现，就会升级进代码规范，变成后续审查要遵守的规则，类似于上学的时候的错题本。
这样，就能在一定的范围里减少重复踩坑的可能了。
小宇觉得，这里面很值得学的一点，就是开发者yetone花时间积累的经验，开始能被后面的AI任务反复用上了，每个人都可以参考、学习，应用到自己的项目里。
当然，这套方法也还在磨合，项目的公开复盘里，就有不少修完又返工、自动检查没有跑完的问题，后面的验收要求也是在这些教训中逐步补起来的。项目才发布没多久，长期维护质量、模型调用成本，以及能不能完全零人类干预，都值得继续观察，在实践中验证才行。
yetone也在项目的Commit里留下了一些非常有意思的对话内容，可以一窥顶级开发者和顶级AI模型的交流日常：
非常有力量感的要求
yetone表示：两个功能我全都要
yetone多次都说：这个太丑了。。
但一个持续接收真实用户反馈的项目，能把这些过程公开出来，小宇觉得已经很有参考价值了。
已经有很多开发者学习yetone的magpie工作流并着手尝试，还有非常好的效果。
截稿的时候，小宇又看了一眼项目主页，版本号已经到1252了，写稿的这段时间悄无声息迭代了五个版本。
当然，任何事都有争议，这个项目的迭代方式前段时间在网络上也经历了很多质疑和争论。
大家也可以在评论区发表一下你的看法。
不过可以确信的是，在你读着小宇的这篇文章的时候，它一直在悄无声息地更新着……
上一篇
如何打开开发者模式？
下一篇
鉴定热门视频(13)