三个 Loop，一个人铲屎 · yetone 的 AI 全自动软件工厂

01

值班表：三条 loop 全天转，人只有一个扇区

把三条 loop 画成三个恒转的环，人的那一份工作缩成一截扇形——这就是整套工作流的形状。

LOOP-01 · 社区与代码
盯 GitHub issue / PR + Discord 反馈，自动修、自动发版、自动回复。

LOOP-02 · 舆情与反馈
盯推特上关于 magpie 的讨论，命中真 bug 就修，上线后回帖。

LOOP-03 · 清理屎山
定期清屎山与恶意代码，沉淀经验教训，拉黑低质量提交者。

HUMAN · 铲屎窗口
每晚抽一点时间，处理 Agent 搞不定的 UI/UX 问题。做完就没活儿了。

02

三班岗：loop 的原始提示词

推文里那三张截图，就是这三条 loop 的完整指令。原文照录，一字未改。

LOOP-01 GitHub · PR · Discord RUNNING

盯 issue/PR，认真 review 别人的代码并实际跑一遍；同时泡在 Magpie Discord 里参与讨论。

> /loop 盯一下 GitHub issues，仔细分析，看看哪些是值得修复和实现的，修复或者实现后记得发版和回复，如果不值得修复或者实现也要回复，如果是中转站的广告商，就统一回复：感谢关注，日后会出相关合作方案，敬请期待。而不能一股脑地把第三方中转站直接加到我们产品里面。也要盯一下GitHub的PR，然后你要认真的去review PR的每行代码、每个逻辑，你要把代码拉下来实际跑一下，验证一下是否没有 bug。因为我怕有的人提的PR，是无脑用Coding Agent乱写的，自己都没测过。所以你要看一下他这个PR，是否有问题，确保一切都没有问题，且实际验证过之后也没有问题的话，你才能够去合并，否则你就去回复一下这个PR或者关掉 PR。
另外还要监控一下 Magpie Discord Server 里用户的反馈，实时的加入讨论，如果有有价值的反馈和建议，就去做修复跟添加新的功能。如果值得进一步讨论，那就继续讨论。记得查看 Magpie Discord Server 里所有的 channel，一个都不能漏掉！记得在 Discord 里要真实地 at 人，而不是只叫名字，不然对方收不到你的消息！

LOOP-02 Twitter / X RUNNING

先花小钱做判断，再决定要不要把这条推文交给大模型——避免浪费 Token。

> /loop 盯一下推特上关于 magpie 的反馈，如果是有价值的反馈，或者是真实可复现的 bug，那么就去做实现或者修复。完毕后记得上线，上线后记得回复推特

你应该先用便宜的决策模型比如 jev 去判断推文是不是与 magpie 相关，是不是 magpie 的反馈，如果不是直接忽略不要把内容转发给你，不然太浪费 Token 了

LOOP-03 屎山与恶意代码清理 RUNNING

全自动合并 PR 的代价是熵增，所以专门排一班岗来反向清理、沉淀经验、拉黑。

> /loop 现在 magpie 完全是自动化更改代码和合并社区里的 PR，你要定时清理一下屎山代码和恶意代码防止项目变得难以维护以至于变废，并总结出经验教训，比如哪些是不应该合并的哪些是验证不缜密的等等放到经验中防止以后的 agent 犯同样的错误，以及要把老是提低质量代码的人拉入黑名单

03

一天怎么过：Agent 干活，人收尾

Agent · 全天

三班岗自己闭环

三条 loop 并行执行，盯着 issue、PR、Discord、推特，该修的修、该发版的发版、该回复的回复。人不用在场。

Human · 每晚

抽一点时间铲屎

主要处理 UI/UX 的问题——这部分机器判断不了「好不好看 / 顺不顺手」。「然后就没活儿了」。

04

凭什么能跑起来：三块底座

yetone 在评论区补的三点，其实比 loop 本身更关键。

01真实三端环境

给 Agent 一台 macOS、一台 Windows，Windows 里再开一个 Linux 虚拟机。三端的复现环境就此齐活——每次都要在这三端真实地复现 bug，再动手修。

02记忆 + 设计文档

它怎么决策？靠 Claude Code「那套简陋但有效的记忆系统」和 repo 里的设计文档。开发 Magpie 之初和 Claude Code 头脑风暴的东西都被记进记忆文件，于是审美与取舍上能做出比较贴合本人的判断。

03全程 browser use

被问「盯推特还用 tw cli 吗」，回答是「所有的操作都是 browser use」——连推特这种反爬重灾区也直接走浏览器。

05

争议背景：一条推文怎么吵起来的

这条推文背后其实有一场「全 AI 自动化做软件到底行不行」的争论——起因是 WquGuru 写了篇《yetone 的魔法：magpie 是怎么让 AI 自己维护项目的》，magpie 被同行喷「快餐式服务」「不太敢用」。

