用 Agent 维护开源项目：把 issue 分诊和 PR 初筛交出去

开源项目最常见的死法不是"代码写不出来"，而是维护者被淹没在 issue 和 PR 里，最后心力交瘁归档仓库。一个残酷的现实是：维护工作的 80% 是重复性判断——这是重复提问吗？能复现吗？PR 有没有测试？改动范围合理吗？这类"读得多、模式固定"的工作，恰恰是 Agent 最擅长的。

issue 分诊流水线

给仓库配一个分诊 Agent（GitHub Action 定时跑，或有人提 issue 时触发），它的工作流分四步：

第一步：去重与关联。读新 issue 的标题和正文，在已有 issue 里搜相似项。找到疑似重复就评论关联并打上 duplicate 标签——这一步能砍掉 30% 的噪音，很多"新 bug"都是老问题的不同表述。

第二步：信息完整性检查。对照你的 issue 模板看缺什么：没贴版本号、没给复现步骤、没贴报错日志，就自动回复索取信息并打上 needs-info。维护者最烦的就是来回追问环境信息，让 Agent 当这个"恶人"。

第三步：严重程度初判。根据关键词和影响面打标签：crash/数据丢失标 critical，文档笔误标 good-first-issue。注意这一步只做"建议标签"，最终确认权留给人——Agent 的误判成本在这里很低，因为标签改起来容易。

第四步：生成摘要日报。每天/每周把新增 issue 按"需人工介入/可延后/已自动处理"分类，推送给你。你看到的不再是 50 个 issue 的列表，而是 5 个真正需要你的。

PR 初筛：让 Agent 当第一 reviewer

PR 的初筛可以更激进一点，因为"要求改"是低风险操作。配置一个 PR bot 做这几件事：检查 CI 是否全绿、改动是否带测试（没测试就评论要求补充）、diff 是否超出合理范围（一个"修 typo"的 PR 改了 40 个文件就标出来）、commit 信息是否符合规范。

通过初筛的 PR，Agent 再生成一份"给维护者的摘要"：改了什么、为什么改、风险点在哪、测试覆盖了什么。你点开 PR 先看这份摘要，3 分钟就能决定合并不合并，而不是花 20 分钟自己读 diff。

一条铁律：Agent 永远不能点 merge。它可以把一切准备好，但合并按钮必须由人来点。这不是不信任 AI，而是保留"这个改动我看过"的责任链——出了问题，你知道该找谁。

从"救火"到"每周 2 小时"

这套流水线搭起来的实际效果是：维护工作从"每天被 @ 惊醒的救火模式"，变成"每周固定 2 小时的批处理模式"。周一看分诊日报，处理 5 个真问题，扫一眼 Agent 的 PR 摘要批量合并，完事。剩下的时间你可以写代码、写文档，或者干脆不干——开源维护本来就应该是可持续的，而不是用爱发电到 burnout。

最后说句实在的：如果你正在维护一个有点 star 但快维护不动的项目，别急着归档。先花一个周末搭这套分诊，很多"已死"项目缺的不是人气，是维护者不被琐事淹没的工作流。