GitHub 如何用 AI 重构反馈处理机制

GitHub 引入了一种自动化、持续的、由 AI 驱动的工作流，将无障碍反馈转化为跨产品团队跟踪和优先级排序的工程工作。该系统基于 GitHub Actions、GitHub Copilot 和 GitHub Models APIs 构建，集中管理用户报告，分析其严重性及其与 Web 内容无障碍指南的合规性，并在各服务之间协调问题分流和解决。

从历史上看，无障碍报告此前来源于多个渠道，包括支持工单、社交媒体和讨论论坛，而且在负责导航、认证和共享组件的团队之间通常缺乏明确的归属。GitHub 通过集中入口并引入标准化的问题模板来解决这一问题，这些模板捕获结构化元数据，包括来源、受影响的组件以及用户报告的障碍。提交问题会触发一个自动化工作流，启动基于 AI 的分析并更新一个集中式项目看板。

GitHub 无障碍高级项目经理 Carie Fisher 强调了在大型工程组织中管理碎片化和高容量输入的挑战，并表示：

无障碍反馈是黄金，但在规模化情况下，它很快会变得令人难以应对。

该工作流始于接收和分类。来自公共讨论板、工单或直接提交的反馈会在几天内得到确认，并被汇入单一的跟踪管道。一个自定义的无障碍问题模板嵌入了元数据，包括来源、组件上下文和用户报告的障碍。创建问题会触发一个 GitHub Action，从而启动 AI 分析并更新集中看板上的项目状态。

Agentic 接收工作流

一旦检测到跟踪问题，另一个 Action 会调用 GitHub Copilot，并结合存储的提示词对 WCAG 违规、严重性以及受影响的用户群体（屏幕阅读器用户、键盘用户、低视力用户）进行分类。这些提示词引用了以 Markdown 维护并通过代码更新的内部无障碍策略和组件库文档。Copilot 会自动填充约百分之八十的结构化元数据，包括推荐的团队分配和基础无障碍测试的检查清单，并发布一条总结其分析的评论。第二个 Action 会解析该评论，以应用标签、状态更新和分配。我们的提示词承担两个角色：分流分析，即按 WCAG 违规、严重性和受影响用户群体对问题进行分类；以及无障碍指导，在此过程中 GitHub Copilot 作为领域专家，帮助团队编写和审查无障碍代码。

分析与更新循环

人工审查仍然是核心。在 Copilot 的初步分析之后，无障碍团队会在一个首响应看板上验证严重性等级和类别标签。若存在差异，将进行修正，并记录修正以优化提示词文件并改进未来的 AI 输出。在验证之后，将确定解决路径：即时更新文档、直接修复代码，或分配给相应的服务团队。来自内部合规系统的关联审计问题进一步提供了现实世界影响的上下文，并有助于在理论上的关键性之外优先处理真实风险。

在一篇相关的 LinkedIn 帖子中，客户参与专家 Lianne G. 指出该工作流的影响，并表示：

借助新的 AI 驱动工作流，我们在 90 天内解决的反馈量提高了 4 倍。

GitHub 报告称，在采用该系统之后出现了可量化的变化。在 90 天内解决的无障碍问题比例从 21% 提升至 89%，而总体解决时间同比下降了超过 60%。该工作流还提供了对重复出现的无障碍模式的可见性，并包含用于优化 AI 提示词和评估标准的反馈循环。

这种方法反映了持续型 AI 系统如何被应用于运营工作流，将自动化分析与人工审查相结合，以在大型工程组织中处理诸如无障碍等跨领域问题。

原文链接：

https://www.infoq.com/news/2026/04/github-ai-accessibility-workflow/