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

要為應用程式加入 AI 功能，請在伺服器端呼叫大型語言模型（LLM）API：把清楚的指令連同相關資料傳送過去，然後使用回傳的結果。大多數實用的功能屬於四種模式之一：摘要、聊天、擷取結構化資料，以及分類。每種功能只需數十行程式碼，AI 生成工具便可以替你寫好。真正決定功能好壞的，是圍繞這次呼叫的工作：把 API 金鑰保存在伺服器端、控制每位用戶的成本，以及在信任輸出前先加以檢查。

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

擷取和分類往往最有價值，但最不顯眼。它們每次悄悄為人省下幾分鐘，而且由於輸出形式固定，你可以自動檢查。聊天功能最顯眼，卻最難做好，因此有獨立的指南：如何建立 AI 聊天機械人應用程式。

它如何融入你的應用程式

每種模式都有相同的結構：

1. 用戶採取行動：按下「摘要」、上傳檔案、傳送訊息。
2. 前端呼叫你自己的伺服器，而不是 AI 供應商。
3. 伺服器建立請求：系統指令、用戶的輸入，以及模型需要的任何資料，這些資料都來自你的資料庫，且只限於此用戶有權查看的部分。
4. 伺服器呼叫 LLM API，使用儲存在環境變數中的金鑰。
5. 伺服器檢查回應：是否為有效的 JSON、標籤是否屬於已知範圍、長度是否合理，然後儲存或回傳。
6. 前端顯示結果，較長的回答會隨到達逐字串流顯示。

金鑰位於第 4 步的伺服器端，從不會到達瀏覽器。如果你對 API 這個概念還不熟悉，什麼是 API 是一篇簡短入門文章，而如何使用 LLM API 則更深入地講解權杖、模型和金鑰。

選擇供應商與模型

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

• **在你的任務上的質素。**用應用程式中幾個真實例子，在兩至三個模型上測試。在你自己的資料上，兩者的差異往往比一般基準測試更清楚。
• **規模與成本。**供應商同時提供較大、能力較強的模型，以及較細、較便宜、較快的模型。分類和簡單擷取通常用細模型已經可以做得很好；長篇推理或細緻的寫作則可能需要較大的模型。
• **結構化輸出。**對於擷取和分類，應優先使用供應商提供的 API 功能，讓模型按你提供的結構回傳 JSON，而不是解析自由文字。
• **資料處理。**閱讀供應商的條款，了解 API 的輸入是否會被儲存或用於訓練，以及這是否符合用戶提供給你的資料。
• **限制。**新帳戶的速率限制通常較低，正式推出前應先檢查。

模型名稱和價格經常變動，因此程式碼應從設定中讀取模型名稱，而不是把它硬編碼在多處地方。

逐步加入一項功能

以一個小型 CRM 為例，每位聯絡人都有很長的備註紀錄。

**1. 儲存金鑰。**在供應商的儀表板建立金鑰，並把它儲存為伺服器端機密，例如 OPENAI_API_KEY 或 ANTHROPIC_API_KEY。

2. 要求一項範圍狹窄的功能：

在聯絡人頁面加入「摘要」按鈕。在伺服器端，使用名為 [ENV_NAME] 的機密，把該聯絡人最近 20 則備註傳送給 [PROVIDER]，指示它寫出三點項目：目前狀況、未解決問題、下一步。只包括已登入用戶可以查看的備註。顯示載入狀態，並以時間戳記儲存摘要；如果呼叫失敗，顯示「暫時無法生成摘要」。切勿把金鑰傳送到瀏覽器。

3. 在能省下輸入功夫的地方加入擷取：

當用戶把電郵簽名貼到「快速新增」方框時，在伺服器端呼叫 [PROVIDER]，並使用供應商的結構化輸出功能，回傳包含姓名、公司、職位、電郵和電話的 JSON。在伺服器端驗證 JSON，用它預先填寫新增聯絡人的表格，並讓用戶在儲存前可以編輯。沒有資料的欄位留空，不要猜測。

「在儲存前讓用戶編輯」這點最關鍵：由模型提出建議，由人作最後決定。

4. 在背景進行分類：

當新的支援工單到達時，把它分類到以下其中一個類別：帳單、錯誤、功能要求、帳戶存取、其他。使用細小且成本低的模型。如果回應不屬於這些標籤，就儲存為「其他」。把標籤顯示為可編輯的標記。

