Threads 留言自動回覆 — 給決策者的評估摘要

日期：2026-08-19

這份是給要拍板的人看的。技術細節、官方出處與逐條驗收紀錄另有一份完整技術版，可提供給您的工程人員。

一頁摘要

您的問題一句話回答
能不能做？能。Threads 官方就提供了這些功能，不需要任何偷跑或模擬人操作的手段。
要多久？程式本身是小工程。真正的時間花在 Meta 的審核，而審核要多久，Meta 官方沒有承諾。
要多少錢？每月的機器費用小到可以忽略（約一杯咖啡）。真正的成本是人：寫答案、審答案、每天處理機器接不住的那些留言。
最壞會怎樣？機器會偶爾答非所問——但那是當場看得見、五分鐘能改掉的錯。整套設計就是為了讓錯誤停留在這一類。
您要準備什麼？三件事：確認帳號登記在誰名下、決定答案由誰寫、先收兩週真實留言看看客人到底在問什麼。第三件今天就能開始，不花一毛錢。

1. 這套東西實際上是什麼

想像您在櫃台請了一位新人。

他手上只有一本您親手寫好、也親自審過的問答本。他唯一的工作是聽客人問什麼，翻本子找出對應的那一頁，照著念。找不到，他就說一句「這題我請同事回覆您」，然後把問題抄進待辦本，交給真人。

他沒有筆。他不能自己寫字。

這是整個方案最重要的一句話。市面上常見的做法是讓 AI 自己想答案——那樣做，AI 查不到資料時會編一段聽起來很合理的假規定，例如憑空生出一條退貨政策。這種錯的可怕之處是：它讀起來完全正常，沒有人看得出來是假的，直到客人拿它跟您爭執。

我們的做法出錯時長什麼樣？答非所問——客人問 A、機器回了 B 的答案，任何人一眼看得出來，改法是把那條文字改掉，五分鐘完成。

兩者的差別不在錯得多不多，在錯得看不看得見。 對客服來說，看得見的錯遠比看不見的便宜。

但上面這段是「為什麼這樣設計」的理由，不是實測數字。 這套做法實際上答得準不準，要等第 7 節的第二階段「只看不說」跑過真實留言之後才會有數字——在那之前，任何人（包括我）講的都只是設計意圖。

每則留言會走的兩條路

客人在貼文底下留言
   |
   +-- 本子裡有這題 --> 原封貼出那條標準答案 --> 約半分鐘後客人看到（全自動，人不介入）
   |
   +-- 本子裡沒有 ----> 貼出唯一一句通用回覆：「請至官網／粉專查詢更多」
                        + 把留言完整抄進待辦清單
                        --> 隔天真人逐則回覆
                        --> 這題補進本子，下次就會自動接住

第二條路是這套系統會越用越好的原因：每一則接不住的留言，都會變成本子裡的新一頁。

2. 它不會做什麼

這一節刻意獨立，是為了讓雙方在動工前對「做不到什麼」有一致認知，避免上線後才發現期待落空。

它不會說明
自己編答案見上一節。它只能念本子裡的字。
即時回覆實際上要半分鐘左右才會顯示。對常見問題的客服沒有實質影響，但請不要對外宣稱是即時的。
私訊客人Threads 沒有開放讓程式發私訊。所以「公開先回一句、細節轉私訊處理」這個常見做法，程式做不到。所有自動回覆都發生在公開留言區——這也是為什麼那句通用回覆必須寫得夠安全。
回覆別人貼文底下的留言只能處理您自己貼文底下的留言。日後若想擴充成「監看提到本品牌的貼文並回應」，那是另一套權限，要重新送審。
處理客訴留言只要出現退費、投訴、檢舉、消保、律師這類字眼，一律不經機器判斷、直接轉真人。這是寫死的規則。
查訂單答案因人而異、又涉及個資，一律真人處理。
決定要不要隱藏惡意留言技術上做得到，但隱藏一則留言會連帶把它底下所有回覆一起藏掉——包括別人在那串裡問的正常問題。所以建議這個動作保留給真人判斷。

還有一個容量上限：一天最多自動回 1,000 則。除非您的帳號單日留言量會破千，否則這不是限制。