「会不会有 github issue 里提示词注入的风险？」

@mev15_eth 提问 → @yetone：「现在已经很难了。」

「功能的决策呢，要不要做，有没有价值，如果同时有不同的方案，该用什么方案。会有一些产品规划的品味取舍问题。」

@sgfvdsg86265 → 这正是靠记忆系统 + 设计文档兜的那一块

「请问为什么不用 scheduled task，不是也能 access 本地文件？loop 在这里有什么优势？」

@ericqsf → @yetone：「没有优势，目的就是监听而已，只要能达成目的，啥方式都可以。」

「200 刀就够用了吗，大佬」

@sundjly → @yetone：「哈哈，完全不够。我每个月在 Magpie + Alma 上的支出至少 400 刀，然后还要注册 200 刀给工作。」

「是不是可以考虑攒一天发一个版，或者让 jev 决策是否发版」

@frostming90

「竟然不是用 Alma 吗( 还有拉黑机制」

@_yuchanns_

「那么问题来了，全自动骂人的 workflow 呢？」

@xuanwo（玩笑）

「护城河不是魔法提示词，是并行 3 个 loop 加上每晚固定铲屎窗口，人只碰 UI/UX 验收，其余让 Opus 5.5 自己闭环。」 — @itsone_ai 的总结

06

评论区的加料：追问、作业与金句

三百多条回复里，「大道至简」是刷屏，真正值钱的是下面这几类。

① 没被回答的追问 · 缺口就在这里

三路并行，怎么不打架？

三个 loop 都可能改同一个 git 仓库：是开 worktree 分分支、靠合并队列，还是按目录/模块划地盘？一堆人在问。还有人问得更细——三路并行的 deny 规则是共用一份还是各路独立，共用的话一路写炸目录会不会把别的也放行。

@LuckyCurveC · @sosolab13 · @MossAI_CN · @LanzhiAI · @NpieAI · @__jingling

同一个 bug 被报三遍怎么办？

GitHub、Discord、X 三路都在收反馈，缺一个去重/聚合层。建议按版本 + 平台 + 复现步骤归成一条记录，只交一路去修，另外两路补证据和通知，能少做不少重复活。

@FI8UZbducJ44839

提示词注入与恶意 issue

issue 里塞恶意脚本、有人滥用 X 和 GitHub 怎么办？作者的回应只有一句：「现在已经很难了。」

@mev15_eth · @0xTYZ · @ut93500882

「什么情况必须叫人」的规则

一位把投研系统也跑成 loop 的人说：最难的不是搭 loop，而是写清楚「什么情况必须叫人」。这条写不清，要么一天被叫很多次，要么出了事没人知道。

@lzuren2001

② 可以直接抄的作业

A便宜模型前置过滤

先让 agnes / Jev 这类低成本模型判断「这条推文/issue 值不值得处理」，再决定要不要交给大模型——最直接的降本增效。

B把铲屎沉淀成规则

每晚修完 UI/UX，顺手写进规则文件：「米色底、橙按钮、大圆角软阴影直接写死不许用」。写一条少铲一类。

C给屎山清理踩刹车

优化到一定阶段就停一段，不然 LLM 会「为优化而优化」搞事情；有人建议补一句「check 代码遵循 YAGNI 原则」。

D三端真机才是关键

没真机，Agent 只能对着截图猜；让它在真实环境里点一遍、改完再照点一遍，「点了没反应」这类反馈才具体。

③ 金句

「并行 3 个 loop 本身不难，难的是每晚那点铲屎——UI/UX、边界、该不该合入。」@shaoxiao_si

「loop 解决执行力，审美和判断还得人肉。每晚那点时间看着最不值钱，其实最贵。」@wxp22888

「能力靠 PR loop 把代码拉下来实际跑一遍——每次改动都有个能自动判对错的检查；剩下要人收拾的正好是 UI/UX，因为『好不好用』没有测试能替人判。」@benshanyoufeng

「以前比语法、比 CSS 熟练，现在拼架构嗅觉和需求拆解。AI 出码 10 倍，审查兜不住，堆屎山的速度也是 10 倍。」@ai2face

「被喷的从来不是工具，而是它把『写代码』环节的价格打穿了，动了别人的奶酪。」@ReignSwords

07

一句话

他的「魔法」= 3 条并行 /loop（盯社区+代码 / 盯推特 / 清屎山）＋ 三端真实环境复现＋ Claude Code 记忆与设计文档兜底决策，人只每晚修 UI/UX。谈不上魔法，真正的门槛在于敢让 Agent 直接改代码、review 并合并 PR、发版，以及搭得起那套环境——还有每月四位数的账单。

而评论区真正有价值的，不是「怎么抄这套 loop」，而是它暴露的三个缺口：并行 agent 的工作区隔离与权限边界、跨渠道 bug 的去重汇总、以及「什么情况必须叫人」的规则。谁先补齐这三点，谁就比这套工作流更完整。