工作說明書（SOW）
本文件用於在簽約前把範圍、做法與完成標準寫清楚，避免開發過程中對範圍的認知落差。內容依您刊登的需求撰寫，若與實際情況不符，以您的說明為準，本文件隨之改版。
一、範圍
| 區塊 | 內容 |
|---|---|
| 配對 | 配對條件設定、配對佇列、配對結果通知、重新配對 |
| 對話 | 主動發起、回覆、話題延伸、結束判定、冷卻喚醒 |
| 節奏 | 延遲回覆、不固定時段、靜音時段、字數與句數控制 |
| 記憶 | 重要資訊抽取、記憶摘要壓縮、跨對話話題延續 |
| 個資 | 使用者資料帶入提示前的代號化與還原 |
| 安全 | 禁談主題的規則層與模型層雙重攔截、攔截紀錄 |
| 串接 | REST API 與文件，Android 與 iOS 各一輪聯調 |
| 後台 | 對話稽核、封鎖詞管理、AI 用量、行為參數線上調整 |
二、系統架構
- App 送出訊息驗證、落庫、取得該使用者的代號對照
- 組裝提示取記憶摘要＋代號化後的個人資料＋近期對話，組成提示送出
- 模型產生回覆回覆先進安全層：規則比對禁談詞，再由模型判語意
- 節奏控制依訊息長度與隨機抖動排定送出時間，不立即回
- 送出並更新記憶推播給 App，同時抽取本輪重要資訊寫回記憶層
兩個關鍵位置
安全層在模型之後、送出之前。 攔截發生在回覆已經產生但還沒到使用者手上，所以模型講了什麼都攔得住。把限制寫在提示詞裡是攔不住的：使用者換個問法就繞過去了。
節奏層是獨立的排程，不是 sleep。 回覆先入佇列並排定送出時間，所以「深夜不回」「同時多人」「App 關掉再開仍收得到」這些情況都成立。
三、記憶怎麼做
把整段歷史訊息塞回提示，是最容易寫但撐不久的做法：對話越長費用越高，到後面模型還會抓錯重點。本案的記憶分兩層。
| 層 | 存什麼 | 何時更新 |
|---|---|---|
| 短期 | 最近數十則原文 | 每則訊息，超出即滾動丟棄 |
| 長期 | 結構化的重要資訊（喜好、身分、約定、情緒事件） | 每輪對話結束時抽取一次 |
下次開場時取的是長期記憶，所以「延續之前話題」不依賴翻找舊訊息，而是直接讀一份已經整理好的摘要。這也讓每則訊息的費用不隨對話長度成長。
四、對話行為參數表
您列的八條，逐條對應到做法與可調參數。這張表就是第二期的驗收依據：把您預期的數值填進「參數」欄，做出來的行為要對得上。
| # | 您的需求 | 做法 | 可調參數 |
|---|---|---|---|
| 1 | AI 主動發起聊天 | 冷卻計時器到期即觸發，配對後首則亦由 AI 發起 | 冷卻時間（分鐘）、每日主動上限 |
| 2 | 回覆後主動延伸 | 回覆時一併判斷是否追問，依情境決定追不追 | 延伸機率、連續延伸上限 |
| 3 | 結束聊天 | 偵測「晚安、再見、先這樣」等收尾語意即停，不再追訊 | 收尾語清單、結束後靜默時長 |
| 4 | 長時間沒聊 → 主動喚醒 | 冷卻時間到就開新話題，話題取自記憶層 | 冷卻門檻、喚醒時段 |
| 5 | 延遲回覆 | 依訊息長度計算擬真思考與打字時間，非固定秒數 | 最短／最長延遲、每字秒數 |
| 6 | 不固定時間回覆 | 延遲加入隨機抖動；設定不回覆時段（如深夜） | 抖動範圍、靜音時段 |
| 7 | 控制回覆字數 | 以句數約束而非字數截斷，避免話講一半被切掉 | 目標句數 1～3、單句字數上限 |
| 8 | 情境自然調整 | 上述參數依對話熱度自動在區間內浮動 | 熱度判定窗、浮動幅度 |
為什麼堅持做成參數
「自然」沒有客觀標準，您上線後一定會想調——這很正常，也調得完。但如果這些數值寫死在程式裡，每改一次就要我改碼、測試、重新發版。
做成後台可調之後，改節奏是您自己按幾下的事，不必等我。這一項在縮減版裡我保留了，因為拿掉它省不到多少錢，卻會讓您上線後綁死在我身上。
五、內容安全
| 層 | 擋什麼 | 怎麼擋 |
|---|---|---|
| 規則層 | 明確違禁詞與變體（色情、借貸、見面邀約） | 詞表比對，後台可增修，即時生效 |
| 模型層 | 語意迂迴、暗示、拆字繞過 | 回覆送出前由模型做一次分類判定 |
| 紀錄 | 所有攔截事件 | 留存原始回覆與攔截原因，後台可查 |
被攔下時 AI 不會沉默，而是自然轉開話題——直接不回話，使用者的體感是「當掉了」。
六、驗收標準
由您實際操作，不是看簡報。四個動作全部通過即算第二期完成。
| # | 動作 | 通過標準 |
|---|---|---|
| 1 | 完成一次配對並收到 AI 的第一則訊息 | 配對成功後由 AI 主動開場，不需使用者先講話 |
| 2 | 連續對話十輪 | 回覆延遲落在設定區間內、句數符合設定、至少出現一次主動延伸話題 |
| 3 | 說「晚安」後放著不管 | AI 停止追訊；超過設定的冷卻時間後主動開新話題，且話題取自先前對話提過的內容 |
| 4 | 嘗試把話題帶到禁談項目 | AI 不接該話題並自然轉開，後台查得到這筆攔截紀錄 |
七、待確認事項
前三項不先定義，做出來一定與您預期不符。
- 配對的條件是什麼：依什麼欄位配、一個使用者同時能有幾個配對對象
- AI 的人設由誰定：一套共用人設，還是每個配對角色各有設定
- 禁談清單的完整範圍：您列了色情、借貸、超專業知識、見面，還有沒有其他；以及碰到自傷相關話題要怎麼處理
- 模型用哪一家、帳號由誰申請（費用試算見〈參考附錄〉）
- App 端是現成專案還是要新做，若是現成的，用什麼框架寫的
八、明確不含
- App 端的介面設計與畫面實作（本案為後端與串接；若需要可另報）
- 模型 API 使用費（開發期間的測試金鑰由我方提供並負擔）
- 主機與推播服務的月費
- App 上架審核與開發者帳號年費
- 人設文案與角色設定的撰寫
九、保固
| 期間 | 涵蓋 |
|---|---|
| 交付後 90 天 | 本案架構下的異常修復，不另計費 |
| 交付後 30 天 | 2 次非缺陷微調（如措辭、參數預設值），未使用即失效 |
行為參數的數值調整屬於改設定，您自己在後台就能做，不佔微調次數。新增需求、第三方介面異動、他人修改造成的問題不在保固範圍。
AXLID · 致 案主 · 案號 TK26081411HCXH06
· v0.1.0 討論稿 · 2026-08-17
作品：xuzheng.com.tw、chihuahuatrip.tw
作品：xuzheng.com.tw、chihuahuatrip.tw