Day 02：專案架構大解密：SwiftUI 前端＋ n8n 工作流＋雲端 AI 引擎

18th鐵人賽

35 瀏覽

嗨，大家今天過得好嗎？歡迎來到鐵人賽 Day 2。

昨天我們聊到了 Vibe Coding 的坑，以及為什麼選擇 n8n 作為後端。今天，在我們把手弄髒、開始對著 AI 瘋狂下 Prompt 之前，必須先做一件傳統但絕對不能省的事情：搞清楚系統架構。

如果你連資料怎麼流動都不知道，AI 產出來的程式碼對你來說就只是會動的黑盒子，一出 Bug 絕對修到崩潰。

我們的實戰目標：AI 硬體菜單推薦 App

為了讓接下來的 30 天有具體的開發目標，我會拿我手上的一個專案來實作。

這個專案原本的設計是在 Web 上的，但我現在要把它改成原生的 iOS App。簡單來說，這是一個「電腦硬體菜單配對系統」：使用者只要在 App 裡輸入預算和用途（例如：「預算三萬，想順跑 3A 遊戲」），系統就會去撈取最新的 CPU、顯示卡價格，並透過 AI 推薦出最符合預算與效能的菜單。

要用最短時間完成這個全端專案，我們的系統架構大概會長這樣：

以前要做這件事，我的後端可能會習慣開個 Java Spring Boot 專案，寫一堆 Controller 處理前端 API，設定 JPA/Hibernate 去連資料庫，最後再包一堆邏輯去戳 OpenAI 的 API。

但在這個講求極速迭代的專案裡，我們把架構大換血，切分成三個核心區塊：

這裡就是 Vibe Coding 的主戰場。我們會大量依賴 AI 來生成 SwiftUI 的畫面。

做法： 讓 AI 幫我們搞定刻畫面、排版、甚至轉場動畫。
底線： 就算交給 AI 寫，我們還是要嚴格引導它遵循 MVC (Model-View-Controller) 架構。把 UI 元件、網路請求 (API Service) 和狀態管理拆開來。絕對不能讓 AI 產出那種把業務邏輯全部塞在 View 裡面的千行麵條 Code。

這裡是整個系統的心臟，用來取代傳統的 API 伺服器。

做法： 我們會在 n8n 裡開一個 Webhook 節點，這個節點就等於是我們後端 API 的入口 (Endpoint)。
優勢： 當 iOS App 把使用者的「預算與需求」當作 JSON Payload 發過來時，n8n 就能接住它，並用拖拉節點的方式進行資料清洗、邏輯判斷 (If/Switch)。完全不用管伺服器路由怎麼寫。

這裡是我們專案的底層基座。

PostgreSQL： 負責儲存硬體清單（CPU、GPU 型號與時價）。n8n 內建 PostgreSQL 節點，可以直接寫 SQL 去撈資料。
LLM (OpenAI / Gemini)： 當 n8n 從資料庫把「硬體價格」撈出來後，會連同使用者的「預算需求」一起打包，寫成一段背後的 System Prompt，丟給 LLM 去思考，最後強制 LLM 回傳 JSON 格式的推薦菜單給 n8n。

把這三層合在一起，使用者按下一鍵推薦後，整個資料流會是這樣跑的：

[App 端] 使用者輸入：「預算 $30,000，打 APEX」，SwiftUI 把資料包成 JSON 發送 HTTP POST。
[n8n 端] Webhook 節點收到 Request。
[n8n 端] Postgres 節點被觸發，去資料庫撈取預算內的 CPU 與 GPU 清單。
[n8n 端] LLM 節點把「需求＋硬體清單」丟給雲端 AI 引擎：「請以這些硬體，配出一台最適合打 APEX 的 3 萬內主機，並以 JSON 格式回傳」。
[n8n 端] 收到 AI 產出的菜單，整理格式後，透過 Webhook Response 回傳給前端。
[App 端] SwiftUI 收到 JSON，解析 Model，完美渲染出推薦畫面。