可访问性：GitHub 如何通过持续 AI 将反馈转化为包容性

title: "可访问性：GitHub 如何通过持续 AI 将反馈转化为包容性" slug: "continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion" date: "2026-03-14" lang: "zh" source: "https://github.blog/ai-and-ml/github-copilot/continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion/" category: "开发者工具" keywords:

• 持续 AI
• 可访问性
• GitHub
• Copilot
• 反馈工作流程
• 包容性
• 开发者工具
• GitHub Actions
• WCAG
• AI 可访问性
• 软件开发
• AI 自动化 meta_description: "GitHub 通过持续 AI 和 GitHub Copilot 彻底改变了可访问性，将用户反馈转化为可操作的问题。了解这种创新工作流程如何促进软件开发中的包容性。" image: "/images/articles/continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion.png" image_alt: "说明 GitHub 持续 AI 可访问性反馈工作流程的流程图。" quality_score: 94 content_score: 93 seo_score: 95 companies:
• GitHub schema_type: "NewsArticle" reading_time: 7 faq:
• question: "在实施其持续 AI 系统之前，GitHub 在可访问性反馈方面面临哪些挑战？" answer: "在新系统实施之前，GitHub 在可访问性反馈方面面临着分散且不一致的问题。问题往往散落在不同的积压项中，缺乏明确的负责人，改进也常常被推迟。这种无序导致了后续行动的不足，让用户的问题得不到解决，并阻碍了真正包容性软件的开发。可访问性问题的跨领域特性，涉及到多个团队，加剧了这些协调挑战，使得难以建立单一的责任点或连贯的解决方案工作流程。"
• question: "'持续 AI 可访问性' 如何定义，以及它如何增强传统的无障碍工作？" answer: "持续 AI 可访问性是一种动态方法，它将自动化、人工智能和人类专业知识整合到软件开发生命周期中。与静态审计或一次性修复不同，它是一个活生生的系统，旨在持续处理和响应用户反馈。它超越了简单的代码扫描器，通过积极倾听真实用户的心声，并利用 AI，特别是 GitHub Copilot 和 GitHub Actions，来澄清、组织和优先处理这些反馈。这确保了包容性被融入到开发的每个环节中，将分散的报告转化为可实施的解决方案，并促进持续改进。"
• question: "GitHub Copilot 如何具体促进可访问性反馈工作流程的效率和有效性？" answer: "GitHub Copilot 通过对可访问性报告进行智能分类和分析，发挥着关键作用。在创建问题时，Copilot 在可访问性主题专家提供的自定义指令指导下，以编程方式分析报告。它自动填充问题约 80% 的元数据，包括 WCAG 违规分类、严重性级别、受影响的用户群体以及建议的团队分配。这种自动化分析显著减少了人工工作量，标准化了问题分类，并提供了即时、可操作的洞察，使人工团队能够专注于解决问题，而不是重复的数据录入和初步评估。"
• question: "GitHub 为 Copilot 设置的“自定义指令”是什么，以及为什么选择它们而不是对模型进行微调？" answer: "GitHub 利用由其可访问性主题专家开发的 Copilot '自定义指令'，来指导其进行分类分析和可访问性辅导。这些指令是存储的提示，指向 GitHub 的可访问性政策、组件库和内部文档，详细说明了如何解释和应用 WCAG 成功标准。选择这种方法而非模型微调，是因为它允许快速迭代和全团队更新。任何团队成员都可以通过拉取请求修改 Markdown 和指令文件来更新 AI 的行为，无需复杂的再训练流程或专业的机器学习知识，确保 AI 的行为能随着标准的演进而发展。"
• question: "尽管广泛使用了 AI 自动化，GitHub 如何确保人类判断和监督在可访问性流程中仍处于核心地位？" answer: "GitHub 有意设计其系统，使 AI 自动化重复性任务，而人类则保留关键的判断和监督。例如，在 GitHub Copilot 的初步分析之后，一个 '提交者审查' 步骤确保人类验证 Copilot 的发现。如果 Copilot 的分析不准确，人类可以对其进行标记，为 AI 的持续改进提供直接反馈。此外，工作流程中的每个 GitHub Action 都可以手动触发或重新运行，确保人类可以在任何时候进行干预。目标是将繁琐的工作交给 AI，赋能人类专注于复杂的解决问题、协作以及对软件修复做出明智决策。"
• question: "GitHub 增强型可访问性反馈系统的主要受益者是谁，以及它如何满足他们的特定需求？" answer: "该系统服务于三个主要群体。问题提交者（社区经理、支持代理、销售代表）受益于一个指导系统，该系统标准化了反馈收集并向他们普及了可访问性概念。可访问性和服务团队（工程师、设计师）获得了结构化、可操作的数据，包括可重现的步骤、WCAG 映射和明确的所有权，从而简化了他们的修复工作。项目和产品经理可以了解痛点、趋势和进展，从而进行战略性资源分配。最终，最大的受益者是残障用户和客户，他们的反馈现在得到了持续的跟踪、优先处理和行动，从而带来了更具包容性的 GitHub 体验。"
• question: "GitHub 如何将来自外部来源的用户反馈整合到其内部可访问性流程中，以确保一致性和可操作性？" answer: "GitHub 承认可访问性反馈可能来自各种外部来源，包括支持工单、社交媒体、电子邮件和直接接触，其中 GitHub 可访问性讨论区是一个主要渠道。无论来源如何，所有反馈都会在五个工作日内得到确认。当外部反馈需要采取行动时，团队成员会使用自定义的可访问性反馈模板手动创建一个内部跟踪问题。此模板标准化了收集到的信息，防止数据丢失。这个新问题随后会触发一个自动化的 GitHub Action，由 GitHub Copilot 进行分析，并将其添加到集中式项目板中，从而确保无论来源如何，都能进行一致的处理和行动。"

