上一篇文章《你以為送外賣全靠小哥飆車嗎？快是因為有高科技的！》讓大家知道原來送個外賣背后居然還有個巨大的物流細分市場——即時配送，而且30分鐘能送到是因為有智能調度系統支撐的。那么問題來了，外賣公司不是搭了個信息化平臺嗎？把訂單放上去，讓騎手小哥上去搶單就行了，有生意誰不做呀？這個調度系統需要多少智能呢？

核心的問題在于，外賣訂單中有容易送的“肉”，也有難以完成的“骨頭"，如果靠搶單就會嚴重依賴騎手的決策能力，挑肉的多而沒人挑骨頭送，假如按照定價高低來搶，一方面人力成本不可控，另一方面搶到遠的肉還影響配送效率，用戶體驗不佳，搶不到肉的騎手會投訴，經常這樣必然會想退出，邊騎邊拿手機搶單安全風險也高。

其實，搶單模式包括再之前效率更低、容易作弊的人工派單模式，還有之后不具備全局優化能力的搶推結合模式，外賣平臺都曾經嘗試過，最終還是得往智能派單方向去走。

因為前幾種模式只是基于位置的服務（Location Based Services，LBS）和延遲隊列（訂單或騎手運力）去執行簡單調度，控制臺調度引擎計算的內容太少，很多訂單的復雜度并未考慮在內，所以用戶下單體驗水平差異很大，平臺管控能力也弱。

因此調度系統的智能不僅僅是靜態的訂單分配問題，還包含動態的騎手路徑規劃問題。

智能調度系統不僅要考慮訂單池、運力池的匹配，還必須將包括路徑規劃算法在內的各種算法，形成算法庫，通過在不同條件下調用合適的算法將訂單池里的待發訂單和運力池里的可用騎手對應關聯起來。

調度系統的智能性在外賣平臺的訂單量大、騎手多的情況下至關重要，靠人工派單或主動搶單會完全亂套。

那么算法庫里的各種復雜算法是靠人想出來的嗎？首先肯定的是必須要有完整的流程來保障算法的可靠設計，并且還是一個不斷循環、反復測試、持續迭代的過程。

算法的迭代也不是光靠數學邏輯強的人坐在辦公室里就能想全、不斷改造升級的，算法的效果必須接受實際運作無情的鞭打和驗證，主動加被動改進是系統調度開發人員的家常便飯。

因此事后有可視化的回放軌跡，反過來了解為什么算法會派出這種不合理的訂單給騎手，也是改進算法的重要工具，至少能夠亡羊補牢。當前適用的算法在平臺訂單量和運力池持續提升的過程中也未必一直好用，所以算法庫版本需要一直升級。升級不是說越加越多算法、越搞越復雜，而有可能是當訂單數量和路徑復雜度指數倍增加時，自動或手動降級、減少算法輸入、犧牲部分效果來保證訂單的可執行。主動降級也是一種智能。

那么到最后，變動這么大的算法不能讓平臺調度出現系統性的崩潰等大風險，必須有工程管理方法去精細化保證整個調度系統，從規劃預防開始，到能實時識別診斷風險，最終風險爆發時可控并基本保障外賣訂單的運作。

所以，你下的外賣訂單交給哪個騎手來送，不是你覺得哪個小哥帥就能決定讓他天天上門的，平臺調度系統會結合各種條件運用算法去計算分配，如果你有指定帥哥定點送外賣的需求，開發人員還得確認是不是普遍需求，值不值得去設置提供這種服務呢，你說是吧？