5. 用凌亂的真實資料測試：長篇備註、空白備註、其他語言、沒有電話號碼的簽名。在正式推出之前，把二十個輸出並排檢視。

撰寫有效的指令

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

• 說明服務對象，以及什麼才算好。「摘要由銷售人員在通話前十秒內閱讀」能為模型提供明確目標。
• **固定格式。**項目符號的確切數目、長度限制、欄位和標籤。
• 說明不確定時該怎麼做。「如果備註沒有提及下一步，請寫『未有記錄下一步』。」這有助減少模型憑空編造的答案。
• 為擷取和分類提供兩到三個範例，展示良好的輸入與輸出。
• 把指令與用戶內容分開，並清楚標示用戶內容，讓模型能分辨兩者。

把提示詞存放在程式碼庫的檔案中，令它們與其他程式碼一樣有版本記錄，並可供審閱。

控制成本

LLM API 按權杖收費（權杖即小段文字），傳送的內容和接收的內容都會計算在內。成本會隨每次請求的上下文數量，乘以執行次數而增長。實用的控制方法包括：

• **只傳送所需內容。**傳送最近 20 則備註，而不是完整歷史紀錄。長文件應先剪裁或分段。
• **使用能勝任工作的最細模型。**在預設使用最大模型之前先作測試。
• 用 API 的最大權杖設定限制輸出長度。
• **快取結果。**把摘要儲存起來，只在來源內容改變時重新生成，而不是每次瀏覽頁面都重新生成。
• **限制每位用戶的用量。**按帳戶或方案設定每日上限，可防止某位重度用戶或某個腳本耗盡預算。
• 對端點設定速率限制，與處理其他昂貴路由的做法一樣。
• 在供應商的儀表板設定預算或警示，並在正式推出後每週檢查用量。
• 按功能記錄權杖用量，讓你知道每項功能各自的成本。

如果 AI 功能是你產品的核心，應把其運行成本計入定價，而不是自行吸收。

安全與信任

AI 的輸出具有機率性。它可能錯得很有把握，也可能被它讀取的文字所左右。因此設計時要考慮到這些情況：

• **把輸出視為不可信的輸入。**驗證結構、在以 HTML 呈現前先作轉義，切勿把輸出當作程式碼或資料庫查詢來執行。
• 對有後果的操作保留人手把關，例如傳送電郵、更改紀錄、退款。由模型擬稿，由人確認。
• **防範提示詞注入。**文件或訊息中可能包含「忽略你的指令」之類的文字。應把模型能看到的內容限制在當前用戶可查看的範圍內，並且不要給它可以在未經你的程式碼檢查權限前就執行敏感操作的工具。
• 標示 AI 生成的內容，讓用戶知道某段摘要或建議是由 AI 生成的，並可以自行核對。
• **妥善處理失敗情況。**供應商可能會出現服務中斷或速率限制。應設定逾時、顯示清楚的訊息，並讓應用程式的其他部分繼續運作。
• **留意用戶的輸入內容。**對於開放式文字輸入，可考慮加入內容審核步驟，並在私隱政策中清楚說明內容會由第三方 AI 供應商處理。

更完整的檢查項目，請參閱 AI 生成應用程式的安全檢查清單。

常見錯誤

• 一開始就做一個通用聊天機械人，而一個「摘要」或「分類」按鈕可能讓更多人受惠。
• 把金鑰放在前端程式碼中，或放在公開的儲存庫裡。
• 把整個資料庫當作上下文傳送，這樣既慢又昂貴，還可能外洩其他用戶的資料。
• 信任自由文字的輸出，而如果改用結構或固定標籤集，便能加以檢查。
• 沒有每位用戶的限制，直到第一張帳單到達才發現問題。

在 Mythex 加入 AI 功能

在 Mythex，你可以在對話中要求 AI 加入你自己的應用程式，並使用你自己的供應商金鑰。請把金鑰儲存為專案機密：當代理需要金鑰時，Mythex 會在對話中顯示機密卡，因此你無須把金鑰貼進對話。代理會負責撰寫伺服器路由、提示詞和介面。你的應用程式的 AI 用量由你的供應商收費，與你建立應用程式時消耗的 Mythex 點數分開計算。文件中有以自己的 API 金鑰加入 AI 功能的起始提示詞範例。

常見問題