accessiBe 发布 Code Agent：无障碍审查搬进 GitHub PR，问题代码当场标出行内改
写代码的人大多有类似经历：无障碍（accessibility）问题不是在写代码时发现的，而是事后从外部"转"过来的——一张截图、一个工单、一个说不清具体哪行代码有问题的编号。等任务流转回开发者手里，代码往往已经上线了。
9 月 17 日，无障碍领域头部公司 accessiBe 宣布推出 Code Agent，思路很简单：把无障碍审查直接搬进 GitHub 的 pull request（PR）里，让问题在写代码的当下被发现和修掉。目前该功能已面向符合条件的 accessFlow 客户开放 beta 测试。以下内容基于官方新闻稿与多家媒体转述整理。
它是怎么工作的
Code Agent 在 PR 打开或更新时自动运行，也可以随时手动触发。它按照 WCAG 2.2 AA 标准（目前主流的无障碍合规标准）审查代码变更，然后做两件很具体的事：
- 标记到行：指出导致问题的那一行代码，而不是给一个模糊的"页面不合规"结论；
- 行内建议修复：像同事的 review 评论一样，直接在 PR 里写出建议的修法，开发者可以接受、拒绝，或者在评论里讨论。
团队还可以按自己的节奏调它：设置严重度阈值（只报严重问题，避免噪音）、排除特定文件或规则，甚至像对待测试和 lint 一样，要求 Code Agent 通过后才能合并。
accessiBe 强调了一点：没有开发者的人工确认，任何修复都不会被合并——每一条改动都是人来拍板。
目前支持什么
Code Agent 现在支持 Vanilla HTML/JavaScript、React 和 Next.js 三类技术栈，会自动检测项目用的框架，检测结果也可以手动覆盖。运行层面，它用的是 accessiBe 平台已有的统一无障碍引擎——也就是说，PR 里给出的修复标准，和网站上线后 accessWidget、accessFlow、accessScan 等工具检查的标准是同一套，从第一次提交到生产环境口径一致。
为什么值得开发团队关注
无障碍问题在很多团队里是"合规成本"：出了问题再修，比第一次就写对要贵得多，而且暴露在生产环境里的时间越长风险越大。Code Agent 做的事本质上是"把无障碍左移"（shift left）——把它变成和测试、lint 并排的一道常规检查，在代码还在你手里的时候就拦住问题。
对需要满足 ADA、WCAG 等合规要求的企业前端和全栈团队来说，这类 PR 内的自动审查是比较实际的落点：不改变现有工作流，只是在已有的 PR 环节里多加一道检查。
可用性
Code Agent 目前处于 beta 阶段，面向符合条件的 accessFlow 客户开放。现有客户可以向自己的客户经理咨询开通；新客户可以联系 accessiBe 了解详情。