ADVERTISEMENT
我常說，本人相信生成式人工智慧是重大技術變革，至少跟智慧型手機一樣重大。之所以這麼說，是因為智慧型手機已經無所不在——是許多人醒來看到的第一件和入睡前看到的最後一件東西。
但我做這種比較還有其他原因。比方說：iPhone 剛推出那時候，行動瀏覽器的流量激增，各大公司都在採取措施應對。對大多數公司來說，這意味著要做「m.google.com」、「m.facebook.com」——要把採用現有桌機格式的頁面適配垂直縱橫比。
雖然花了近十年時間，但最後我們還是弄清楚了什麼叫做「原生」的行動體驗。為了實現這個目標，我們得發明全新的互動模式：手指一捏一合表示縮放、下拉去更新螢幕、滑動向前。我們最後開發出Instagram、Uber 以及Strava 等應用程式——在桌面優先的世界裡，這些產品根本不可能存在。
但如今，關於AI 介面，我們正處於類似的轉折點。不過我們的做法不是將桌機電腦的網站塞進手機螢幕，而是將AI 功能強加進聊天視窗。就像「m.facebook.com」未能抓住行動裝置真正潛力，屬於一種妥協一樣，無所不在的聊天機器人介面也在阻礙AI 發揮變革力量。
目前，感覺我遇到的「人工智慧」產品95% 都將聊天機器人整合進現有的SaaS 應用——不過實際上，這個數字應該跟5% 更接近。
對話的認知成本
想理解為什麼聊天機器人介面往往是錯誤選擇的，請看請其基本限制。最明顯一點：這會為使用者帶來認知負擔。
想像一張包含不同AI 功能的圖表，衡量的兩個維度：「能產生多大影響/價值？」，「有效使用該功能會多燒腦？」理想情況下，你希望工具影響夠大，同時又幾乎不需要主動思考。就大語言模型（ LLM ）而言，影響很大，但使用的認知負荷也很高。
想像一下用ChatGPT 產生一些程式碼（不是用花俏的AI 程式碼編輯器）。其輸出有一個需要修復的錯誤。在用聊天機器人介面的情況下，你得：
- 將整個檔案複製（或產生）到聊天視窗中
- 解釋你要修復的錯誤（或你想變更的那一行程式碼）
- 等待整個檔案重新生成
- 翻看變更的內容
- 確認沒有其他內容被無意修改或產生幻覺
- 將結果複製回程式碼編輯器
這……本來該是一次很簡單的編輯，卻要做這麼多工作。如果你反覆調整程式碼或嘗試讓ChatGPT 幫你調試，這可能意味著你得一次次檢查看有沒有幻覺或繞過「... the rest of the code here ...」這種問題。
對於新的使用者來說，還有可用性的問題（或缺乏可用性）。目前，對新的LLM ，我大致知道對它的預期是什麼，但不是每個人都知道。挑戰不僅在於聊天機器人是通用的——還在於它們幾乎沒有給使用者任何關於其能力或限制的線索。如果沒有明確的UI 指示，使用者只能猜測什麼是可能的，什麼是不可能的。
我特別欣賞Amelia Wattenberger 的說法：
好的工具會讓人清楚知道該怎麼用。更重要的是，知道不該怎麼用。說到好手套，我們馬上就會明白應該如何用它們。因為它們是手的形狀！我們知道把它們戴在手上。而具體的材料會告訴我們更多：金屬網手套用於防止物理傷害，橡膠手套用於防止化學傷害，皮手套用來開摩托車看起來會很酷。
不妨比較一下典型的聊天介面。我們收到的唯一線索是應該在文字方塊輸入的字元。而這個介面跟Google 搜尋框、登入表單以及信用卡欄位看起來沒什麼兩樣。
幸運的是，電腦介面已經有50 年的歷史了，而我們找到了解決這個問題的方法也有40年了。
直接操縱：40 年前的解決方案
為了幫助更好地理解為什麼聊天機器人的使用者體驗有問題，我想討論一個20 世紀80 年代的概念：直接操作介面。四十多年前由Ben Schneiderman 提出，這些介面具有以下幾個關鍵特徵：
- 連續的物件表示：使用者可以在螢幕上看到可以與之互動的物件的視覺表示。
- 實體操作：使用者不需要使用複雜的語法或指令，而是可以透過點擊、拖曳或捏合等物理動作與物件互動。
- 快速、增量及可逆的操作：使用者可以快速執行操作、立即查看結果，並輕鬆復原或修改其操作。
- 即時回饋：使用者操作的效果立即顯示在螢幕上，即時確認結果。
在當今世界，這意味著諸如拖放、調整視窗大小、音量滑桿、捏合縮放等互動。聽起來似乎稀鬆平常，但如果沒有確實的發明出來，這些就不會存在。
我們仍在開發鼓勵以新方式直接操作的軟體。比方說，Figma 讓畫布的每個物件都可選擇，並拖曳控鍵和滑桿時更新屬性。你可以全心投入正在設計的媒體。
類似地，Notion 採用了「塊」這個核心概念，並用它來創建有形的、可塑的檔案。你可以拖曳區塊來重新組織不同的部分，或轉換成不同的輸出類型。
目前許多人工智慧介面所面臨的挑戰是忽略了上述原則。哪些指令行得通並不明顯。變更往往是全改完或一點都不動，而不是漸進性的。回饋不可預測且經常延遲。而且動作不容易復原。
要說清楚的是，我這裡不是建議要完全放棄掉自然語言互動這種方式。相反，我們需要在對話與直接操作之間找到適當的平衡。有時候，你想討論文件的結構；有時候，你只想改寫一句話。
一個關鍵洞察，不同的任務需要不同的互動模型。正如Figma 用直接操作進行視覺設計，但仍為進階使用者保留指令面板一樣，AI 介面需要精心融合多種互動模式以及對內容進行抽象的手段。
調整抽象的層次
為了探索如何超越聊天機器人這種介面，我們可以研究不同互動模型在實踐中是如何協同的。以AI增強的程式碼編輯器Cursor為例，它展示了不同的抽象層面如何在一個介面下共存的：
- 在最低的層面，cursor提供了逐字符的程式碼補全。這幾乎沒有什麼認知負擔——沒有上下文切換，無需構思提示詞，也不會打斷你的工作流程。
- 在更高一個抽象層面，他們有內嵌的程式碼產生功能。在需要編寫新函數或元件時，你可以用自然語言描述想要的內容，並直接在需要的位置產生。其關鍵在於，結果以「差異」（diff）形式呈現——你可以準確地看到新增或修改的部分，並逐一接受變更。
- 在最高抽象層面，他們提供了側邊欄對話框，可用於處理更複雜的任務，比方說分析架構或調試問題。但即便在這裡，介面也不僅僅是一個通用的聊天機器人。 AI能理解程式碼庫的上下文，可以引用特定檔案和函數，並提出可以直接預覽和應用的變更建議。
重要的是，這些不僅是不一樣的介面——更是針對不同任務規模的合適介面。在自動補全變數名稱時，你不需要靠聊天對話解決；但要理解一個複雜演算法時，你可能確實需要跟機器聊聊。
而且確保所有變更都由一個經過微調的模型篩選，來產生差異，這意味著無論程式碼建議來自哪裡，都可以透過統一的介面進行審查和接受變更。
這種「層次化的抽象」模式可應用的地方遠不止於程式碼編輯器。想像如果人工智慧寫作工具應用類似原則的話：
- 字符級建議，用於文案編輯和改寫
- 句子級分析，關注論點和清晰度
- 段落級建議，優化主題和邏輯流
- 文件級回饋，評估結構和主題
- 所有變更均以具體、可逆的差異對比形式呈現
Maggie Appleton 在探索AI寫作工具的潛力方面進行了出色的探索。假設ChatGPT可以在各種編輯「角色」之間切換會怎麼樣？或者如果發展一個工具對收集證據或強化論點的過程進行結構化呢？
超越聊天機器人時代
好消息是，我們已經開始看到新型AI產品取得了實際進展。 Shortwave，一款AI驅動的郵件使用者端，透過按鈕、快捷鍵以及基於上下文的建議，將AI操作深度整合到其使用者介面中。而Cove，一個用於AI協作的可視化工作空間，正在賦予AI直接進行操作的能力。
我對基礎模型開發者原生地引入這些想法也感到樂觀。比方說，ChatGPT新的Canvas功能如今就提供了更好的直接操作方式，並基於你是在寫程式碼還是寫文字提供了不同的專用工具。其快速操作選單尤其是一個極佳的案例，從中可以看出如果我們針對具體使用場景利用大語言模型的力量能取得什麼樣的成果。
我深信，AI介面的未來不會是更好的聊天機器人，AI介面的未來要看精心設計、面向特定領域的工具，這些工具能讓AI的能力更直覺、更可操作。實現這一目標需要設計師和工程師們共同學習與成長。
產品設計師必須超越聊天機器人的範式，思考如何為特定使用者量身訂做AI能力。當我們仍在摸索AI能做什麼，且技術不斷演變時，這項任務會極具挑戰性。如何為下個月可能出現的新功能設計介面？從使用者體驗的角度來看，一個擁有更多自主AI的世界會是什麼樣的呢？
工程師也面臨自己的挑戰。開發這些新介面需要熟悉新興的AI技術堆疊—包括思考防護措施、檢索增強生成（RAG）管道、緩解幻覺問題、串流反應等。
正如我們從m.google.com轉型到Instagram和Uber一樣，我們正處於從通用聊天介面轉型為AI原生體驗的關鍵節點。未來的這些體驗究竟是什麼樣子，時間會給出答案，但前進的方向已經清晰：我們需要設計能讓AI的力量更加直觀、易用、並可直接操作的介面。
請注意！留言要自負法律責任，相關案例層出不窮，請慎重發文！