過去一年發生了一件奇怪的事。
AI 在開發軟體方面變得超乎想像地強大。
但不知為何，產品卻開始變得越來越千篇一律。
這聽起來很矛盾。
模型變得更聰明。Agent 變得更強。上下文視窗大幅擴展。開發者的生產力大幅提升。
然而，如果你最近瀏覽過 Product Hunt、獨立開發者的產品發表，或是 AI 新創的展示，你可能也注意到了同樣的模式。
不同的創辦人。
不同的產品。
不同的產業。
但介面卻開始詭異地相似。
同樣的卡片。
同樣的儀表板。
同樣的版面配置。
同樣的視覺層級。
同樣的「AI 生成的 SaaS」美學。
程式碼能運作。
但前端卻不令人印象深刻。
我認為這是因為大多數開發者專注在一個已不存在的問題上。
生成程式碼。
今天，生成程式碼很容易。
生成一個真正有設計感的前端則困難得多。
大多數現代的 AI 工作流程已經長這樣：
用 Claude Code 做規劃。
用 Cursor 做實作。
發佈。
重複。
老實說，這已經強大到能以比以往更快的速度打造產品。
Claude Code 已成為我思考架構、拆解系統、構思該建什麼的首選工具。
Cursor 仍是將這些想法轉化為可運作軟體的最佳環境之一。
這兩個工具都不是問題。
事實上，它們正是軟體開發變得如此驚人快速的原因。
問題發生在程式碼生成之後。
那時，前端品質變成了一個完全不同的挑戰。
我看了越多產品，就越意識到一個可運作產品和一個優秀產品之間的差距，往往不再是功能。
而是打磨。
是一致性。
是設計決策。
是脈絡。
這正是我開始對前端原生工作流程感興趣的原因。
當我第一次看到這個工作流程的視覺化呈現時，它完美地捕捉了我對現代 AI 開發的思考方式。
Claude 幫我思考。
Cursor 幫我建構。
但「可運作的軟體」和「生產級產品」之間仍然缺少一個環節。
這就是 Kombai 試圖解決的。
不是取代任何一個工具。
而是填補一個它們都不是為了解決的缺口。
解釋這個最簡單的方法就是一個簡單的問題：
為什麼 AI 生成的前端看起來還是 AI 生成的？
不是全部。
但數量多到通常幾秒內就能認出來。
這很少是因為程式碼寫得差。
問題通常更深層。
大多數 AI 工具理解提示詞。
前端工程師理解系統。
這個區別聽起來很小。
其實不然。
一位資深前端工程師看到一個按鈕時，想的不是：
「這是一個按鈕。」
他們想的是：
這是哪個元件？
它使用了哪個設計 Token？
其他地方已經有這個了嗎？
它符合字體層級嗎？
它屬於設計系統嗎？
這個模式可以重複使用嗎？
這些問題創造了一致性。
而一致性創造了品質。
最好的前端不是元件的集合。
它們是決策的集合。
而這些決策會隨著時間累積。
我認為這正是大多數 AI 工作流程今天崩潰的地方。
生成的版本通常能運作。
生產級版本則感覺有設計感。
生成的版本滿足了基本要求。
生產級版本建立了信任。
而這兩種結果之間的差異通常不是更多程式碼。
而是更多的脈絡。
- 設計模式：從介面開始，而非從實作開始
我每個用 AI 工具建立的前端專案，起手式都一樣：提示 → 程式碼 → 重整 → 重複。
Kombai 的設計模式完全翻轉了這個模式。
你不是從實作開始，而是從介面本身開始。你在一個無限畫布上工作——構思版面、迭代元件、調整視覺決策——而 AI 擁有真正的創意品味。
輸出的成果看起來不像預設的 Tailwind 模板，也不像 shadcn 的樣板。它看起來像是經過設計的東西。
為什麼這很重要：這些設計並未與你的程式碼庫脫節。它們就存在於你的儲存庫中。
這就引出了下一件讓我真正驚訝的事。
- 改變一切的四方同步
大多數 AI 工作流程在設計與程式碼之間存在一道堅固的牆。
你在某處設計（Figma、v0 或其他），在另一處實作（Cursor、Claude Code）。然後你就永遠待在第二層，透過編輯檔案和重整瀏覽器來進行修改。
Kombai 打破了這道牆——而且是全方位地打破。
你的設計、程式碼和渲染後的 UI 都一起存在於你的儲存庫和 IDE 中。你可以編輯其中任何一項，其餘部分只需點擊一下就能更新。
這在實務上意味著什麼：
畫布上的設計 → 儲存庫中的程式碼
你的畫布和設計是以程式碼形式建立的，並且存在於你的儲存庫中。因此，你可以在提示詞中使用 @ 直接引用它們，將它們的脈絡引入任何任務，並直接從它們生成生產級程式碼。想從設計中的一個元素建立新元件？把 Agent 指向它。想更新 Token 以符合新設計？一個提示詞就搞定。
儲存庫中的程式碼 → 畫布上的設計
Kombai 的設計模式隨時擁有你儲存庫的完整脈絡。所以你也可以反向操作——使用你現有的程式碼來產生新設計。想為你的產品輪播建立變化版？叫它把那個元件複製到畫布上並生成創意版本。想設計一個已經存在於你程式碼庫中的模態框的最大化狀態？它已經知道模態框長什麼樣子。
在瀏覽器中編輯渲染後的 UI → 儲存庫中的程式碼
在 Kombai 瀏覽器中打開你正在執行的應用程式的任何部分。像在設計工具中一樣視覺化編輯文字、樣式和版面。然後一鍵將這些編輯內容發送給 Agent，它就會在你的實際程式碼中實作它們。
不再需要在瀏覽器、檢查器和程式碼編輯器之間切換。你看到它，修好它，就完成了。
瀏覽器中的渲染 UI → 畫布上的設計
使用網頁捕捉功能，將你即時 UI 的任何部分直接發送到你的設計畫布。適用於在 localhost 上執行的頁面以及你儲存庫外部的 URL。之後你可以對它們進行迭代、生成變化版，或透過在提示詞中引用它們來作為靈感。
這不是展示用的技巧。這是前端工作一個根本不同的心智模型。
不再是「程式碼 → 重整 → 檢查 → 重複」，你是在同一個真相的三個視角中工作——而且你可以從任何一個進入或離開。
回饋循環變得非常短。而當你每天要做幾十個前端決策時，這會快速累積。
- 生產級程式碼，真正重複使用你現有的系統
Kombai 內部最有趣的想法之一，聽起來簡單但意義深遠。
它在生成任何東西之前，會先理解你的技術棧。
大多數 AI 生成的前端錯就錯在這裡。
它們在已有現成元件時生成新元件。它們在設計系統已有 Token 時建立新 Token。它們緩慢地、不知不覺地增加不一致性，直到程式碼庫感覺像是五個不同團隊建造的。
Kombai 會先查看你現有的元件、Hook 和 Token。然後重複使用已經存在的東西。
一位資深前端工程師不只是寫新程式碼。他們會問：這個已經存在了嗎？我應該重複使用某個東西嗎？這符合我們已經建立的模式嗎？
這就是 Kombai 試圖編碼的思考方式。
這張圖可能比任何行銷頁面更能說明問題。
大多數 AI 工具看到的是指令。
Kombai 試圖理解這些指令所在的環境。
而隨著專案變大，這個差異變得越來越有價值。
因為現在沒有人會為生成一個元件而苦惱。
挑戰在於生成第一百個元件時不破壞一致性。
挑戰在於新增功能時不慢慢侵蝕設計系統。
挑戰在於快速前進的同時維持前端品質。
這就是脈絡開始成為競爭優勢的地方。
我現在使用的完整技術棧
以下是三個工具實際分工的方式：
Claude Code → 架構、規劃、思考該建什麼以及為什麼。
Cursor → 實作，將計畫轉化為可運作的軟體。
Kombai → 設計、前端打磨，以及在專案擴展時保持介面一致。
每一層都有明確的工作。沒有任何一個試圖取代其他。
過去一年我最大的體悟是，未來可能不屬於單一 AI 工具。
它屬於 AI 技術棧。
專門的工具解決專門的問題。每一層都做它真正被設計來做的事。
Claude Code 沒有試圖變成 Figma。Cursor 沒有試圖變成設計系統。Kombai 也沒有試圖變成通用程式碼助手。
最強大的工作流程發生在每一層都有明確責任的時候。
一個工具幫你推理。
一個工具幫你實作。
一個工具幫你打磨。
而三者結合，產出的成果遠比任何單一工具獨自運作要優秀。
這張圖完美捕捉了這個區別。
建構和打磨是不同的技能。
建構讓軟體能運作。
打磨讓使用者信任它。
建構創造功能。
打磨創造體驗。
建構讓人們願意嘗試產品。
打磨讓他們願意回來。
多年來，打磨很昂貴，因為它需要高度專業的前端人才。
AI 開始改變這一點。
不是取代前端工程師。
而是讓前端脈絡更容易取得。
這最終就是 Kombai 引起我注意的原因。
不是因為它能生成程式碼。
現在每個 AI 工具都能生成程式碼。
不是因為它取代了 Cursor。
它沒有。
不是因為它取代了 Claude Code。
它也不該。
有趣的部分在於，它專注於大多數 AI 工具大致忽略的軟體開發層面。
前端脈絡。
而當 AI 生成的軟體成為常態時，脈絡可能成為整個工作流程中最有價值的資產之一。
如果要用一句話總結我目前的工作流程，那就是：
Claude Code 幫我思考。
Cursor 幫我建構。
Kombai 讓前端感覺有設計感。
而現在軟體開發中最大的轉變，不是 AI 越來越會寫程式碼。
而是我們終於意識到，程式碼從來就不是全部工作。
產品是系統。
介面是系統。
設計是系統。
前端品質是系統。
而在未來幾年勝出的工具，可能不是那些生成最多程式碼的。
而是那些理解最多脈絡的。
這就是為什麼我對前端原生工作流程越來越感興趣。
不是因為它們取代了技術棧的其他部分。
而是因為它們讓整個技術棧更好地協同工作。
而在一個每個人都能生成軟體的世界裡，這個差異可能比以往任何時候都更重要。
立即試用 Kombai：https://kombai.com/