彻底变革可访问性：GitHub 的持续 AI 方法

多年来，GitHub 面临着一个常见但关键的挑战：如何有效地管理可访问性反馈。与典型的产品问题不同，可访问性问题无处不在，通常会跨越多个团队和系统。屏幕阅读器用户的一份报告可能涉及导航、身份验证和设置，这使得传统的孤立反馈流程效率低下。这导致报告散乱、漏洞未解决，以及用户对问题停留在很少实现的虚构“第二阶段”感到沮丧。

认识到需要进行根本性转变，GitHub 着手集中反馈、创建标准化模板并清理大量积压工作。只有在建立了这个坚实的基础之后，才出现了这样的问题：AI 如何进一步改变这个过程？答案在于一个创新的内部工作流程，该流程由 GitHub Actions、GitHub Copilot 和 GitHub Models 提供支持，旨在持续将每一条用户反馈转化为可跟踪、可优先排序和可操作的问题。这种方法确保 AI 增强了人类的判断力，简化了重复性任务，并允许专家专注于提供包容性软件。

持续 AI：包容性的活系统

GitHub 的“持续 AI 可访问性”不仅仅是一个工具；它是一种活生生的方法论，将自动化、人工智能和人类专业知识相结合，将包容性直接嵌入到软件开发的结构中。这一理念是 GitHub 对 2025 年全球可访问性意识日 (GAAD) 承诺的基础，旨在通过有效路由和转化用户反馈为有意义的平台改进，加强整个开源生态系统的可访问性。

核心认识是，最具影响力的突破源于倾听真实用户的声音，然而大规模倾听带来了巨大的挑战。为了克服这一点，GitHub 构建了一个反馈工作流程，它作为一个动态引擎运行，而不是一个静态的票务系统。GitHub 利用自己的产品，澄清、组织和跟踪用户及客户反馈，将其转化为可实施的解决方案。

在深入研究技术解决方案之前，GitHub 采用了以人为本的设计方法，确定了系统需要服务的主要用户画像：

• 问题提交者： 社区经理、支持代理和销售代表，即使没有深厚的可访问性专业知识，也需要指导以有效报告问题。
• 可访问性和服务团队： 工程师和设计师，需要结构化、可操作的数据——例如可重现的步骤、WCAG 映射和严重性评分——以高效解决问题。
• 项目和产品经理： 领导层需要清晰地了解痛点、趋势和进展，以便做出战略性资源分配决策。

这种基础性的理解使得 GitHub 能够设计一个系统，将反馈视为流经明确定义管道的数据，并能够随着他们的需求而发展。

自动化可访问性反馈管道

GitHub 围绕事件驱动模式构建了其新架构，其中每个步骤都会触发一个 GitHub Action 来协调后续操作，确保无论反馈来源如何，都能进行一致的处理。虽然最初在 2024 年中期是手动构建的，但现在可以使用 Agentic Workflows 等工具显著加快此类系统的开发，这些工具允许通过自然语言创建 GitHub Actions。

