這兩天在技術圈討論度頗高的開源項目 Rowboat，本質上是對 Anthropic 和 OpenAI 目前產品邏輯的一次反叛。我們已經習慣了那種「發送、等待、閱讀」的往復循環，但這種模式正在產生一種隱性的勞動不對稱。當你把會議記錄、Jira 票據和程式碼全部塞進 Claude 或 ChatGPT 的 Context Window，它吐出來的東西往往只是創造了更多需要你閱讀的文字。我們在處理資訊，而 AI 在製造資訊，這種天平傾斜讓所謂的「生產力工具」變得像是在餵食一頭永遠吃不飽的野獸。Rowboat 嘗試把 Claude 的能力從那個狹窄的聊天氣泡裡解放出來，讓它變成一種「工作平面」而不是「聊天對象」，這件事本身就很有趣。
在目前的四大平台中，Google 的 Gemini 其實是最有本錢處理這種「非對話式」工作流的。Gemini 的優勢在於它對 Google Workspace 的原生整合，理論上它不應該只是側邊欄的一個分身。當我們在處理長達數十萬 token 的專案文檔時，Claude 3.5 Sonnet 的 Artifacts 功能雖然驚艷，但它依然被困在一個「預覽窗格」裡。你無法在那個窗格裡直接調用複雜的系統級 API，它更像是一個精美的展示櫥窗。相比之下，Rowboat 這類工具想做的，是讓 AI 直接成為 IDE 或生產力套件的骨架，而不是一個住在裡面的房客。
技術層面上，這牽涉到 Context 的管理哲學。ChatGPT 目前的做法是透過「專案」資料夾來組織對話，讓使用者手動選擇要餵給模型哪些檔案。這在處理單一任務時很有效，但一旦進入跨專案的協作場景，這種以「對話」為核心的架構就顯得捉襟見肘。Rowboat 提出的 local-first 概念，實際上是想繞過雲端平台對資料流向的控制。如果你把所有的筆記和程式碼都索引在本地，透過 API 調用 Gemini 1.5 Pro 的百萬級長文本能力，你得到的就不再是一段建議，而是一個能夠即時反映你工作狀態的動態儀表板。
提到技術細節，很多人會拿 DeepSeek 的 API 成本來做對標。但在實際的開發場景中，Google 的 function calling 穩定性在面對複雜工具鏈時，表現通常優於這類後起之秀。當你在 Rowboat 這種自定義工作平面中設置超過二十個不同的工具接口時，Gemini 處理參數邏輯的細膩程度，往往決定了這個平面是真能運作，還是只會噴出一堆報錯代碼。相較於 DeepSeek 最近在開發者社群引發的討論，Gemini 這種大廠在基礎建設上的穩定性，才是這類第三方介面敢於嘗試「本地優先」的底氣。
然而，這類工具的出現也暴露出一個尷尬的現實：四大平台在介面創新上的停滯。ChatGPT 出了 Canvas，Claude 有了 Artifacts，但它們依然沒有跳出「對話框」的邏輯。它們假設使用者的所有問題都能透過一段文字來啟發，並透過另一段文字來解決。可是當我們在處理複雜的架構設計或長期的知識管理時，文字對話的效率其實極低。Rowboat 這種把「工作表面」當作主要產出物的設計，是對 Grok 那種追求即時、混亂且碎片化的社交媒體風格最極端的反向修正。Grok 追求的是情緒與資訊的瞬間碰撞，而我們現在需要的，可能是一個能安靜幫我們理清 Jira 混亂狀態的沈浸式環境。
這種「不對稱的努力」最終會把我們帶向哪裡？如果每個人都用 Claude 寫出更長的報告，而每個人又都用 Gemini 來總結這些報告，我們是不是只是在幫雲端服務商刷 token 消耗量而已。當開源社群開始試圖接管 UI，把主動權從 Anthropic 或 OpenAI 手中奪回時，這是否意味著我們對「聊天機器人」的耐心已經耗盡？
如果未來的工作介面不再是一個對話框，而是一個會根據當前任務自動重組的動態畫布，那麼現在這些拼命優化對話語氣的模型開發商，是不是從一開始就選錯了戰場？