為什麼你的 SaaS 需要「預留 AI 接口」？我們用三個產品驗證的架構設計
目錄
- TL;DR
- 現況：一個 API Key 撐起三個產品
- 問題一：單點故障
- 問題二：場景錯配
- 問題三：無法升級
- 解法：AI-Ready 架構的 7 個設計原則
- 原則 1：Model Router，不綁死任何一家
- 原則 2：Prompt Template Registry，Prompt 是資產，不是字串
- 原則 3：Response Cache，相同問題不要問兩次
- 原則 4：Structured Output，AI 回的東西必須可驗證
- 原則 5：BYOK（Bring Your Own Key），讓客戶用自己的 key
- 原則 6：MCP Server，讓你的系統能被 AI Agent 呼叫
- 原則 7：Observability，AI 呼叫必須可追蹤
- 我們的實施路線圖
- Phase 1（現在）：品牌層
- Phase 2（Q2 2026）：技術層
- Phase 3（Q3 2026）：生態層
- 你現在就該做的事
- 結語
利益揭露：Ultra Lab、MindThread 與 Ultra Advisor 同屬傲創實業，是同集團產品。
TL;DR
你現在建的每一個系統，三年內都會被問：「這能接 AI 嗎？」
如果你的答案是「要重寫」，你就輸了。如果你的答案是「已經接好了，開就行」，你就贏了。
這篇文章是我們用三個上線產品（Mind Threads、UltraProbe、Ultra Advisor）踩坑後整理的實戰指南。不是理論，是正在跑的 code。
現況：一個 API Key 撐起三個產品
先說實話。截至 2026-03-05，我們三個產品都只用 Google Gemini：
| 產品 | AI 用途 | 模型 |
|---|---|---|
| Mind Threads | 社群文案生成（35篇/天） | Gemini 2.0 Flash |
| UltraProbe | AI 安全掃描（12 攻擊向量） | Gemini 2.5 Flash |
| Ultra Advisor | 保單 OCR + 產品分類 | Gemini 2.0 Flash |
這在初期是對的。Gemini Flash 免費額度夠大、速度夠快、中文能力堪用。但這個架構有三個致命問題：
問題一：單點故障
2026 年 2 月 Google 出了一次 API 限流事件，我們三個產品同時掛掉。一個 API key、一個供應商、三個產品。這不是架構，這是賭博。
問題二：場景錯配
Gemini Flash 對「生成社群文案」很好，但對「精確的安全分析」和「結構化 OCR」不夠穩定。不同任務需要不同模型，但我們被綁死在一個。
問題三：無法升級
客戶問：「你的系統能串 Claude 嗎？能用 GPT-4o 嗎？」我們的回答只能是：「可以，但要改 code。」這不是產品化的回答。
解法：AI-Ready 架構的 7 個設計原則
以下是我們正在實施的改造，每一條都來自真實的踩坑經驗。
原則 1：Model Router，不綁死任何一家
// 錯誤做法：直接 import 特定 SDK
import { GoogleGenerativeAI } from '@google/generative-ai'
// 正確做法：統一介面 + 路由
interface AIProvider {
generate(prompt: string, config: AIConfig): Promise<AIResponse>
}
const router = createAIRouter({
primary: 'gemini-2.5-flash',
fallback: ['claude-sonnet-4-6', 'gpt-4o-mini'],
routing: {
'content-generation': 'gemini', // 文案用 Gemini（快）
'security-analysis': 'claude', // 安全分析用 Claude（精確）
'structured-extraction': 'gemini', // OCR 用 Gemini（多模態）
'code-generation': 'claude', // 程式碼用 Claude（邏輯）
}
})
為什麼重要：模型更新速度是按月計的。今天最強的模型，三個月後可能被超越。你的架構不該因為換模型就要改 business logic。
同一個原則用在發佈端，可以參考我們怎麼用抽象層管理對 Meta API 的依賴風險。
原則 2：Prompt Template Registry，Prompt 是資產，不是字串
我們犯的最大錯誤：把 prompt 直接寫死在 API handler 裡。
// 錯誤做法：prompt 散落在各個 API 檔案
const ANALYSIS_PROMPT = `你是專精於 prompt injection 防禦的 AI 安全稽核員...`
// 正確做法：集中管理 + 版本控制
const promptRegistry = {
'probe.scan-prompt': {
version: '2.1',
template: loadTemplate('probe/scan-prompt.md'),
model: 'claude-sonnet-4-6',
temperature: 0.3,
maxTokens: 4096,
schema: ScanResultSchema, // Zod schema for validation
},
'threads.generate-post': {
version: '1.4',
template: loadTemplate('threads/generate-post.md'),
model: 'gemini-2.0-flash',
temperature: 1.0,
maxTokens: 1024,
}
}
為什麼重要：Prompt 是你最核心的 IP。散落在 code 裡你無法追蹤哪個版本效果好、無法 A/B 測試、無法讓非工程師優化。
原則 3：Response Cache，相同問題不要問兩次
Ultra Advisor 做對了一件事：保單產品分類結果存到 Firestore cache。同一個保險產品，第二次查詢直接回 cache，不打 Gemini。
// Ultra Advisor 的快取策略（已上線）
async function lookupProduct(insurer: string, name: string) {
const cached = await db.collection('productCache')
.where('insurer', '==', insurer)
.where('productName', '==', name)
.limit(1).get()
if (!cached.empty) {
await cached.docs[0].ref.update({
searchCount: FieldValue.increment(1)
})
return cached.docs[0].data()
}
// Cache miss — call Gemini
const result = await gemini.generate(classifyPrompt(insurer, name))
await db.collection('productCache').add({ ...result, insurer, name })
return result
}
效果：相同產品查詢從 2-3 秒降到 50ms，Gemini API 費用減少 60%。
原則 4：Structured Output，AI 回的東西必須可驗證
UltraProbe 踩過的坑：Gemini 有時候回的 JSON 格式不對，整個掃描結果就壞了。
// 正確做法：用 Zod 驗證 AI 輸出
import { z } from 'zod'
const ScanResultSchema = z.object({
grade: z.enum(['A', 'B', 'C', 'D', 'E', 'F']),
score: z.number().min(0).max(100),
vulnerabilities: z.array(z.object({
name: z.string(),
severity: z.enum(['CRITICAL', 'HIGH', 'MEDIUM', 'LOW', 'NONE']),
finding: z.string().max(100),
suggestion: z.string().max(100),
}))
})
// AI 回傳後立即驗證
const raw = await aiRouter.generate(prompt)
const parsed = ScanResultSchema.safeParse(JSON.parse(raw))
if (!parsed.success) {
// Retry with stricter prompt, or fallback to another model
}
為什麼重要：AI 輸出是不確定的。你的系統不能因為 AI 回了一個怪格式就 500 Error。
UltraSite 後來把這條再推一步：Gemini 只回傳 JSON 內容，HTML 交給手工模板。
原則 5：BYOK（Bring Your Own Key），讓客戶用自己的 key
Mind Threads 已經實作了這個模式：用戶可以在設定頁面輸入自己的 Gemini API key，繞過平台的用量限制。
// Mind Threads 的 BYOK 實作
async function getApiKey(userId: string) {
const settings = await db.collection('userSettings').doc(userId).get()
const userKey = settings.data()?.geminiApiKey
if (userKey) {
return { key: userKey, source: 'user', unlimited: true }
}
return { key: process.env.GEMINI_API_KEY, source: 'platform', unlimited: false }
}
為什麼重要：
- 降低你的 API 成本
- 讓 Pro 用戶不受平台限制
- 未來可以支援多家模型的 key（Gemini key、OpenAI key、Anthropic key）
原則 6：MCP Server，讓你的系統能被 AI Agent 呼叫
這是 2026 最重要的趨勢。MCP（Model Context Protocol）讓 AI Agent 可以直接操作你的系統。
Ultra KB 已經是 Agent-Ready 架構（Notion 知識庫可被 AI 讀寫），但我們還沒有正式的 MCP Server。規劃中的接口：
// 規劃中的 MCP Server 工具定義
const tools = [
{
name: 'ultraprobe_scan',
description: '掃描一段 System Prompt 的安全漏洞',
input: { prompt: 'string', language: 'zh-TW | en' },
output: { grade: 'A-F', vulnerabilities: 'array' }
},
{
name: 'ultrakb_query',
description: '從知識庫查詢特定主題的文件',
input: { query: 'string', collection: 'string' },
output: { documents: 'array', relevance: 'number' }
},
{
name: 'threads_generate',
description: '生成一篇 Threads 貼文',
input: { topic: 'string', persona: 'viral|knowledge|story|quote' },
output: { content: 'string', hashtags: 'array' }
}
]
為什麼重要：當 Claude Desktop、Cursor、Windsurf 這些工具的用戶可以直接呼叫你的服務，你就不只是 SaaS，你是 AI 生態系的一部分。
後來我們在一個房仲平台專案實作這一層，先上線的不是 MCP，而是 REST API、OpenAPI spec、llms.txt 三個對外零件，做法整理在讓產品 AI agent 也能操控的實作清單。
原則 7：Observability，AI 呼叫必須可追蹤
我們現在缺的最嚴重的東西：AI 呼叫的可觀測性。
// 每一次 AI 呼叫都應該記錄
interface AICallLog {
id: string
timestamp: Date
model: string
provider: string
endpoint: string // 哪個 API 觸發的
promptTokens: number
completionTokens: number
latencyMs: number
cost: number // 估算成本
success: boolean
retryCount: number
cacheHit: boolean
userId?: string // 誰觸發的
}
為什麼重要：你不知道每個月花多少錢在 AI 上、哪個功能最耗 token、哪個模型最常失敗。沒有數據，就沒有優化。
我們的實施路線圖
以下是 2026-03-05 發文時的規劃與進度。
Phase 1（現在）：品牌層
- 所有服務標註 AI-Ready 能力
- 文件化現有 AI 整合點
- 統一 prompt 管理規範
Phase 2（Q2 2026）：技術層
- 建立 AI Router middleware（multi-model）
- 所有 prompt 遷移到 template registry
- 加入 Zod schema 驗證所有 AI 輸出
- 實作 response cache 層
Phase 3（Q3 2026）：生態層
- UltraProbe MCP Server
- Ultra KB 語意搜尋（RAG）
- AI Observability Dashboard
- 客戶 BYOK 支援多家模型
你現在就該做的事
不管你的產品在什麼階段，這三件事成本最低、價值最高：
把 AI 呼叫抽成獨立函數。不要在 business logic 裡直接
fetch(gemini_url)。一個aiService.generate()就夠了。把 prompt 獨立成檔案。
.md或.txt都行，不要寫死在 code 裡。記錄每一次 AI 呼叫的 token 數和延遲。
console.log就好，之後再建 dashboard。
這三件事加起來不到半天，但它們決定了你的系統三年後是「可以接 AI」還是「要重寫」。
結語
AI 不是功能，是基礎設施。
就像你不會等到需要搜尋時才加資料庫索引，你也不該等到客戶問「能接 AI 嗎」時才開始改架構。
我們用三個產品、數萬次 API 呼叫驗證了這套方法論。它不完美，但它正在運作。
如果你正在建 SaaS，現在就預留 AI 接口。未來的你會感謝現在的你。
Min Yi Xie, Founder, Ultra Creation 截至 2026-03-05，運營 6 個 AI 產品，日均 AI 呼叫 200+ 次
想讓你的系統 AI-Ready？ 從上面三件事開始。想聊聊你的架構，歡迎聯繫 Ultra Lab。
常見問題
SaaS 要怎麼設計，才能預留 AI 接口？
本文整理 7 個設計原則：用 Model Router 統一介面，不綁死任何一家模型；用 Prompt Template Registry 集中管理 prompt 並做版本控制；用 Response Cache 讓相同問題不要問兩次；用 Structured Output 驗證 AI 回傳的格式；用 BYOK 讓客戶用自己的 API key；用 MCP Server 讓 AI Agent 能呼叫你的系統；用 Observability 記錄每一次 AI 呼叫。目標是被問到「這能接 AI 嗎」時，答案是「已經接好了，開就行」，而不是「要重寫」。
為什麼 SaaS 不該只綁一家 AI 模型供應商？
本文列出三個問題。一是單點故障：2026 年 2 月 Google 出了一次 API 限流事件，只用 Gemini 的三個產品同時掛掉。二是場景錯配：Gemini Flash 適合生成社群文案，但對精確的安全分析和結構化 OCR 不夠穩定。三是無法升級：客戶問能不能串 Claude 或 GPT-4o，只能回答要改 code。解法是 Model Router：用統一介面加路由，依任務類型分派模型，並設定 fallback 模型。
AI 回傳的 JSON 格式不對，系統要怎麼處理？
用 Zod 定義輸出的 schema，AI 回傳後立即用 safeParse 驗證；驗證失敗就用更嚴格的 prompt 重試，或 fallback 到另一個模型。AI 輸出是不確定的，系統不能因為 AI 回了一個怪格式就 500 Error。
怎麼降低 AI API 的費用和回應時間？
把結果存成快取，相同問題第二次查詢直接回快取，不再呼叫模型。本文的例子是 Ultra Advisor 把保單產品分類結果存到 Firestore cache，相同產品查詢從 2-3 秒降到 50ms，Gemini API 費用減少 60%。另外要記錄每一次 AI 呼叫的 token 數、延遲和估算成本，才知道哪個功能最耗 token、哪個模型最常失敗。
想讓系統能接 AI，現在最該先做哪幾件事？
三件成本最低、價值最高的事：把 AI 呼叫抽成獨立函數，例如一個 aiService.generate()，不要在 business logic 裡直接呼叫模型 API；把 prompt 獨立成 .md 或 .txt 檔案，不要寫死在 code 裡；記錄每一次 AI 呼叫的 token 數和延遲，先用 console.log，之後再建 dashboard。三件事加起來不到半天。