AI 應用開發怎麼做？從架構選擇到部署的完整流程與常見陷阱

寫 App 的世界，真的變天了

最近很多人在聊寫程式這件事，你知道嗎，感覺整個遊戲規則都變了。以前我可能還會跟你說，學 Python 吧，從基礎開始。但現在...老實說，我有點猶豫了。

不只是我這樣覺得。Replit 的執行長 Amjad Masad 最近就在一個 Podcast 上說，如果他現在才開始學寫程式，他不會從 Python 開始。然後 OpenAI 的 Sam Altman 也講了一些話，聽起來就像在暗示「寫程式」這個工作，可能快要不是我們以前認識的那個樣子了。

我自己這兩年一頭栽進 AI 開發裡，真的有很深的感觸。以前搞個 AI 功能，那真是...呃，九彎十八拐，又貴又難搞。但現在，特別是 2024、2025 年之後，用 AI 來打造 App 的方法，變得異常簡單，而且效果好得嚇人。所以，我想來聊聊這個新的開發方式，一個我自己覺得「對」的方式。

一句話結論

簡單講，就是你不再需要為 App 的所有商業邏輯寫死程式碼了。你現在可以把大型語言模型 (LLM) 當成你 App 的大腦兼後端伺服器，你只需要用「人話」去教它、指揮它該怎麼做。

這聽起來有點玄，對吧？但這就是所謂的「LLM as the Backend」或「LLM 當後端」的核心思想。

所以，這到底是什麼意思？

我們來直接看一個例子，這樣比較好懂。假設我們要開發一個叫「LinguaFlow」的語言學習 App。以前的作法是什麼？

你得規劃資料庫、寫 API、設計每個功能。例如「單字庫」，你要寫一個模組來新增單字、查詢單字、做測驗。然後「文法教學」又是另一個模組，裡面有一堆規則。每個功能都是一塊塊寫死的程式積木，疊在一起。

但用「LLM 當後端」的思路，完全不一樣。我們把 App 的「大腦」外包給 LLM，像是 GPT-4 或 Claude 3.5 Sonnet 這種模型。我們的工作，從「寫程式碼」變成「寫說明書」。

聽起來很抽象，我們直接用一張比較表來看，你會更有感覺。

你看，整個開發的重心從「寫程式」轉移到了「寫提示詞」。我們不再是命令電腦一步一步做，而是像在跟一個很聰明的實習生溝通，你告訴他目標和規則，他自己會想辦法完成。這就是從「指令式編程」到「宣告式編程」的轉變，一個蠻大的思維跳躍。

實作指引：那我們來蓋「LinguaFlow」吧

好，理論講完了，我們來動手。當然不是真的寫扣啦，是把整個思路跑一遍。用這個方法，我們要打造一個語言學習 App，主要有幾個部分：

1. 前端 (UI)：這部分很單純，就是使用者看到的介面。一個網頁或手機 App，負責接收用戶打的字、顯示 LLM 回傳的結果。重點是，前端本身沒有任何學習邏輯，它就是個漂亮的傳聲筒。
2. 後端 (Orchestration Layer)：這是一個很薄的程式層，你可以用 Python 配 LangChain 或 LlamaIndex 這類工具來做。它的工作很簡單：接收前端來的請求、選一個對應的「提示詞」、把提示詞和用戶輸入組合起來、丟給 LLM API、最後解析 LLM 回來的東西再丟回給前端。
3. LLM (大腦)：這就是我們的核心。可以是 OpenAI 的 API，也可以是 Anthropic 的。最近我自己是蠻愛用 GitHub Copilot Pro 方案裡附的 Claude 3.5 Sonnet，一個月才 10 美元，CP 值真的很高，寫程式相關的任務它表現超好。
4. 資料庫：用來記錄每個使用者的狀態，像是他學會了哪些單字、文法學到哪等等。

整個流程的核心，就是那個「後端」怎麼跟「LLM」溝通。而溝通的語言，就是我們說的「提示詞工程」(Prompt Engineering)。

心法一：用一個「系統提示詞」幫 LLM 熱機

