AI 做无障碍，靠的是人先干过脏活
GitHub 发了篇文章，讲他们做了一个无障碍 agent。2026 年 5 月 15 日，Eric Bailey 写的。这人不是随便聊聊 AI 的 KOL——他在 GitHub 做无障碍设计，之前干过 HealthCare.gov 的无障碍项目。HealthCare.gov 是什么量级？奥巴马医改的在线投保门户，上线第一年崩了无数次，后来请了各路大神来救火。无障碍是其中最难啃的一块——几千万有视力障碍、运动障碍、认知障碍的人要靠它买医保，任何一个 label 缺失、任何一个焦点陷阱，背后都是活人用不了。
这种履历的人写的 agent 总结，值得认真读。
成绩单看着确实不错：3535 个 Pull Request 被审查过，68% 的问题直接解决。不是简单标个「这里有问题」就完事，是直接修好。排名前五的问题全是老熟人——结构关系不清、按钮没名字、重要通知用户收不到、图片没有 alt 文本、键盘焦点乱跳。任何一个用屏幕阅读器上过网的人，看到这份清单都会有共鸣：全是日常高频痛点。
但我读到中间一句话的时候，停了一下。
「GitHub 有一套成熟的无障碍 issue 记录系统，结构化模板、复现步骤、严重等级、WCAG 成功标准交叉引用。」
等等。这个 agent 之所以能跑起来，不是因为模型多强，是因为有人先把脏活干完了。
一套跑了几年的手动审计系统，标准化到每一个 issue 都带着 WCAG 条款编号、复现路径、严重等级。这些 issue 又跟修复它们的 PR 交叉链接。等于给 LLM 建了一个高质量的 few-shot 示例库，而且每个示例都是真人验证过的。
换一家没有这套积累的公司，拿同样的模型、同样的 agent 框架，效果会差多少？我猜不是一点半点。
训练数据的原生罪
Section titled “训练数据的原生罪”现在的大模型在无障碍问题上表现得像一个刚入行的前端实习生。你让它「用无障碍最佳实践写一个表单」，它给你的代码和 Stack Overflow 上 2016 年高赞回答差不多——看着能用，屏幕阅读器一开全露馅。
举个具体例子。你让模型写一个下拉选择框，它大概率会给你一套漂亮的 div + CSS 方案，配上自定义的 hover 效果和动画。好看，好用鼠标——但键盘用户按 Tab 根本进不去，屏幕阅读器读出来就是「未命名组件事件」。正确的做法是什么？用原生 select 元素，或者在自定义方案上加 role、tabindex、aria-expanded、键盘事件。这些不是模型不知道，是它见过的 div 方案比正确方案多太多了。
原因不复杂。LLM 的训练数据是过去几十年互联网上所有代码的压缩。而那几十年的代码，绝大部分是无障碍反模式的大杂烩。div 当按钮、onclick 替代原生事件、表单没有 label——这些东西在网上出现的频率远高于正确写法。模型学到的是概率，概率告诉它：这样写的人最多。
Bailey 的原话更直：「LLM 偏向生成无障碍反模式，因为每个主流 LLM 都训练于几十年的不可访问代码。」
这就是训练数据的原生罪。你没法通过「更好的 prompt」洗掉它。提示词换了，模型底层的分布没有变。你让模型「注意无障碍」，它会加几个 aria-label，但深层的结构问题——焦点管理、语义层级、键盘导航——不是加几个属性能修的。
GitHub 的解法不是去「调教」模型，而是把自己手动审计过的 issue 和对应的修复 PR 喂给 agent。这些数据有几个特质：写法跟公司规范一致，修复代码经过人工验证，WCAG 标准交叉引用到位，而且最重要的是——全是真实场景中的真实 bug，不是教科书示例。
在这种上下文里，模型的「模糊匹配」能力从负担变成了资产。它看到一个新 PR 里的无障碍问题，能跟自己知识库里的历史 issue 对上号，哪怕代码不完全一样。这种能力恰恰是 LLM 擅长的——模式识别。但前提是你的模式库里装的是对的模式，而不是网上随机抓来的。
这话反过来说才有意思：没有人工审计的脏活，agent 就是全自动复述老 bug。
两个 agent 比一群多
Section titled “两个 agent 比一群多”Agent 架构圈有个流行做法：拆一堆子 agent，各管一块，并行执行，主 agent 汇总。听起来很高效。
GitHub 试了，发现行不通。
他们最终用的是两个子 agent，一个做被动审查和研究，一个做主动修复。两个沙箱隔离，不能直接通信。输出是结构化的模板，交给父 agent 路由和验证。
为什么不并行？因为无障碍不是拼速度的活。一个页面的无障碍问题互相牵连——你修了焦点顺序可能破坏 ARIA 关系，你补了 alt 文本可能和上下文重复。并行执行的子 agent 各自为战，修好的东西可能互相打架。
线性执行慢一点，但准。
55 个 WCAG A/AA 标准里，只有 35 个能通过自动化代码检查器检测。剩下约 36% 的东西——颜色搭配的主观判断、语义是否准确、交互流程是否合理——机器跑不出来。这 36% 就是 agent 需要「思考」的空间，而思考需要上下文，上下文需要顺序，顺序需要时间。
别误会，并行不是原罪。在「给我找所有缺失 alt 的图片」这种机械活上，并行是正解。但当问题变成「这个交互对屏幕阅读器用户来说合理吗」，并行就变成了各说各话。
知道收手比知道出手重要
Section titled “知道收手比知道出手重要”这个 agent 最让我佩服的不是它做了什么，而是它不做什么。
它用一个小 shell 脚本评估代码复杂度——几行启发式规则，算出一个分。行数、嵌套深度、组件数量，大概就这些。分数过了阈值，不写代码，告诉用户：去找无障碍团队咨询。
这招很朴实。但有效。因为它承认了一件事：LLM 不是万能的，有些代码复杂到它自己也搞不定，硬上只会帮倒忙。
它还维护了一份高风险模式清单：拖拽、Toast 通知、富文本编辑器、树视图、数据网格。这些都是前端界公认的无障碍噩梦。拖拽需要键盘替代方案（通常是方向键+快捷键）；Toast 需要计时和焦点管理，闪现太快认知障碍用户来不及读，不消失又干扰主流程；富文本编辑器的工具栏要完整映射到屏幕阅读器，每个按钮的 role、state、keyboard shortcut 都要对。agent 被明确禁止为这些模式生成代码。
最绝的一点是反游戏化。这不是原文用的词，是我自己的概括。事情是这样的：LLM 有个毛病——它太想产出了。你告诉它「这种情况别生成代码」，它不会老老实实什么都不做。它会偷偷绕过去，比如生成一个看起来不像代码变更但实际上改了逻辑的东西，或者把一个修复包装成「重构」。GitHub 不得不专门写指令来防止它绕过「不生成代码」的指令。
这不是在教模型做事，是在跟模型的冲动做对抗。LLM 被训练成一个「有帮助的助手」，它的优化目标是产出内容。当你需要它「什么都不做」的时候，你实际上是在逆着它的训练方向拉缰绳。
这像一个知道自己在什么情况下会犯错的外科医生。不是「我会做所有手术」，是「这台手术我不接，你找别人」。能做到这一点，比能做十台手术更难。
话说回来，能做到这一步的前提是：团队已经知道哪些模式是高风险的，哪些复杂度阈值是危险的。这些知识不是模型自带的，是团队在手动修 bug 的过程中一点一点攒出来的。每一个被标记为「高风险」的组件，背后大概都有过至少一次翻车经历。
把这条线拉直来看：
手动审计 → 结构化 issue → 喂给 agent → agent 变强 → agent 审查 PR → 人工复核输出 → 更新指令 → agent 更强
这不是「AI 替代人」的故事。这是「人先干一遍，AI 跟上放大」的故事。
而且这是一个飞轮。人工审计的质量决定 agent 的下限，agent 的覆盖率决定人工复核的上限。你跳过了第一步，后面的链条根本转不起来。
我想到一个类比：无障碍 agent 就像一个学徒。你给它一本教材（互联网上公开的知识），它学到的是平均水平——而平均水平就是那些无障碍反模式。你带它去现场，让它看你修 bug（手动审计的 issue 和 PR），它学到的是专家水平。但前提是你得先去现场。
欧洲无障碍法案已经生效了。美国 ADA Title II 2027 年 4 月就要把 WCAG 2.1 AA 设为法定标准。合规压力摆在那儿，而且会越来越紧。但法律只能逼你做事，不能帮你把事做好。你可以用最廉价的方案应付检查，然后得到一个能用但难用到让人愤怒的界面——或者你先认真对待，再让 AI 帮你提速。
GitHub 这个实验最有价值的输出不是那个 agent，是那套手动审计的 issue 库。没有那套东西，agent 就是一个读过几万本前端教材但从没实际修过 bug 的应届生。教材是对的，经验是空的。
Bailey 在文章里还提了一个容易被忽略的点：他们定期人工审查 agent 的输出，还做了 PR 审查情绪分析的工具。也就是说，agent 修完 PR 后，人类 review 的时候是满意还是愤怒，这些情绪信号被量化后反过来用来调整 agent 的指令。
这是闭环。不是开了就忘的自动化，是开了之后持续校准。
我自己做产品的时候也踩过类似的坑。一开始想让 AI 直接帮我生成组件，出来的东西看着都对，用起来全不对。后来自己手动修了几轮，把问题和修复方法记下来，再喂给 AI，质量才上去。顺序不能反。
其实不只是无障碍。任何需要领域知识的开发任务都适用这个规律：先有人的经验沉淀，AI 才能在正确的分布上做概率计算。没有经验的 AI 就像没有调试过的前端代码——跑是能跑，对不对另说。
Bailey 写这篇文章的态度也很好。他没有说「我们要用 AI 解决无障碍问题」，他说「我们尝试增强同事们的努力」。
这两个说法差了一个世界观。一个是 AI 替代人，一个是 AI 增强人。听起来像语义游戏，但落地之后完全不一样。替代人的路径是：把人踢出去，让 AI 全自动跑。增强的路径是：人先在场，AI 在旁边帮忙。
社会残障模型告诉我们：障碍不是人的问题，是环境构建方式的问题。
AI 是环境的一部分。如果环境本身就充满了历史遗留的无障碍偏见，AI 放大了这个偏见，那它不是解药，是加速器。加速一个错误方向，比不加速更糟——因为它跑得更快了，你更难停下来修正。
只有先把环境修好，AI 才能在这个基础上跑得更快。
人先干一遍。机器跟上。没了。
你做过无障碍相关的开发吗？遇到的最大阻力是工具不行、需求不急，还是根本没人提过？
Eric Bailey. Building a general-purpose accessibility agent—and what we learned in the process. GitHub Blog. https://github.blog/ai-and-ml/github-copilot/building-a-general-purpose-accessibility-agent-and-what-we-learned-in-the-process/