去年有個做電商的客戶凌晨兩點(diǎn)給我打電話，聲音都在抖。競爭對手在200多個SKU上跟他打價格戰(zhàn)，有時候就便宜5毛錢，訂單卻嘩嘩往那邊流。他干了三年電商，第一次覺得手動刷新頁面是一種酷刑。

每天早上9點(diǎn)、下午3點(diǎn)、晚上11點(diǎn)，他打開三個競爭對手的網(wǎng)站，逐一點(diǎn)開200多個產(chǎn)品頁，把價格抄進(jìn)Excel。200乘以3，再乘以365，他一年點(diǎn)擊了21.9萬次頁面。這還沒算比價、算降幅、決定要不要跟價的時間。

我跟他說：「給我48小時?！?/p>

三件套架構(gòu)：沒有云，沒有數(shù)據(jù)庫服務(wù)器，月租5美元

這個機(jī)器人的骨架簡單到有點(diǎn)寒酸。Python寫的爬蟲，SQLite本地數(shù)據(jù)庫，郵件和Telegram雙通道報警。三部分拼在一起，塞進(jìn)一臺最便宜的VPS（虛擬專用服務(wù)器），月租5美元。

爬蟲每6小時跑一趟，用cron定時觸發(fā)。不是實時，但夠用了——電商價格戰(zhàn)很少在6小時內(nèi)翻天覆地。SQLite存下每次抓取的價格，自動算環(huán)比變化。報警閾值設(shè)在5%，降幅超過就推送。

整個系統(tǒng)沒有調(diào)用任何云服務(wù)API，沒有AWS賬單 surprise?？蛻魡栁遥骸高@能撐多久？」我說：「直到你把VPS的錢賺回來——大概三天?！?/p>

核心代碼不到50行，但有個關(guān)鍵洞察：每個電商網(wǎng)站的價格，都能被一個CSS選擇器精準(zhǔn)定位。

比如競爭對手A的價格在.price-current這個class里，競爭對手B在span[data-price]，競爭對手C藏得深一點(diǎn)，在#product-detail .final-price。找一次，記一輩子。爬蟲不需要理解頁面結(jié)構(gòu)，只需要知道「錢在哪個盒子里」。

這里有個反直覺的點(diǎn)：很多人第一反應(yīng)是上機(jī)器學(xué)習(xí)、視覺識別、OCR截圖。但電商網(wǎng)站的HTML是結(jié)構(gòu)化的，價格不是圖片里的文字，是明碼標(biāo)價寫在代碼里的。用BeautifulSoup解析，比訓(xùn)練一個識別模型快100倍，準(zhǔn)100倍。

從 panic 到自動化：200個SKU的監(jiān)控流水線

部署第一天，爬蟲抓回來第一批數(shù)據(jù)?？蛻舳⒅鳷elegram推送看了十分鐘，說了一句話：「原來他們周三下午統(tǒng)一調(diào)價?！?/p>

這個發(fā)現(xiàn)值多少錢？他之前手動抄價格，永遠(yuǎn)抄的是「某個時刻」的價格，看不出規(guī)律。機(jī)器人跑了72小時，數(shù)據(jù)連成線——競爭對手每周三下午3點(diǎn)批量降價，周五晚上恢復(fù)。節(jié)奏清晰得像地鐵時刻表。

他調(diào)整了策略：周三上午提前鎖一批庫存，下午對手降價時他按兵不動，周五晚上對手回漲，他的「原價」突然變成「低價」。不戰(zhàn)而屈人之兵。

前三個月的賬算得清楚：少打了三次價格戰(zhàn)，每次節(jié)省4000美元左右的毛利侵蝕，合計1.2萬美元。VPS成本15美元，開發(fā)時間一個周末。ROI（投資回報率）用計算器按會溢出。

但數(shù)字背后有個更值錢的東西：他從「被動反應(yīng)」變成了「主動觀測」。以前他的信息流是碎片化的——刷到哪個算哪個，情緒驅(qū)動決策?，F(xiàn)在他有一張持續(xù)更新的價格地圖，可以選戰(zhàn)場、選時機(jī)。

這個轉(zhuǎn)變的本質(zhì)，是把「競爭情報」從成本中心變成了決策基礎(chǔ)設(shè)施。

