AI Engineer onepage/ Voice UX
Allen Pike, Forestwalk Labs · 13:05
這支影片在講：AI 介面從打字聊天走向語音輸入、視覺輸出
Allen Pike 延伸 Andrej Karpathy 的觀點：人最自然的輸入是說話，但最適合吸收的輸出往往是畫面。真正難的不是做出 demo，而是在一秒內回應，讓 AI agent 像會議中的自然助理一樣順手。
Published: 2026-06-28Video ID: 65X0pQ6Lmbg
01 / 問題
文字聊天不是 AI UX 的終點
目前多數 AI 產品仍是「打字進、文字回」。但語音能帶出速度、語氣、猶豫與意圖，視覺則更適合承載解釋、控制與互動。
02 / 反轉
語音輸出反而更難
全語音對話需要約 200ms 內反應，對網路、speech-to-text、模型推論與回傳都是硬仗。視覺輸出給了產品更寬的時間窗口。
03 / 解法
用低延遲架構換自然感
用夠快的模型、每 1-2 秒 eager inference、穩定 prefix caching，把回應壓進使用者注意力還沒斷掉的範圍。
Watch for this
影片最值得抓的四個訊號
Human limit
100ms
電腦反應若要讓人感覺即時，經典目標大約是十分之一秒。
Attention limit
1s
超過一秒，使用者容易失去思路；visual output 可在這個窗口內成立。
Voice loop
200ms
真正順暢的 voice-in / voice-out 對話，需要更激進的延遲預算。
Cache shape
90/10
讓前 90% context 穩定，最後 10% 放變動輸入，才能降低成本與延遲。
Core story
Voice-in / visuals-out 為什麼值得重新看
一
說話是高頻寬輸入，不只是更快的文字
影片強調，人在說話時不只每分鐘字數比打字高，還會透過語氣、停頓、確定或不確定感傳遞額外資訊。這就是重要事情仍然常常需要「開個 call」的原因。
二
視覺輸出讓 AI 不必一直插話
Forestwalk 的例子是會議中的 agent：人提到 Slack integration bug，agent 能安靜把 Linear issue 建好，並以畫面或狀態回應。好體驗不是讓 AI 用聲音搶話，而是捕捉意圖後自然完成動作。
三
低延遲才是 delight 的分水嶺
語音介面過去常被認為又慢又笨，問題不一定是語音本身，而是 response chain 太長。只要延遲超過使用者注意力窗口，再聰明的模型也會讓體驗變鈍。
Architecture notes
讓體驗真的順的三個工程條件
一個專門負責即時反應的快模型講者提到小模型若部署平台 P95 latency 高，仍然不適合即時互動。需要 Haiku class 或小型 open-source model 負責 soft real-time 回應。
重工作交給非同步大模型快模型先維持對話節奏；需要更深推理時，把工作派給較大模型，再把結果重新 interleave 回即時流程。
不要等完整靜默才送推論傳統語音流程會等使用者停下來，甚至再等一秒 silence。這在一秒預算內太貴，因此要願意每 1-2 秒送出推論。
把 prefix caching 當產品架構若每次請求的 context 前段穩定，就能吃到平台的 prefix caching，讓頻繁推論變得更快、更便宜。
Use this checklist
如果你正在做語音或會議中的 AI agent，先檢查這五點
產品目標是 voice-in / voice-out，還是 voice-in / visuals-out？前者需要接近 200ms 的 conversational loop；後者可以用一秒內的視覺回應先創造自然感。
你量的是平均延遲，還是 P95 / P99 體感？即時互動裡，偶發的 5-10 秒回應會直接破壞信任；小模型也必須搭配低延遲 inference 平台。
你的 agent 是否能在不中斷人的情況下回應？會議場景中，最好的回應常是建立 issue、更新畫面、顯示狀態，而不是用聲音打斷對話。
推論是否能在使用者仍說話時提早開始？如果流程必須等完整句子與長靜默，延遲預算很快就用完。要把 partial intent 當一等公民處理。
context 是否穩定到能吃 prefix cache？長跑 agent、常駐會議 agent、頻繁觸發的 assistant，都應設計穩定 context 前綴與少量變動尾段。
Source video