自動找案的真實距離：四天、638 則貼文，換一則只有 3 個人看到的回覆

事情的起點是一則貼文。

有人在 Threads 上發案：公司要做一套預約自動化系統，內容包含系統串接、AI 回覆篩選、安排時段、排除衝突時段、系統提醒通知，問有沒有工程師或資訊公司可以報價。

底下三十幾則回覆。點開來看，大半長這樣：「你好 我們是 ⋯⋯ 我們有提供 AI 客服及語言訓練模型等服務 請先參考我們公司官網 希望有討論需求的機會」。

包括我自己那則。

我盯著那三十幾則罐頭看了一會，想的不是「我要貼更快」，是「這件事整個做錯了」。於是花了一個下午，做了一支雷達。以下是過程，包含四個我一度以為是別人的問題、結果全是我自己造成的失敗。

一、第一條路是死的

先講技術路徑，因為多數人會直覺想到「用官方 API 啊」。

Meta 的 Threads 確實開了一個 /keyword_search 端點，可以搜全站公開貼文，文件甚至明講：搜到的貼文你可以回覆、引用、轉發。這完全就是我要的東西，額度也大方——搜尋每天 2,200 次，發文每天 250 則。

我拿現有的 token 打過去，回這個：

{"error":{"message":"Application does not have permission for this action","code":10}}

要用這個端點，得申請 threads_keyword_search 權限，而這個權限必須過 Meta 的 App Review：錄螢幕示範、可能還要企業驗證，一到兩週起跳。沒過審的話，這個端點只會搜到「你自己發的貼文」——等於沒用。

所以官方這條路要走，但不能等。當天能動的只剩瀏覽器自動化：開一個瀏覽器，像人一樣去搜尋頁把結果讀下來。

（名詞解釋：瀏覽器自動化就是寫程式去操作一個真的瀏覽器，點什麼、讀什麼都由程式決定。缺點是網站改版就會壞，好處是不用等任何人審核。）

二、我決定不做全自動

這是整個專案最重要的一個決定，而它跟技術無關。

原始需求是「自動找案、自動回覆」。做得到，但我把它砍成「自動找案、自動寫草稿、人工決定貼不貼」。三個理由：

第一，平台會擋。 我之前做過另一支 Threads 批次留言的工具，間隔六秒就觸發了 Meta 的反濫發偵測，錯誤代碼 4279009，得把間隔拉到 75 秒才過得去。同一段推銷文貼到多則陌生人貼文底下，是這類系統最敏感的行為模式。帳號被限流之後，你連正常發文都沒有觸及。

第二，罐頭沒有用。 那三十幾則回覆就是實證。在一則熱門發案文底下，能被看見的不是「我們有提供服務」，是能講出對方沒想到的那一句。

第三，前期你根本不知道要調什麼。 關鍵字撈得準不準、評分嚴不嚴，都要看過實際結果才知道。看不到就沒得調。

所以最終的形狀是：每三小時掃一輪，判讀完把高分的那幾則連同一份寫好的回覆草稿推到我的 Telegram，我在手機上看一眼，複製、必要時改一改，自己貼上去。

三、真正花時間的不是爬蟲，是寫下「我們不接什麼」

爬蟲的部分大概二十分鐘。判讀的部分——也就是「這則貼文值不值得回」——才是核心，而它的品質完全取決於一份文件。

我把官網三個頁面、服務定價的原始設定檔、加上這幾年自己做過的專案，整理成一份接案能力書。裡面有價格（單頁官網 9,000 起、多頁 18,000 起、機器人 50,000 起⋯⋯）、有可以拿來佐證的實績、有評分規則，還有一份「不接」清單：

純平面設計零星件、硬體韌體、區塊鏈博弈、人力派遣長期駐點、要求無償比稿、明顯低於門檻的預算、以作品集交換、同業推銷、純抱怨與產業評論。

這份清單是整個系統裡最有價值的東西。