技術(shù)債與反脆弱：當(dāng)爬蟲遇到驗證碼

跑了兩個月，第一個故障來了。某個競爭對手上了Cloudflare，爬蟲開始收到503和驗證碼頁面。客戶的Telegram安靜了，他慌了，以為生意要崩。

我加了兩行配置：輪換User-Agent頭，加10秒隨機(jī)延遲。問題解決。這不是對抗，是禮貌——讓服務(wù)器覺得你是真人，不是DDoS攻擊。

后來我們又遇到一次變體：競爭對手改了頁面結(jié)構(gòu)，CSS選擇器失效，爬蟲抓到空值。數(shù)據(jù)庫里出現(xiàn)一條0美元的價格記錄，觸發(fā)誤報警。修復(fù)很簡單：加價格合理性校驗，低于成本價或高于市場價3倍就丟棄，同時發(fā)「數(shù)據(jù)異?！雇ㄖ?。

這些補(bǔ)丁累加起來，代碼從50行漲到200行。但核心邏輯沒變：抓取→存儲→比較→報警。其他都是護(hù)欄。

有個細(xì)節(jié)值得說：SQLite在這種場景下比PostgreSQL、MySQL更合適。不是性能，是復(fù)雜度。單機(jī)、零配置、斷電不丟數(shù)據(jù)、備份就是一個文件復(fù)制?？蛻舻腣PS供應(yīng)商有一次意外重啟，服務(wù)自動恢復(fù)，數(shù)據(jù)完好。如果是云數(shù)據(jù)庫，這時候要查連接池、查故障轉(zhuǎn)移日志，凌晨三點(diǎn)你接不到我的電話。

從工具到習(xí)慣：當(dāng)監(jiān)控變成日常

三個月后，客戶給我發(fā)了一張截圖。他的Telegram里除了價格報警，多了幾條自己寫的備注：「這個降幅是清庫存，不用跟」「這家在測試新客價，老客價格沒變」。

他開始在數(shù)據(jù)上疊加自己的業(yè)務(wù)判斷。機(jī)器人提供 raw data（原始數(shù)據(jù)），他提供 context（上下文）。這是人機(jī)協(xié)作的理想狀態(tài)：機(jī)器做它擅長的——持續(xù)、無疲勞、精確；人做人擅長的——解讀意圖、權(quán)衡利弊、承擔(dān)決策責(zé)任。

我問他：「現(xiàn)在還會手動查價格嗎？」他說：「會，但心態(tài)變了。以前是找敵人，現(xiàn)在是驗證假設(shè)?！?/p>

這個機(jī)器人沒有名字，沒有界面，沒有產(chǎn)品文檔。但它完成了一個真實的商業(yè)任務(wù)：把一個人從21.9萬次無意義的點(diǎn)擊里解放出來，讓他有時間思考「為什么降價」而不是「降了多少」。

技術(shù)圈有個說法叫「自動化焦慮」——怕機(jī)器取代人。但這個案例反過來：機(jī)器取代的是人的機(jī)械勞動，釋放的是人的認(rèn)知帶寬?？蛻舻母偁帉κ忠苍谟妙愃乒ぞ?，甚至可能更貴、更復(fù)雜。但他贏在一個細(xì)節(jié)：他的機(jī)器人是他自己參與設(shè)計的，每個閾值、每個報警規(guī)則都對應(yīng)他的業(yè)務(wù)判斷。

工具可以復(fù)制，但工具與業(yè)務(wù)的咬合方式很難復(fù)制。

現(xiàn)在他的監(jiān)控清單從200個SKU擴(kuò)到了400個，加了兩個新競爭對手，報警閾值按品類細(xì)分——快消品5%，耐用品3%，季節(jié)性商品手動開關(guān)。機(jī)器人還是那臺5美元的VPS，代碼還是我那個周末寫的骨架。

上周他問我：「要不要上機(jī)器學(xué)習(xí)，預(yù)測對手什么時候降價？」我說：「你現(xiàn)在的數(shù)據(jù)夠嗎？」他算了算，八個月，不到4000條價格記錄。我說：「再攢一年，到時候我?guī)湍憧纯??！?/p>

他回了一個表情：

如果你也在手動刷新競爭對手的頁面，你的閾值是多少——多少毛利侵蝕會讓你決定，這個周末必須做點(diǎn)什么？