看着仓库里堆起的 152 个 PR、128 个 issue，我一开始真怀疑：卧槽难道当前版本真有小三百个地方是坏的？结果今天耐着性子挨个点开看，直接给我气笑了。
有个哥们提了个 PR，说改进了 Agent 生图失败的诊断逻辑，代码有模有样，CI 也全绿。
我认认真真看完，让他补一条当时生图失败的记录，结果他回我：其实没有失败记录，希望能按“诊断补全”来评。
当场就被气笑了，直接关了。
我自己平时也是重度拥抱 AI 的，但真的受不了有些 PR 连作者自己发的是啥都没看懂，让 AI 几分钟跑出一坨代码就往仓库里丢。生图、布局、路由本来就是牵一发动全身的逻辑，别人随手一提，我去确认问题存不存在、来回跑项目对比验证，搭进去的就是实打实的几十分钟。
现在想通了，以前是我自己没经验，掉进了“老实人误区”——总觉得别人写了代码、测试绿了，我就得一视同仁花精力审完。
其实 150 多个 PR 根本不代表项目有 150 个问题，除了真正有价值的改进，里面混着不少没复现、没收益、明显是在刷贡献的 AI PR。
今天索性把 Archify 的维护和贡献规则彻底改了：先分流，不再试图清空 PR 队列。
每轮只挑 5–10 个真正影响生图质量和交付的问题细审，没价值的直接拒绝。凡是改行为的，一律先提 issue 讨论。除了改错别字这种纯机械修补，没说清楚真实问题和收益的代码，不再进逐行 review。
动生图链路、布局、路由的 PR，先拿最新 main 证明问题还在，再按影响范围跑 benchmark 补齐前后产物对比，谁提改动谁举证。参考 Ghostty、LLVM 和 Astral 加上 AI 贡献披露：用 AI 没问题，但必须写清楚问题来自真实使用还是人工构造，提交者得能解释改了什么、为什么改、验证过什么。
每次看到有人真拿 Archify 去理解代码、画方案、做汇报，我都觉得熬夜做这个项目特别值。
但说实话，我的业余精力真的有限，只想留给真正用它干活的人，实在不想再下班后陪着一堆连作者自己都不看的 AI 垃圾耗时间了。
不知道大家现在遇到这种 AI 刷的 PR 都是咋处理的，真有点顶不住了，有啥好办法没有？