Skip to content
Go back

從介面膨脹到回歸本質:Claude Code 的設計哲學

Edit page

*摸索

過去幾年,我一直在使用各種開發工具。從 VSCode 到 JetBrains 系列,從 Notion 到各種專案管理平台,每個工具都有精心設計的圖形介面。按鈕、選單、面板、視窗,層層疊疊。

這些介面看起來很美,功能也很完整。但我開始注意到一個問題:我花越來越多時間在「找功能」上。某個設定藏在哪個選單的第三層?這個操作要點哪個按鈕?介面越豐富,認知負荷越重。

當介面成為理所當然,我們是否思考過:這些層層包裝的 UI 真的必要嗎?

直到我開始接觸終端機指令,才發現原來很多操作可以如此直接。git commitnpm run buildssh user@server,沒有多餘的點擊,沒有隱藏的選單,所有邏輯都在文字指令中清晰呈現。

但我當時並沒有深入思考這件事。直到 Gemini 3 發表,以及 Claude Code 正式推出。

*實驗

Gemini 3 展現了多模態 AI 的成熟度。它不只能看懂圖片、影片,更重要的是它能「理解脈絡」。這種理解能力讓我開始思考:如果 AI 能理解複雜的脈絡,那它是否也能理解系統層級的操作?

然後我看到 Claude Code 的設計選擇:它選擇從終端機作為起點。

這個選擇一開始讓我困惑。為什麼不像 Cursor 或 GitHub Copilot 那樣,做成 IDE 外掛?為什麼要回歸到看似「原始」的終端機介面?

我開始試著從不同角度理解這個決策。我發現:

這讓我想起一個更深層的事實:電腦上所有的操作,最終都會回歸到終端機執行的指令層級,甚至更底層,那些邏輯晶片、運算晶片、記憶體上的運作。

圖形介面只是一層包裝。當 AI 的多模態能力足夠成熟,它可以直接理解並執行終端機指令時,那層包裝的必要性就開始動搖。

*得失

在嘗試用 Claude Code 工作一段時間後,我發現了一些有趣的變化:

收穫

代價

但更重要的發現是:這不是「終端機 vs GUI」的二元對立,而是重新定義介面的必要性

情境過去的假設現在的理解
檔案管理需要視覺化檔案總管lstree 配合 AI 理解就夠
Git 操作需要 GUI 工具才能理解分支git log --graph 配合 AI 解釋更清晰
專案建置需要 IDE 的建置按鈕npm run build 更直接
除錯需要圖形化 debugger終端機 log 配合 AI 分析同樣有效

當 AI 能理解終端機指令的脈絡,能主動建議下一步操作,能解釋錯誤訊息,那麼原本「需要介面才能降低門檻」的假設就不再成立。

*調整

這個觀察讓我重新思考「介面」這件事的本質。

過去我們設計介面,是為了降低使用門檻。不懂指令的人可以點按鈕,不懂參數的人可以看表單。介面是人類與系統之間的翻譯層

但當 AI 的多模態能力成熟到一定程度:

這時候,AI 本身就成為了那個翻譯層

這就是為什麼 Claude Code 選擇終端機作為起點。不是因為終端機「更先進」,而是因為當 AI 能做好翻譯工作時,直接對話底層系統是更有效率的選擇。

介面不是消失,而是被重新定義:

我開始調整自己的工作方式:

  1. 優先思考「我想做什麼」而非「我要點哪個按鈕」
  2. 用自然語言描述需求,讓 Claude Code 轉譯成終端機指令
  3. 把時間花在理解指令背後的邏輯,而非記憶 GUI 的操作流程

*我的轉變

這段探索最大的收穫,不是學會了多少終端機指令,而是思維方式的轉變

過去我習慣依賴介面。看到按鈕就點,看到選單就展開。介面在哪,我的思考就被限制在哪。

現在我開始意識到:電腦上的所有操作,無論表面上用什麼介面,最終都會回歸到系統底層的執行邏輯。那些邏輯晶片、運算晶片、記憶體的運作,才是真正在發生的事。

介面只是一種「呈現方式」,而非「唯一方式」。

當 AI 能扮演好翻譯者的角色,我們可以選擇更直接的路徑:不透過層層介面的包裝,直接用自然語言表達意圖,讓 AI 轉換成系統能理解的指令。

這不是「回歸原始」,而是「跳過冗餘」。

我現在的工作流程變得更流暢。不再需要記住某個功能藏在第幾層選單,不再需要在多個視窗間切換找按鈕。我只需要清楚表達「我想做什麼」,Claude Code 會幫我找到最直接的路徑。

這讓我有更多認知空間去思考真正重要的問題:這個功能該怎麼設計?這段邏輯該怎麼優化?這個架構該如何調整?而不是浪費腦力在「記住工具怎麼用」上。

*What readers can take away


Edit page
Share this post on:

Next Post
老闆、員工與 AGENT:AI 工業化的分工再洗牌