如何為你的應用程式加入 AI 功能

要為你的應用程式加入 AI 功能，請從伺服器呼叫大型語言模型（LLM）API：把清楚的指令加上相關資料送出去，再使用回傳的結果。大多數實用的功能屬於四種模式之一：摘要、聊天、擷取結構化資料與分類。每一種只需要幾十行程式碼，AI 建置工具就能幫你寫出來。真正決定功能好不好用的，是呼叫前後的工作：把 API 金鑰留在伺服器上、控制每位使用者的成本，以及在信任輸出之前先檢查它。

大多數 AI 功能背後的四種模式

擷取與分類往往最有價值，也最不容易被注意到。它們默默地為每筆紀錄省下幾分鐘的時間；而且因為輸出是固定格式，你可以自動檢查。聊天最顯眼，但也最難做好，它有自己的指南：如何建立 AI 聊天機器人應用程式。

它如何融入你的應用程式

每種模式的形狀都相同：

1. 使用者採取行動：點選「摘要」、上傳檔案、送出訊息。
2. 你的前端呼叫你自己的伺服器，而不是 AI 供應商。
3. 你的伺服器建立請求：系統指令、使用者的輸入，以及模型需要從資料庫取得的任何資料，但只包含此使用者有權限看到的資料。
4. 你的伺服器呼叫 LLM API，金鑰存放在環境變數中。
5. 你的伺服器檢查回應：是否為有效的 JSON、是否為已知標籤、長度是否合理，然後儲存或回傳。
6. 前端顯示結果，較長的回答會隨著內容送達而串流顯示。

金鑰在第 4 步時只存在於伺服器，永遠不會到達瀏覽器。如果你對 API 的概念還不熟悉，什麼是 API 是一篇簡短的入門文章，而如何使用 LLM API 則會更深入地說明 token、模型與金鑰。

選擇供應商與模型

主要供應商（OpenAI、Anthropic、Google 等）都提供結構大致相似的文字 API。選擇時可以考慮以下問題：

• 在你的任務上的品質。 拿應用程式中幾個真實的範例，在兩到三個模型上測試。在你自己的資料上，差異通常比通用基準測試更明顯。
• 規模與成本的取捨。 供應商提供能力更強的大型模型，也提供較便宜、較快速的小型模型。分類和簡單擷取通常用小模型就很好；長篇推理或細膩的寫作，可能就需要大型模型。
• 結構化輸出。 對於擷取與分類，請優先使用能讓模型依你提供的結構描述回傳 JSON 的 API 功能，而不是解析自由文字。
• 資料處理。 閱讀供應商的條款，了解 API 的輸入是否會被儲存或用於訓練，以及這是否符合你的使用者提供的資料性質。
• 用量限制。 新帳號的速率限制通常較低，正式上線前請先確認。

模型名稱與價格變動頻繁，因此程式碼應該從設定檔讀取模型名稱，而不是把它硬寫在許多地方。

逐步新增一個功能

以一個具體例子來說：一個小型 CRM，每位聯絡人都有一長串的備註紀錄。

1. 儲存金鑰。 在供應商的後台建立金鑰，並把它存成伺服器端的機密，例如 OPENAI_API_KEY 或 ANTHROPIC_API_KEY。

2. 要求一個範圍較窄的功能：

在聯絡人頁面新增一個「摘要」按鈕。在伺服器端，使用名為 [ENV_NAME] 的機密，把該聯絡人最近 20 則備註送到 [PROVIDER]，指示它寫出三個重點：目前狀態、未解決的問題、下一步。只包含已登入使用者可以看到的備註。顯示載入狀態，把摘要連同時間戳記一起儲存，若呼叫失敗則顯示「目前無法產生摘要」。絕不把金鑰送到瀏覽器。

3. 在能省下打字的地方加入擷取：

當使用者把電子郵件簽名檔貼到「快速新增」方塊時，在伺服器端呼叫 [PROVIDER]，使用供應商的結構化輸出功能，回傳包含姓名、公司、職稱、電子郵件和電話的 JSON。在伺服器端驗證 JSON，用它預先填入新增聯絡人表單，並讓使用者在儲存前可以編輯。不確定的欄位留白，不要猜測。

「讓使用者在儲存前編輯」是最重要的部分：由模型提出建議，決定權在人。

4. 在背景進行分類：

