手机手语 AI 里程碑：从 ASL 转文字到超越语音的无障碍手机智能体

当前手机手语 AI 能做到什么

手机手语 AI 的当前里程碑，是 ASL 到英文的 sign-language-to-text 开始进入真实手机输入场景。Google DeepMind 关于 sign-language AI 的说明介绍了 SL2T：它为 Gboard 和 Live Transcribe 提供 ASL-to-English sign dictation，并首先在 Pixel 11 上可用。换成用户场景，就是会 ASL 的用户可以用手语把内容转成英文文本，用于输入、沟通或把想法带入手机应用。

这个进展很重要，因为它把“手机能听见声音”拓展到“手机能看懂部分手语输入”。对聋人用户、重听用户、不能或不愿使用语音的人来说，AI 无障碍不应该只围绕麦克风展开。手机输入可以来自手语、键盘、Switch Access、RTT、字幕、当前屏幕、触摸、视觉确认和震动提示。越多输入和输出方式被认真支持，手机 Agent 才越接近真正可用。

边界同样要说清楚。当前公开可用性从 Pixel 11 上的 ASL 到英文开始；更多设备、更多语言和更广泛能力属于后续方向。它也不是通用 Android 应用控制能力。把手语翻译成文本，只是把用户语言输入转成可处理的句子；要真正发消息、创建提醒、打开应用或修改设置，还需要目标解析、权限、确认、执行和恢复。

如果你关心其他无障碍输入和语音路线，可以先看视障用户 Android 语音手机设置：TalkBack、Voice Access、Gemini 与 FoneClaw。本文聚焦手语 AI 这件事给手机 Agent 构建者带来的新要求：不要把无障碍等同于语音。

手语转文字不是语音转写的手势版

手语 AI 和语音转写不同。语音转写通常把声音中的词识别成文字；手语翻译要处理一种视觉-空间语言。ASL、BSL、中国手语、日本手语、法国手语等都是独立自然语言，全球存在 200 多种手语。手语不是“用手比英文”，也不是全球统一手势码。

手语的语言信息来自多个通道：手形、动作方向、空间位置、面部表情、头部和身体姿态、节奏、指拼、分类词和空间指代。很多语法信息是同时发生的，而不是像口语文字那样线性排列。比如面部表情可以承载疑问、否定或强度，空间位置可以指代人物和地点，身体转向可以帮助表达对话关系。

这意味着，手语转文字不是把一个手势词典逐项查表。只识别手形或戴手套追踪手指，无法完整覆盖语法、空间和非手部信号。一个好的手机手语 AI 要尊重手语作为语言的身份，也要尊重聋人社群的使用习惯。翻译结果应该可审阅、可修正、可撤回；系统需要承认歧义和错误，而不是把模型输出当成最终意图。

对手机 Agent 构建者来说，设计后果很直接：不要把“识别到文本”当成“用户已经授权动作”。文本只是输入。下一步还要确认用户想对哪个应用、哪个联系人、哪个文件或哪个设置执行什么动作。

SL2T 架构、证据和隐私取舍

DeepMind 公开的 SL2T 设计把一部分处理放在设备上，一部分放在服务器上。设备端使用 MediaPipe Holistic 提取身体、手部和面部等 pose landmarks。根据 DeepMind 的说明，系统把几何坐标发送到服务器进行翻译，原始视频会被丢弃。这比直接上传完整视频更克制，但它仍然不是“所有处理都在本地”。几何坐标也可能携带与身体动作和语言表达相关的信息，产品设计仍要认真处理告知、同意、保留和安全。

从证据看，DeepMind 说明模型训练覆盖超过 100,000 小时、50 多种手语的数据，公开产品起点则是 ASL 到英文。这个差异很关键：训练范围可以帮助模型学习视觉语言结构，但当前用户能用到的产品能力要按公开可用性判断。读者问“AI 能在手机上识别手语吗”，最准确的回答是：在当前支持设备和语言范围内，ASL 到英文输入已经进入手机场景；它还不是所有 Android 手机、所有手语和所有任务的通用能力。

官方示例也披露了剩余错误。罕见手势、快速 fingerspelling、classifiers、passive constructions 和 tense 都可能出现翻译问题。这个披露很有价值，因为它提醒我们：手语 AI 的输出要有检查步骤。对于聊天、搜索或草稿，错误可以通过编辑修正；对于拨打电话、发送消息、提交表单、医疗、法律、财务或紧急场景，翻译后还需要更强的确认和回滚。

对隐私的取舍也要按任务看。实时会话、公共场合、医疗沟通、学校和工作场景，对摄像头、网络、存储和字幕历史的要求不同。聋人手机助手必须让用户知道输入从哪里来、数据到哪里去、结果如何保存、错误怎样修正。

按任务选择无障碍输入和输出

无障碍 AI 手机智能体不能只依赖一种输入。Android Accessibility 概览列出了多种输入、输出、字幕、屏幕阅读、开关、Braille 和 RTT 选项。不同任务应该选不同组合，而不是让所有用户都走语音或手语路线。

Android Live Transcribe 帮助说明适合附近语音和声音转文字，并支持 typed responses、声音标签、历史控制和部分设备上的离线语言。Android Live Caption 帮助说明适合给支持的媒体和通话加字幕，并在其帮助页中说明了 on-device processing。RTT 适合通话中的文字会话，Switch Access 适合非触摸交互，TalkBack 适合屏幕阅读，震动和视觉提示适合提醒。

这张表的核心是按任务组合 modality。一个人可能在安静环境用手语输入，在走路时用文字，在通话中用 RTT，在设置手机时用 Switch Access。可访问设计的目标不是替用户指定唯一模式，而是让每个模式都能接入同一个清楚、可确认的动作流程。

