嗨,大家今天過得好嗎?歡迎來到鐵人賽 Day 4。
昨天我們已經把 n8n 引擎在 Local 端架設完畢,後端基礎建設算是搞定了。今天我們要切換一下大腦,把視角拉回前端。
既然這系列主打「Vibe Coding」,大家一定迫不及待想打開 ChatGPT、Claude 或是 Cursor,直接叫 AI 幫我們把「硬體菜單推薦 App」的畫面噴出來。但先等一下!在送出你的第一句 Prompt 之前,我們得先聊聊怎麼「下指令」。
很多剛接觸 AI 輔助開發的人,最常犯的錯誤就是把 AI 當成許願池,下這種「講話式」的指令:
災難示範:
「幫我寫一個 iOS App 的首頁,主題是電腦硬體推薦,要有輸入預算的框框跟下拉選單選用途,然後按鈕按下去會出現推薦菜單。」
AI 看了當然會說「沒問題!」,然後在幾秒鐘內吐給你一個長達 500 行的 ContentView.swift。
結果呢?你會發現 UI 排版、假資料 (Mock Data)、按鈕點擊後的邏輯判斷、甚至是預留的 API 請求,全部擠在這個 View 裡面。這就是標準的義大利麵條 Code (Spaghetti Code)。未來你只要想加個功能,或是要跟 n8n 串接時,絕對會改到懷疑人生。
在 Vibe Coding 的時代,Prompt 就是你的架構設計圖。如果你想要 AI 寫出有擴展性、好維護的程式碼,你的 Prompt 必須具備高度的「結構化」與「限制性」。
對於前端開發(尤其我們是用 SwiftUI),我個人習慣使用以下這套 【角色 + 架構 + 任務 + 限制】 的 Prompt 框架:
先定調 AI 的技術水準與寫 code 風格,這會影響它產出程式碼的品質與命名習慣。
「你現在是一位擁有 10 年經驗的資深 iOS 開發者,精通 Swift 與 SwiftUI。」
這是我們對抗爛 Code 的核心防線。明確告訴 AI 你的專案架構,以我的習慣,我會強制要求它遵守 MVC。
「請嚴格遵守 MVC (Model-View-Controller) 設計模式。
- View: 只負責 UI 渲染與畫面狀態呈現,不允許包含任何業務邏輯與 API 請求。
- Model: 負責定義資料結構 (如硬體清單、預算表單)。
- Controller (或 ViewModel): 負責狀態管理與未來對外的 API 互動。」
詳細描述你要完成的畫面或功能,把 UI 元件拆解清楚。
「請幫我實作『硬體菜單推薦』的輸入首頁。需要包含:
- 一個 TextField 讓使用者輸入數字(預算)。
- 一個 Picker (下拉選單) 讓使用者選擇用途(如:3A 遊戲、影音剪輯、文書處理)。
- 一個送出按鈕。」
限制它不要自作聰明加一堆不需要的套件,並要求它分檔案輸出。
「- 不要使用任何第三方套件。
- 請將 Model, View, Controller 拆分成不同的檔案輸出,並清楚標示檔名。
- 程式碼需包含中文註解。」
把上面四個元素組裝起來,這就是我們待會要丟給 AI 的完整 Prompt 範本:
你現在是一位擁有 10 年經驗的資深 iOS 開發者,精通 Swift 與 SwiftUI。
請幫我實作「硬體菜單推薦 App」的輸入首頁。
【架構規範】
請嚴格遵守 MVC 設計模式,不可將所有程式碼塞在 ContentView。
- View:只負責 UI 渲染,不允許包含任何業務邏輯。
- Model:負責定義表單資料結構 (預算、用途)。
- Controller / ViewModel:負責狀態管理,並實作一個假的送出 Function 預留給未來的 API 呼叫。
【具體任務】
首頁需要包含:
1. 標題:「AI 硬體菜單配對」。
2. 預算輸入框 (TextField,僅限數字)。
3. 用途選擇 (Picker,選項包含:3A 遊戲、影音剪輯、文書處理)。
4. 一個醒目的「產生推薦菜單」按鈕。
【限制】
- 僅使用原生 SwiftUI,不依賴第三方套件。
- 請將 Model, View, Controller 分別以不同的 Swift 檔案輸出,並提供對應的檔名與程式碼。
當你用這套框架去引導 AI,你會發現它吐出來的程式碼不僅整潔,而且已經幫你把檔案拆得漂漂亮亮。就算它寫錯了,你也很容易知道該去 Controller 還是 View 裡面抓蟲 (Debug)。
明天,我們就要打開 Xcode 建立新專案,並把這段 Prompt 實際丟給 AI,看看我們如何一鍵生成符合 MVC 架構的 SwiftUI 完美起手式!
我們 Day 05 見!