工作流程响应关键事件：问题创建通过 GitHub Models API 启动 GitHub Copilot 分析，状态更改触发团队交接，问题解决则提示与原始提交者进行跟进。自动化涵盖了常见路径，但人类可以手动触发或重新运行任何 Action，从而保持监督和灵活性。

七步反馈工作流程：

1. 接收： 反馈来自各种来源，例如 GitHub 可访问性讨论区（占报告的 90%）、支持工单、社交媒体和电子邮件。所有反馈都会在五个工作日内得到确认。对于可操作项，团队成员使用自定义的可访问性反馈模板手动创建一个跟踪问题，该模板捕获了基本上下文。此创建事件会触发一个 GitHub Action，以调用 GitHub Copilot 并将问题添加到集中式项目板。

2. Copilot 分析： 一个 GitHub Action 调用 GitHub Models API 来分析新创建的问题。

3. 提交者审查： 最初的提交者审查 Copilot 的分析，确认其准确性或进行调整。

4. 可访问性团队审查： 专业的无障碍团队进行更深入的审查并制定解决方案。

5. 链接审计： 链接相关的审计或外部资源，以提供上下文和合规性信息。

6. 闭环： 一旦问题得到解决，该问题将被正式关闭，并通知原始用户或客户。

7. 改进： 对系统性能的反馈，包括 Copilot 的分析，为持续更新和改进提供依据。

这种持续的流程确保了反馈生命周期每个阶段的可见性、结构性和可操作性。

GitHub Copilot 的智能可访问性分类

这个自动化系统的核心是 GitHub Copilot 的智能分析。当一个跟踪问题被创建时，一个 GitHub Action 工作流程会以编程方式调用 GitHub Models API 来分析报告。GitHub 做出了战略性选择，使用存储的提示（自定义指令）而不是模型微调。这允许任何团队成员通过简单的拉取请求更新 AI 的行为，消除了对复杂再训练流程或专业机器学习知识的需求。当可访问性标准发生变化时，团队会更新 Markdown 和指令文件，AI 的行为也会在下次运行时随之适应。

GitHub Copilot 配置有其可访问性主题专家开发的自定义指令。这些指令服务于两个关键角色：

• 分类分析： 根据 WCAG 违规、严重性（sev1-sev4）和受影响的用户群体对问题进行分类。
• 可访问性辅导： 指导团队编写和审查可访问的代码。

指令文件引用了 GitHub 的可访问性政策、组件库和内部文档，为 Copilot 提供了如何解释和应用 WCAG 成功标准的全面理解。

自动化分为两个关键步骤：

1. 第一个 Action： 在问题创建时，Copilot 分析报告，自动填充问题约 80% 的元数据。这包括超过 40 个数据点，例如问题类型、用户细分、原始来源、受影响的组件以及用户体验摘要。然后，Copilot 在问题上发布评论，其中包含问题摘要、建议的 WCAG 标准、严重性级别、受影响的用户群体、建议的团队分配以及一个验证清单。
2. 第二个 Action： 随后的这个 Action 解析 Copilot 的评论，根据指定的严重性应用标签，更新项目板上的问题状态，并将其分配给提交者进行审查。

至关重要的是，如果 Copilot 的分析不准确，任何人都可以通过提出描述差异的问题来标记它，这直接反馈到 GitHub 对 AI 的持续改进过程中。

人类监督和迭代可访问性增强

工作流程强调人类监督和协作。在 Copilot 自动化分析之后，“提交者审查”阶段（第 3 步）允许人工提交者验证 AI 的发现。这种人机协作方法确保了准确性，并允许手动更正或标记，以促进 Copilot 的持续改进过程。随后的步骤——可访问性团队审查、链接审计和闭环——进一步整合了人类专业知识，确保复杂问题由专家解决，并且用户获得及时、有效的解决方案。

这个动态系统标志着 GitHub 的一个重大转变。通过利用 AI 处理反馈管理中重复且数据密集的部分，他们将一个混乱、常常停滞的流程转变为一个持续、主动的包容性引擎。这意味着每一条可访问性反馈现在都得到了可靠的跟踪、优先排序和处理，超越了“第二阶段”的承诺，为所有用户提供了即时、切实的改进。最终目标不是取代人类判断，而是赋能人类判断，释放宝贵的时间和专业知识，专注于战略性修复并培养真正可访问的软件体验。