三條路的差異不在報價上
同一個資料需求，你可以自己寫腳本、可以買現成的擷取工具、也可以找服務商。
這三條路的價格是能直接比的，但價格不是主要差異。真正拉開距離的是三件事：誰來定欄位口徑、目標站改版時誰負責修、以及資料出問題時找誰。
這篇不推銷任何一條路。下面把三條路各自適合什麼情況寫清楚，包括什麼時候你根本不該找我們。
什麼情況下自己寫最划算
以下條件同時滿足，自己動手是最優解：
- 一次性需求，不需要週期重複
- 量在幾百到幾千筆
- 目標站結構簡單：列表頁上就有你要的全部欄位，分頁規整，不需要逐筆點進詳情頁
- 團隊裡有人寫過腳本，Python 加兩個套件的程度就夠
- 結果不進關鍵業務流程，錯幾筆不影響決策
這種情況下，會寫的人花兩三個小時就跑完了，而走一遍需求溝通、測試、報價、確認的流程，時間成本反而更高。
這類需求我們在評估階段會直接建議你自己做。 接下來對雙方都沒意思——你多花錢，我們也賺不到什麼。
自己寫的隱藏成本不在寫，在維護。目標站改版一次腳本就廢，你得自己發現、自己定位、自己改。一次性需求沒有這個問題，所以它才適合自己做；一旦變成週期性的，這筆帳就要重算。
什麼情況下現成工具夠用
擷取工具適合這種情況：
- 目標是主流平台，工具有現成的範本
- 量在方案範圍內
- 能接受工具定義的欄位結構，不需要依自己的口徑調整
- 只做單個站點，不需要和別的來源合併
工具的價值是把「寫腳本」這一步省掉了，對於範本涵蓋到的場景確實高效。
隱藏成本有三處，都不在訂閱費裡：
第一，欄位口徑是工具定的。 變體商品算一筆還是多筆、價格取原價還是現價、評論數是總數還是某時段內——這些工具依自己的邏輯處理，你要的口徑它不一定支援。等資料拿回來才發現口徑不對，重做的是你。
第二，跨站點的結果結構不一致。 三個站點跑出來三種欄位結構，合併的工作量經常超過擷取本身。這一步工具不管。
第三，範本失效時你只能等。 目標站改版後，範本什麼時候修好取決於工具方的排程，不取決於你的專案進度。
什麼情況下找服務商
反過來，下面幾條命中任意兩條，找人做通常更划算：
- 跨多個站點或多個國家，需要統一口徑後合併
- 欄位口徑要依你的用途定，不是接受現成結構
- 週期性重複，需要長期穩定跑
- 結果要進業務流程，錯誤會傳導到決策
- 出問題需要有人負責，而不是自己排查
服務商這條路的隱藏成本也要說清楚：溝通成本是真實存在的。需求寫不清楚會來回確認幾輪，這也是站上反覆強調需求範本的原因——一份可執行的資料需求應該包含什麼那篇就是為了壓縮這一段。
更大的風險是找到不靠譜的。判斷服務商的幾個具體問題，寫在關於我們裡，那些標準你可以拿去問任何一家，包括我們。
一個四問判斷順序
依這個順序問，通常兩三步就能定：
第一問：一次性還是週期性？ 週期性的直接排除自己寫——除非你願意長期承擔維護。維護成本不會消失，只會在你和服務商之間轉移。
第二問：一個站還是多個站？ 多個站基本排除工具。不是工具跑不了，是跑完之後的結構不一致，合併成本會吃掉省下來的錢。
第三問：欄位口徑誰定？ 要依你的用途定口徑，就排除工具。工具給的是它的結構，不是你的。
第四問：出問題誰負責？ 如果這份資料錯了會影響決策，那麼「有人對結果負責」本身就是要買的東西之一。
三條路都走不通的情況
這種情況比想像中多：
- 核心欄位只有登入後可見
- 單次查詢上限低到拆分成本超過資料本身的價值
- 目標站結構頻繁變動，維護成本高於資料帶來的收益
- 資料用途本身落在不該做的範圍內
前三種換哪條路結果都一樣，因為限制來自目標平台不是執行方式。第四種任何一條路都不該走。
碰到這幾種，要改的是需求本身，不是執行方式。受限平台還有哪幾條路可走，寫在受限平台的資料怎麼辦。
一句話總結
一次性、小量、單站、簡單結構——自己做。 單站、主流平台、接受現成口徑——用工具。 跨站、要定口徑、要週期跑、要有人負責——找人。
如果你不確定自己落在哪一檔，把需求寄過來，評估階段就能給出判斷——包括「這個你自己做就行」這個結論。測試不另外收費，具體驗證哪幾件事寫在小規模測試到底測什麼。