首先，你要給 LLM 一個「人設」。在 App 一啟動的時候，就先送出一個系統級的提示詞，告訴它：「你現在是 LinguaFlow，一個親切的語言老師...」。

這就像在演戲前，先給演員劇本跟角色設定。這個提示詞會一直存在，確保 LLM 不會「忘記」自己的身份。

我自己習慣的作法是，會先跟 LLM 講好規則，然後用一個奇怪的「結束詞」告訴它我講完了，你可以開始工作了。這聽起來有點蠢，但很有用，可以避免它在我還在定義規則的時候就自己亂動。就像原文作者用的那個詞一樣... 對，就是 SAUSAGE。

 你是 LinguaFlow，一個有幫助且友善的語言學習導師。你的目標是幫助使用者有效且愉快地學習新語言。
 
 你將與一位正在學習 [目標語言] 的使用者互動。使用者目前的熟練度是 [使用者等級] (初學者、中級、高級)。
 你應該：
 * 提供清晰簡潔的解釋。
 * 經常使用範例。
 * 保持鼓勵和耐心。
 * 根據使用者的等級調整你的回應。
 * 追蹤使用者的進度（已學詞彙、已涵蓋的文法概念）。這些資訊會在每次互動中提供給你。
 * 按照個別任務中指定的 JSON 格式回傳結果。
 
 使用者目前已學會的詞彙是：[已學詞彙] (這裡會動態更新)。
 
 我會給你一系列特定功能的提示詞，以便你建立詳細的技術和開發計畫。在我用「SAUSAGE」這個詞結束提示之前，不要開始寫程式或建立計畫。
 

心法二：為每個功能設計專屬的「任務提示詞」

有了人設之後，接下來就是針對每個 App 功能，設計一個個獨立的「任務卡」。這些任務卡通常會用 JSON 格式，非常清楚地告訴 LLM 現在要做什麼。

例如，「單字教學」功能，我們的任務卡可能是這樣：

 {
  "task": "introduce_word",
  "word": "Maison",
  "target_language": "French",
  "user_level": "Beginner"
 }
 
 // --- 接著是給 LLM 的指示 ---
 根據上面的 JSON，向使用者介紹新單字 'Maison'。提供定義、一個法文例句及其英文翻譯，還有一個簡單的發音提示。請用以下 JSON 格式回傳結果：
 {
  "word": "Maison",
  "definition": "House, home",
  "example_sentence": "J'habite dans une grande maison.",
  "example_sentence_translation": "I live in a big house.",
  "pronunciation_tip": "Sounds like 'may-zohn'."
 }
 

「文法測驗」功能也一樣：

 {
  "task": "quiz_word",
  "words_to_test": ["Maison", "Chat", "Livre"],
  "target_language": "French",
  "user_level": "Beginner"
 }
 
 // --- 給 LLM 的指示 ---
 根據提供的 JSON，為 'words_to_test' 中的 *一個* 單字創建一個選擇題。用以下 JSON 格式回傳：
 {
  "question_type": "multiple_choice",
  "word": "Chat",
  "question": "What is the meaning of 'Chat'?",
  "options": ["Dog", "Cat", "Book", "House"],
  "correct_answer": "B"
 }
 

你看，我們根本沒寫一行 if-else 或 for 迴圈。我們只是在「描述」我們想要什麼。LLM 會自己去生成題目、選項，甚至干擾項。這就是最神奇的地方。

心法三：讓 LLM 幫你管理使用者狀態

這點超級重要。一個好的 App 需要記住使用者的進度，對吧？以前這得靠後端工程師寫一堆邏輯來處理。現在，我們連這個都可以外包給 LLM。

