copilot-pr-autopilot 实战：用 GraphQL 列出并分类 PR 全部未解决审查线程（Step 3）-北京尧图网络

copilot-pr-autopilot 实战用 GraphQL 列出并分类 PR 全部未解决审查线程Step 3【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本文以 awesome-copilot 仓库中的copilot-pr-autopilot技能为背景深入讲解其审查循环的第 3 步如何通过ghCLI 与 GitHub GraphQL API 一次性拉取某个 Pull Request 上所有审查者Copilot、人类、github-advanced-security及其他机器人留下的未解决线程并对每个线程的作者进行分类。读完本文你将掌握03-list-open-threads.ps1的输入输出契约、Path字段的解析规则、author_class的判定逻辑以及这些数据如何驱动后续的分诊triage、修复、回复与收敛判定。在自动审查循环中的位置copilot-pr-autopilot的完整循环是一条 1 → 9 步的闭环请求审查 → 等待审查 →列出线程→ 分诊 → 修复 → 构建测试 → 提交推送 → 回复/解决 → 收敛校验未收敛则回到第 1 步直至第 9 步返回Converged: true才执行一次性清理并结束。完整流程见 skills/copilot-pr-autopilot/SKILL.md循环编排见 skills/copilot-pr-autopilot/references/orchestration.md。第 3 步是循环的数据入口它把所有待处理事项从 GitHub 拉下来并标准化第 4 步的分诊triage完全依赖这份分类表。按编排约定本步由explore类型的子代理执行预算 5 分钟默认 5 分钟/次子代理调用见 orchestration.md 中的时间盒协议。输入与返回契约本步的输入只有一个必填项输入说明PrNumber目标 Pull Request 的编号输出是一张表格每个未解决线程一行列为{ thread_id, file, line, author, author_class, severity, summary }其中各字段含义字段含义thread_id线程在 GitHub 上的唯一 IDGraphQL 节点id第 8 步回复/解决时要用它file线程锚定的文件路径line线程锚定的行号文件级/PR 级评论没有行锚点author发起评论的作者login原始值可能带[bot]后缀author_class作者分类取值copilot或human-or-bot由原始author.login推导severity严重程度供分诊参考第 4 步会结合分诊规则做最终决策summary评论内容摘要这张表必须原样传给第 4 步 —— 分诊规则表完全依赖它来区分哪些线程由循环自己处置、哪些默认升级给用户。核心命令一行脚本拉取全部未解决线程运行本步的唯一入口是仓库中打包好的 PowerShell 脚本pwsh ./scripts/03-list-open-threads.ps1 -PrNumber n脚本路径为 skills/copilot-pr-autopilot/scripts/03-list-open-threads.ps1。该脚本返回所有审查者Copilot、人类、github-advanced-security、其他机器人的未解决线程而不是只返回 Copilot 的 —— 这正是本步的设计要点循环不仅要处理 Copilot 的评论还要能识别出哪些线程是人类/其他机器人的从而在分诊阶段默认将其升级给用户处理。脚本还支持几个可选参数参数默认值说明-Owner/-Repo从gh repo view自动解析指定仓库坐标两者必须同时传或不传只传一个会被拒绝-PrNumber必填PR 编号-MaxBodyLength500截断Body列到该字符数传0关闭超长正文会以…结尾输出格式脚本以单行压缩 JSON输出不是 PowerShell 的格式化表格便于直接管道给ConvertFrom-Json或jq{PrNumber:122,Owner:octo,Repo:demo,OpenThreadCount:3,Threads:[ {ThreadId:PRRT_xxx,Author:copilot-pull-request-reviewer[bot],Path:src/foo.js:42,CreatedAt:2026-09-11T12:00:00Z,Body:...summary...}, ... ]}Path 字段的解析规则文档明确要求的调用方约定脚本在输出线程时会把文件与行号合并成Path评论锚定在具体行时Path形如src/foo.js:42file:line没有行锚点文件级评论、PR 级评论时Path只有file不带:line后缀。调用方在解析时必须只做最后冒号切分整数校验仅在:后缀能被解析为整数时才拆出line否则把整个Path当作文件路径处理。这避免了把文件名中含:的情况如 Windows 路径或带行号风格的文件名误判为行号。作者字段的退化处理脚本对author字段做了兜底若评论的author缺失或login为空如已删除账号统一输出(deleted)保证下游解析不会因缺字段而崩溃。author_class 分类规则拿到每行线程后需要把原始author.login映射为两个类别之一原始author.loginauthor_classcopilot-pull-request-reviewercopilotcopilot-pull-request-reviewer[bot]copilot其他任何值人类、github-advanced-security、其他机器人human-or-bot文档强调一个关键陷阱[bot]后缀只出现在部分接口表面。GitHub GraphQL 在通过requestedReviewer.login引用时返回copilot-pull-request-reviewer而在通过 review 的author.login引用时可能返回copilot-pull-request-reviewer[bot]—— 二者是同一个参与者必须同时匹配两种形式。这个规则在仓库中是被集中定义的而非散落在各脚本里。scripts/_lib.ps1 用一条规范化正则实现了它Set-Variable -Name CopilotPrAutopilot_CopilotReviewerLoginRegex -Value (?i)^copilot-pull-request-reviewer(\[bot\])?$ -Option ReadOnly -Force -Scope Script(?i)忽略大小写(\[bot\])?让[bot]后缀成为可选从而一次匹配两种表面。集中定义的意义在于第 1 步触发、第 2 步状态快照和第 10 步清理的脚本都依赖这条正则来识别 Copilot 审查者如果登录名将来发生变化只需改这一处。为了兼容早期调用方_lib.ps1还保留了不带前缀的别名$CopilotReviewerLoginRegex。分类完成后的表格交给第 4 步分诊规则按author_class决定处置权详见 skills/copilot-pr-autopilot/references/04-triage.mdcopilot线程 → 循环自主处置按 ROI vs Risk 规则决定 fix / decline / escalatehuman-or-bot人类审查者、github-advanced-security等→默认escalate-to-user除非用户明确把这些线程纳入循环范围。本步只负责标记真正的策略由分诊应用。源码级实现GraphQL 查询与分页03-list-open-threads.ps1的实现可以从几个角度拆解。查询结构脚本使用一条 GraphQL 查询按 100 条一批分页遍历reviewThreadsquery($owner: String!, $repo: String!, $pr: Int!, $after: String) { repository(owner: $owner, name: $repo) { pullRequest(number: $pr) { reviewThreads(first: 100, after: $after) { pageInfo { endCursor hasNextPage } nodes { id isResolved comments(first: 1) { nodes { author { login } body path line createdAt } } } } } } }几个关键设计点comments(first: 1)只取每个线程的发起评论。path、line、body、author都来自这条发起评论同一线程的回复链故意不在此处展开—— 脚本的定位是分诊的输入不是对话历史阅读器。isResolved过滤do...while循环先把所有页拉完pageInfo.hasNextPage驱动endCursor翻页再在内存里用Where-Object { -not $_.isResolved }过滤出未解决线程即未解决状态是唯一的事实来源。畸形线程跳过而非崩溃若某个线程没有发起评论comments.nodes.Count -eq 0脚本continue跳过而不是抛异常保证单个坏数据不影响整批结果。数据规范化输出前脚本做了三层清洗正文换行折叠body中的 CR/LF 被替换为空格避免多行评论破坏 JSON/表格结构正文截断超过MaxBodyLength默认 500 字符的部分用…截断 —— 长 Copilot 评论会占据 stdout 并拖慢分诊时间戳统一createdAt通过_lib.ps1的Format-IsoUtcString规范化为 ISO-8601 UTC 字符串yyyy-MM-ddTHH:mm:ssZ。这是因为ConvertFrom-Json会把 ISO 时间自动反序列化成[datetime]其默认.ToString()依赖区域设置、不可往返统一格式化后 01/02/03 各步骤输出的时间契约完全一致。底层基础设施_lib.ps1的共享函数脚本在开头执行. $PSScriptRoot/_lib.ps1dot-source这会立刻触发Assert-GhReady前置检查若gh不存在或gh auth status失败脚本在做任何工作之前就以一条可操作的错误信息终止提示安装命令和gh auth login调用方应将这条消息原样转达给用户并停止循环不要重试或绕过。此外还依赖两个关键 helperInvoke-GhGraphQL包装gh api graphql同时检查进程退出码和响应体里的errors数组把 GraphQL 错误含type、path、extensions.code聚合成可读信息避免出现裸的Unexpected character encounteredResolve-RepoCoords未显式传-Owner/-Repo时用gh repo view自动解析本地仓库坐标。跨版本 PowerShell 兼容性_lib.ps1专门处理了一个 Windows PowerShell 5.1 的原生命令参数传递 bug含内嵌双引号的参数在 5.1 下会被错误拆分。因此Invoke-Gh会把含的-f/-F参数重写为-F fieldtempfile内容先写入临时文件gh从文件读取同时用-F而非-f因为gh的-f不会展开前缀。整个脚本族在 PowerShell 5.1 与 7 下行为一致SKILL.md 声明两种运行时均已测试。下游消费这张表如何驱动整个循环第 3 步的产出在第 4 步、第 5 步、第 8 步被依次消费第 4 步分诊按{ thread_id, action, rationale }返回决策action ∈ fix | decline | escalate-to-user。规则优先级审查者类型策略 → ROI vs Risk → fix/decline 规则清单 → 项目特定策略钩子 → 冲突评论解决防振荡→ 升级规则。其中振荡硬停不可协商如果代理准备重做自己在之前某轮已经回退的编辑必须立即升级给用户见 04-triage.md。第 5 步修复只消费fix行派发并行修复子代理最多 5 个并行、每个 5 分钟。第 8 步回复/解决消费完整表。fix/decline行回复并解决escalate-to-user行回复但加-NoResolve保持线程打开08-reply-resolve.md这是给人类合并负责人留的显式交接因此第 9 步的收敛可以在OpenThreadCount 0时依然成功。Gotchas三类必须记住的坑文档在 Gotchas 中强调三个易错点[bot]后缀出现在部分接口表面—— 匹配copilot-pull-request-reviewer和copilot-pull-request-reviewer[bot]两种形式二者是同一个参与者。仓库中用_lib.ps1里的正则一次性解决但手工核对日志/输出时仍要注意。人类 / advanced-security 线程默认escalate-to-user—— 本步的分类只是标记第 4 步才应用策略。自动回复或自动解决人类审查线程会掩盖未处理的问题这在社交层面是错误的。未解决状态是唯一事实来源—— 已过时但未解决的线程依然会出现这是正确行为不要过滤掉它们它们和其他未解决线程一样在第 8 步被正常回复与解决第 10 步的10-cleanup-outdated.ps1只是最终兜底不是主机制。实际运行注意事项运行前提是ghCLI 已安装并完成认证gh auth login脚本会在 dot-source_lib.ps1时自动校验需要Triage/Write权限才能触发 Copilot 审查但列出线程不需要—— 任何能读取 PR 的认证用户都可以运行本步。若循环处于单次迭代模式Copilot Code Review 未在仓库/账号启用01-request-review.ps1触发失败后的降级路径本步依然照常运行它列出的是已存在的全部审查线程人类、advanced-security 等随后按步骤 3→8 跑一遍收敛布尔在单次迭代下坍缩为OpenThreadsAwaitingReply 0。详见 orchestration.md 的单次迭代回退。遇到 API 行为异常时先查阅 skills/copilot-pr-autopilot/references/api-quirks.md —— 其中记录了已验证的requestReviewsByLogin触发路径、latestReviews陈旧缓存陷阱应改用reviews(last:100)、以及三个 GraphQL 易错点requestReviewsByLoginvsrequestReviews、botLoginsvsuserLogins、App slugcopilot-pull-request-reviewervs 显示登录名Copilot。小结第 3 步是 copilot-pr-autopilot 循环的眼睛用一条分页 GraphQL 查询把 PR 上所有审查者的未解决线程拉到本地规范化为单行 JSON附上author_class分类再交给分诊步骤决定每个线程的命运。它的核心工程决策 —— 未解决状态即事实来源、只取发起评论、路径行号只在可解析为整数时切分、Copilot 登录名双形式匹配、前置gh就绪检查、PS 5.1/7 双运行时兼容 —— 保证了循环可以在任意启用了 Copilot Code Review 的仓库上稳定、可审计地运转。想继续深入可以从 scripts/03-list-open-threads.ps1 的源码、scripts/_lib.ps1 的共享基础设施以及 references/04-triage.md 的分诊规则表开始读起。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

copilot-pr-autopilot 实战：用 GraphQL 列出并分类 PR 全部未解决审查线程（Step 3）

相关推荐

SerenityOS 移植 mednafen 实战：两个关键补丁背后的兼容性改造

`0001-Don-t-build-misc-stuff.patch`

MicroG 华为 HarmonyOS 适配完整指南：绕过签名伪造失败

更多资讯

Label Studio 标注一致性（Agreement）计算完整指南：Consensus 与 Pairwise 方法论、指标与权重配置

Task Master Auto-Implement：Claude Code 插件中的智能任务自动实现工作流

Actual 怎么套用官方自定义规则示例处理收款人与转账自动化

如何用 MSAL 在 Refine 中接入 Azure AD B2C 登录？

Beads 的 MCP Server 集成指南：在无 Shell 环境中让 Coding Agent 使用 bd 管理任务

量化交易数据源怎么选？四个常用工具一张表对比

今日更新

SpacetimeDB C++ 模块库实战：用 C++20 在数据库内构建 WebAssembly 模块

别踩雷！不是所有 AI 写作工具都靠谱，2026 高校认可工具精选

SSM+MySQL幼儿园管理系统源码解析：从部署到优化

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？