一个月处理 1,500 个 GitHub Issue：用 Agent 清理积压的工程方法

2026-09-04 46 预计阅读时间: 1 分钟
来源: nextjs.org AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：8 分钟

Next.js 团队在一个月内关闭了 1,500 个 GitHub Issue。真正值得关注的并不是关闭按钮按了多少次，而是他们让 Agent 研究历史报告、整理证据，再推进积压问题。对于维护时间较长的开源项目，这类工作往往比编写新功能更消耗注意力。

公开摘要没有披露具体模型、提示词和自动化规则，因此下面不会猜测 Next.js 的内部实现，而是给出一套可以落地改造的同类工作流。

Agent 适合研究问题，不适合直接决定问题

旧 Issue 很少能仅凭标题判断。一个看似可以关闭的问题，可能已经被某次提交修复，也可能只是多年没有人继续反馈；两者需要的关闭说明完全不同。

Agent 在这里最有价值的任务包括：

  • 阅读 Issue 正文、评论和关联 Pull Request。
  • 提取版本、运行环境、复现步骤与错误信息。
  • 检索仓库中可能相关的提交、测试和发布记录。
  • 识别重复报告，并解释两者为何相似。
  • 生成建议结论和回复草稿，同时附上证据。

最终动作应与置信度绑定。高置信度的重复问题可以进入批量复核队列；无法复现、信息不足或可能涉及回归的问题，则应交给维护者判断。Agent 输出的核心不是一个 close 标签，而是一份可审查的研究记录。

把积压队列变成可验证的流水线

一个稳健的流程可以分成四步：筛选候选、收集上下文、生成建议、人工执行。每一步都保留结构化结果，便于抽样检查和回滚。

候选筛选应当使用可解释的条件，例如：一年以上没有更新、没有负责人、带有 needs-repro 标签。不要直接把“时间久”解释成“已经解决”，时间只能缩小调查范围。

Agent 的输出也应该固定格式：

issue: 12345
recommendation: needs_author_feedback
confidence: 0.82
reason: "报告缺少最小复现，且最后一次请求补充信息后 14 个月无回复"
evidence:
  - "评论 #4 请求提供复现仓库"
  - "当前支持版本中未找到相同堆栈的测试"
proposed_comment: "我们暂时无法验证该问题，请提供基于当前支持版本的最小复现。"
requires_human_review: true

这样的结果可以被程序校验，也让维护者迅速看出 Agent 的结论是否有依据。自由文本报告虽然容易生成，却很难批量审计。

可以这样实践：先生成候选清单，不自动关闭

下面的脚本假设已经安装 GitHub CLI，并通过 gh auth login 完成认证。修改 REPO、标签和日期后运行，它会读取候选 Issue，生成 JSON Lines 文件供后续 Agent 或人工审核使用，不会修改仓库状态。

#!/usr/bin/env bash
set -euo pipefail

REPO="your-org/your-repo"
LABEL="needs-repro"
BEFORE="2024-01-01"
OUTPUT="issue-candidates.jsonl"

: > "$OUTPUT"

gh issue list \
  --repo "$REPO" \
  --state open \
  --label "$LABEL" \
  --search "updated:<$BEFORE no:assignee" \
  --limit 200 \
  --json number,title,url,updatedAt,labels \
  --jq '.[]' > "$OUTPUT"

printf 'Wrote %s candidates to %s\n' "$(wc -l < "$OUTPUT" | tr -d ' ')" "$OUTPUT"

接下来可以把每个 Issue 的正文和评论交给 Agent，但提示词必须限制其权限，并要求引用证据：

你是 GitHub Issue 调研助手。请阅读给定 Issue、评论和关联提交。

你的任务：
1. 判断它是否可能已修复、重复、缺少信息或仍可复现。
2. 每个判断必须引用输入中存在的证据。
3. 不得因为长时间无活动就认定问题已解决。
4. 信息不足时输出 needs_human_review。
5. 只生成建议和回复草稿，不执行关闭、加标签或指派操作。

请输出符合约定 schema 的 YAML，不要添加 schema 之外的字段。

审核通过后，再由维护者逐个执行明确动作。例如，确认重复问题后可以使用：

gh issue close 12345 \
  --repo your-org/your-repo \
  --reason "not planned" \
  --comment "Closing as a duplicate of #12001. Please continue the discussion there."

不要让生成建议和执行关闭共享同一权限。研究任务只需要读取权限；执行程序应使用单独的凭据、较低的批次上限，并记录操作者、理由和时间。

衡量质量，而不只是关闭数量

“关闭了多少 Issue”容易统计，却不足以判断工作流是否健康。更有价值的指标包括建议采纳率、错误关闭率、重新打开率、人工审核耗时，以及不同类别的置信度校准情况。

上线时可以从每天 20 个候选开始，由维护者全量复核。积累一批结果后，再按类别逐步调整：重复问题可以提高自动化程度；安全问题、疑似回归和仍受支持版本中的缺陷必须继续人工处理。

采用前应确认以下边界：

  • Agent 只能根据可访问的仓库证据提出建议。
  • 每个关闭动作必须包含具体、对用户有帮助的说明。
  • 批量操作需要速率限制、审计日志和暂停开关。
  • 随机抽查已关闭问题，并跟踪重新打开的原因。
  • 不把“没有回复”与“问题不存在”混为一谈。

大规模清理 Issue 的关键并不是让 AI 替维护者作决定，而是让它承担检索、归纳和起草这些高耗时工作。维护者保留判断权，同时获得足够清晰的证据，积压队列才会真正缩小，而不是被数字暂时掩盖。

# AI # LLM # Next.js # React # 前端

相关推荐