另外每則回覆最多 500 個字（表情符號會吃掉比較多額度），所以答案寫不完的，正確做法是放官網連結。這其實是好的約束——超過 500 字的答案本來就不該塞在留言區。

3. 要多久

時程要拆成兩段看，因為這兩段的性質完全不同。

第一段：我們能控的——寫程式、建答案庫、內部測試。可以排期、可以趕工的小工程。

第二段：Meta 的審核——不能控。 要讓 Meta 主動通知我們「有人留言了」，必須先過三關：應用程式審核、商家身分驗證、應用程式正式上線。審核時 Meta 會實際操作我們的系統來確認功能屬實。

⚠ Meta 官方文件沒有寫審核要幾個工作天，也沒有任何時間承諾。 網路上流傳的天數都是別人分享的經驗，不是官方數字，所以我不會把任何數字寫進承諾裡。

還有一個順序陷阱：因為審核時 Meta 要實際操作我們的系統，所以必須先把系統做到能跑，才送得出審核——不能等審核過了再開發。這代表開發工時要先投下去，而通過與否、何時通過，雙方都控制不了。

還有一個要靠您配合的時程點：要用真實帳號測試之前，我們必須先在 Meta 後台送出一張測試者邀請，再由您那邊的帳號自己去點「接受」。這一步我們做不了，排時程時要把「等對方點接受」算進去。

比較安全的安排：第 7 節的第一階段完全不需要審核、可以立刻開始，而它產出的東西正好是決定「這套系統值不值得做」的依據。

4. 要多少錢

機器的錢：可以忽略

項目每月
幫忙判斷「這題是本子裡的第幾題」的 AI 服務月留言 1,000 則約 美金 0.16 元；就算月留言一萬則，也只有 美金 1.6 元
放系統的主機約 美金 5–6 元，或直接用您現有的網站主機
Threads 本身Meta 官方文件沒有寫任何收費機制

這代表選型不必為了省錢犧牲準確度。 如果測試發現便宜的 AI 判斷得不夠準，換貴一點的，月費仍然停留在美金個位數。

人的錢：這才是真正的成本

項目性質
撰寫並審核答案庫（建議 30–50 條起步）一次性，但份量最重。每一條答案都會被原封不動地公開貼出去，所以每一條都要有人簽名負責
每天處理待辦清單持續性。機器接不住的留言仍然要真人回，只是從「每則都要看」變成「只看接不住的那些」
開發與送審一次性

一個常見的誤會要先講清楚

買了 ChatGPT 的月費訂閱，不等於程式就能用。 程式串接走的是另一套按用量計費的服務，跟訂閱是兩本帳。上表估的就是那一套的費用（也正是因為它便宜，所以可以忽略）。

5. 會出什麼包

五類風險，以及每一類防不掉的部分是什麼。

風險會怎樣怎麼防防不掉的
① 答非所問客人問 A，機器貼了 B 的標準答案，公開可見上線前先跑「只看不說」階段（見第 7 節），實測配對錯誤率再決定要不要開；上線後每條答案有獨立開關，出錯就單獨關掉、不必停整套配對錯誤率沒辦法降到零。 這套設計不是消除錯誤，是把錯誤限制在「當場看得見、五分鐘改得掉」的範圍內
② 漏掉客人的留言Meta 通知我們的那條線斷了，留言就進不來——不會有錯誤訊息，只是客人覺得被無視不能只等通知。系統每小時自己回頭把最近的貼文掃一遍，比對有沒有漏接兩次補掃之間會慢一點。而且停機一旦超過 36 小時，那段期間的通知 Meta 就永久丟棄、再也不補送——只能靠系統自己回頭掃。所以「復機後主動回掃」不是貼心功能，是唯一的救援手段
③ 半夜安靜地停掉系統要有一把 Meta 發的鑰匙才能代表您的帳號說話，這把鑰匙 60 天要換一次。忘了換就安靜停住——不噴錯，只是不再回覆任何人換鑰匙自動化，並在剩 14 天、剩 3 天各發一次警報鑰匙一旦真的過期，就補救不回來了——沒有任何辦法讓它復活，唯一的路是再麻煩您重跑一次授權。（還有第二個時鐘：您當初「授權給這個程式」本身效期 90 天，是靠同一個換鑰匙的動作一起延長的。所以換鑰匙這件事斷掉，兩件事會一起死。）另外若警報管道本身壞了（信箱沒人看）仍可能漏
④ 品牌帳號被外人拿去發言有人冒充 Meta 對我們的系統下假指令，讓您的帳號公開發文驗證每一則通知的來源簽章（見第 8.3 節，這是整份評估唯一的資安項目）驗證的前提是我們的密鑰沒有外流。 密鑰一旦流出去，簽章就形同虛設——所以 8.2 節那份人員名單的清理，跟這一條是同一件事
⑤ 客訴被機器人回了客人在氣頭上抱怨，機器貼一句罐頭回覆——比不回覆更傷關鍵字硬性攔截，優先於任何 AI 判斷：含退費、投訴、檢舉、消保、律師等字眼直接進真人佇列，機器連看都不看黑名單列不完所有的情緒表達。 有人會用很客氣的措辭表達強烈不滿，那種攔不住——這是為什麼那句通用回覆必須寫得即使貼給生氣的人也不會火上加油

