一周用AI智能体团队造出免费无障碍扫描器：实战复盘

小型网页代理商经常会收到客户发来的那封邮件："我们的网站无障碍吗？"这个问题没有廉价的答案——真正的回答是一次符合性审计，需要WCAG专家花费数天完成，而小团队既无法以自身的费率出售这项服务，也很难在项目间隙挤出时间做。于是问题被搁置，或被含糊地回答——后者反而更糟。

开发者Sheree Preston给出的解法是：用一支AI智能体团队，在大约一周内构建了一款免费、可白标的无障碍扫描工具Curbcut。她坦诚地说明了这个工具能做什么、不能做什么，以及"与AI团队协作一周"究竟是怎样一种体验。

一个无法廉价回答的问题

对小型网页代理商或自由职业者而言，"我们的网站无障碍吗"这个问题背后是一道现实鸿沟。专业的无障碍审计是一项高度专门化的工作，需要以WCAG标准为生的专家投入数天时间。这类专业能力，小作坊很难justify：既卖不上价，也挤不出做它的时间。

Sheree的产品定位因此刻意收窄且诚实——不是审计，而是一次快速、通俗易懂的"初步检视"。你粘贴一个URL，大约一分钟后就能得到一份评分化、带优先级的报告：哪里出了问题、违反了哪条WCAG 2.2规则、谁会受到伤害、建议的代码修复方案是什么。

WCAG（Web Content Accessibility Guidelines，网页内容无障碍指南）是由W3C制定的国际标准，目前主流版本为2.1和2.2。它将无障碍要求分为三个合规等级：A（最低）、AA（通常是法律要求的基准）和AAA（最高）。每条准则对应具体的成功标准，例如图片必须有替代文本、色彩对比度需达到特定比值、所有功能必须可通过键盘操作等。在许多国家，AA级合规已被纳入法律要求——美国的《美国残疾人法》（ADA）、欧盟的《欧洲无障碍法》均有相关条款，企业若不达标可能面临诉讼。正因为此，"我们的网站无障碍吗"这个问题在商业层面并非可选项，而是一个潜在的法律风险点，小型代理商却往往没有能力提供专业的回答。

产品的核心设计：白标 + 诚实

Curbcut支持白标输出。填入代理机构和客户的名称后，报告标题会显示为"Prepared for [客户] by [代理机构]"，可以作为自己的交付物直接递交给客户。它回答了那个尴尬的问题、开启了对话，并指向后续真正值钱的修复工作——而修复才是代理商利润所在。

这种定位的聪明之处在于：工具本身不与专业审计师抢饭碗，而是作为"引流"和"对话起点"存在。它承认自己的局限，把正式审计留给专家，自己则承担"快速初筛"的角色。

与AI团队协作一周到底是什么样

Sheree对协作方式毫不神秘化：她没有写代码，自己也不是无障碍专家。她拥有的是一支AI智能体团队——一个"AI CTO"负责把她的方向转化为计划并拆解成具体任务，一个"AI工程师"负责实现、测试和验证。她的工作是那些无法委托的部分：用通俗语言描述产品、做决策，以及像客户一样审视结果——读报告、点击真实站点、发出直率的反馈邮件。

第一周有两个插曲很能说明问题。其一，她误把一个邮箱地址粘进了URL输入框，遭遇了一条令人困惑的拒绝提示。她发了截图，当天提示信息就被重写——而追查原因时暴露出一个更大的缺口：标准工具根本无法扫描带密码保护的staging测试站点，而这恰恰是代理商工作的核心场景。同一周，团队就上线了对"把登录信息带在URL里的staging链接"的支持，并设下严格规则：凭据只发送给你粘贴的那个确切主机，绝不出现在报告、日志或任何其他地方。

其二，她测试了一个防火墙拒绝自动访问者的站点。扫描器正确地报告了失败，但提示太含糊，分不清是bug还是站点本身的问题。现在的提示会明确说明"网站拒绝了扫描"，并解释为何在浏览器能正常打开页面时这很可能是原因。

整个循环就是：她破坏它或描述它，团队修复它，没有通过绿色自动化测试套件和真实检查的改动绝不上线。拿到第一份全绿报告时，她没有庆祝，而是追问工具"没有检查"什么——这个问题再一次改变了产品。

