Excel突然算錯三分之一：用戶自創"分鐘轉小時"公式

一個運行了一年多的薪酬系統，賬單數字突然集體跑偏33%。工程師挖了數小時數據庫代碼，最后發現bug不在程序里——在用戶的腦回路里。

一張圖看懂：問題出在哪

Albert（化名）是英國北部一家法國咨詢公司分部的軟件工程師，專門維護各類甲骨文企業資源計劃系統的數據對接。某天，他接到緊急工單：員工工時統計表算出的人工成本，憑空多了約三分之一。

他打開用戶發來的文件，確認數字確實不對。第一反應很合理——數據管道出問題了。他花了數小時深挖數據庫里的PL/SQL存儲過程，邏輯看起來無懈可擊。更詭異的是，他自己生成的測試文件，數字完全正確。

和用戶一聊，真相浮出水面。

系統按客戶要求輸出的是「分鐘數」。用戶覺得數字太大，想換成小時，于是手動把所有數值除以了100。Albert不得不現場科普：分鐘轉小時要除以60，不是100。

100和60的差值，正好讓結果偏離約33.3%。

為什么100看起來"更對"

這個錯誤太常見了。十進制思維是本能——百分制、百進制貨幣、百分數，日常接觸的全是100的倍數。時間卻是六十進制的活化石，來自古巴比倫的數學遺產。

用戶看到「5400分鐘」，直覺反應是「54」，而非「90」。數字變小了，單位"看起來"對了，報表順眼了，財務災難也埋下了。

Albert的排查過程很有代表性：先懷疑系統，再懷疑代碼，最后才懷疑人。這是工程師的慣性路徑——畢竟軟件比用戶更可預測。但企業軟件的特殊之處在于，它往往是"半成品"：系統輸出原始數據，用戶在Excel里完成最后一公里的加工。

這最后一公里，沒有版本控制，沒有單元測試，沒有代碼審查。只有一個覺得數字"太大"的人，和除號鍵。

企業軟件的灰色地帶

甲骨文薪酬系統本身沒出問題。數據管道正常，數據庫邏輯正常，文件生成正常。故障發生在系統邊界之外——那個用戶自制的"轉換層"。

這是企業IT的常態痛點。再完善的ERP系統，也擋不住用戶把數據導出到Excel里"再加工"。據Albert描述，這種集成已經穩定運行超過一年，說明系統本身的設計是可靠的。但可靠性只覆蓋到文件生成那一刻，之后的故事系統一無所知。

更隱蔽的風險是：用戶的"修復"可能長期潛伏。如果這次偏差不是33%這么顯眼，而是3%，會不會更晚才被發現？財務對賬時的小額差異，往往被歸因于"四舍五入"或"時區問題"，直到某天審計師翻開原始底稿。

Albert花了數小時排查數據庫，最終用一句話解決。時間成本的不對稱，暴露了企業支持流程的盲區——我們擅長追蹤技術故障，卻不擅長追蹤"用戶創新"。

能防嗎？難

技術上可以強制約束。比如輸出時直接換算成小時帶小數，不給用戶動手空間。或者在文件里加只讀保護、公式鎖定、甚至宏檢測。但這些手段都有副作用：靈活性降低，用戶抵觸，支持成本轉移。

Albert所在的公司選擇了另一條路：按客戶規格輸出分鐘數。這給了下游自由，也給了下游犯錯的空間。商業軟件永遠在"管控"與"靈活"之間走鋼絲，而Excel是這條鋼絲上最滑的一段。

這個案例的諷刺之處在于，用戶主動"優化"了數據，卻破壞了準確性。他們的意圖是好的——讓數字更易讀——但執行依據的是直覺而非 domain knowledge（領域知識）。企業軟件的設計者常常假設用戶會按培訓操作，現實是用戶會按"看起來對"的方式操作。

Albert最后說，他"不得不向用戶解釋"基本數學。這句話的疲憊感很熟悉——不是技術難題的疲憊，是溝通成本的疲憊。修復一個除號只需一秒，修復一個認知偏差需要反復。

《The Register》的"On Call"專欄常年收集這類故事，說明這不是孤例。從全球范圍看，Excel導致的財務錯誤每年造成數十億美元損失——有些是把基因名當成日期自動轉換，有些是復制粘貼時行號錯位，有些，就像Albert遇到的，是100除以60的倔強。

尾聲

Albert的故事沒有系統性的解決方案，只有一個具體的教訓：當數字突然跑偏33%，先問問用戶有沒有"優化"過什么。這個比例太特殊了——它幾乎是100/60的簽名。

下次看到類似的偏差，或許可以省掉數小時的數據庫排查。畢竟，在軟件工程里，最不可預測的變量從來不是代碼。