還有一項不是技術風險，但要先說：答案庫的內容如果本身寫錯，那個錯誤會被大量、重複地發送出去。所以每一條答案都要記錄「是誰審的、什麼時候審的」。這是人的責任，不是系統能解決的。

6. 您要準備什麼

以下七件事，前三件會實質改變方案的形狀，建議優先。

#要確認的事為什麼會影響方案
1Meta 的應用程式與商家檔案，登記在誰名下？最急的一件，見第 8.2 節
2答案從哪來？ 已經有現成的客服話術／常見問答文件，還是要從零寫？這是本案最大的一次性工時。有現成文件的話，時程可以大幅縮短
3一天大約幾則留言？決定 1,000 則的上限夠不夠用，也決定真人每天要花多少時間處理待辦
4Threads 帳號目前是公開還是私人？私人帳號收不到 Meta 的留言通知，整套機制會靜默失效——不會報錯，只是什麼都不會發生。企業帳號必須是公開的
5能否接受留言文字送到國外處理？見第 8.1 節，這件事需要您明確點頭
6出錯時由誰對客人負責？涉及責任邊界，建議動工前先講清楚
7原本的回覆系統是怎麼壞的？目前只知道「原有系統出了問題」。若能知道具體是怎麼失效的，新系統才能避免重蹈覆轍
8客人要求刪除自己的留言資料時，誰處理？Meta 的平台條款要求：必須對外提供一個明確、好找的管道讓人要求刪除資料，通常做法是在隱私政策頁放聯絡方式。這件事要在送審之前就備妥，因為隱私政策網址是送審材料之一

7. 建議的走法

階段做什麼要 Meta 審核嗎產出
第一階段收兩週真實留言，人工分類成一張表不用「常見問題佔幾成」這個數字 ＋ 答案庫初稿
第二階段只看不說：機器讀留言、跑判斷、寫進待辦，但一個字都不發只要讀取權限命中率與配對錯誤率的實測數字
第三階段開啟自動回覆，先只開最有把握的 5–10 條要上線
第四階段依照接不住的比率持續補答案不用命中率隨時間往上走

為什麼第一階段今天就該開始

整套系統的價值，全部押在「常見問題佔幾成」這一個數字上。

⚠ 如果實際上多數留言是在問「我的訂單到哪了」——那是因人而異、沒有固定答案的問題——那該做的就不是這套系統。

而這個判斷，只需要兩週的留言紀錄和一張試算表就能做出來。不需要等任何審核、不需要寫任何程式、不花任何錢。

所以第一階段既是開發的第一步，也是這個專案的煞車。

8. 三件必須讓您點頭的事

這三件不是技術細節，是需要您知情並同意的決定。

8.1 客人的留言會被送到國外

判斷「這題是本子裡的第幾題」這個動作，是交給一家美國公司（OpenAI）的服務做的。這代表留言文字會傳到國外的伺服器。

⚠ 在法律上這叫「個人資料的跨境傳輸」，不只是「用了一個工具」。

已經查證的事實：

