手機手語 AI 里程碑：Pixel ASL 轉文字、Android 無障礙與 FoneClaw 超越語音設計
看懂手機手語 AI 目前能做什麼：Google DeepMind SL2T 先在 Pixel 11 提供 ASL-to-English dictation，Android 無障礙工具如何搭配，手機 Agent 為何要把語言輸入、核准、執行與復原分開。
- Google DeepMind 的 SL2T 目前把 ASL-to-English sign dictation 帶到 Gboard 和 Live Transcribe，先從 Pixel 11 開始；更多裝置與語言屬於後續方向。
- 手語是自然語言，不是英文逐字手勢化；手形、身體、臉部表情、空間指涉與時序一起承載語法，因此手機手語 AI 和語音轉錄是不同問題。
- SL2T 以裝置端 MediaPipe Holistic 擷取 pose landmarks，再把幾何座標送到伺服器翻譯，DeepMind 說明 raw video 會被丟棄；這仍需要隱私、錯誤修正與使用者確認設計。
- FoneClaw 目前不宣稱手語辨識或 SL2T 整合；我們能從 typed input、使用者選擇的 context、能力路由、核准、停止與復原，建立超越語音的手機 Agent 控制面。
手機手語 AI 現在能做什麼
AI 能在手機上理解手語嗎？目前最具體的手機里程碑，是 Google DeepMind 的 SL2T 把 ASL-to-English sign dictation 帶到 Gboard 和 Live Transcribe，先從 Pixel 11 開始。根據 Google DeepMind 對 sign-language AI 的說明，這項能力讓使用者能以美國手語輸入，系統再輸出英文文字，用於文字欄位或 Live Transcribe 這類手機場景。
這是一個重要進展，因為手機輸入長期偏向語音、鍵盤、觸控和少數輔助方式。對使用 ASL 的聾人使用者來說，sign dictation 代表手機開始接受更貼近自己語言的輸入方式，而不是把所有可及性都壓在語音辨識上。它也提醒 phone-agent builders：未來的手機助理不能只問「能不能聽懂我說話」，還要問「能不能理解我可用、偏好、文化上自然的輸入」。
目前邊界也要講清楚。SL2T 的產品支援從 Pixel 11、ASL-to-English、Gboard 和 Live Transcribe 這些場景起步；更多 Android 裝置、更多 sign languages、生成能力或更廣泛任務控制，屬於後續工作方向。Android 手語轉文字是一種 language input milestone，不是所有 Android 手機已具備通用手語理解，也不是手語輸入能直接控制所有 App 的證明。
從 FoneClaw 的角度看，這個里程碑的價值在於它把「無障礙手機代理」拉出語音中心思維。FoneClaw 目前不宣稱手語辨識或 SL2T 整合；我們能從這個進展學到的是，任何輸入方式進入手機任務後，還需要清楚的意圖解析、目標選擇、核准、可見結果與復原。
手語翻譯為何不同於語音轉錄
手語 AI 和語音轉錄相同嗎？不相同。語音轉錄通常把聲音中的語音單位轉成文字；手語翻譯要理解一套視覺語言。全世界有 200 多種手語，它們不是同一套 universal gestural code，也不是把英語、中文或其他口語逐字換成手勢。ASL 是美國手語，不是全球通用手語。
手語的語言訊號也不只在雙手。手形、動作方向、位置、身體姿勢、臉部表情、視線、空間定位、classifier 和時間結構都可能承載語法或語意。使用者可以在空間中建立人、物、位置和事件，再透過後續手勢引用。這種同時性的語法和線性的語音序列不同，因此單靠手套、少數手勢字彙或手形分類，難以涵蓋真實手語。
這對手機設計有直接影響。若產品把手語當成「沒有聲音的英文」，就會在語法、語氣、人物關係與空間指涉上出錯。真正尊重聾人社群的手機手語 AI，應該把 sign languages 當成獨立自然語言，並清楚標示目前支援哪一種語言、輸出哪一種書寫語言、錯誤如何修正、使用者如何確認。
這也讓「超越語音的 AI 無障礙」更具體。語音輸入是一條路，手語輸入是另一條路；typed text、caption、RTT、Switch Access、braille、visual confirmation 和 haptic alerts 也都可能是同一個使用者在不同任務中需要的組合。好的 phone agent 不應假設所有人都能或都想用聲音。
SL2T 架構、證據與隱私取捨
DeepMind 說明的 SL2T 架構，先在裝置上使用 MediaPipe Holistic 擷取 pose landmarks，也就是身體、手部與臉部等幾何座標；接著將這些 geometric coordinates 傳到伺服器進行翻譯，並依 DeepMind 說明丟棄 raw video。這個分界很重要：它不是把完整影片直接當成長期輸入保存，也不是完全本機翻譯。使用者和 builder 都要分清 on-device landmark extraction 與 server translation。
訓練資料規模也值得注意。DeepMind 表示模型訓練涵蓋超過 100,000 小時、50 多種 sign languages，但初始產品支援是 ASL-to-English。這種差異很常見：研究與訓練覆蓋範圍可以很大，產品可用範圍通常要從更小、可驗證、可支援的語言和裝置開始。對使用者來說，購買或更新手機前要看「現在可用」而不是只看研究方向。
證據也要讀完整。DeepMind 提供官方 examples 並公開 remaining errors，例如 rare signs、rapid fingerspelling、classifiers、passive constructions 和 tense 等錯誤類型。這些錯誤不是讓人否定技術，而是提醒我們：sign-to-text 的輸出要可檢查、可修正，尤其在要用來傳訊息、填表單、建立任務或觸發手機動作之前。
隱私取捨也不能被一句「丟棄 raw video」簡化。Landmarks 比 raw video 少了許多視覺細節，但它們仍可能與身體動作、語言內容和個人使用情境有關。手機手語 AI 應清楚告知：哪些資料在裝置上處理、哪些送到伺服器、保留多久、能否刪除、是否可離線、在工作或學校帳號中是否有不同政策。Live Caption 的本機處理說法，不能直接套到 SL2T、Live Transcribe 或任何第三方手機代理。
聾人手機助理要把這些事做成使用者看得懂的控制：輸入是否被辨識、翻譯是否可信、哪一步要確認、錯誤怎麼改、相機或網路失效時怎麼 fallback。技術突破只是第一段，可信的手機工作流才是第二段。
依手機任務選擇可及的輸入與輸出
無障礙 AI 手機代理不應把所有任務都推向同一種輸入。Android 本身已經提供多種 modality。Android Accessibility overview整理了 screen reader、caption、Switch Access、braille、RTT 等多種選項，並提醒 feature availability varies by device。對 builder 來說，重點不是替使用者排名，而是讓每個任務能選對輸入與輸出。
| 任務 | 可用輸入 | 可用輸出/確認 | 設計重點 |
|---|---|---|---|
| 輸入一段訊息或搜尋文字 | ASL-to-English dictation、typed text、手寫、鍵盤 | 可編輯文字、視覺預覽、震動提示 | 送出前要能修正翻譯與收件人 |
| 理解周遭對話 | Live Transcribe、typed response | 即時文字、sound labels、history controls | 轉錄和手語翻譯分開，連線與語言可用性要檢查 |
| 觀看手機媒體或通話字幕 | Live Caption | 裝置音訊字幕、選定裝置的 typed call responses | Live Caption 的本機處理範圍不要外推到其他功能 |
| 電話溝通 | RTT、typed responses、captioned call routes | 文字對話、視覺狀態、來電提示 | 緊急與正式通話需確認可用性 |
| 非觸控操作手機 | Switch Access、外接裝置、觸控替代 | 焦點框、掃描狀態、可視化控制 | 速度、疲勞與可取消操作比炫技更重要 |
| 手機代理任務 | 打字輸入、手語轉文字輸出、使用者選定情境 | 動作預覽、核准、任務狀態、停止、fallback | 輸入語言和執行權限必須分開 |
Android Live Transcribe 說明指出，它會把附近 speech and sound 轉成螢幕文字，也支援 typed responses、sound labels、history controls 和在支援裝置上的 selected offline languages。Android Live Caption 說明則記錄 supported media and calls captions，並說明 Live Caption 的 on-device processing。這些工具各自處理不同 communication gap，不能互相混用。
若你要比較視障或低視能使用者的 Android 語音工作流，可看 視障使用者 Android 語音手機設定：TalkBack、Voice Access、Gemini 與 FoneClaw。本篇聚焦手語與超越語音的 phone-agent 設計，但結論相同：可及性不是單一模式，而是任務、身體狀態、環境、語言和控制偏好的組合。
把語言輸入和安全手機動作分開
手語 AI 能控制 Android 應用程式嗎？手語轉文字本身只是輸入層。即使 SL2T 把 ASL 翻成英文句子，手機代理還要做下一段：判斷使用者意圖、解析目標 App、找到收件人或欄位、檢查權限、顯示即將執行的動作、等待確認、完成後驗證結果。translation 不是 authorization，input 不是 execution。
舉例來說，使用者用手語輸入「傳訊息給 Alex，我 10 分鐘後到」。手機先要確認翻譯文字正確，再解析 Alex 是哪位聯絡人，接著選擇訊息 App，準備草稿，顯示收件人和內容，最後等使用者核准。若翻譯把時間或對象弄錯，或有多個 Alex，系統應該停下來讓使用者修正，而不是把翻譯結果直接變成外部動作。
可及的 confirmation 不能只依賴聲音。對聾人使用者，核准介面應提供清楚文字、視覺狀態、可選按鈕、震動或其他可感知提示。高影響動作，例如發送正式訊息、撥號、分享位置、刪除資料、改系統設定，也要能在使用者可讀、可修正、可取消的狀態下進行。
這就是能力路由的重要性。手機代理要決定哪個 tool、App、Skill 或 Workflow 適合，但 capability matching 不能直接執行。若你想深入 AutoAttach、Suggest、Fallback 如何讓 Android 任務選對能力，可讀 AI 代理能力路由指南：AutoAttach、Suggest、Fallback 如何讓 Android 任務選對能力。對 beyond-voice accessibility 來說，路由越聰明，核准和復原越要清楚。
用超越語音的無障礙視角評估 FoneClaw
FoneClaw 支援手語辨識嗎？目前 FoneClaw 不宣稱 sign-language recognition，也不宣稱與 DeepMind SL2T 整合。這個邊界要先說清楚，因為手機手語 AI 是獨立且高門檻的語言輸入技術。FoneClaw 目前能提供的是 phone-agent control plane：typed interaction、使用者選擇的 context routes、目前畫面脈絡、能力路由、工具政策、可見任務狀態、停止和權限復原。
我們從打造 FoneClaw 學到，無障礙不應被簡化成「加語音輸入」。很多使用者需要 typed input、可見結果、可停下的任務、可修正的草稿、清楚的權限提示、可回復的 fallback。對聾人使用者來說，語音輸入並不是自然入口；對許多情境來說，聲音輸出也不是可靠提示。因此 FoneClaw 的可見任務狀態、文字互動和可操作確認，比單純語音助手更接近 phone-agent accessibility 的基礎。
FoneClaw 的 capability routing 不會把「模型理解了」當成「工具已獲准執行」。AutoAttach、Suggest 和 Fallback 可協助選擇能力；tool policy、approval、task stop 和 recovery 負責行動邊界。若未來某個 sign-to-text 輸入層把手語轉成文字，FoneClaw 仍需要用同樣規則處理後續 Android 動作：目標解析、權限、核准、結果與復原。
目前 FoneClaw 支援 100+ built-in tools，完整能力可看 FoneClaw 功能頁。我們在公開說明中不把工具數字細拆成會變動的清單，而是讓使用者確認目前支援的 Android action categories。對無障礙手機代理來說，工具越多越需要治理：誰能呼叫、何時需要核准、失敗如何停止、使用者如何接手。
我們也知道這條路還需要進步。真正面向聾人使用者的 phone agent，必須把手語語言輸入、視覺確認、震動提示、文字回饋、錯誤修正和社群測試放進設計流程。FoneClaw 目前的貢獻，是提供部分 beyond-voice control-plane building blocks；手語辨識本身仍應由專門且經社群參與驗證的語言技術承擔。
和聾人使用者一起稽核手機代理
DeepMind 說明中很重要的一點，是 Deaf participants 和 advisory committee 參與了 concept、data、evaluation 和 impact assessment。這不是形式，而是無障礙 AI 的基本條件。聾人社群不是單一使用者類型；不同 sign languages、地區、年齡、教育背景、雙語程度、身體狀態和設備習慣，都會影響手機手語 AI 的真實可用性。
稽核第一項是 language coverage。系統支援 ASL-to-English，就應清楚說 ASL-to-English；支援其他 sign language 時，也要清楚列出，不應用「手語」籠統帶過。第二項是 signer diversity：左撇子、一手手語、不同膚色、不同手部大小、不同鏡頭角度、不同速度、不同穿著和光線，都會影響辨識。DeepMind 也提到 left-handed 和 one-handed signing 是實際設計關切。
第三項是 physical use。手機要怎麼拿？相機是否穩？坐著、站著、在戶外、低光源、單手操作時是否可用？第四項是 privacy and latency。手語輸入通常需要鏡頭，使用者要知道影像或 landmarks 怎麼處理；延遲太高會打斷對話。第五項是 error repair：翻譯錯 rare signs、rapid fingerspelling、classifiers、passive constructions 或 tense 時，使用者能不能快速修改，不必重來整句。
第六項是 action safety。若翻譯結果要進入手機代理，系統必須在傳送、撥號、分享、刪除或改設定前提供可見核准。第七項是 fallback。相機、網路、辨識或語言不支援時，使用者應可切到 typed input、Switch Access、RTT、Live Transcribe 或手動操作。若你要深入權限與稽核設計，可看 AI 代理身份與權限治理：逐工具核准、稽核紀錄與 FoneClaw Android 控制。
依賴超越語音工作流前先做可回復測試
最後，用一個低風險任務測 beyond-voice phone workflow。選「把一句文字準備成不送出的訊息草稿」比直接傳送更安全。第一步，確認輸入文字：若來自 sign-to-text，先檢查翻譯是否正確；若來自 typed input，確認沒有錯字。第二步，確認目標：收件人、App、欄位和權限都要可見。
第三步，確認動作預覽：草稿內容、對象和下一步要能讀到或以可及方式感知。第四步，測 stop：在核准前停止任務，看系統是否保持可接手狀態。第五步，測 fallback：關掉網路、遮住相機、撤回權限或讓目標模糊，確認可以改用 typed input、手動選擇、目前畫面脈絡或安全停止。
若你在 Android 上使用懸浮入口與目前畫面脈絡，可搭配 Android 懸浮 AI 助手與目前畫面：提問、核准、執行與復原指南 了解可見上下文如何進入任務。一次成功不能代表所有語言、App、裝置和光線都可靠；但可回復測試能幫你知道：當輸入、翻譯、權限或網路出錯時，手機代理是否仍把使用者放在控制位置。