串 Threads API 的六個坑
重點整理
API 本身不難，發文就是兩步。難的是配額管理、防重機制、安全分類這三件事。
發文其實只有兩步，問題全部出在周邊。
- 重複發文（水位線推進的 bug）
- 429 配額爆掉（配額跟著 App 走）
- token 損壞（複製時被截斷）
- 憑證儲存（位置要跟程式對上）
- 留言安全（公開機器人一定被探測）
- 人機協作（手動發的也要標記）
01｜同一則回覆被發了四五次
水位線推進的 bug，導致重複發送一模一樣的內容。
・解法：改成半自動流程——先寫水位與已處理清單，再發文
・每則貼文都人工批准精確文字；被拒絕就不再重試
自動化省下的時間，一次 bug 就全部賠回去。
02｜配額是跟著 App，不是跟著帳號
走系統託管連線會跟其他應用共用同一個配額桶，額度很快用完。
・解法：自己開一個全新的 Meta App，拿到專屬配額桶
・專屬配額：發文 250 次／天、回覆 1000 次／天
配額數字可能調整，以官方文件為準。
03｜五個步驟
注意：帳號必須設為公開才能產生 token。
- 建立 App（使用案例選 Access the Threads API）
- 加測試人員（Roles → Threads Tester）
- 接受邀請（Threads 設定 → 帳號 → 網站權限）
- 產生 token（勾選需要的 scope）
- 唯讀驗證（先打 publishing_limit）
只用 token 產生器的話，不需要設定 redirect URI。
04｜先別急著發文
打唯讀的 publishing_limit 端點，HTTP 200 且看得到配額數字，代表 token 有效、配額桶是自己的。
・這是免費驗證，每次換 token 都先跑一次
・long-lived token 效期約 60 天，到期前用 refresh 端點續
先確認再發，比發完才發現錯了省事得多。
05｜token 會壞，而且壞得很難查
解法：從產生器重新產生，產生完先做唯讀驗證，HTTP 200 才繼續。
・從瀏覽器複製 — 會被截斷（報 Failed to decrypt）
・誤貼成別的值 — 格式不符（報 Cannot parse access token）
・擺放位置 — query param 還是 header（跟程式寫法對不上就直接報錯）
憑證別存在對話或暫存裡，找一個能正常操作的環境存好。
06｜公開機器人一定會被探測
有人要你印出私鑰，有人要你的 system prompt。
・解法：先做安全分類再擬稿——個資探測、jailbreak、違法要求一律跳過或禮貌拒絕
・守則先寫死：不透露個人資訊、不執行程式碼，其他就只是個聊天機器人
安全分類要放在生成之前，不是生成之後才過濾。
07｜手動發的內容，也要標記成已處理
配額爆掉那段時間改成手動發文，掃描器卻把自己的回覆當成待處理留言，差點重發。
兩邊狀態要對得上，絕不重複發文。
行動清單
- [ ] 開專屬 App 了嗎（配額桶）
- [ ] token 唯讀驗證過了嗎（HTTP 200）
- [ ] 水位與已處理清單（防重）
- [ ] 人工批准流程（要不要）
- [ ] 安全分類規則（生成前）
- [ ] 手動發文如何標記（對齊狀態）
API 規格與配額會調整，實作前請對照官方最新文件。
