當需求預測變成"給我兩分鐘"

Slack彈出一條消息："周五前要個零件需求預測，粗略就行。"你看了眼時間，周二下午五點。按老辦法，這意味著從數據庫提數、清洗成周度時間序列、構造滯后特征、訓練基線模型、驗證不騙自己、再搭個能打開的看板——至少一周。但現在有人回復："給我兩分鐘。"

Anton是什么

這是一個開源的桌面智能體，在Mac、Linux、Windows本地運行。開發者對它的描述很直白：你用自然語言跟它說話，它真的去干活。

連接數據庫、找趨勢、訓模型、搭看板——你提需求，它拆解步驟、寫Python和SQL、在沙箱里跑代碼、出錯自己調試、把結果帶回來。所有代碼存在一個叫"scratchpad"的地方，逐行可查，沒有黑箱。

安裝是一條命令，GitHub上有說明，五分鐘搞定。本文用Windows桌面版演示。

正方：這確實省掉了臟活累活

我先讓Anton連上數據源。左側有個"Add Datasource"按鈕，選Postgres，填提示信息。這里用的是演示用的Supabase數據庫，F-35 sustainment項目的航空電子采購訂單數據——真實形狀的數據，不是玩具。

憑證不會傳給大語言模型。Anton存在本地vault里，只按名稱引用。

連上之后我問它："搜一下兩個數據源里的采購訂單表。"幾秒后它返回：Supabase數據庫里有一張500行的采購訂單表，零件號、供應商、交貨周期、數量、國防項目標簽、質量標記——該有的列都有。它還主動建議："要不要跟suppliers和line_items表做個關聯？"

我沒接這個茬，直接下任務："做一個未來六個月的需求預測。"

Anton開始規劃。它列出的步驟包括：識別相關表、理解數據結構、構造時間序列、處理缺失值、選模型、訓練、驗證、生成預測。然后它問：是用Prophet、ARIMA，還是XGBoost/LightGBM這類梯度提升？

我選了XGBoost。它確認目標變量是quantity，時間粒度是周，需要構造滯后特征和滾動統計量，還要按part_number分組做多序列預測。

接著它就去了。寫SQL提數，用pandas處理，構造特征工程，訓練模型，生成預測，還順手做了可視化。整個過程在沙箱里完成，代碼全在scratchpad里。

從"給我兩分鐘"到拿到結果，實際用了不到十分鐘。預測覆蓋未來26周，按零件號分組，包含點預測和置信區間，輸出直接是DataFrame格式。

反方：但"能跑"和"能用"是兩回事

Anton確實生成了預測，但仔細看scratchpad里的代碼，問題很明顯。

特征工程部分，它構造了滯后1-4周的quantity，以及4周滾動均值和標準差。這對平穩序列還行，但采購訂單數據常有季節性波動和促銷脈沖，這些特征捕捉不到。它也沒處理異常值，而500行數據里明顯有幾個數量級偏離的訂單。

模型選擇上，它直接用了XGBoost的默認參數，沒做交叉驗證，更沒有針對時間序列的滾動驗證。訓練集測試集是按時間順序切分的，這沒錯，但測試集只有最后20%的數據，對于六個月預測來說，驗證力度太弱。

最麻煩的是誤差估計。它給出的"置信區間"其實是用預測值加減一個固定比例算出來的，不是從模型不確定性推導的。這在業務場景里會出大事——Sarah拿著這個區間去做庫存決策，可能嚴重超買或斷供。

還有數據泄漏的風險。Anton在構造特征時用了全局的均值填充缺失值，如果測試集的信息通過這個均值泄露進訓練集，評估結果就不可靠。這需要人工檢查才能發現。

看板部分，它生成了matplotlib圖表，保存為HTML。Sarah確實能打開，但交互性幾乎為零，沒法下鉆到具體零件號，也沒法調整時間窗口。比起Tableau或Power BI的原生看板，這只是個靜態快照。

我的判斷：這是"草稿生成器"，不是"工作替代者"

Anton的真正價值，在于把"從零到能跑"的時間從一周壓縮到十分鐘。它適合快速驗證想法、應付緊急需求、或者給非技術同事一個可討論的起點。

但它不解決"做好"的問題。特征工程的業務理解、模型選擇的合理性檢驗、誤差估計的嚴謹性、結果的可解釋性——這些仍需人類判斷。Anton生成的代碼是草稿，不是終稿。

對于Sarah的周五需求， realistic的做法是：用Anton十分鐘出個初版，然后花半天人工檢查關鍵假設，跟業務確認特征邏輯，再花一天加固驗證流程。總時間從一周縮到兩天，質量可控。

完全放手讓Anton端到端執行？目前看，風險收益比不劃算。它省掉的是重復編碼時間，不是思考時間。

技術實現上的取舍

Anton的架構有幾個值得注意的設計。本地運行意味著數據不出境，這對采購訂單這類敏感數據很關鍵。沙箱隔離防止代碼搞壞主機環境。Scratchpad的透明性比很多閉源工具強——你能看到它到底做了什么，而不是只能信任一個黑箱輸出。

但它也有明顯邊界。大語言模型的規劃能力受限于訓練數據，遇到冷門的數據庫schema或特殊的業務邏輯，它可能規劃出看似合理實則行不通的步驟。這時候需要人工介入調整。

工具鏈的依賴也是個隱患。Anton調用了pandas、scikit-learn、xgboost等庫，版本兼容性它自己處理，但如果你的環境有特殊要求，可能需要手動覆蓋。開源的好處是能改，壞處是也得不維護。

對從業者意味著什么

需求預測這個活兒，長期以來被夾在兩個極端之間：Excel拖公式的業務人員，和寫PyTorch的算法工程師。中間地帶的"會寫SQL、懂點統計、能搭看板"的分析師，活最多，工具卻最原始。

Anton這類工具的出現，不是在替代分析師，而是在重新定義分工。重復性的數據提取、格式轉換、基礎建模代碼，逐漸交給智能體；人類的精力釋放到問題定義、假設檢驗、結果溝通上。

這對25-40歲的科技從業者是個信號：純技術執行力的溢價在下降，"理解業務+能判斷機器輸出質量"的組合在上升。Anton能寫XGBoost代碼，但它不知道F-35零件的供應風險該怎么量化——這個知識缺口就是你的位置。

數據收束

Anton的GitHub倉庫顯示，項目發布兩周內獲得3400星標，Issue區有47個功能請求和23個bug報告。核心貢獻者3人，主要提交集中在數據連接器和沙箱穩定性上。對比同類工具如LangChain的52k星標，它處于極早期階段，但"本地運行+透明代碼"的差異化定位已經吸引了一批企業數據團隊的試用反饋。

預測市場的規模數據：Gartner估計2024年供應鏈預測軟件支出約19億美元，年增長率11%。其中"增強型預測"（即AI輔助的人類決策）占比從2021年的15%升至2024年的34%。Anton瞄準的正是這個縫隙——比全自動預測工具便宜，比傳統BI工具智能。

但用戶留存的關鍵指標尚不明確。項目文檔沒有披露月活或次日留存，Issue區的反饋以功能請求為主，缺少深度使用后的質量評估。這意味著"兩分鐘出預測"的故事已經講通，"預測準不準"的答案還在風中。