去年幫一個(gè)做觀光采摘的朋友做了一套大棚管理系統(tǒng)他最開(kāi)始的需求表格里只寫了三行字想知道蔬菜哪天熟想讓人網(wǎng)上預(yù)約想少接電話。就這么一個(gè)樸素的需求最后做出來(lái)的東西就是標(biāo)題里這套 vuenodejsElementUi 的大棚蔬菜成熟預(yù)測(cè)與水果采摘預(yù)約系統(tǒng)。整套系統(tǒng)沒(méi)有什么高深算法但勝在閉環(huán)完整管理員登記品種和批次環(huán)境數(shù)據(jù)按天進(jìn)庫(kù)后端每天自動(dòng)推算成熟日期并把預(yù)計(jì)產(chǎn)量折算成可預(yù)約配額游客在前端選日期、選時(shí)段、提交預(yù)約現(xiàn)場(chǎng)核銷一把梭。這篇文章不打算只講代碼我會(huì)把業(yè)務(wù)拆解、數(shù)據(jù)庫(kù)設(shè)計(jì)、預(yù)測(cè)算法怎么一步步落地、預(yù)約防超賣怎么處理、前端組件怎么選、部署時(shí)踩了什么坑全部串起來(lái)講一遍。適合兩類人看一是想給自家大棚/果園做套管理系統(tǒng)的新手開(kāi)發(fā)者二是農(nóng)產(chǎn)品運(yùn)營(yíng)者想搞清楚這套系統(tǒng)到底能解決什么問(wèn)題。1. 為什么把成熟預(yù)測(cè)和采摘預(yù)約放進(jìn)同一個(gè)系統(tǒng)1.1 傳統(tǒng)大棚的人肉調(diào)度到底差在哪先說(shuō)個(gè)常見(jiàn)的場(chǎng)景。一個(gè)中型大棚種了黃瓜、番茄、草莓好幾個(gè)品種每個(gè)品種分了好幾批定植。成熟時(shí)間靠管理員每天鉆大棚看覺(jué)得差不多熟了就發(fā)個(gè)朋友圈說(shuō)周六開(kāi)放采摘。結(jié)果往往是兩種極端一種是發(fā)早了游客來(lái)了果子還沒(méi)紅透體驗(yàn)很差人家下次不來(lái)了另一種是發(fā)晚了周末兩天熟透的果子沒(méi)人摘要么爛在地里要么全家老小齊上陣緊急采摘累得半死還賣不出好價(jià)。采摘預(yù)約那邊更原始基本靠電話和微信群接龍。一個(gè)周末可能收到幾十條預(yù)約消息管理員得手動(dòng)抄在本子上現(xiàn)場(chǎng)再一個(gè)一個(gè)核對(duì)。遇到下雨天有人臨時(shí)不來(lái)或者有人沒(méi)預(yù)約直接沖過(guò)來(lái)現(xiàn)場(chǎng)亂成一鍋粥。更麻煩的是沒(méi)有歷史數(shù)據(jù)今年種什么、什么時(shí)候種、產(chǎn)量怎么樣全靠腦子記第二年又從頭開(kāi)始摸索。所以這個(gè)系統(tǒng)的第一個(gè)價(jià)值不是好看而是把經(jīng)驗(yàn)變成數(shù)據(jù)。每一批的定植日期、生長(zhǎng)天數(shù)、成熟日期、實(shí)際產(chǎn)量都被記錄在案第二年同一品種的預(yù)測(cè)會(huì)越用越準(zhǔn)。1.2 從預(yù)測(cè)到預(yù)約的完整業(yè)務(wù)閉環(huán)這套系統(tǒng)的業(yè)務(wù)閉環(huán)其實(shí)是一條清晰的鏈路登記品種檔案 - 創(chuàng)建種植批次 - 記錄環(huán)境數(shù)據(jù) - 跑成熟預(yù)測(cè) - 生成采摘日歷 - 開(kāi)放預(yù)約配額 - 游客下單 - 現(xiàn)場(chǎng)核銷每個(gè)環(huán)節(jié)都會(huì)影響后面環(huán)節(jié)的數(shù)據(jù)。比如預(yù)測(cè)出某批番茄在5月20日前后進(jìn)入成熟期預(yù)計(jì)產(chǎn)量200公斤系統(tǒng)就會(huì)在5月20日起的連續(xù)幾天生成采摘日歷每天放出一定比例的預(yù)約配額。游客能看到的預(yù)約頁(yè)面不是空的而是有實(shí)際數(shù)量限制的日歷選了日期和時(shí)段就能看到還剩多少名額直接下單。這個(gè)設(shè)計(jì)的關(guān)鍵在于配額跟著預(yù)測(cè)走而不是管理員想起哪天開(kāi)放就哪天開(kāi)放。預(yù)測(cè)數(shù)據(jù)驅(qū)動(dòng)預(yù)約上限預(yù)約數(shù)據(jù)反過(guò)來(lái)校驗(yàn)預(yù)測(cè)準(zhǔn)不準(zhǔn)——每批蔬菜實(shí)際成熟后系統(tǒng)會(huì)把實(shí)際日期和預(yù)測(cè)日期做對(duì)比誤差自動(dòng)記錄。整套系統(tǒng)就像給大棚裝了一個(gè)不斷進(jìn)化的調(diào)度大腦。2. 技術(shù)選型的取舍Vue Node.js Element UI 能扛住什么2.1 為什么是 Vue 而不是別的我剛接這個(gè)項(xiàng)目的時(shí)候第一反應(yīng)也是要不要用 React 或者直接上 Next.js。但冷靜下來(lái)分析一下需求這是一個(gè)典型的中小型管理系統(tǒng)加一個(gè)簡(jiǎn)單的游客預(yù)約頁(yè)主要操作者是管理員和手機(jī)端游客復(fù)雜度不高開(kāi)發(fā)周期要求緊而且后續(xù)維護(hù)的人可能就是一個(gè)懂點(diǎn)前端的農(nóng)場(chǎng)員工。Vue 的優(yōu)勢(shì)恰好在這個(gè)定位上最能發(fā)揮模板語(yǔ)法直觀表單雙向綁定省事上手成本比 React 低一個(gè)臺(tái)階。特別是像定植日期選擇環(huán)境數(shù)據(jù)錄入預(yù)約日歷展示這種大量表單和狀態(tài)同步的場(chǎng)景v-model 幾乎是零心智負(fù)擔(dān)。再加上視圖和邏輯分離得比較自然后學(xué)者接手代碼時(shí)不需要理解太多函數(shù)式編程的概念。如果換成 React你得處理受控組件、不可變數(shù)據(jù)、Hooks 依賴數(shù)組這些概念不是說(shuō)不好而是對(duì)一個(gè)以實(shí)用第一為目標(biāo)的業(yè)務(wù)系統(tǒng)來(lái)說(shuō)屬于不必要的學(xué)習(xí)成本和溝通成本。2.2 Node.js 在這里承擔(dān)了什么角色后端選 Node.js最大的原因不是性能而是前后端語(yǔ)言統(tǒng)一。做這套系統(tǒng)的人大概率是同一個(gè)開(kāi)發(fā)者甚至可能是從零開(kāi)始學(xué)全棧的新手。前端寫 Vue后端寫 Node.js整個(gè)技術(shù)棧只有一種語(yǔ)言開(kāi)發(fā)效率高很多調(diào)試的時(shí)候也不用切換思路。Node.js 在業(yè)務(wù)處理上非常適合這種 IO 密集型、邏輯偏流程化的系統(tǒng)。成熟預(yù)測(cè)涉及大量環(huán)境記錄遍歷、日期計(jì)算、配額增減操作這些在 Express 里處理很順手。異步模型對(duì)大棚里傳感器上報(bào)數(shù)據(jù)、定時(shí)任務(wù)跑預(yù)測(cè)、用戶并發(fā)提交預(yù)約這類場(chǎng)景也有天然優(yōu)勢(shì)。這里不涉及什么重計(jì)算所以不需要上 Python 服務(wù)或者單獨(dú)搞個(gè)微服務(wù)。單體應(yīng)用、一個(gè) Node 進(jìn)程、一臺(tái)服務(wù)器夠用。2.3 Element UI 的邊界與版本風(fēng)險(xiǎn)Element UI 是 Vue 2 時(shí)代最成熟的中后臺(tái)組件庫(kù)做管理后臺(tái)完全是長(zhǎng)在它舒適區(qū)里的表格、表單、彈窗、日期選擇、分頁(yè)、上傳開(kāi)箱即用。尤其是我在系統(tǒng)里重度使用的 el-table 配合 el-tag、el-date-picker 和 el-calendar寫起來(lái)非?？鞓邮揭步y(tǒng)一。但這里要提醒一句Element UI 官方已經(jīng)不再對(duì) Vue 2 進(jìn)行長(zhǎng)期維護(hù)如果你的項(xiàng)目是從零開(kāi)始建議直接用 Vue 3 Element Plus。我之所以堅(jiān)持用 Vue 2 Element UI是因?yàn)榕笥逊?wù)器上有一套舊代碼是基于 Vue 2 的里面有一些已經(jīng)跑通的模塊比如品種圖片管理、微信掃碼登錄的雛形直接遷移成本不低。新項(xiàng)目千萬(wàn)別走這條路選 Element Plus 才是長(zhǎng)期更穩(wěn)妥的方向。3. 數(shù)據(jù)庫(kù)設(shè)計(jì)把成熟度變成可計(jì)算、可追溯的數(shù)據(jù)3.1 十幾張表里的關(guān)鍵六張整套系統(tǒng)我拆了十幾張表但真正核心的其實(shí)是六張。把它們的設(shè)計(jì)邏輯看清楚整個(gè)系統(tǒng)的骨架就出來(lái)了。第一張是品種檔案表variety存的是每個(gè)蔬菜水果品種的基礎(chǔ)參數(shù)品種名稱、基準(zhǔn)生長(zhǎng)天數(shù)、有效積溫閾值、生育下限溫度、參考單價(jià)、默認(rèn)開(kāi)放預(yù)約比例。這張表是預(yù)測(cè)算法和預(yù)約配額的參數(shù)來(lái)源所以前期必須跟大棚管理員反復(fù)確認(rèn)寧可一開(kāi)始填得保守也不要瞎填。第二張是種植批次表batch關(guān)聯(lián)到品種和大棚記錄定植日期、預(yù)測(cè)成熟日期、實(shí)際成熟日期、預(yù)計(jì)產(chǎn)量、狀態(tài)。狀態(tài)有育苗中、生長(zhǎng)期、臨近成熟、已成熟、已清棚幾種。這里的關(guān)鍵是 batch 里的實(shí)際成熟日期是后期做預(yù)測(cè)誤差修正的核心依據(jù)一定要在每批蔬菜真正成熟時(shí)及時(shí)更新不能拖。第三張是環(huán)境數(shù)據(jù)表env_record按天記錄每個(gè)大棚的最高溫、最低溫、平均溫、濕度、光照時(shí)長(zhǎng)、土壤濕度。注意這是按天粒度不需要實(shí)時(shí)秒級(jí)數(shù)據(jù)因?yàn)槌墒祛A(yù)測(cè)關(guān)心的是整個(gè)生育期的累積效果而不是某小時(shí)的極端波動(dòng)。第四張是成熟預(yù)測(cè)記錄表prediction_log每次跑預(yù)測(cè)都會(huì)生成一條記錄內(nèi)容包括批次、預(yù)測(cè)日期、預(yù)測(cè)成熟日期、當(dāng)天算法版本、最終實(shí)際成熟日期、誤差天數(shù)。這張表是用來(lái)做模型校準(zhǔn)和復(fù)盤的核心數(shù)據(jù)。第五張是采摘日歷表harvest_schedule每天每個(gè)批次生成一條采摘記錄包含采摘日期、預(yù)計(jì)可采摘量、已預(yù)約量、總配額、鎖定狀態(tài)。預(yù)約系統(tǒng)真正讀寫的是這張表。第六張是預(yù)約訂單表reservation_order字段包括關(guān)聯(lián)的采摘日歷、游客姓名、手機(jī)號(hào)、預(yù)約日期、時(shí)段、數(shù)量、狀態(tài)、核銷碼。狀態(tài)流轉(zhuǎn)后面專門講。3.2 環(huán)境數(shù)據(jù)從哪來(lái)傳感器、手動(dòng)錄入與天氣API環(huán)境數(shù)據(jù)的數(shù)據(jù)源是這套系統(tǒng)最容易被忽略的工程問(wèn)題。大棚里的環(huán)境數(shù)據(jù)往往沒(méi)有標(biāo)準(zhǔn)接口我在實(shí)際部署中遇到的情況是三種來(lái)源并存第一種是傳感器上報(bào)。一個(gè)十幾塊錢的溫濕度傳感器通過(guò) WiFi 定時(shí)往服務(wù)端的接口推數(shù)據(jù)格式也很簡(jiǎn)單就是一個(gè) JSON 包。這種方案推薦在老棚改造時(shí)用成本低不用埋線。第二種是手動(dòng)錄入。很多小棚主根本沒(méi)有傳感器那就靠管理員在后臺(tái)把最高最低溫填一下。為了降低錄入成本后臺(tái)頁(yè)面做了一個(gè)一鍵帶入昨日數(shù)據(jù)并允許微調(diào)的功能實(shí)測(cè)下來(lái)錄入效率提升明顯。第三種是第三方天氣 API 拉取。有些大棚所在的區(qū)域沒(méi)有傳感器我用歷史天氣 API 把最近30天的每日氣溫補(bǔ)進(jìn)去。這里要注意免費(fèi)額度限制以及天氣數(shù)據(jù)是按地理范圍給的跟大棚實(shí)測(cè)值有偏差只能作為種子數(shù)據(jù)和兜底。數(shù)據(jù)源的設(shè)計(jì)原則是所有來(lái)源統(tǒng)一寫入 env_record 表并增加一個(gè) source 字段標(biāo)明來(lái)源。預(yù)測(cè)算法在讀取數(shù)據(jù)時(shí)優(yōu)先級(jí)是傳感器 手動(dòng)錄入 天氣API。這樣既能利用數(shù)據(jù)兜底又不會(huì)讓低質(zhì)量數(shù)據(jù)污染預(yù)測(cè)結(jié)果。4. 成熟預(yù)測(cè)模塊從定植日期到成熟日期的推算邏輯4.1 第一版就用基準(zhǔn)天數(shù)法起步很多新手一上來(lái)就想著上機(jī)器學(xué)習(xí)模型我勸你先冷靜。這套系統(tǒng)在數(shù)據(jù)積累不足的前半年任何復(fù)雜模型都不如一個(gè)簡(jiǎn)單的基準(zhǔn)天數(shù)法靠譜。基準(zhǔn)天數(shù)法的邏輯一句話就能說(shuō)清楚每一個(gè)品種定義好一個(gè)從定植到成熟需要的自然天數(shù)比如某個(gè)品種的番茄是60天。那么預(yù)測(cè)成熟日期 定植日期 基準(zhǔn)天數(shù)。當(dāng)然純加天數(shù)會(huì)忽略溫度對(duì)生長(zhǎng)速度的影響。所以我做了個(gè)帶溫度修正的版本大約長(zhǎng)這樣function predictByBaseDays(batch, variety, recentAvgTemp) { // 溫度修正系數(shù)品種適宜溫度約25度實(shí)際平均溫度偏離越遠(yuǎn)修正越明顯 const optimalTemp 25; let tempFactor recentAvgTemp / optimalTemp; tempFactor Math.max(0.8, Math.min(1.2, tempFactor)); // 防止系數(shù)過(guò)分偏離 const baseDays variety.base_growth_days; const adjustedDays Math.round(baseDays * tempFactor); const predictedDate addDays(batch.plant_date, adjustedDays); return predictedDate; }這段代碼的核心思想是最近一段時(shí)間溫度偏冷生長(zhǎng)變慢預(yù)測(cè)日期向后推溫度偏暖生長(zhǎng)略快預(yù)測(cè)日期往前提。限制在0.8到1.2之間是為了不讓短期天氣異常把預(yù)測(cè)結(jié)果帶飛。實(shí)測(cè)下來(lái)這個(gè)算法在數(shù)據(jù)量不足的時(shí)候已經(jīng)比完全靠感覺(jué)強(qiáng)多了。誤差基本能控制在正負(fù)3到5天對(duì)預(yù)約系統(tǒng)來(lái)說(shuō)意味著開(kāi)放配額的日期不會(huì)偏移得離譜。4.2 有效積溫GDD模型的落地等積累了接近一個(gè)完整種植季的數(shù)據(jù)后我切到了有效積溫模型也就是 GDDGrowing Degree Days。這個(gè)模型在農(nóng)業(yè)上用得比較成熟核心思想是每種作物從定植到成熟需要累積一定的生長(zhǎng)度日數(shù)每天貢獻(xiàn)多少度日由當(dāng)天的溫度決定。公式很簡(jiǎn)單每日GDD max(0, (當(dāng)日最高溫 當(dāng)日最低溫) / 2 - 品種下限溫度)品種下限溫度意思是低于這個(gè)溫度作物基本不生長(zhǎng)一般番茄是10度左右葉菜類會(huì)更低一些。然后從定植日開(kāi)始逐日累加當(dāng)累計(jì)GDD達(dá)到品種閾值時(shí)那一天就是預(yù)測(cè)成熟日期。function calcDailyGDD(tempMax, tempMin, baseTemp) { const avg (tempMax tempMin) / 2; return Math.max(0, avg - baseTemp); } function predictByGDD(batch, envRecords, variety) { let accumulatedGDD 0; for (const record of envRecords) { accumulatedGDD calcDailyGDD(record.temp_max, record.temp_min, variety.base_temp); if (accumulatedGDD variety.gdd_threshold) { // 達(dá)到積溫閾值的那天就是預(yù)測(cè)成熟日 return record.record_date; } } return null; // 數(shù)據(jù)不足無(wú)法預(yù)測(cè) }這段代碼看起來(lái)不長(zhǎng)但它解決了一個(gè)關(guān)鍵問(wèn)題不再用月份或絕對(duì)天數(shù)做判斷而是用熱量累積做判斷。大棚里哪怕冬天種番茄只要供暖夠、積溫達(dá)標(biāo)照樣能成熟。而提前成熟或延遲成熟的原因也都能通過(guò)積溫?cái)?shù)據(jù)解釋清楚。要注意的點(diǎn)是 envRecords 必須按日期排序而且缺失的天數(shù)不能靜默跳過(guò)否則累計(jì)積溫會(huì)偏低應(yīng)該做插值或者直接把前一天的數(shù)值帶入。我一開(kāi)始沒(méi)處理這個(gè)問(wèn)題連續(xù)兩個(gè)批次的預(yù)測(cè)都比實(shí)際偏晚三四天排查了半天才發(fā)現(xiàn)是某段時(shí)間傳感器斷線、數(shù)據(jù)缺了三天沒(méi)補(bǔ)。4.3 用預(yù)測(cè)日志做簡(jiǎn)單自學(xué)習(xí)老實(shí)說(shuō)無(wú)論是基準(zhǔn)天數(shù)法還是積溫模型都是對(duì)生長(zhǎng)過(guò)程的一種近似。真正讓這套系統(tǒng)越用越準(zhǔn)的是每批記錄做完之后的誤差回填和自修正。我在每次跑預(yù)測(cè)之前會(huì)先查一下這個(gè)品種最近幾批的歷史誤差const logs await PredictionLog.findAll({ where: { varietyId: variety.id, actualDate: { not: null } }, order: [[predictDate, DESC]], limit: 5 }); const avgError logs.reduce((sum, log) sum log.errorDays, 0) / logs.length; // 用歷史平均誤差做平移修正 const offset Math.max(-3, Math.min(3, Math.round(avgError)));這里算出的 avgError 是預(yù)測(cè)成熟日期 - 實(shí)際成熟日期的平均值。如果是正數(shù)說(shuō)明系統(tǒng)總是預(yù)測(cè)晚了也就是實(shí)際比預(yù)測(cè)早熟那就把下一次預(yù)測(cè)日期往前挪。負(fù)數(shù)則相反。之所以給偏移量加正負(fù)3天的限制是防止某一批極端數(shù)據(jù)比如突然的病蟲(chóng)害導(dǎo)致提前清棚把修正幅度拉得過(guò)大。這個(gè)機(jī)制本質(zhì)上是負(fù)反饋校準(zhǔn)。雖然簡(jiǎn)單但在真實(shí)農(nóng)業(yè)場(chǎng)景里非常管用。因?yàn)槊恳慌N植都在為系統(tǒng)貢獻(xiàn)新樣本品種庫(kù)越用越熟。5. 采摘預(yù)約模塊配額、沖突與狀態(tài)流轉(zhuǎn)5.1 每日配額怎么算預(yù)約模塊的第一個(gè)核心問(wèn)題是每天放多少量出去。放多了到時(shí)候成熟量不夠游客白跑一趟放少了明明能摘的果賣不掉浪費(fèi)了產(chǎn)量。我的算法分兩步。第一步是根據(jù)預(yù)測(cè)成熟日期和預(yù)計(jì)產(chǎn)量在采摘日歷表里生成未來(lái)N天的記錄。第二步是把每天的開(kāi)放配額設(shè)為預(yù)計(jì)成熟量的一個(gè)百分比比如80%剩下20%作為線下散客和突發(fā)情況的預(yù)留。function generateHarvestSchedule(batch, predictedDate, estimatedYield) { const openRatio 0.8; // 可預(yù)約比例 const scheduleDays 5; // 成熟期持續(xù)約5天 const dailyQuota Math.round((estimatedYield * openRatio) / scheduleDays); for (let i 0; i scheduleDays; i) { const date addDays(predictedDate, i); await HarvestSchedule.create({ batchId: batch.id, harvestDate: date, quotaKg: dailyQuota, bookedKg: 0 }); } }這里有兩個(gè)細(xì)節(jié)值得提。一是成熟期持續(xù)天數(shù)最好不要寫死我在品種檔案表里加了一個(gè) mature_duration 字段不同品種的掛果期差異很大。二是預(yù)約與采摘日之間要留出至少一天的提前量不能在成熟當(dāng)天才生成日歷——游客需要規(guī)劃行程管理員需要安排人力。5.2 預(yù)約狀態(tài)機(jī)設(shè)計(jì)預(yù)約訂單的狀態(tài)不能只有成功和失敗兩個(gè)我設(shè)計(jì)了四個(gè)狀態(tài)用一張表說(shuō)明狀態(tài)觸發(fā)操作含義待確認(rèn)游客提交預(yù)約單子已進(jìn)入系統(tǒng)配額已占用已確認(rèn)管理員后臺(tái)核單確認(rèn)安排游客收到確認(rèn)信息已核銷現(xiàn)場(chǎng)核銷碼驗(yàn)證游客已到現(xiàn)場(chǎng)完成采摘已取消管理員取消或超時(shí)未到釋放配額游客不能再直接進(jìn)場(chǎng)待確認(rèn)到已確認(rèn)之間我加了一個(gè)人工審核步驟純粹是為了防止惡意占單。比如有人一次約50公斤但整個(gè)大棚當(dāng)天配額才60公斤如果自動(dòng)確認(rèn)其他游客就沒(méi)法約了。人工核單可以在后臺(tái)看到單人的預(yù)約頻次對(duì)這種異常單直接取消?，F(xiàn)場(chǎng)核銷用的是核銷碼邏輯跟電影票取票一樣訂單生成時(shí)后端隨機(jī)生成一個(gè)6位碼游客在預(yù)約詳情頁(yè)能看到管理員在后臺(tái)輸入這個(gè)碼完成核銷。我試過(guò)二維碼方案但考慮到大棚現(xiàn)場(chǎng)網(wǎng)絡(luò)不穩(wěn)定、掃碼槍又需要額外成本6位碼反而最實(shí)用。核銷之后訂單狀態(tài)變?yōu)橐押虽N采摘日歷上的 bookedKg 不再占用未來(lái)配額因?yàn)槟遣糠止呀?jīng)被摘走消耗掉了。5.3 并發(fā)超賣問(wèn)題的一段SQL預(yù)約最容易出問(wèn)題的是高并發(fā)下的超賣。想象一下周末上午同時(shí)有十個(gè)人盯著一個(gè)日期時(shí)段提交預(yù)約如果代碼邏輯是先查一下還有沒(méi)有配額有的話再扣減那這十個(gè)請(qǐng)求幾乎都會(huì)看到同一個(gè)剩余配額然后全部通過(guò)檢查最后把配額扣成負(fù)數(shù)實(shí)際到場(chǎng)卻發(fā)現(xiàn)根本沒(méi)那么多果。解決思路是在數(shù)據(jù)庫(kù)層面用一條語(yǔ)句同時(shí)完成檢查配額和扣減配額兩個(gè)動(dòng)作利用數(shù)據(jù)庫(kù)的行鎖來(lái)保證原子性UPDATE harvest_schedule SET booked_kg booked_kg ? WHERE id ? AND booked_kg ? quota_kg * open_ratio;關(guān)鍵在于 UPDATE 語(yǔ)句執(zhí)行后返回的 affectedRows。如果影響行數(shù)為1說(shuō)明扣減成功如果為0說(shuō)明配額已經(jīng)被占滿了需要提示游客該時(shí)段已約滿請(qǐng)選擇其他日期。這條語(yǔ)句天然防超賣因?yàn)樵诓l(fā)場(chǎng)景下數(shù)據(jù)庫(kù)會(huì)串行化這些更新操作絕不會(huì)有兩個(gè)事務(wù)同時(shí)通過(guò)同一個(gè)配額的檢查和扣減。我在代碼里把這段邏輯封裝在事務(wù)里和創(chuàng)建訂單的 INSERT 放在一起保證配額扣減成功但訂單創(chuàng)建失敗這種半吊子情況不會(huì)出現(xiàn)。如果用不了事務(wù)也得保證先扣配額再建訂單并且扣失敗的請(qǐng)求直接返回失敗這樣業(yè)務(wù)上才不會(huì)有臟數(shù)據(jù)。6. 前端頁(yè)面拆解Element UI 在管理后臺(tái)和預(yù)約頁(yè)的落地用法6.1 管理后臺(tái)表格、日歷、表單怎么組合管理后臺(tái)是這個(gè)系統(tǒng)里 Element UI 最發(fā)光的地方。我按照大棚管理員的真實(shí)操作流把頁(yè)面分成五個(gè)模塊數(shù)據(jù)總覽用 el-row 和 el-col 鋪幾個(gè)統(tǒng)計(jì)卡片顯示當(dāng)前在種批次、本周可采摘量、待處理預(yù)約數(shù)、預(yù)測(cè)偏差均值。批次管理el-table 列出所有批次狀態(tài)用 el-tag 渲染顏色按生長(zhǎng)期到成熟期變化。行內(nèi)直接放編輯記錄生長(zhǎng)跑預(yù)測(cè)三個(gè)操作按鈕。環(huán)境錄入默認(rèn)展示今天的表單用 el-date-picker 選日期el-input-number 填各項(xiàng)數(shù)據(jù)。特意做了移動(dòng)端適配管理員在大棚里邊走邊填手機(jī)也能用。預(yù)測(cè)日歷基于 el-calendar 做一個(gè)帶顏色的日歷視圖某天有批次預(yù)測(cè)成熟就在對(duì)應(yīng)日期格子里顯示品種名和預(yù)計(jì)可采摘量顏色越深說(shuō)明當(dāng)天成熟量越大。預(yù)約訂單用 el-tabs 分狀態(tài)展示訂單配合 el-table 和 el-pagination方便管理員逐個(gè)處理待確認(rèn)訂單。這中間最省心的組件是 el-table。寫批次管理列表的時(shí)候只需要定義 columns 數(shù)組和小模板排序、篩選、加載狀態(tài)全被組件接管了。內(nèi)置的 expand 行展開(kāi)功能也被我用來(lái)展示每批的歷次預(yù)測(cè)記錄管理員不用跳頁(yè)面就能看到這批預(yù)測(cè)是越來(lái)越準(zhǔn)還是越來(lái)越偏。6.2 游客預(yù)約頁(yè)的H5適配問(wèn)題游客端預(yù)約頁(yè)我一開(kāi)始也想用 Element UI 搞定結(jié)果在手機(jī)上一打開(kāi)就發(fā)現(xiàn)問(wèn)題了。Element UI 的組件在移動(dòng)端雖然能勉強(qiáng)用但按鈕偏大、表格布局不靈活、彈窗樣式很生硬整體體驗(yàn)像是PC頁(yè)面被強(qiáng)行縮小很不舒服。解決方案是最務(wù)實(shí)的做法開(kāi)發(fā)了兩套入口。管理后臺(tái)和游客后臺(tái)共享同一個(gè) Vue 工程但游客預(yù)約相關(guān)的頁(yè)面單獨(dú)走一組移動(dòng)端路由頁(yè)面用簡(jiǎn)單的 viewport 適配寫不依賴 Element UI 的復(fù)雜容器組件而是用原生布局加少量自定義樣式。日期選擇用原生的 input[typedate] 或者簡(jiǎn)單的日歷組件時(shí)段選擇用單選卡片提交按鈕做成底部通欄大按鈕這些都是移動(dòng)端最順手的交互形態(tài)。如果你不想寫兩套另一個(gè)方案是游客端直接換成 Vant 組件庫(kù)跟 Element UI 共存也不會(huì)沖突。Vant 是專門做移動(dòng)端的表單和日歷組件都更適合手機(jī)操作。我當(dāng)時(shí)沒(méi)有引入 Vant 是考慮到包體積和代碼維護(hù)量但如果你的預(yù)約流程更復(fù)雜比如要選多天、多品種建議直接上 Vant。前端這塊我的體會(huì)是選組件庫(kù)之前先想清楚這套頁(yè)面在什么設(shè)備上用。管理后臺(tái)就是 PC 上用的Element UI 完美游客預(yù)約頁(yè)就是手機(jī)上用的必須按移動(dòng)端思路來(lái)硬湊只會(huì)讓使用者覺(jué)得別扭。7. 后端 API 與定時(shí)任務(wù)系統(tǒng)自動(dòng)完成預(yù)測(cè)與提醒7.1 接口設(shè)計(jì)速覽后端我用的 Express結(jié)構(gòu)上是經(jīng)典的 controller / service / model 分層。接口設(shè)計(jì)遵循 RESTful 風(fēng)格這里列幾個(gè)核心接口方法路徑說(shuō)明GET/api/batches批次列表支持按狀態(tài)、品種篩選POST/api/batches新建種植批次POST/api/env-records新增一條環(huán)境數(shù)據(jù)GET/api/harvest-calendar獲取可預(yù)約采摘日歷POST/api/reservations提交預(yù)約訂單PUT/api/reservations/:id/status核銷、取消、確認(rèn)操作GET/api/prediction-logs預(yù)測(cè)記錄列表管理員相關(guān)接口我用 JWT 做鑒權(quán)游客提交預(yù)約則不需要登錄因?yàn)橛慰皖A(yù)約的核心信息是手機(jī)號(hào)而不是賬號(hào)體系。這樣既降低了游客的操作成本也讓管理員不用維護(hù)一套用戶注冊(cè)模塊。7.2 定時(shí)任務(wù)與通知系統(tǒng)有兩個(gè)定時(shí)任務(wù)都是用 node-cron 跑的。第一個(gè)任務(wù)是每天凌晨2點(diǎn)全量重算預(yù)測(cè)。為什么要全量因?yàn)榄h(huán)境溫度每天都可能讓預(yù)測(cè)日期變化預(yù)約日歷要跟著變不能只算一次。任務(wù)邏輯是遍歷所有處于生長(zhǎng)期的批次 - 讀取截至昨日的最新環(huán)境數(shù)據(jù) - 調(diào)用預(yù)測(cè)函數(shù) - 更新批次的預(yù)測(cè)成熟日期 - 重新生成未來(lái)N天的采摘日歷。第二個(gè)任務(wù)是每天早8點(diǎn)給當(dāng)天有預(yù)約的游客發(fā)提醒。這個(gè)提醒功能建議接短信服務(wù)商或者公眾號(hào)模板消息需要申請(qǐng)相應(yīng)資質(zhì)。我開(kāi)發(fā)的時(shí)候先用的是一個(gè)輕量通知方案把當(dāng)天預(yù)約名單在前一天晚上導(dǎo)出成 Excel 發(fā)到管理員微信由管理員在微信群里做一個(gè)簡(jiǎn)單提醒開(kāi)發(fā)成本最低。等穩(wěn)定了再升級(jí)成自動(dòng)短信。定時(shí)任務(wù)在開(kāi)發(fā)環(huán)境跑沒(méi)問(wèn)題部署到服務(wù)器后有兩個(gè)坑一是服務(wù)器時(shí)區(qū)要設(shè)為東八區(qū)否則 cron 的定時(shí)點(diǎn)會(huì)偏二是如果任務(wù)跑了一半進(jìn)程崩了沒(méi)有斷點(diǎn)續(xù)跑機(jī)制所以我給每個(gè)任務(wù)都加了簡(jiǎn)單的日志和異常捕獲失敗后至少能看到日志定位而不是靜默丟失。8. 我在部署中踩過(guò)的坑與最終效果8.1 傳感器數(shù)據(jù)污染問(wèn)題系統(tǒng)上線最開(kāi)始的幾次預(yù)測(cè)出現(xiàn)了非常離譜的結(jié)果比如某批黃瓜預(yù)測(cè)成熟日期比實(shí)際晚了半個(gè)月。查到最后發(fā)現(xiàn)是傳感器上報(bào)的數(shù)據(jù)出了問(wèn)題大棚里有個(gè)溫度探頭靠近風(fēng)機(jī)出風(fēng)口每天正午會(huì)記錄到60多度的高溫導(dǎo)致當(dāng)天 GDD 被嚴(yán)重拉高而我的算法又是按累計(jì)達(dá)到閾值來(lái)判斷成熟的所以預(yù)測(cè)日期被提前了提前到實(shí)際并不可能的程度。解決方法是校驗(yàn)層。所有環(huán)境數(shù)據(jù)寫入前必須經(jīng)過(guò)一個(gè)簡(jiǎn)單的過(guò)濾器溫度不在 -20 到 55 度的直接標(biāo)記為異常并丟棄濕度不在 10% 到 100% 的也丟棄單日 GDD 超過(guò)品種適宜區(qū)間 1.5 倍以上的按上限值截?cái)?。這類臟數(shù)據(jù)清洗看起來(lái)不高級(jí)但它是整套預(yù)測(cè)模塊穩(wěn)定運(yùn)行的前提。8.2 預(yù)約量虛高的真實(shí)原因還有一次某天預(yù)約日歷顯示已經(jīng)約出80%結(jié)果當(dāng)天只來(lái)了六成的人。一調(diào)查發(fā)現(xiàn)不少游客預(yù)約后并沒(méi)有來(lái)而且沒(méi)有取消。預(yù)約量虛高直接導(dǎo)致兩個(gè)問(wèn)題管理員按照預(yù)約量準(zhǔn)備采摘籃子和包裝材料多準(zhǔn)備了浪費(fèi)真正想來(lái)的游客看到約滿提示放棄下單轉(zhuǎn)去了別家。應(yīng)對(duì)措施是引入超時(shí)未核銷自動(dòng)釋放配額規(guī)則預(yù)約成功后在采摘日前一天的下午6點(diǎn)前如果游客沒(méi)有主動(dòng)取消系統(tǒng)按預(yù)約時(shí)間的先后順序嘗試給后補(bǔ)游客釋放少量配額。這里我用了一個(gè)后臺(tái)配置項(xiàng)把自動(dòng)確認(rèn)和釋放策略做成可調(diào)參數(shù)運(yùn)營(yíng)一段時(shí)間后調(diào)整到比較合理的數(shù)值。對(duì)于不守約的游客連續(xù)兩次以上未到且未取消的手機(jī)號(hào)會(huì)被系統(tǒng)標(biāo)記下次預(yù)約時(shí)需要人工審核。8.3 一個(gè)關(guān)于模型迭代的勸告最后想跟所有想做同類系統(tǒng)的人說(shuō)一句大實(shí)話不要在項(xiàng)目一開(kāi)始就想著一步到位上人工智能模型。我做這套系統(tǒng)的第一版預(yù)測(cè)模塊加一起不到200行代碼全是簡(jiǎn)單的算術(shù)和條件判斷但它在真實(shí)大棚里能跑起來(lái)、能產(chǎn)出結(jié)果、能被管理員接受。反而是那些一開(kāi)始就設(shè)計(jì)得特別復(fù)雜的方案往往因?yàn)閿?shù)據(jù)量不足、業(yè)務(wù)理解不夠最終淪為擺設(shè)。系統(tǒng)上線兩個(gè)種植季之后種了幾個(gè)批次的番茄和草莓預(yù)測(cè)誤差中位數(shù)穩(wěn)定在正負(fù)2天以內(nèi)預(yù)約轉(zhuǎn)化率也比之前靠朋友圈接龍時(shí)高了不少。這個(gè)結(jié)果不是因?yàn)槲宜惴ǘ鄰?qiáng)而是因?yàn)槊恳慌鎸?shí)數(shù)據(jù)都在沉淀每一批記錄都在修正參數(shù)。農(nóng)業(yè)這個(gè)領(lǐng)域數(shù)據(jù)比模型值錢積累比炫技重要。如果你也準(zhǔn)備做類似的系統(tǒng)我的建議是先砍需求第一版只要能用基準(zhǔn)天數(shù) 溫度修正把預(yù)測(cè)做出來(lái)用配額扣減 狀態(tài)流轉(zhuǎn)把預(yù)約跑通這套東西就已經(jīng)能落地了。后面再慢慢加積溫模型、誤差自學(xué)習(xí)、通知提醒、數(shù)據(jù)可視化。做管理系統(tǒng)最大的忌諱是一次性把所有功能都想全結(jié)果把自己困在架構(gòu)里出不來(lái)。