在每次互動後，我們可以把互動的摘要丟給 LLM，然後下一個指令：

 {
  "task": "update_state",
  "user_id": "user-123",
  "interaction_summary": "使用者成功答對了 'Chat' 的測驗，但在對話中混淆了陽性和陰性冠詞。"
 }
 
 // --- 給 LLM 的指示 ---
 根據以上互動摘要，分析使用者表現並更新他的狀態。
 1. 使用者是否學會了新單字？
 2. 他的熟練度等級是否需要調整？
 3. 推薦下一個學習重點。
 
 請用以下 JSON 格式回傳更新後的狀態：
 {
  "user_level": "Beginner",
  "learned_vocabulary": ["Maison", "Chat"],
  "recommendation": "下一課可以專注於法文的名詞性別 (gender of nouns)。"
 }
 SAUSAGE
 

我們的後端程式只要接收到這個 JSON，然後把它存進資料庫就好了。你看，連「個人化推薦」這種複雜的功能，都只是幾個提示詞的事。

但，真的有這麼完美嗎？

當然不可能。這種新方法雖然又快又猛，但也有一些新的挑戰，說真的，有些還蠻棘手的。

• 提示詞技巧決定一切：App 的好壞，幾乎完全取決於你寫提示詞的功力。寫得不清楚、有歧義，LLM 就會給你一堆垃圾。這是一門全新的手藝，需要大量練習。
• 可靠性和可預測性：LLM 是機率模型，不是計算機。它有時候會「自由發揮」，也就是我們說的「幻覺 (Hallucination)」。你不能 100% 確保它每次都回傳一樣的結果。所以怎麼設計提示詞來約束它，就很重要。
• 成本問題：呼叫強大的 LLM API 是要錢的。雖然前面說的 GitHub Copilot Pro 方案很划算，但如果用量一大，還是得精打細算。不過呢，跟養一個後端團隊比起來...嗯，可能還是便宜多了。
-
• 安全性：如果你的 App 會處理敏感資料，那就要非常小心。你等於是把資料傳給了第三方（像 OpenAI），這中間的資安風險需要審慎評估。
-
• 除錯 (Debugging) 超級難：以前程式出錯，你可以設中斷點、看 log，一步步追。但 LLM 像個黑盒子，它為什麼會回這個奇怪的答案？天曉得。除錯變成一種...呃，更像是「通靈」和不斷修改提示詞的過程。

說到這個，就不能不提本地化的考量。國外這些像是 OpenAI、Anthropic 的模型，在英文世界裡真的很強。但在台灣，我們用在處理繁體中文的脈絡時，有時候會發現一些細微的文化或語意差異。這時候，有些團隊會考慮串接像是國科會或台智雲（TWS）開發的本地模型，雖然通用能力可能沒那麼強，但在特定中文場景下，經過微調（fine-tuning）後，表現可能會更穩定、更符合在地需求。這就是一種權衡了。

常見錯誤與修正

我自己剛開始玩的時候，也踩了不少坑。這裡列幾個常見的錯誤，希望可以幫你少走點冤枉路。

• 錯誤一：把 LLM 當成資料庫。很多人會想把所有使用者資料都塞進提示詞的 context 裡。千萬別！那個 context window 是有限而且昂貴的。正確做法是把長期狀態存在傳統資料庫，只把當前互動最相關的資訊提供給 LLM。
• 錯誤二：期望 LLM 吐出完美的 JSON。就算你在提示詞裡要求了 JSON 格式，LLM 有時候還是會多給你一些「不好意思，這是我生成的 JSON...」之類的廢話。你的後端程式必須要有一層強健的解析和驗證機制，去「清理」LLM 的回覆，只取出你需要的 JSON 部分。
• 錯誤三：一個提示詞打天下。試圖用一個超大、超複雜的提示詞去處理所有事情，通常結果都很慘。比較好的做法是把任務拆解成一系列小提示詞，形成一個「Chain of thought」，一步步引導 LLM 完成複雜任務。這也是 LangChain 這類工具的核心價值。

總之，我自己是覺得，這個「LLM 當後端」的開發模式，絕對是未來幾年軟體開發的主流之一。它不會完全取代傳統程式設計，但對於那些需要高度彈性、快速迭代、和自然語言互動的應用來說，這簡直是天賜的禮物。

與其擔心工作會不會被取代，不如趕快動手玩玩看，去感受一下這個新的開發典範。這真的...蠻酷的。