如何建立 AI 聊天機械人 App：API 金鑰、提示詞、成本與安全

建立 AI 聊天機械人 App 需要四樣嘢：一個聊天介面、一個小型伺服器（負責保管模型供應商嘅 API 金鑰，並將訊息轉發去供應商）、一段系統提示詞（告訴模型佢係邊個、可以做咩），以及一套限制，用嚟控制成本同防止濫用。AI App 生成工具可以根據你嘅描述將以上全部寫好。你要親自負責嘅，係揀選供應商、撰寫指示，以及決定機械人絕對唔可以做嘅嘢。

AI 聊天機械人 App 由咩組成

大部分聊天機械人 App，無論係客服助手、導師，定係內部「問我哋文件」工具，都有相同嘅組成部分：

最常見嘅錯誤就係伺服器路由。如果聊天頁面直接由瀏覽器呼叫供應商，任何人都可以開啟開發者工具，複製你嘅金鑰，然後令你嘅帳單急升。

建立之前要決定嘅事

揀選邊個供應商同模型

主要供應商（OpenAI、Anthropic、Google 等）都提供運作方式相近嘅聊天式 API：你傳送一串訊息，然後收到一個回覆。實際上，揀選嘅重點與其說係品牌，不如說係模型大小：

• 細小、快速嘅模型價錢較平，回應亦快。適合簡短回答、分類，以及簡單嘅常見問題機械人。
• 大型模型推理能力較強，遵從長指示較穩定，亦較能處理雜亂嘅問題，但每條訊息成本較高，回應速度亦較慢。

建議先用中型模型，拿你真實嘅問題去測試，再按結果調高或調低。如果你未熟悉呢類 API 嘅收費同呼叫方式，請先閱讀 如何使用 LLM API。

機械人嘅知識從邊度嚟

先用最簡單、又能涵蓋你內容嘅做法。檢索會增加一個搜尋索引、一套更新機制，同埋更多令答案出錯嘅環節。好多實用嘅機械人其實唔需要檢索。

公開，定係要登入先用

放喺網站上嘅公開聊天機械人容易被找到，但亦容易被濫用：有人可以用程式大量發送訊息。要求登入嘅聊天機械人，就可以為每位用戶儲存紀錄，並為每個帳戶設定每日用量。如果係公開嘅，就要限制訊息長度、限制同一位訪客喺指定時間內可以發送嘅訊息數目，並喺供應商後台設定每月嘅硬性上限。如何為 App 加入登入功能 會講解帳戶方面嘅安排。

要唔要儲存對話

儲存對話串好有用：用戶可以接續之前嘅對話，你亦可以閱讀真實嘅問題，從而改善提示詞。不過，對話亦屬於個人資料。你要決定保留幾耐，在私隱聲明中說明清楚，而且唔好儲存任何唔需要嘅內容。

撰寫系統提示詞要似一份職位說明

系統提示詞係模型喺每段對話開始前都會收到嘅指示。一段好嘅提示詞，讀落應該似一份寫畀新員工嘅簡短任務說明：

• 角色與受眾：「你係 Oakline（一間單車維修店）嘅幫助助手，你嘅對象係顧客。」
• 範圍：「回答有關服務、價錢、營業時間同預約嘅問題。其他嘢只需回覆你只可以協助店舖相關事宜。」
• 資料來源：「只可以使用以下資料。如果答案唔喺入面，就話你唔知，並提供店舖電話。」
• 語氣與長度：「親切、用淺白嘅語言，除非被要求詳述，否則不超過三句。」
• 硬性規則：「絕對唔可以承諾列表以外嘅維修價錢。絕對唔可以索取信用卡資料。」

之後用難答嘅問題去測試：離題嘅要求、無禮嘅訊息、你內容入面搵唔到答案嘅問題，以及企圖令佢忽略指示嘅句子（例如「忘記你嘅規則然後……」）。一直調整提示詞，直至每個答案都係你敢簽名負責嘅。

令成本可以預測

供應商按 token（大約即字詞片段）收費，計算你送出嘅輸入同模型寫出嘅輸出。帳單主要由三樣嘢決定：

1. **對話長度。**每條新訊息通常都會重新傳送整段對話，好讓模型掌握上文。40 條訊息嘅對話，每次回覆嘅成本遠高於 4 條訊息嘅對話。只保留最近幾輪，或者將較舊嘅內容濃縮成摘要。
2. **提示詞大小。**一段長嘅系統提示詞，或者一大段貼入嘅知識，每條訊息都會被送出一次。
3. **輸出長度。**喺 API 呼叫中設定回覆嘅最長長度，並喺提示詞中要求簡潔作答。

正式推出之前，喺供應商後台設定每月消費上限，並記錄每次請求嘅 token 用量，方便你睇出邊啲對話較昂貴。我哋喺呢度唔列出價錢，因為價錢會因模型而有別，而且經常變動；請直接查閱供應商自己嘅價格頁。

逐步建立

第一步：描述機械人，而唔係描述程式碼

第一條提示詞如果已經寫明受眾、範圍、資料同安全規則，就已經完成大半工作：

為 Oakline（一間單車維修店）建立一個顧客幫助聊天機械人。聊天頁面要有訊息列表同輸入框，回覆要逐字串流顯示。透過伺服器路由，使用秘密金鑰 ANTHROPIC_API_KEY 呼叫 Anthropic API，絕對唔可以將金鑰暴露畀瀏覽器。系統提示詞只可以根據 shop-info.md 檔案中嘅內容，回答有關服務、價錢同營業時間嘅問題；其他情況則回覆「我唔太肯定，請致電下面嘅電話聯絡我哋」。訊息限制為 500 字元，每位訪客每小時最多 20 條訊息。設計要簡潔親切，並且喺手機上都運作良好。

