參考附錄
與工作說明書、報價單共用的參考資料，獨立成一份避免重複。
一、模型費用試算
陪聊型對話的每則訊息都短，但頻率高。以下以每位活躍使用者每天 40 則往返、提示帶記憶摘要約 800 token 估算。
| 活躍使用者 | 每日訊息 | 輕量模型月費 | 中階模型月費 |
|---|---|---|---|
| 100 人 | 4,000 則 | 約 NT$900 | 約 NT$4,500 |
| 500 人 | 20,000 則 | 約 NT$4,500 | 約 NT$22,000 |
| 2,000 人 | 80,000 則 | 約 NT$18,000 | 約 NT$90,000 |
記憶層的做法直接決定這張表
如果把整段歷史訊息塞回提示，提示長度隨對話累積成長，上面的數字到第二個月就會翻好幾倍。
本案的記憶存的是壓縮過的結構化摘要，長度不隨對話成長，所以月費和使用者數成正比，不和使用時間成正比。這是這個架構最實際的價值。
二、模型選型
| 輕量模型 | 中階模型 | |
|---|---|---|
| 對話自然度 | 日常閒聊足夠，長句情緒回應略平 | 明顯較好 |
| 延遲 | 1～3 秒 | 2～5 秒（本案有擬真延遲，這個差距使用者感受不到） |
| 費用 | 見上表 | 約 5 倍 |
| 建議 | 開發期兩者都接，用您的真實情境比較後再定。本案有擬真延遲設計，速度差異被吸收掉，所以決策點只在自然度與費用 |
三、擬真延遲怎麼算
固定延遲幾秒很快就會被看穿。本案的送出時間由三段組成：
| 段 | 算法 | 預設 |
|---|---|---|
| 思考時間 | 依收到的訊息長度換算 | 0.5～3 秒 |
| 打字時間 | 依要送出的回覆字數 × 每字秒數 | 每字 0.15 秒 |
| 隨機抖動 | 在總時長上加一個隨機比例 | ±40% |
三段相加後若落在靜音時段內，則順延到時段結束——這就是「哪些時段不回覆」。全部參數在後台可調。
四、技術選型
| 項目 | 選擇 | 理由 |
|---|---|---|
| 後端 | Python（非同步） | 模型串接與 I/O 密集的排程都是它的強項 |
| 資料庫 | PostgreSQL | 對話、記憶、稽核都需要交易保證；記憶檢索用得上向量擴充 |
| 排程 | 獨立的送出佇列 | 延遲回覆與喚醒都靠它，不能用 sleep 佔住連線 |
| 推播 | Firebase Cloud Messaging | 雙平台通用，本案量級在免費額度內 |
若您的 App 端已有既定的後端技術棧，這一節可以配合調整，不影響報價。
AXLID · 致 案主 · 案號 TK26081411HCXH06
· v0.1.0 討論稿 · 2026-08-17
作品：xuzheng.com.tw、chihuahuatrip.tw
作品：xuzheng.com.tw、chihuahuatrip.tw