需求寫得越具體，測試越有價值
資料擷取專案最常見的時間浪費，不在擷取，而在來回確認需求。
一句「幫我擷取一下這個網站的資料」，需要三到五輪溝通才能進入測試。而一份寫清楚六項內容的需求，通常一兩天內就能給出實測結論和報價。
需求裡應該包含的六項
一、目標網站
給具體連結，不要只給網站名。
最好的做法是給出一個你希望擷取的具體結果頁連結——帶著篩選條件的那種。比如不是給出某個商家平台的首頁，而是給出「某國某城市某個產業的搜尋結果頁」連結。這一個連結能說清楚的資訊，往往比幾百字描述更多。
二、篩選條件
說明範圍怎麼劃定：地區、類目、關鍵字、時間區間、排序方式。
關鍵字類需求建議提供兩到三個同義說法。同一個品類在不同市場的叫法差異很大，只用一個字詞往往會漏掉相當一部分結果。
三、數量範圍
給一個區間，並說明這個數量是硬性要求還是期望值。
這裡有個常見誤解：期望的最終筆數和需要擷取的原始筆數不是一回事。如果你要求每一筆都必須有聯絡方式，而目標平台上這個欄位的填寫率只有一半，那麼要拿到一萬筆合格資料，實際需要處理的原始資料遠不止一萬筆。
四、欄位清單
把欄位分成兩類寫：
- 必須有：缺了這份資料就沒用的欄位
- 有了更好：能拿到更好，成本高的話可以放棄的欄位
這個區分很重要。有些欄位只在詳情頁可見，把它從「必須有」降到「有了更好」，成本可能差一倍。
同時說明欄位的口徑。比如「價格」是指原價、現價還是促銷價；「評論數」是指總數還是某個時間段內的數量。口徑不明確的欄位，交付後大概率要重做。
五、交付格式
XLSX、CSV 還是 JSON，以及是否需要依某個欄位拆分成多個檔案。週期性專案還要說明是每次全量交付，還是只給增量。
六、資料用途
這一項經常被跳過，但它同時影響兩件事。
一是合規判斷——用途直接決定這個需求能不能做。二是欄位設計——用途明確後，很多欄位的必要性會自動清晰。做客戶開發就必須有聯絡方式，做價格監控就必須有擷取時間戳記和固定的擷取週期，做內容選題則可以完全不要聯絡方式。
一份可以直接套用的需求範本
- 目標結果頁連結：
- 篩選條件（地區／類目／關鍵字／時間區間）：
- 期望數量範圍：
- 必須有的欄位：
- 有了更好的欄位：
- 交付格式：
- 更新頻率（一次性／每週／每月）：
- 資料用途：
把這八行填完發過來，基本可以直接進入測試環節。
欄位口徑的兩個常見坑
第一個是變體和重複。 同一個商品有多個規格、同一家公司有多個分店條目，算一筆還是算多筆，會讓最終筆數和平均值統計出現明顯差異。這個規則要在欄位設計階段定死。
第二個是快照欄位。 價格、評分、庫存、互動數都是隨時間變化的值。這類欄位必須配擷取時間才有意義，否則資料放上一段時間就無法解釋了。我們的交付預設都會帶擷取時間戳記，原因就在這裡。