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