一個真正動手做事、而不只是回答問題的助理

讓我們完整走過一次真實互動,因為抽象的說法——「一個會行動而不只是回答的助理」——在你親眼看到之前並不能說明什麼。有人在本站每個頁面浮動出現的 Ask-AI 按鈕中輸入「幫我做一個有連續紀錄的習慣追蹤器」。以下是從這句話到實際運作的建置之間,實際發生的事——以及我們選擇在哪裡把人的手重新放回方向盤上。

這句話

九個字,沒有標點符號,沒有選單導覽,甚至不知道建構工具在哪個頁面。這就是輸入內容,而且和這個系統收到的大多數請求形狀相同:不是指令,而是一個願望。沒有人會這樣說:「打開建構工具,把專案命名為 Habit Tracker,在提示欄填入連續紀錄追蹤的描述,然後把焦點移到開始按鈕上。」他們只會直接說出自己想要什麼存在。這兩種說法之間的落差——願望 vs. 指令——正是這個功能的全部核心。

解析

不論那句話是用什麼語言輸入,都會用同一種語言處理——我們在整個產品中支援二十種語言,呼應平台更廣泛的多語言定位,而助理並不是在固定的英文腳本上疊加一層翻譯,而是直接用你輸入的語言原生推理。針對「有連續紀錄的習慣追蹤器」這個具體例子,解析必須同時完成三件事:

• 辨識這是一個建置請求,而不是一個提問
• 擷取一個專案名稱
• 擷取足夠的規格內容,讓提示欄不至於空白

只要其中任何一項出錯,使用者就會落在一個與他們原本要求不符的建構工具畫面上,這比完全不採取行動還糟——因為現在他們得先發現這個落差,再修正它,然後重新來過。

暫存畫面

這部分在展示時很容易被輕描淡寫,實務上也很容易做錯:它並不會直接啟動建置。它只是打開建構工具,專案已命名、提示欄已填好文字,執行動作只差一次點擊。這是一個刻意設下的停頓點,不是因為沒時間做完而抄的捷徑。開啟頁面和預先填好表單,就算猜錯了代價也很低——最糟的情況,你只需要修改文字或關掉分頁。所以助理就直接執行,不會跳出確認對話框,也不會問「你確定要跳轉嗎」。

仍屬於你的那一次點擊

那次仍然屬於你的點擊

我們是在反覆討論之後才定案的,老實說兩個極端都不算明顯正確。如果每個動作都要確認,那等於是把舊有「點三層選單」的體驗重做一遍,只是外面掛了個聊天視窗,反而比原本更糟。如果什麼都不確認,遲早解析會在模糊的請求上猜錯,然後花別人的錢啟動一次沒人要求的執行。就這個例子而言,結果是:助理一次就能帶你到已載入好的建構工具畫面,而真正會花錢的按鈕,仍然是一次真實、經過深思、由人親自按下的點擊。

背後的基礎架構

這個流程中有一件事你完全看不到,而這正是它重要的原因:整個過程——導覽、暫存的提示、最終的建置——都只發生在你的工作區內,不會涉及其他任何人的工作區。不論請求怎麼措辭,助理都無法被說服跨越租戶邊界,因為它並不是一個坐在權限系統之外、特別處理的聊天功能——就機制而言,它只是平台上的另一個代理,運作在和其他所有代理一樣的單一帳戶邊界之下。不存在「聊天機器人能不能看到這個」這種另外要回答的問題,因為在這個聊天功能存在之前,答案早已由基礎架構決定好了。

不會發生的事

順著同一個例子再往前走一步，就會碰到助理在沒有提示下願意做到的極限，而值得明確說明這條界線究竟在哪。它會為你打開建置工具。除此之外：

• 它不會花費超出你已核准的金額
• 它不會以你的名義將完成的專案發佈到任何地方
• 它不會採取任何離開你自己工作區沙盒、觸及外部世界的動作

整個這類動作都沒有助理代辦的路徑——不是更嚴格的確認，而是根本沒有這條路。如果你想公開一個專案，那仍然是你自己要找到並按下的按鈕，一如既往。

為什麼停止點設在這裡，而不是設在更保守的地方

我們原本可以讓每一個步驟都要求許可，並稱之為謹慎。但我不認為那是謹慎——我認為那只是把這個功能原本要去除的瑣碎作業，變成更慢的版本而已。一個只會描述建置按鈕在哪裡的聊天機器人，就算判斷錯誤，影響範圍也很小：浪費三十秒，你稍微惱怒，什麼都沒花掉。而一個會實際安排建置的助理，如果護欄沒設好，出錯的代價就高得多——這正是「花費前需確認」這條界線存在的真正原因：不是我們為了顯得負責而加上的權宜之計，而是我們看清失敗會落在哪裡，才把停止點精準設在那裡。在那條界線之前的一切——讀懂你的句子、備妥畫面、讓你只差一次點擊就完成——完全不需要許可，因為沒有任何一步會傷害到你。