不要為人類設計軟體了——OpenClaw 作者談 AI 時代的軟體設計範式

本文整理自 TBPN（The Block Party Network）2026 年 1 月 28 日播出的訪談，由 John Coogan 主持，訪問開源 AI 助手 OpenClaw 作者 Peter Steinberger。這個專案在短短數週內經歷了三次更名（Clawdbot → Moltbot → OpenClaw），目前 GitHub 星數已突破十萬。

一個聽起來瘋狂的建議

Peter Steinberger 在訪談中用了一句話，概括他建造 OpenClaw 整套技術架構的核心原則：不要為人類設計，要為模型設計。

他舉了一個很具體的例子。當他幫自己的 AI 助手建造各種工具時，如果模型需要一個 --log 參數，他就建一個真的叫 --log 的參數。不是建一個漂亮的 Web 儀表板讓人類去點，而是建一個 AI 模型預期會存在的命令列介面。因為模型的訓練資料裡充滿了 Unix 命令和 CLI 工具，它們對這種介面的理解遠比對任何 GUI 都深。

這不只是一個工程上的偏好。Peter 認為這是一整套新的軟體設計思維：過去五十年，軟體設計的核心問題是「人類怎麼用」；接下來的十年，核心問題會變成「AI 怎麼用」。

為什麼 AI 更懂 CLI

Peter 在 OpenClaw 裡幾乎沒有用 MCP（Model Context Protocol），而是把所有功能包成獨立的 CLI 工具。Google 日曆有 CLI、Sonos 音響有 CLI、居家監視器有 CLI、連智慧床都有 CLI。他在建造 OpenClaw 之前，花了好幾個月就在寫這些小型命令列工具。

他的解釋是這樣的：AI 模型認識 Unix。你的電腦上可以裝一千個小程式，模型只需要知道程式的名字。它去呼叫 help 選單，讀完就知道怎麼用了。整個互動模式和 Unix 的管線（pipe）哲學完全吻合——每個工具做一件事，透過標準輸入輸出串接。

這種設計讓 OpenClaw 的能力隨著工具數量線性成長。每多一個 CLI，助手就多一項技能。而且這些工具之間可以自由組合——模型可以決定先呼叫 A、把結果餵給 B、再根據 B 的輸出決定要不要呼叫 C。這種彈性是 MCP 之類的框架做不到的。

更重要的是，這些 CLI 不需要額外的文件。模型第一次呼叫一個不熟悉的 CLI 會失敗，但它會讀到 help 訊息，然後第二次就成功了。Peter 說這個「失敗一次、學會一次」的迴圈大概只需要十五秒，但換來的是一個乾淨的 context——不需要在 session 啟動時就把所有工具的完整說明塞進去。

那個語音訊息的故事

訪談中最能體現「為模型設計」這個哲學的案例，是 Peter 在摩洛哥馬拉喀什的經歷。

他當時在旅行途中用 WhatsApp 跟自己的 AI 助手對話。某一次他沒有多想，直接傳了一則語音訊息。但他從來沒有在系統裡建過語音訊息的處理功能。

他看到「正在輸入」的指示燈亮了，十秒後收到一條正常的回覆。

事後他問 AI 怎麼做到的。AI 的回答是這樣的：你傳了一個訊息，但裡面只有一個檔案連結，沒有副檔名。我檢查了檔案標頭，發現是 Opus 音訊格式。我用你 Mac 上的 FFmpeg 把它轉成 Wave。本來想用 Whisper 做語音辨識，但你沒裝，而且安裝報錯了。不過我在你的環境變數裡找到了 OpenAI 的 API key，就用 curl 送到 OpenAI 的語音轉文字服務，拿到文字後回覆你了。

Peter 說這是他的頓悟時刻。他用的措辭是：這些東西是極度聰明、足智多謀的野獸——只要你給它們足夠的權力。

而它之所以能做到這一切，正是因為 Peter 的系統是為模型設計的。FFmpeg 是一個 CLI 工具，AI 知道怎麼用。curl 是一個 CLI 工具，AI 知道怎麼用。環境變數是一個標準的 Unix 概念，AI 知道去哪裡找。整個問題的解決過程，AI 沒有用到任何為人類設計的介面——沒有按鈕、沒有選單、沒有設定頁面。它用的全部是底層的命令列工具和系統慣例。

如果 Peter 當初把語音處理包成一個精美的 Web API、或是一個有圖形介面的 App，AI 反而不知道怎麼用。正是因為底層全都是模型能理解的 CLI 和 Unix 工具，AI 才能在遇到全新情境時，自己拼出一條解決路徑。

我的觀察

MCP 的尷尬處境