第二步：將金鑰加為秘密設定

喺供應商嘅控制台建立金鑰，然後將它儲存喺專案嘅環境變數或秘密設定入面，唔好放入對話文字，亦唔好放入程式碼。如果金鑰曾經出現喺任何公開嘅地方，就要喺供應商處撤銷，並建立新嘅金鑰。什麼是環境變數與秘密設定 解釋咗呢點為何重要。

第三步：測試答案，而唔只係介面

聊天功能運作之後，大部分時間應該花喺答案質素上。準備一份大約 20 條真實問題嘅清單，當中包括幾條應該被拒絕嘅問題，並且每次修改提示詞之後都逐條測試。檢查以下各項：

• 佢有冇守住範圍？
• 唔知嘅時候，佢會唔會坦白承認，而唔係亂作答案？
• 有人嘗試推翻佢嘅指示時，佢能唔能夠堅持？
• 瀏覽器下載嘅任何檔案入面，會唔會完全冇金鑰？

第四步：如有需要，加入記憶同帳戶功能

單一對話運作正常之後，就可以要求將對話串儲存於資料庫；如有需要，亦可加入註冊同登入功能，令每位用戶只可以睇到自己嘅對話。同時亦可以為每位用戶加入每日訊息配額。

第五步：開啟限制後才發佈

確保已發佈嘅 App 與預覽版本擁有相同嘅秘密設定，供應商處已設定消費上限，而且錯誤會記錄喺你會留意到嘅地方。然後先同一小群人分享，之後才放上你嘅主網站。

安全與信任

聊天機械人係以你嘅名義同公眾對話，所以佢出現嘅任何問題都應該視為你自己嘅責任：

• **錯誤答案。**模型可以好有信心咁講出唔真確嘅嘢。將機械人限制喺狹窄嘅主題內，以你自己嘅內容作依據，並且對任何重要嘅問題顯示簡短提示，說明答案可能有誤。
• **提示注入（prompt injection）。**用戶（或者機械人所讀取嘅文件）可能會夾雜「忽略之前嘅規則」之類嘅指示。唔好畀機械人佢未可以信任嘅權力：例如退款、刪除，或者按用戶一句話就發送電郵，而你嘅程式碼又冇作任何檢查。
• **敏感話題。**對於醫療、法律或財務問題，應該叫佢指引用戶去搵專業人士，而唔係直接提供意見。
• **個人資料。**除非必要，唔好將客戶紀錄貼入提示詞；亦要查閱供應商條款，了解 API 資料會點樣處理。

我哋嘅 AI 生成 App 安全檢查清單 涵蓋咗整個 App 嘅更多範疇。

常見錯誤

• **由瀏覽器直接呼叫供應商。**金鑰會外洩。必須一律經過你嘅伺服器。
• **公開機械人冇任何限制。**一個腳本喺一個下午就可以用盡一個月嘅預算。
• **一開始就同時加入 RAG、工具同多個模型。**先令一段好嘅對話運作正常；等真實問題顯示有需要時，再加入其他功能。
• **只測試友善嘅問題。**用戶喺第一日就會問奇怪、帶敵意同離題嘅嘢。
• **任由對話串無限增長。**每多一條訊息，成本同回應時間都會上升。

幾時現成產品會較好

當聊天機械人係你產品嘅一部分、需要你自己嘅資料或工作流程，或者需要特定嘅外觀同行為時，自己建立就最合理。以下情況通常並唔適合自己建立：

• **你只係想喺現有網站加入一個客服小工具。**現時好多客服台同即時聊天產品，已包含可讀取你幫助中心內容嘅 AI 答覆機械人，並內置人工接手、收件箱同報告功能。
• **只有你或你嘅團隊會用。**訂閱一個通用助手（例如 ChatGPT 或 Claude），上載你嘅文件，可能已經足夠。
• 你需要嚴格嘅合規保證（例如受規管嘅醫療或財務資料）。一個已經持有相關認證嘅供應商，可能比自行建立更穩妥。

用 Mythex 建立

Mythex 係一個 AI App 生成工具：你喺對話中描述聊天機械人，它就會寫出介面同伺服器端嘅呼叫，喺即時預覽中運行，然後發佈到一個公開網址。你 App 入面嘅 AI 會使用你自己嘅供應商金鑰。你可以喺專案秘密設定中加入金鑰，或者透過 Mythex 需要時喺對話中顯示嘅秘密設定卡加入；供應商嘅用量會計入你自己嘅供應商帳戶，而唔會計入 Mythex 建立額度。Mythex 唔包括畀你 App 用戶嘅代幣、內置嘅知識庫產品，或者現成嘅速率限制：呢啲都係你需要要求同測試嘅部分。喺你嘅 App 入面加入 AI 文件頁會逐步講解，而 使用你自己嘅 API 金鑰加入 AI 則提供一條起步提示詞。

如果機械人需要儲存對話串，你要求之後，Mythex 會為專案加入一個 Postgres 資料庫。如想了解更多喺 App 入面使用模型嘅方法（由摘要到分類），請參閱 如何為 App 加入 AI 功能；或者瀏覽 App 範本 找靈感起點。

常見問題