因為 AI 缺的從來不是聰明。它讀得懂中文，判斷得出語氣，看得出誰在發案誰在抱怨。它缺的是你的價目表和你的禁區。你不告訴它「兩萬預算的五頁官網我們接得起來」，它就沒有基準可以判斷。你不告訴它「要求先做免費 demo 的直接扔掉」，它就會很努力地幫你寫一封熱情的回覆給一個永遠不會付錢的人。

實測的結果很乾淨。第一輪掃了 85 則，判 0 分的包括：接案平台的自我推銷、設計師自薦、室內設計裝潢需求、機場接送、日股投資心得、越南文的動漫閒聊、以及一則「想找人架作品集網站，沒什麼預算，可以用作品集交換嗎」。

全部擋掉，一則都沒漏進來。

四、四個偽裝

接下來是這個下午最花時間、也最值得寫下來的部分。

要讓排程用的瀏覽器能搜到最新貼文，它得先登入。而這一步，我卡了將近一小時，中間經歷四次誤判——每一次，壞掉的東西都偽裝成了另一種壞掉。

偽裝一：我的檢查打斷了使用者。

我寫了一支登入程式，每三秒檢查一次頁面狀態，判斷登入完成了沒。問題是 Threads 的登入要跳到 Instagram 認證再跳回來，而在跳轉的中間那個瞬間，頁面剛好符合我的「已登入」條件，程式就把頁面導走去驗證——驗證失敗，又導回登入頁。

使用者看到的症狀是：在 Threads 和 IG 之間無限跳，永遠登不進去。

看起來完全像是 Meta 那邊的問題。實際上是我的檢查程式在破壞它要檢查的東西。修法是把整個輪詢改成被動的：登入過程中一行都不碰頁面，只讀瀏覽器存的登入憑證。

偽裝二：登入了，但登的不是那個。

改成讀憑證之後，我把判斷條件寫成「有沒有名為 sessionid 的登入憑證」。有了就算成功。

結果 Instagram 的憑證也叫這個名字。使用者的 IG 一登入，我的程式九秒後就宣告成功、把視窗關掉——而 Threads 那一步，他根本還沒點。

IG 登入不等於 Threads 登入。 這句話寫下來很蠢，但在程式裡，它是一個字串比對的疏忽。

偽裝三：驗證用了一個成功和失敗都會出現的訊號。

我以為前兩個修完就沒事了，因為程式印出「✅ 登入完成，搜尋讀得到 10 則貼文」。

問題是——沒登入也讀得到貼文。Threads 的搜尋頁對未登入的人一樣會回結果，只是它會悄悄無視你「只看最新」的設定，塞給你 2024、2025 年的舊文。所以「讀得到貼文」這件事，在成功和失敗兩種情況下都成立，它根本不能當證據。

最後找到的可靠訊號是：看回傳結果的時間戳，前六則裡有幾則是七天內的。這個訊號只有在真的登入時才會出現。

這是我覺得最該記住的一條：驗證用的訊號，必須是「只有成功時才會出現」的東西。一個成功和失敗都會亮的燈，不是燈，是裝飾。

偽裝四：帳號被停用，長得跟沒登入一模一樣。

修完前三個，程式終於說登入成功了。但實際去掃，搜尋頁一片空白——零則貼文，零個登入連結。

我把整頁的文字撈出來看，才發現：

我們已停用你的帳號 ⋯⋯ 經檢閱後，我們發現你的帳號仍然違反《社群守則》中有關帳號誠信的規則 ⋯⋯ 你無法對此處置要求再次檢閱。

登入時挑到了一個閒置的舊帳號，而那個帳號在半年前就被停用了。Threads 對停用帳號的處理是把所有網址都導到同一個公告頁——首頁、搜尋頁、個人頁，全部。那個頁面沒有內容，但也沒有「登入」按鈕，所以在我的偵測邏輯裡，它既不算登出，也不算登入，就是一片什麼都沒有的空白。