當新的客服工單進來時，將它分類為以下其中之一：帳單、錯誤、功能需求、帳號存取、其他。使用小型、低成本的模型。如果回應不是這些標籤之一，就儲存為「其他」。把標籤顯示為可編輯的標記。

5. 用混亂的真實資料測試：很長的備註、空白的備註、其他語言、沒有電話號碼的簽名檔，並在發布前把二十筆輸出並排檢視。

撰寫有效的指令

每次請求都會附上的指令（通常稱為系統提示詞），是品質的來源。

• 說明對象是誰，以及什麼才算好。 「摘要會被業務人員在通話前的 10 秒內閱讀」能給模型一個目標。
• 固定格式。 精確的條列數量、長度限制、欄位、標籤。
• 說明不確定時該怎麼做。 「如果備註中沒有提到下一步，就寫『未記錄下一步』」能減少模型編造答案。
• 提供兩到三個範例，展示擷取與分類的良好輸入與輸出。
• 將指令與使用者內容分開， 並清楚標示使用者內容，讓模型能分辨兩者。

把提示詞放在程式碼庫的檔案中，讓它像其他程式碼一樣有版本、可供審查。

控制成本

LLM API 以 token（小段文字）計費，送出的內容與回傳的內容都會計算。成本會隨著每次請求的上下文量，乘上執行的頻率而增加。實用的控制方法：

• 只送出必要的內容。 最近 20 則備註，而不是整段歷史。長文件要修剪或切分。
• 使用能完成任務的最小模型。 不要預設就用最大的模型，先測試。
• 限制輸出長度，使用 API 的最大 token 數設定。
• 快取結果。 儲存摘要，只有在來源變動時才重新產生，而不是每次頁面瀏覽都重新產生。
• 限制每位使用者的用量。 為每個帳號或方案設定每日上限，避免單一重度使用者或單一腳本把費用推高。
• 對端點進行速率限制，就像對其他昂貴的路由一樣。
• 在供應商後台設定預算或警示，上線後每週檢查用量。
• 依功能記錄 token 用量，這樣你就知道每個功能花費多少。

如果 AI 功能是你產品的核心，請把它的營運成本納入定價，而不是自行吸收。

安全與信任

AI 的輸出具有機率性。它可能錯了卻說得很有把握，也可能被它所讀取的文字誘導。請據此建構系統：

• 把輸出視為不可信任的輸入。 驗證結構、在渲染成 HTML 前進行跳脫，絕不將它當作程式碼或資料庫查詢執行。
• 對於有後果的操作，保留人工介入。 例如寄送電子郵件、變更紀錄、退款。由模型起草，由人確認。
• 防範提示詞注入。 文件或訊息中可能含有「忽略你的指令」之類的文字。把模型能看到的內容限制在目前使用者可以看到的範圍內，並且不要給它可以執行敏感操作的工具，除非你的程式碼先檢查過權限。
• 標示 AI 產生的內容，讓使用者知道某段摘要或建議是由 AI 產生的，並且可以自行核對。
• 妥善處理失敗。 供應商可能會停機或觸發速率限制。設定逾時、顯示清楚的訊息，並讓應用程式的其他部分繼續運作。
• 留意使用者送出的內容。 對於開放式文字輸入，可以考慮加入內容審核步驟，並在隱私政策中清楚說明內容會由第三方 AI 供應商處理。

更完整的檢查清單請見 AI 建置應用程式安全檢查清單。

常見錯誤

• 一開始就做通用聊天機器人，但一個「摘要」或「分類」按鈕可能對更多人更有幫助。
• 把金鑰放在前端程式碼中，或放進公開的程式碼庫。
• 把整個資料庫當作上下文送出，這樣又慢、又貴，還可能外洩其他使用者的資料。
• 盲目信任自由文字的輸出，而結構描述或固定標籤集合會讓結果可以檢查。
• 沒有每位使用者的限制，直到第一張帳單寄來才發現問題。

在 Mythex 中加入 AI 功能

在 Mythex 中，你可以在對話中要求在自己的應用程式內加入 AI，並使用你自己的供應商金鑰。請把金鑰存成專案機密。當代理程式需要金鑰時，Mythex 會在對話中顯示機密卡片，讓你不必把金鑰貼進對話。之後代理程式會撰寫伺服器路由、提示詞與介面。你的應用程式的 AI 用量由你的供應商計費，與你在建置時花費的 Mythex 點數是分開的。文件中有一個起始提示詞，見使用你自己的 API 金鑰為應用程式加入 AI 功能。

常見問題