把手语输入和手机动作分开设计

安卓手语转文字把语言输入带进手机，但它还没有完成手机 Agent 的全部工作。翻译后的句子可能是“给王明发消息说我十分钟后到”，也可能是“提醒我下午三点吃药”，还可能是“打开地图去这个地址”。每一句都需要进一步解析：目标是谁，应用是哪一个，动作风险多高，是否需要权限，是否要先展示草稿。

无障碍手机智能体尤其要避免把确认只做成声音。确认界面要能被看见、读出、触达、放大、用开关选择，也要能让用户修正识别错误。比如模型把 fingerspelling 识别错了，用户要能编辑；联系人重名时，要能清楚选择；时间不确定时，要能看到候选；权限缺失时，要能进入设置并回到任务。

动作预览应该包含五件事：目标应用、对象、内容、权限、结果。发送消息要显示收件人和正文，创建提醒要显示时间和内容，打开导航要显示目的地，读取屏幕要说明读取范围。对于高影响动作，翻译输入只是起点，用户确认才是执行前的关键状态。

FoneClaw 的能力路由也遵循这个分层思路。AutoAttach、Suggest 和 Fallback 可以帮助选择上下文和能力，但匹配本身不是执行授权。需要理解这条技术路线的读者，可以继续看AI 智能体能力路由指南：AutoAttach、Suggest、Fallback 如何选择 Android 工具。

用超越语音视角评估 FoneClaw

先把当前边界说清楚：FoneClaw 当前公开能力覆盖 typed interaction、用户选择的上下文路线、受治理工具、可见任务状态、审批、停止和恢复；手语识别、ASL-to-English 输入层和 DeepMind SL2T 集成不属于当前公开能力。我们不把 FoneClaw 写成手语识别工具，也不把 typed input 等同于手语翻译。

这个边界之外，手语 AI 里程碑给我们很强的产品提醒：手机 Agent 不能只为语音设计。FoneClaw 已经支持用户用文字发起任务，用户也可以在支持场景中选择附件或当前屏幕上下文，让模型理解任务背景。模型负责理解和规划，FoneClaw 用 100+ built-in tools 承接受支持 Android 动作，并把工具策略、审批、停止和权限恢复分开处理。

从无障碍视角看，最重要的是可见控制。用户发起任务后，需要看到模型理解了什么、准备执行哪个工具、目标对象是谁、哪些权限会被用到、下一步是否会产生外部影响。声音反馈可以有，但不能成为唯一确认方式。任务状态、停止按钮、错误解释、视觉结果和恢复路径，对聋人用户、重听用户、嘈杂环境中的用户、不能说话的用户都同样重要。

FoneClaw 还需要继续朝更完整的 accessibility-first 方向建设：更好的键盘和开关可达性、更清晰的视觉确认、更少依赖声音的任务反馈、更强的错误修正路径，以及和真实用户共同测试。我们把当前可用的 typed/context 路线当成基础，把未来更多输入方式看成手机 Agent 必须认真接住的方向。关于当前屏幕如何作为用户主动选择的上下文进入手机任务，可以看Android 悬浮 AI 助手与当前屏幕：从提问到可控操作的完整指南。

和聋人用户一起审计手机 Agent

DeepMind 的文章提到，聋人参与者和顾问委员会参与了概念、数据、评估和影响分析。这一点比任何单个 benchmark 更值得手机 Agent 团队学习。无障碍产品不能只由听人团队在实验室里决定“已经够好”。手语语言覆盖、签者差异、摄像头角度、单手或左手签、光线、背景、疲劳、网络、隐私、修错方式，都需要和真实用户一起验证。

审计清单可以从八项开始。第一，语言覆盖：是 ASL、BSL、中国手语，还是其他手语？第二，签者多样性：年龄、肤色、手型、动作速度、左手/右手、单手场景是否覆盖？第三，物理使用：手机如何摆放，摄像头是否能稳定看到上半身和面部？第四，隐私：视频、landmarks、文本和历史在哪里处理和保存？第五，延迟：实时对话是否跟得上？

第六，错误修复：用户能否看到翻译、编辑、撤销、重试？第七，动作确认：手机 Agent 是否把翻译内容、目标应用和风险清楚展示？第八，fallback：摄像头不可用、网络断开、识别失败时，键盘、Switch Access、Live Transcribe、RTT 或人工输入是否能接上。审计不是只看成功样例，还要看失败时用户是否仍有控制权。

手机 Agent 的权限和审计也要可理解。谁发起了任务、用到了哪些工具、读取了哪些上下文、哪个动作被批准、哪个动作被停止，都应该可追踪。更深的治理设计可以读AI 智能体身份、权限与审计日志：逐工具审批控制怎么落到手机 Agent。

依赖前先测试一个可逆工作流

在依赖任何超越语音的手机流程前，先选一个低风险任务测试。比如把一句 ASL-to-English、键盘输入或 typed response 转成“创建一个普通提醒”，然后检查七件事：输入文本是否准确，目标动作是否正确，提醒时间是否清楚，权限是否可理解，执行前是否能看见预览，是否能停止，失败后是否有替代输入路径。

第二个测试是通信草稿，不直接发送。让系统准备一条短信、邮件或聊天草稿，确认联系人、正文和应用都正确，再由用户决定发送。这样可以验证语言输入、意图解析、目标选择和确认界面，同时避免高影响错误。

第三个测试是故意制造失败：遮住摄像头、断开网络、改用不同输入方式、撤销权限、使用容易混淆的联系人。一个可靠的无障碍 AI 手机智能体，不只要在理想条件下成功，还要在识别失败、权限缺失和用户停止时继续保护用户控制权。