每天早上站在衣柜前糾結(jié)穿什么這個場景我相信大多數(shù)人都不陌生。打開天氣App看一眼溫度再翻半天衣柜最后隨手抓一件出門——這不是個例是穿搭決策最真實的日常。去年幫幾位做畢設(shè)方向咨詢的同學(xué)梳理過一個基于Python協(xié)同過濾算法的天氣穿搭推薦系統(tǒng)的技術(shù)方案整個過程把冷啟動、數(shù)據(jù)清洗、推薦融合、效果評估這些問題完整過了一遍。這篇文章就把這個項目從需求拆解到落地的全鏈路掰開揉碎講清楚內(nèi)容偏實操適合正在發(fā)愁畢設(shè)選題、或者想用一個推薦系統(tǒng)練手刷簡歷項目的同學(xué)參考。所謂天氣穿搭推薦系統(tǒng)簡單說就是輸入一個城市、拿到實時天氣系統(tǒng)從穿搭組合庫里給你推薦幾套適合當(dāng)前天氣的搭配并支持你打分、收藏、瀏覽再根據(jù)這些行為逐步把推薦調(diào)準(zhǔn)。聽著不難但真做起來有幾個地方非常容易翻車算法選型、天氣數(shù)據(jù)接入、冷啟動處理、以及把推薦結(jié)果包裝成一個能演示能給老師看的完整系統(tǒng)。下面按實際開發(fā)順序把每一步都展開講。1. 從穿衣糾結(jié)說起這個系統(tǒng)的真實需求拆解1.1 穿搭推薦到底該推薦什么很多人一開始會把需求想簡單了以為天氣穿搭推薦就是溫度低于10度就推薦羽絨服。這樣寫出來的是一個天氣查詢加上幾條if-else規(guī)則撐不起一個畢設(shè)的深度更談不上推薦系統(tǒng)四個字。這個項目里的推薦對象不是單件衣服而是穿搭組合。一套穿搭包含上裝、外套、下裝、鞋子可能還有配飾圍巾、帽子、雨傘等。系統(tǒng)推薦的是一個組合而不是一件單品。這一點決定了后續(xù)數(shù)據(jù)建模的方式——協(xié)同過濾的評分單元是用戶對一套穿搭組合的反饋不單單是對一件衣服的反饋。從用戶角度拆解一下核心需求其實是三件事第一知道今天外面什么天氣條件比如溫度、濕度、風(fēng)力、有無雨雪第二給出一批穿得出去的選項既要應(yīng)付當(dāng)前天氣又要兼顧個人風(fēng)格偏好第三讓用戶能給反饋能越用越懂Ta。前兩個靠天氣數(shù)據(jù)和規(guī)則約束第三個就是協(xié)同過濾算法的用武之地。1.2 功能邊界范圍控制決定完成度畢設(shè)最忌諱的是一開始鋪太大結(jié)果Django裝好了、后臺管理寫了、手機(jī)端也開了個頭最后哪個都沒做完。我在梳理這個項目時把功能邊界死死劃定在四條主線上天氣數(shù)據(jù)模塊按城市獲取實時天氣包括溫度、天氣現(xiàn)象、濕度、風(fēng)力并做緩存處理。穿搭數(shù)據(jù)模塊內(nèi)置一批覆蓋不同溫度區(qū)間和天氣場景的穿搭組合帶標(biāo)簽屬性。推薦核心模塊基于用戶歷史行為數(shù)據(jù)用協(xié)同過濾計算相似用戶、預(yù)測評分、生成Top-N推薦列表再用天氣約束做過濾排序。用戶交互模塊注冊登錄、瀏覽穿搭、打分/點贊/收藏/不喜歡、查看推薦結(jié)果。這四個模塊閉環(huán)之后系統(tǒng)至少是一個能注冊、能推薦、能反饋、能看效果的完整產(chǎn)品。至于后臺管理、數(shù)據(jù)分析大屏、小程序端這些都屬于有余力再做的部分。先把主線跑通再談擴(kuò)展。2. 為什么選Python協(xié)同過濾一次算法選型的完整思考2.1 三種候選方案的優(yōu)劣勢對比拿到天氣穿搭推薦這個命題后第一件事不是寫代碼而是選算法。我當(dāng)時把候選方案分成三類它們的差異非常明顯方案實現(xiàn)難度個性化能力數(shù)據(jù)依賴答辯可講深度規(guī)則引擎if-else天氣映射低無少淺協(xié)同過濾用戶/物品中強(qiáng)需要用戶行為數(shù)據(jù)深深度學(xué)習(xí)模型如序列建模高強(qiáng)需要大量數(shù)據(jù)深規(guī)則引擎最大的問題是無個性所有用戶拿到的是同一批推薦無法體現(xiàn)用戶偏好。深度學(xué)習(xí)模型聽起來高級但畢設(shè)場景下很難湊夠訓(xùn)練樣本幾百條用戶行為數(shù)據(jù)丟進(jìn)神經(jīng)網(wǎng)絡(luò)里基本是玄學(xué)調(diào)參還容易在答辯時被問到參數(shù)量多少、訓(xùn)練收斂怎么判斷、過擬合怎么處理答不上來就會露怯。協(xié)同過濾是正正好的量級實現(xiàn)復(fù)雜度適中、可解釋性強(qiáng)、在數(shù)據(jù)量小的情況下也能跑出合理結(jié)果。更重要的是協(xié)同過濾的相似用戶、評分預(yù)測、最近鄰這些概念非常適合在論文里畫圖、在答辯時講原理老師能聽到完整的思路而不只是一個黑盒子。2.2 協(xié)同過濾在本項目中的落地形態(tài)協(xié)同過濾本身又有兩種主路線基于用戶User-based CF和基于物品Item-based CF。在我的方案里兩者不是二選一而是做了組合用戶量少、每個用戶的交互記錄也不多時User-based CF更直觀目標(biāo)是找到和我口味相似的人穿了什么。當(dāng)穿搭組合數(shù)量增長到一定規(guī)模后Item-based CF可以兜住相似穿搭的召回比如用戶喜歡一件淺色風(fēng)衣系統(tǒng)就推類似的牛仔褲和板鞋。實際代碼里我建議先實現(xiàn)User-based CF作為主推薦鏈路把Item-based CF作為備用或混合策略放在后面。原因是評分矩陣通常很稀疏基于用戶的相似度計算在數(shù)據(jù)量小的階段反而更穩(wěn)定也更容易在答辯時講清楚我如何找到目標(biāo)用戶的最近鄰、如何預(yù)測評分。有一點必須提醒協(xié)同過濾是個性化排序器不是規(guī)則過濾器。天氣約束本質(zhì)上是硬條件比如下雨天不能推薦帆布鞋和淺色褲裝這個邏輯不能指望協(xié)同過濾自己學(xué)會。所以系統(tǒng)的整體設(shè)計是規(guī)則過濾天氣條件 協(xié)同過濾個性化排序——先用天氣硬條件把不合適的穿搭篩掉再對剩下的候選做協(xié)同過濾排序。兩個模塊各干各的活整體效果就會好很多。關(guān)于這方面的設(shè)計你完全可以解釋為應(yīng)對冷啟動和物理約束的混合推薦策略這也是答辯的加分項。3. 天氣數(shù)據(jù)接入與穿搭特征化處理3.1 天氣數(shù)據(jù)的關(guān)鍵字段與清洗天氣數(shù)據(jù)是這個系統(tǒng)的重要輸入。我用的方式是接入通用天氣API推薦用聚合類接口獲取以下字段當(dāng)前溫度攝氏度體感溫度天氣現(xiàn)象晴、多云、陰、小雨、大雨、雪等相對濕度百分比風(fēng)力等級或風(fēng)速是否降水有的接口會直接給降水概率這些字段里溫度、天氣現(xiàn)象、風(fēng)力是直接影響穿搭的硬指標(biāo)。濕度看起來沒那么重要但南方回南天那種濕度體感溫度和實際溫度差異巨大對穿搭影響不小建議保留。接口拿回來的數(shù)據(jù)不能直接用要做清洗。最典型的問題有三個一是部分字段可能為空比如晴天接口不返回降水字段需要做缺省值填充二是溫度是字符串還是數(shù)字需要類型轉(zhuǎn)換三是接口的天氣現(xiàn)象編碼不統(tǒng)一晴可能是sunny也可能是晴的編碼值需要統(tǒng)一映射成本地字典。3.2 溫度、濕度、天氣現(xiàn)象如何映射成穿搭條件這一步是整個項目里最有領(lǐng)域味道的部分。把天氣數(shù)據(jù)變成穿搭的約束條件我建立了一張?zhí)鞖狻┐钣成浔砗诵倪壿嫲礈囟群同F(xiàn)象兩個維度打標(biāo)簽。溫度維度的推薦規(guī)則我人為分成了幾個區(qū)間注意邊界要定義成半開區(qū)間比如(-inf, 0]、(0, 10]、(10, 20]、(20, 26]、(26, inf)避免一個溫度值同時落到兩個區(qū)間里溫度區(qū)間推薦穿搭方向10度以下羽絨服、厚毛衣、加絨褲、雪地靴、圍巾10~20度風(fēng)衣、衛(wèi)衣、針織開衫、牛仔褲20~26度長袖T恤、薄外套、休閑褲26度以上短袖、短褲、裙子、涼鞋天氣現(xiàn)象作為硬約束疊加在上面有小雨時推薦方案里必須包含防水鞋或者雨傘有大風(fēng)時不建議推薦飄帶款風(fēng)衣和過短的裙子下雪天則要在地面濕滑場景下推薦防滑的鞋履。穿搭組合的構(gòu)建方式也很重要。我在設(shè)計數(shù)據(jù)結(jié)構(gòu)時給每套穿搭掛了一組屬性適合溫度區(qū)間、適配天氣現(xiàn)象、風(fēng)格標(biāo)簽休閑/通勤/運(yùn)動/約會、季節(jié)標(biāo)簽。實際上就是把穿搭特征化讓天氣條件和穿搭之間的匹配關(guān)系可以程序化判斷而不是靠人肉維護(hù)一套套規(guī)則。這里要說明一下溫度區(qū)間和穿搭方向的映射沒有一個絕對標(biāo)準(zhǔn)不同人對冷暖的體感差異很大。項目中你可以在初始化數(shù)據(jù)時參考主流的體感溫度穿衣指南把它當(dāng)作先驗規(guī)則而不是精確真理。答辯時如果老師問為什么10度是一個分界點你可以回答這個閾值來自穿衣指南的常規(guī)范式且后續(xù)可以根據(jù)用戶反饋動態(tài)調(diào)整把區(qū)間邊界也放入可配置的管理中。這比死磕10度更科學(xué)要聰明得多。4. 協(xié)同過濾核心模塊從評分矩陣到Top-N推薦4.1 稀疏矩陣與相似度計算我先把用戶行為的評分規(guī)則定下來因為這是協(xié)同過濾的原材料。我把行為類型映射成分?jǐn)?shù)瀏覽記1分、點贊記2分、收藏記3分、主動穿著反饋我今天穿了這套記5分。這樣每產(chǎn)生一個行為就相當(dāng)于給用戶—穿搭組合構(gòu)成的矩陣填充了一個數(shù)值。具體實現(xiàn)時用Pandas建矩陣非常方便import pandas as pd # 模擬一份用戶行為數(shù)據(jù)user_id, outfit_id, behavior_type behavior_df pd.DataFrame([ {user_id: 101, outfit_id: 1, behavior_type: collect}, {user_id: 101, outfit_id: 3, behavior_type: view}, {user_id: 102, outfit_id: 1, behavior_type: like}, # ... 更多行為記錄 ]) # 行為到分?jǐn)?shù)的映射 score_map {view: 1, like: 2, collect: 3, wear: 5} behavior_df[score] behavior_df[behavior_type].map(score_map) # 透視得到用戶-穿搭評分矩陣缺失位置填0 user_item_matrix behavior_df.pivot_table( indexuser_id, columnsoutfit_id, valuesscore, fill_value0 )這里有一個新手容易踩的坑直接用0填充缺失值后再算余弦相似度會把沒有行為和打0分等同起來。在評分語義里0分意味著用戶表示不喜歡而缺失意味著用戶根本沒看過這套穿搭。所以更嚴(yán)謹(jǐn)?shù)淖龇ㄊ怯嬎阆嗨贫葧r只取兩個用戶都有行為記錄的穿搭維度來算或者采用調(diào)整后的余弦相似度。不過對于畢設(shè)的數(shù)據(jù)規(guī)模來說用sklearn的cosine_similarity直接算0填充矩陣也能出一版效果后面如果再優(yōu)化可以把上面這一點作為改進(jìn)項在論文里寫成稀疏性問題優(yōu)化。4.2 評分預(yù)測與Top-N推薦評分預(yù)測我采用的是最經(jīng)典的最近鄰加權(quán)公式目標(biāo)用戶u對穿搭i的預(yù)測評分等于u的歷史平均評分加上近鄰用戶評分的加權(quán)偏差。import numpy as np from sklearn.metrics.pairwise import cosine_similarity def predict_rating(user_id, outfit_id, user_item_matrix, k10): # 計算用戶相似度矩陣 user_sim cosine_similarity(user_item_matrix) user_sim pd.DataFrame(user_sim, indexuser_item_matrix.index, columnsuser_item_matrix.index) # 當(dāng)前用戶對每套穿搭的平均評分 user_mean user_item_matrix.loc[user_id].values user_mean_rating user_mean[user_mean 0].mean() # 找當(dāng)前用戶的k個近鄰 neighbors user_sim.loc[user_id].drop(indexuser_id).sort_values(ascendingFalse).head(k) # 鄰居對該穿搭的評分 outfit_scores user_item_matrix[outfit_id].to_dict() numerator, denominator 0.0, 0.0 for neighbor_id, sim_score in neighbors.items(): neighbor_rating outfit_scores.get(neighbor_id, 0) if neighbor_rating 0: continue neighbor_avg user_item_matrix.loc[neighbor_id] neighbor_avg_rating neighbor_avg[neighbor_avg 0].mean() numerator sim_score * (neighbor_rating - neighbor_avg_rating) denominator abs(sim_score) if denominator 0: return user_mean_rating return user_mean_rating numerator / denominator預(yù)測分?jǐn)?shù)算出來之后對候選穿搭集合按預(yù)測分降序排列取前N個就是Top-N推薦列表。但注意這個列表里的候選項已經(jīng)提前被天氣條件過濾過了所以在代碼里我會先跑天氣過濾再跑協(xié)同過濾排序。整個順序是天氣字段 → 穿搭屬性硬過濾 → 協(xié)同過濾預(yù)測分 → Top-N排序 → 輸出給前端展示。也是在這里可以加入Item-based CF做補(bǔ)充如果矩陣過于稀疏算出來的用戶相似度不穩(wěn)定就改用穿搭組合之間的相似度——用戶喜歡A搭配則推薦和A屬性相似的B搭配。兩套結(jié)果可以做加權(quán)混合權(quán)重根據(jù)行為數(shù)據(jù)量動態(tài)調(diào)整比如行為記錄少于50條就偏向Item-based達(dá)到500條以上就偏向User-based。這是我在實際項目里覺得性價比最高的一個調(diào)優(yōu)套路。4.3 冷啟動問題的處理沒有任何行為數(shù)據(jù)的全新用戶協(xié)同過濾直接失效。我在系統(tǒng)里做了一個冷啟動兜底方案新用戶注冊時可以選擇偏好風(fēng)格標(biāo)簽休閑、通勤、運(yùn)動、約會系統(tǒng)先用這些標(biāo)簽匹配穿搭庫再按當(dāng)前天氣條件 穿搭全站熱度做初始推薦。這個方案實現(xiàn)成本很低卻能保證新用戶打開系統(tǒng)看到的不是暫無推薦。同時為了在畢設(shè)演示時讓算法看起來有效可以寫一段模擬數(shù)據(jù)生成腳本批量生成幾百個用戶的模擬行為記錄覆蓋不同天氣條件下的瀏覽、點贊、收藏、穿著反饋。這樣演示時隨便注冊一個新用戶或直接挑一個老用戶體驗推薦列表都有內(nèi)容、有差異效果和數(shù)據(jù)量都拿得出手。5. 數(shù)據(jù)庫、接口與前端把推薦結(jié)果真正用起來5.1 核心表結(jié)構(gòu)與數(shù)據(jù)流推薦系統(tǒng)再聰明前端沒有數(shù)據(jù)支撐也是白搭。數(shù)據(jù)庫的合理設(shè)計是系統(tǒng)能跑通的基座。我這邊的核心表做了五張字段設(shè)計上都和推薦邏輯對齊用戶表user_id、用戶名、密碼、偏好風(fēng)格標(biāo)簽、所在城市。穿搭組合表outfit_id、名稱、圖片URL、溫度下限、溫度上限、適配天氣現(xiàn)象、風(fēng)格標(biāo)簽、季節(jié)標(biāo)簽、全站熱度。穿搭單品表item_id、outfit_id、單品類型上裝/外套/下裝/鞋/配飾、單品名稱。用戶行為表behavior_id、user_id、outfit_id、行為類型、行為分?jǐn)?shù)、創(chuàng)建時間。推薦日志表log_id、user_id、outfit_id、推薦分?jǐn)?shù)、當(dāng)前天氣快照、排名位置、推薦時間。數(shù)據(jù)流走的是閉環(huán)邏輯用戶瀏覽穿搭產(chǎn)生行為記錄 → 行為寫進(jìn)用戶行為表 → 推薦接口讀取行為數(shù)據(jù)構(gòu)建評分矩陣 → 協(xié)同過濾算分 → 推薦結(jié)果寫入推薦日志表 → 前端接口按用戶ID拉取最新推薦列表。這個閉環(huán)最核心的一點是用戶每一次點擊都有記錄所以前端按鈕一定要和后端接口對得上。5.2 推薦接口的輸入輸出設(shè)計后端我用的Python輕量框架來提供接口整體設(shè)計成三個關(guān)鍵接口就夠了天氣查詢接口入?yún)槌鞘忻虺鞘蠭D返回溫度、天氣現(xiàn)象、濕度、風(fēng)力等結(jié)構(gòu)化天氣信息。推薦獲取接口入?yún)橛脩鬒D和城市ID內(nèi)部先查天氣再走推薦鏈路返回Top-N套穿搭組合每套包含穿搭圖片、各單品名稱、推薦分和推薦理由比如適配當(dāng)前小雨天氣。行為上報接口入?yún)橛脩鬒D、穿搭I(lǐng)D、行為類型負(fù)責(zé)把前端的點擊、點贊、收藏、穿著反饋寫入數(shù)據(jù)庫。推薦接口的返回結(jié)構(gòu)建議統(tǒng)一為JSON前端拿到后直接渲染。還可以增加一個調(diào)試參數(shù)debugtrue返回里帶上這次推薦的天氣條件快照和預(yù)測分明細(xì)演示和排錯時非常有用。這個習(xí)慣我一直保留等于給系統(tǒng)留了一雙后眼。5.3 前端展示的交互邏輯前端不需要多復(fù)雜但信息層級要清晰。頁面我建議分成三個區(qū)域頂部是當(dāng)前城市天氣卡片展示溫度、天氣圖標(biāo)、濕度、風(fēng)力中間是推薦穿搭列表每個卡片展示穿搭圖片、名稱、單品清單、推薦詞右下角有喜歡、收藏、不喜歡按鈕底部可以加一個歷史推薦記錄區(qū)讓用戶看到之前在什么天氣條件下推薦了什么東西。交互邏輯的關(guān)鍵是反饋按鈕要能即時生效。用戶點了喜歡前端調(diào)用行為上報接口后端寫一條行為記錄下一次推薦結(jié)果就會發(fā)生變化。這個反饋—更新—再推薦的動態(tài)效果在演示時比任何圖表都更有說服力也是證明協(xié)同過濾真實生效的最直觀證據(jù)。如果想讓頁面顏值再高一點可以給穿搭卡片配上真實的平鋪圖或者模特上身圖。畢設(shè)答辯階段圖片數(shù)據(jù)源不好拿用穩(wěn)定的占位圖服務(wù)或者手繪簡筆圖也可以關(guān)鍵是界面干凈統(tǒng)一。我見過太多項目實力還行但頁面丑陋被老師誤判為不夠用心這個印象分不值得丟。6. 調(diào)試踩坑與畢設(shè)交付的實戰(zhàn)經(jīng)驗6.1 用戶行為太少時推薦結(jié)果像隨機(jī)數(shù)這大概是所有協(xié)同過濾項目里最常見的坑了。調(diào)試時我經(jīng)常遇到的情況是注冊一個新用戶推薦列表出來十套穿搭但怎么刷新都不變或者變化毫無規(guī)律。剛開始很容易誤以為是算法寫錯了最后定位到是因為模擬數(shù)據(jù)太少矩陣稀疏得沒法形成有效相似度。解決辦法分兩步走。第一步把模擬行為數(shù)據(jù)的規(guī)模做大一點至少覆蓋200個用戶、50套穿搭、每個用戶至少10條行為記錄讓相似度計算有據(jù)可依。第二步在算法感知不到任何可參考數(shù)據(jù)時兜底使用天氣規(guī)則推薦保證推薦結(jié)果在冷啟動階段也穩(wěn)定有邏輯。這兩個辦法配合基本能解決看起來像隨機(jī)的問題。6.2 天氣接口的限流與臟數(shù)據(jù)問題開發(fā)階段反復(fù)請求天氣接口很容易被限流導(dǎo)致頁面加載天氣模塊時偶爾超時報錯。我在項目里加了一層簡單的內(nèi)存緩存同一城市30分鐘內(nèi)不重復(fù)請求天氣模塊接口掛了就返回上一次的緩存數(shù)據(jù)如果連緩存都沒有就默認(rèn)使用晴、22度這類安全數(shù)據(jù)。這樣演示時哪怕現(xiàn)場斷網(wǎng)天氣模塊也不會白屏。臟數(shù)據(jù)的問題則藏在編碼上。天氣接口返回的原始編碼如果和本地映射字典不一致會出現(xiàn)匹配不上導(dǎo)致過濾結(jié)果為空的情況。我做了兩層保險先把接口返回的天氣現(xiàn)象統(tǒng)一轉(zhuǎn)成拼音或英文key再和映射表匹配同時所有天氣現(xiàn)象匹配穿搭的查詢都寫成模糊匹配比如接口返回小雨轉(zhuǎn)中雨也要能命中雨這個約束標(biāo)簽。6.3 中文字符集與數(shù)據(jù)庫連接的老坑很多同學(xué)做到一半發(fā)現(xiàn)數(shù)據(jù)庫里存的中文全是問號或者讀取出來亂碼。這種問題十有八九是連接字符串里沒有指定字符集。比如MySQL連接時URL參數(shù)里要顯式加上charsetutf8mb4同時建表時把文本字段的字符集統(tǒng)一設(shè)成utf8mb4。另外如果從CSV文件導(dǎo)入初始穿搭數(shù)據(jù)文件編碼要用utf-8-sig而不是普通的utf-8不然第一列中文大概率讀出來帶亂碼前綴。這些細(xì)節(jié)看起來小卻能在演示前一刻把整個界面干崩項目里提前處理掉會省很多心。6.4 效果演示與驗收的準(zhǔn)備思路畢設(shè)答辯或者項目驗收時最有說服力的不是代碼多炫而是有對比、有過程、有數(shù)據(jù)。我建議準(zhǔn)備三樣演示素材一個完整的用戶路徑演示注冊新用戶 → 選偏好 → 看天氣 → 看推薦 → 對某套穿搭點贊 → 刷新推薦列表強(qiáng)調(diào)結(jié)果發(fā)生了變化。一張推薦效果離線評估表把用戶行為按時間排序前70%當(dāng)訓(xùn)練集后30%當(dāng)測試集統(tǒng)計推薦列表的命中率測試集里用戶真正交互過的穿搭是否出現(xiàn)在推薦結(jié)果中。哪怕命中率只有百分之十幾也比沒有數(shù)據(jù)強(qiáng)。一份算法改進(jìn)對比記錄普通協(xié)同過濾直接推薦和加上天氣硬過濾之后的推薦兩者在當(dāng)期天氣條件下可穿率上的差異。這三樣素材準(zhǔn)備下來哪怕代碼有一些小瑕疵老師也能感受到你是真的理解這個項目從數(shù)據(jù)到算法的全鏈路而不只是照著PPT念了一遍背景和意義。整個項目做下來我的感受是天氣穿搭推薦系統(tǒng)的難點從來不在某一個單獨(dú)點上——天氣數(shù)據(jù)是一層、穿搭領(lǐng)域規(guī)則是一層、協(xié)同過濾算法是一層、前后端聯(lián)動又是一層每一層單獨(dú)拿出來都不復(fù)雜難的是把它們嚴(yán)絲合縫地拼在一起形成一個用戶可感知的越用越準(zhǔn)的閉環(huán)。做這類推薦系統(tǒng)項目別急著堆代碼先把天氣映射表、評分規(guī)則、冷啟動方案這三件事想明白后面的編碼會順很多。