降低這件事風險的三個做法，都可以直接實施：

  1. 只送必要的字——只送留言內容，不送留言者的帳號名稱與頭像。判斷是哪一題，不需要知道是誰問的。
  2. 要求對方不要留存——呼叫時就設定不保存。
  3. 敏感的根本不送出去——涉及個資的類別（例如訂單查詢）在關鍵字那一關就被攔下來了，這類留言根本不會離開我們的機器。

如果您仍有顧慮，還有兩個選項：向該公司申請「零留存」的特別條件，或改用可以在自己機器上跑的 AI（後者的判斷準確度要另外評估）。

之所以必須讓您知道：留言的客人並不知道自己的留言會被送到國外。若這套系統要對外收費營運，建議在您的隱私政策裡寫明。

要特別說清楚一件事：本文只處理到「這件事存在、您需要知道」這一層。台灣個資法本身有哪些義務，本評估沒有涵蓋——別把 8.1 節當成合規已經做完了。若要對外收費營運，這部分建議另請專業確認。

8.2 那兩樣東西登記在誰名下

這是所有待辦裡最急、而且今天就能查的一件。

Meta 的審核結果不是掛在某個人身上，是掛在兩樣東西上：應用程式（權限審核綁在這裡）與商家檔案（商家身分驗證綁在這裡）。

所以真正要問的不是「有沒有做完」，而是「這兩樣東西登記在誰名下」。三種情況，成本天差地遠：

情況商家檔案應用程式後果
A貴公司名下貴公司名下最好。 整理一下管理員名單、把鑰匙換掉就能接手，審核不必重來
B貴公司名下第三方建立商家驗證留得住，應用程式的審核留不住。 要用貴公司自己的應用程式重建並重新送審
C第三方名下第三方建立等於從零開始。 而且在對方關閉之前，現有服務隨時可能中斷

現在就能查，不必等任何人：登入 Meta 商務管理平台看商家檔案的擁有者與管理員名單；登入 Meta 開發者後台看該應用程式的擁有者與成員名單。

⚠ 這兩份名單本身是資安問題，不是行政問題：名單上任何一個不該再有權限的帳號，都等於一條能用貴公司品牌帳號公開發文的路徑。名單上該只剩下現在真的需要的人。

建議動工前先做三件事：清理這兩份名單、把應用程式的密鑰換掉、把舊的存取權限撤銷後重新產生。

這件事的優先順序高於本專案的任何開發工作——系統再嚴謹，也擋不住一個有合法權限、從側門走進來的發文者。

（本節是帳號歸屬與行政層面的判斷，不是 Threads 功能上的限制。上表三種情況的後果，是依「審核綁應用程式、驗證綁商家檔案」這兩項機制推論出來的，實際情形請以您在 Meta 後台看到的擁有者資訊為準。）

8.3 有人可能冒充 Meta 對我們的系統下指令

這是整份評估裡唯一的資安項目。

系統必須有一個公開在網際網路上的接收窗口，Meta 才連得到、才能通知我們有人留言。問題是：任何知道這個窗口位置的人，都可以自己發一則假的「有人留言了」通知過來——不驗證來源的話，系統會照著假通知去用您的品牌帳號公開發文。

防法是現成的：Meta 在每則通知上都附了一組簽章，我們收到後用只有雙方知道的密鑰重算一次，對不上就丟掉。

值得注意的是，Meta 官方的措辭是「不強制，但你應該做」——對一個會自動公開發文的系統，我們視為強制。差別在於：不驗證，攻擊面是「任何人都能讓您的品牌帳號公開發言」；驗證了，攻擊者得先拿到我們的密鑰（這也是 8.2 節要換密鑰的原因）。

附註

本文是決策摘要，不是技術規格。技術細節、官方文件出處、以及逐條驗收紀錄，另有一份完整技術版，可提供給貴公司的工程人員。

技術版的事實層經過四輪獨立審查（前三輪判定不通過，第四輪全項通過），共補入 16 項缺口、更正 3 處誤述。本文的每一項事實均引用自該版本，未另行新增。

本文為技術可行性評估，不構成法律意見。 第 8.1 節關於跨境傳輸與隱私政策揭露的部分，若這套系統要對外收費營運，建議另請專業確認。