換對帳號，三十秒就過了。

四個偽裝，共同點是：每一個失敗，都長得像另一種失敗。 而前三個更難堪一點——它們不是功能壞了，是我寫來確認功能好不好的那段程式在說謊。

自動化系統最危險的狀態從來不是壞掉。壞掉會停、會報錯、會有人來罵。危險的是壞得很像正常：它每天準時跑、印出綠色的勾、一則通知都不漏——只是它讀的是 2025 年的舊貼文。

所以這套東西我刻意讓它很吵。掃不到貼文、被登出、帳號被停用、判讀逾時、任何沒接到的例外，全部推紅字到 Telegram，而且分別講清楚是哪一種。沒有安靜的降級，沒有拿罐頭結果假裝有跑。沒收到通知，就是真的沒案子。

五、還有一個非典型的失敗

第一次正式跑，抓了 85 則，然後整輪掛掉。

原因是我把 85 則貼文一次塞進同一個判讀請求裡。模型的回覆有長度上限，寫到一半被截斷，回傳的資料格式就壞了——不是判錯，是整批作廢。

改成每 20 則一批。順手加了一件事：抓完立刻把原始資料存檔。因為抓一輪要跑四五分鐘，後面任何一步掛掉都能直接拿存檔重跑判讀，不用再去騷擾 Threads 一次。

這種「批次大小」的坑，跟前面四個偽裝其實是同一類：都是東西在你沒看見的地方安靜地不合格了。

六、跑出來的東西，和 AI 自己寫的但書

第一輪完整掃描：85 則，1 則達標。

那一則是一家公司要改版官網，需要三個語系，預算可談。AI 給了 8 分，寫了一份草稿，切入角度是「三個語系要各自做搜尋引擎的結構化資料，還是只是介面切換、內容共用？這會影響報價落點」。

草稿旁邊還有一欄我讓它填的「風險」。它自己寫：

對方要的是「合作心聲／口碑分享」，不是報價；直接切報價會偏業配感，且沒回應到他問的溝通順暢度、售後處理速度這類經驗性問題。

我看到這一欄的時候有點愣住。

它寫了一份不錯的草稿，然後在旁邊告訴我這份草稿的切入角度可能是錯的——因為對方要的是別人的使用經驗，不是一份估價單。

這一句話，就是我為什麼不做全自動的完整答案。如果按下去就自動送出，這則回覆會變成第三十六則罐頭。而現在它變成一個提示：這一則要換個方式回，或者根本不該由我來回。

七、四天後，回來對帳

上面那些，是雷達上線那天寫的。這個系列的規矩是要講清楚代價，所以四天後我回來把帳算完。先講結論：它做到了我要求的每一件事，然後生意是零。

四天，九輪掃描，累積讀過 638 則不重複貼文，判出 3 則值得回的案子。判讀品質維持得很乾淨——擋掉的是同業推銷、日股廣告、命理心得、民宿宣傳，沒有誤殺；沒案子的日子最高分只有 2 分，是真的沒案子，不是門檻訂太嚴。到這裡為止，這支雷達是達標的。

然後是難看的部分。

3 則案子，我只回了 1 則。分數最高的那則（就是上一節那個三語系官網，8 分），到今天四天沒回。

而唯一那則我真的貼出去的回覆，我把 Threads 後台的數據調出來：

3 次瀏覽。1 個讚。0 則回音。

三個人。不是三百，是三。

原因雷達自己早就寫在「風險」欄裡了：「貼文已近 48 小時且需求完全未展開，留言區可能已有其他人搶答」。等我回上去，那則貼文底下已經 29 則留言，我排在最後面。預言成真，而寫預言的是我自己的程式。