Sheree描述的"AI CTO + AI工程师"架构，是当前AI辅助开发领域中"多智能体协作"（multi-agent）模式的一个具体实践。与单一对话式AI不同，多智能体框架将不同职责分配给不同的角色——一个负责将模糊需求转化为可执行的技术规划，另一个负责代码实现与测试验证。这种分工模仿了人类团队的协作结构，在一定程度上减少了"单一模型全包"时容易出现的上下文混乱和任务漂移问题。对非技术创始人而言，这种模式的关键不在于理解代码，而在于能否提供清晰的产品意图和严格的结果验收标准——恰恰是Sheree在本文中反复强调的那两件事。值得注意的是，333个自动化测试并非由她手写，而是智能体团队在迭代过程中逐步积累的，这本身也是AI辅助开发能够维持质量的结构性保障之一。

Curbcut今天能做什么

产品的具体能力清单清晰而克制：

• 粘贴URL即可——无需注册、无需邮箱、无需信用卡，支持带密码保护的staging链接。
• 抓取目标页面及同站点下最多四个链接页面，对服务器发送的HTML运行一套固定的14项具体WCAG 2.2检查。
• 约一分钟后输出：评分化、带优先级的通俗英语报告，附建议的代码修复方案。
• 若某项检查无法对页面做出判断，它会被列出而非猜测——放在评分下方一个琥珀色的"Curbcut无法检查的内容"面板中，这样"绿色"意味着你清楚实际检查了什么。
• 报告支持白标且可打印，可直接交付客户。
• 隐私优先设计：服务器仅保留每日扫描次数的裸计数，不记录URL、不记录访客数据、不使用cookie。
• 每次改动都在自动化测试套件护航下发布（写作时为333个通过测试），并已对包括gov.uk在内的真实站点验证过。

它不能做什么——并且主动声明

这是Sheree最在意的部分，因为"过度宣称"正是信任崩塌的方式。

• 它读取的是服务器发送的HTML，无法看到浏览器之后用JavaScript绘制的内容——轮播图、cookie横幅、嵌入式小组件。因此一个重度依赖JS的页面在这里可能得到比实际应得更高的分数。
• 两项检查——色彩对比度和焦点指示器——需要站点的样式表。当样式表无法读取时，它们会跳过，琥珀色面板会如实说明，而不是猜测。
• 它一次只扫描一个站点、深入几个页面。它是报告生成器，不是爬虫。
• 最重要的：**这不是一次符合性审计。**它不会认证站点，也不提供法律保护。它只是开启真正工作的那次快速、带优先级的初步检视——如果客户之后需要正式审计，那位专家依然值得他的费用。

静态HTML扫描与JavaScript渲染内容之间的鸿沟，是自动化无障碍检测工具面临的最核心技术局限。现代网页大量依赖客户端JavaScript动态生成DOM——React、Vue、Angular等框架构建的单页应用（SPA），其实际呈现给用户的内容与服务器原始返回的HTML几乎完全不同。这意味着对于重度前端框架的站点，基于静态HTML的扫描器可能遗漏大量实际存在的无障碍问题：动态加载的模态框、无焦点管理的交互组件、运行时注入的ARIA属性缺失等。Axe-core、Lighthouse^广告等更成熟的工具通过在真实浏览器环境中运行来部分绕过这一问题，但相应地引入了更高的运行成本与复杂度。Curbcut选择静态扫描并主动声明这一局限，是工程成本与诚实边界之间有意识的取舍。

阶段性真相与下一步

Sheree对反馈来源也极为精确：到目前为止，塑造产品的一切都来自内部测试——她自己的扫描、她自己的错误，以及团队的自动化检查和真实站点扫描。还没有外部用户发表意见，因为目前根本还没有外部用户。这正是当前阶段的意义所在：真实世界测试、反馈驱动。没有路线图表演，下一个功能将取决于第一批真实用户说缺什么。

这个案例值得关注的，不只是工具本身，更是"一人+AI智能体团队"的协作范式：非技术背景的创始人，通过清晰的产品描述、果断的决策和严苛的结果判断，在一周内交付了一个带333个测试、经真实站点验证的可用产品。它既展示了AI辅助开发的生产力上限，也诚实地标注了工具能力的边界——而后者，恰恰是这类产品最稀缺的品质。