在與 AI 合作開發產品的這段時間，我了解到一件事：要向一般人解釋軟體產品的開發邏輯，其實不需要艱澀的技術術語。一間餐廳的運作，早已示範了軟體開發中所有的關鍵議題。

一般來說，經營小餐廳，可以將餐廳分為「外場」與「廚房」。外場負責服務客人，廚房負責料理。兩者邏輯不同、分工明確，但最終的目標一致 — 讓客人帶著滿意的體驗離開。這正是軟體產品中「前端」與「後端」的縮影。

在開火之前，先決定體驗

在廚房開火、服務生就位之前，有一個核心問題必須先被回答：這間餐廳要為誰提供什麼樣的體驗？

是極致精緻的法式料理，還是輕鬆高效的早午餐店？這個決定將影響一切細節：桌椅的材質、燈光的色溫、菜單的視覺設計，甚至服務生說話的語氣。

這就是設計（Design）的工作。設計不只是「讓畫面好看」，而是在動手開發前，定義出一套一致的風格語言。如果細節彼此衝突，客人進門就會感到莫名的不協調。在軟體世界中，這套規則被稱為設計系統（Design System），它是整個產品外在表現的靈魂與基石。

外場：使用者看得見的一切

風格確立後，外場開始運作。桌椅依序擺放，菜單遞到客人面前。這是顧客在用餐過程中唯一能直接接觸的部分。

這就是前端（Frontend）的本質。使用者在螢幕上看到的介面、點擊的按鈕、填寫的表單，都是「外場」。它們的首要職責是溝通與引導 — 讓人看得懂、用得順。至於牛肉要怎麼煎、菜盤要怎麼擺，那是廚房的事，外場不應涉入過深。

好的外場有著清晰的邊界：桌椅負責承載、菜單負責承諾、服務生則負責傳遞需求。在前端開發中，這叫「元件化」與「職責分離」，確保畫面呈現與資料傳遞互不干擾。

出餐口：溝通的唯一橋樑

廚房與外場之間，有一個關鍵的「出餐口」。訂單從這裡傳進去，料理從這裡送出來。

在軟體中，這個窗口叫 API。不論外場裝潢如何翻新，只要出餐口的規則不變，廚房就不受影響。這個清晰的接口，確保了前後端可以獨立演進，而不會牽一髮而動全身。

廚房：從原始食材到秩序井然的料理

廚房決定了一間餐廳的真材實料。食材品質、烹飪工法、出菜順序，這些客人在外頭看不見的邏輯，才是產品的核心。

對於一間小店，一個廚師包辦所有事通常沒問題。但當規模變大、菜色變複雜，混亂便隨之而來：廚師動線重疊、改一道菜的做法卻弄亂了另一道菜的備料。這時你必須將廚房重新組織，從「大雜燴」轉向「專業分區」。

這種專業分區的概念，對應的就是軟體工程中的 DDD（領域驅動設計）。

將複雜的後端切割成不同的專業區域（如冷盤區、熱炒區、甜點區），每個區域擁有獨立的工具與職責。要協作時，必須走規定的管道，而非隨意介入。這讓系統在成長過程中，依然保持可被理解、可被修改的秩序。

交班：從「人」轉向「系統」的治理

然而，即便分工再完美，餐廳仍會面臨管理上的考驗：交班、人會離開。

主廚請假了、資深服務生離職了，如果所有的食譜、客人偏好、作業細節都只活在員工的腦子裡，那這間餐廳的品質就是脆弱的。

讓餐廳長久經營的關鍵，不是尋找天才廚師，而是建立一套「就算換了人，品質也不會跑掉」的機制。建立食譜、訂單管理、外送派單、關鍵環節要自動化監控。

這就是 Harness Engineering（駕馭工程） 在解決的問題。它不是寫在紙上、隨時會被遺忘的 SOP，而是直接運作在系統裡的規則與機制。它讓產品的品質不依賴「誰在當班」，而是依賴「系統本身的設計」。

結語：好的產品，像是一場無感的服務

回頭看，軟體開發的不同階段，其實就是在回答一間餐廳面臨的各種挑戰：

• 設計：定調風格與體驗。
• 前端與架構：梳理內外分工與溝通路徑。
• DDD：在規模擴大時維持內部秩序。
• Harness Engineering：確保跨班次的穩定與品質持續。

一間頂尖的餐廳，客人感受不到後廚的忙亂，也察覺不到人員的更迭。他只知道，每次來訪，體驗都始終如一。

會寫下這篇文章，是因為在 AI 輔助開發的時代，許多非工程背景的朋友也開始嘗試 Vibe Coding，每個人都能輕鬆地在自家廚房「煮出一道菜」。但如果要將這道菜變成一間能長久經營、持續擴張的「餐廳」，就必須跨入軟體工程的理解範疇。

這篇文章並非要教你如何寫程式，而是希望提供一個入門的邏輯框架。當你理解了餐廳運作的道理，你就掌握了軟體產品開發的核心邏輯。希望這些類比能成為你的地圖，帶領你在與 AI 協作的產品之路上，走得更穩、更遠。