這中間我還做了一個看起來很科學的決定。 上線隔天，我撈了 35 則發案貼文的時間分布，發現有兩個尖峰：上班後的 08–10 點（29%）、晚飯後的 20–21 點（23%），凌晨和下午幾乎掛零。於是我把「每三小時掃一次」改成「一天兩輪，各壓在尖峰正後方」——省資源，有數據支持，聽起來完全正確。

成效數字出來以後，這個決定變成了主要嫌疑犯。因為在留言區，晚回等於白回。同一週我手動貼的那幾則罐頭回覆，品質明顯比 AI 草稿差，但因為回得早，拿到 40 到 256 次瀏覽——比精心寫的那則多了幾十倍。差別不在文案，在時間。

不過還有一個更難堪的對照。同一週，我在自己貼文底下的導流留言，單則瀏覽是 5,681、8,832、9,101、9,249。

在別人的發案文底下推銷，曝光是個位數到三位數。經營自己的內容，曝光是四位數。

誠實的邊界在這裡：三則案子、四天，樣本太小，我不能宣稱「早回就有用」——因為手動那幾則雖然曝光高，同樣是 0 回音、0 詢問。目前的資料只證明了一件事：晚回一定沒用。「早回有沒有用」還沒被驗證，而這正是接下來要測的。

第五個偽裝

前面四個偽裝，講的都是「壞掉偽裝成另一種壞掉」。四天後我遇到第五個，它是另一個方向的：沒壞，偽裝成有用。

我當初刻意讓這套系統很吵——掃不到貼文會吵、被登出會吵、判讀逾時會吵。壞掉一定有聲音，這件事我做對了。

但我沒讓「活著，而且什麼都沒收穫」發出聲音。

於是四天裡，每天綠燈：程式準時跑、貼文抓得到、判讀正確、通知準時進 Telegram。所有儀表板都是正常的。而真正該被看見的那個數字——發出去的回覆有幾個人看到——從來沒有人去查，因為系統從來不會主動告訴你這個。

我是坐下來寫這篇對帳，才把它調出來的。

這大概是自動化最貴的一課，比前面四個偽裝加起來都貴：你會為「壞掉」設計警報，但很少有人為「白忙」設計警報。壞掉會停、會叫、會有人處理；白忙會準時上工、指標全綠、每天消耗你的資源，然後什麼都不發生，而且可以這樣持續好幾個月。

所以現在多了一條規矩：任何自動化系統上線時，除了「壞掉會不會吵」，還要回答第二個問題——「它有沒有用，是哪個數字說了算？誰去看那個數字？多久看一次？」答不出來，就是還沒做完。

收尾：真正的產出

一個下午，一支雷達，跑起來了。判讀乾淨，通知會吵，出事講得清楚。四天後回來對帳，找案子這件事它做到了，把案子變成生意這件事沒有。

但如果要我說這件事真正的產出是什麼，不是那支程式。

是那份接案能力書。是那份逼我把「我們接什麼、多少錢、幾週交、哪些絕對不碰」全部寫成文字的清單。

在那之前，這些東西都在我腦子裡，以默契的形式存在。報價的時候憑感覺，遇到不想接的案子憑直覺婉拒。它們運作得很好——只要決策者是我本人。

一旦你要把判斷交給另一個東西執行，默契就得變成規格。而寫規格的過程，會逼你面對一些你其實一直在迴避的問題：這個價位到底接不接？這種客戶到底要不要？我們的實績裡，哪一個才真的說得上話？

自動化最被低估的副作用，大概就是這個。你以為你在教一台機器做事，實際上你是在被迫把自己說清楚。

那份清單現在放在版本控制裡，官網改價的時候要一起改。它比雷達本身重要——雷達壞了重寫一支就好，那份清單重寫一次，等於重新想一次自己是誰。

而四天後那筆帳，讓這句話多了一個但書：清單再清楚，也不保證有人在聽。找得到案子跟接得到案子，中間隔著的不是判讀能力，是你出現的時機和你出現的地方。這一段路，自動化目前替我省下的時間，比我想像的少很多。