社区机器人最有价值的回复，有时是暂时不回复。一个只有“启动失败”四个字的Issue，缺的是可复现上下文；一条涉及具体架构的疑问，可能值得维护者亲自判断。若机器人把所有入口都变成自动答题，维护成本只是从写回复变成了纠正误答。
Anthropic在10月16日发布的内部工作研究提到，人类注意力可能成为Agent输出的瓶颈。这是该公司内部观察，不是所有开源社区的效果统计，但它很适合拿来反问：自动化到底减少了多少待审内容，还是仅仅增加了评论数量？
从投递入口缩小工作范围
GitHub建议只订阅必要事件，并检查event type与action。处理issues.opened和处理issue_comment.created不是同一件事。签名验证应该发生在解析业务内容和排队之前，投递标识要进入幂等记录。
快速响应Webhook也不等于工作完成。可以在可靠入队后确认接收，再由后台处理；进程内随手启动一个goroutine，无法保证进程退出后的任务继续存在。
把分流结果设计成有限集合
这个例子只有IGNORE、ASK_CONTEXT、SUGGEST_DOC和HUMAN四种结果。机器人自己的事件被忽略；缺少环境信息时只请求补充；找到经过维护的文档映射才给建议。未匹配到证据的情况交给人。
图中HUMAN是正常出口，不能把它统计成系统故障。也不要把发出文档链接自动算作问题解决；解决状态需要用户确认或明确的后续结果。
先用规则把可验证的部分写好
保存为example.mjs并运行node example.mjs。这里的文档映射是教学夹具，问题文本只用于分流，未调用任何大模型，也不会发送GitHub评论。
import assert from 'node:assert/strict'; const docs = new Map([['install', 'docs/install.md']]); function triage(issue) { if (issue.authorType === 'Bot') return {kind:'IGNORE'}; if (!issue.environment || !issue.reproduction) return {kind:'ASK_CONTEXT'}; const evidence = docs.get(issue.topic); return evidence ? {kind:'SUGGEST_DOC', evidence} : {kind:'HUMAN'}; } const issue = {authorType:'User',environment:'demo',reproduction:'node app.mjs',topic:'install'}; assert.equal(triage({...issue,authorType:'Bot'}).kind, 'IGNORE'); assert.equal(triage({...issue,environment:''}).kind, 'ASK_CONTEXT'); assert.deepEqual(triage(issue), {kind:'SUGGEST_DOC',evidence:'docs/install.md'}); assert.equal(triage({...issue,topic:'race'}).kind, 'HUMAN'); console.log('issue routing: ok');本地运行输出：
issue routing: ok记录能帮助维护者追问的证据
每次判定保存issue编号、规则版本、使用的文档版本、决策和原因。日志默认不存整段Issue，避免把用户贴出的访问令牌扩散到观测系统。先看需要人工查看的队列有没有变短，再考虑扩大自动回复范围。
适用范围与未测部分
只验证规则分流。签名、可靠队列、真实仓库、模型回答正确率和GitHub写回均未在本例中集成测试。社区运营效果需要另行记录真实解决结果。
参考资料
- GitHub Webhook best practices
- How employment is changing at Anthropic（2026-10-16）