Peter 的觀點放在更大的產業脈絡下看，有一個微妙的諷刺：Anthropic 傾全力推動的 MCP 標準，正在被使用 Anthropic 自家模型建造爆紅專案的開發者公開質疑。

MCP 的設計初衷是合理的——提供一個標準化的協定，讓 AI 模型能用一致的方式呼叫各種外部工具。這對生態系的建構有明顯的好處。但 Peter 的實踐揭示了一個 MCP 目前沒有解決的問題：模型和工具的互動不只是「呼叫和回傳」，還包括探索、組合、失敗後重試。

CLI 天然支援這些行為——你可以 pipe、可以 grep、可以用 shell script 把多個步驟串起來。MCP 目前的協定設計是「request-response」模式，每次呼叫都是原子操作，不支援工具之間的即時串接。

這不代表 MCP 沒有未來。MCP 的真正價值可能不在於它的技術架構，而在於它推動了一件事：讓更多公司願意為 AI 提供結構化的 API。Peter 自己也承認這一點。但如果 MCP 想要成為 AI 工具互動的通用標準，它可能需要從 CLI 的設計哲學裡借鑑更多東西——特別是可組合性和漸進式學習。

Unix 哲學的意外復興

Peter 的設計選擇帶出了一個更大的歷史弧線：1969 年在貝爾實驗室誕生的 Unix 哲學，在 2026 年的 AI 時代竟然比過去二十年的任何時候都更有生命力。

Unix 哲學的核心是三條原則：每個程式做一件事而且做好它；程式之間透過文字流串接；用小工具的組合取代大型整合系統。這套哲學在圖形介面時代被邊緣化了——普通使用者不碰命令列，企業軟體走向「大而全」的整合平台。

但 AI 模型天然偏好 Unix 的工作方式。它們的訓練資料裡有大量的命令列操作、shell script、管線組合。當一個 AI agent 需要完成一個複雜任務時，它的本能反應不是「找一個什麼都能做的大工具」，而是「把幾個小工具串起來」。

這意味著一件有趣的事：過去二十年，軟體產業追求的是整合——Slack 要做成協作平台、Notion 要做成全能工作空間、Salesforce 要把所有企業流程塞進一個系統。但在 AI agent 的世界裡，那些小而美、功能單一、介面簡潔的 CLI 工具，可能比巨型平台更有價值。

這不是復古情懷。這是因為 AI 改變了「使用者」的定義。當軟體的主要使用者從人類變成 AI 模型，設計範式就必須回歸到模型最擅長操作的介面——而那恰好是半個世紀前 Unix 工程師設計出來的東西。

「為 AI 設計」是一門全新的設計學

Peter 在訪談中輕描淡寫地說了一句「為模型思考方式設計」，但這句話的含意如果展開來，足以催生一個全新的設計領域。

過去幾十年的軟體設計，核心關注的是人類的認知模型：人類怎麼理解導航結構、怎麼處理視覺層次、怎麼在多個選項中做選擇。整個 UX 設計學科就是建立在「人類是使用者」這個前提上的。

但 AI 模型的「認知模型」和人類完全不同。模型不需要視覺層次，因為它不看畫面。模型不需要導航結構，因為它可以直接呼叫任何端點。模型不需要「簡化選項」，因為它可以同時處理數百個參數。模型需要的是：明確的輸入輸出格式、可預測的行為模式、豐富的錯誤訊息（讓它能從失敗中學習）、以及可組合的模組化介面。

這些需求和傳統 UX 設計的原則幾乎完全相反。好的人類介面追求「隱藏複雜度」，好的 AI 介面追求「暴露所有能力」。好的人類介面追求「減少選項」，好的 AI 介面追求「提供最大彈性」。好的人類介面追求「防止錯誤」，好的 AI 介面追求「讓錯誤可診斷」。

我們正處在一個轉折點：軟體的主要「使用者」正在從人類轉移到 AI 模型。這不是說人類不再使用軟體——而是越來越多的軟體互動會透過 AI 中介來完成。人類對 AI 說需求，AI 去操作軟體，軟體把結果回傳給 AI，AI 再把結果翻譯成人類能理解的形式。

在這個架構裡，軟體的介面需要同時服務兩種截然不同的「使用者」：面向人類的部分繼續用 UX 設計原則，面向 AI 的部分需要一套全新的設計語言。Peter 用他的 CLI 工具庫示範了後者的雛形，但這只是一個開始。

當「為 AI 設計軟體」從一個人的實驗變成一門系統性的學問，它會影響從 API 設計、錯誤處理、文件撰寫到系統架構的每一個層面。這可能是 AI 時代最被低估的設計革命——不是 AI 能做什麼設計，而是我們該怎麼為 AI 設計。