Excel公式寫得長≠厲害，可讀性才是硬通貨

你打開同事發來的表格，發現一個單元格里塞了200個字符的嵌套函數。你盯著屏幕看了三分鐘，括號還沒數清楚——這到底是高手杰作，還是技術債務？

場景代入：那個讓你頭皮發麻的公式

凌晨一點，財務部小王終于搞定了月度報表。最后一個單元格，他敲下一行長達四行的公式，嵌套了七層函數。按下回車的瞬間，結果正確。他截圖發了朋友圈："Excel大神認證。"

三個月后，審計來了。小王離職了。接手的同事對著那個單元格發呆兩小時，最終選擇整列手動重算。

這不是虛構場景。這是無數辦公室的常態。

原文描述了一種特殊的快感：「許多人按下回車時，看到冗長的多行公式返回正確結果，會獲得一種獨特的多巴胺刺激。」這種快感被誤讀為能力證明——公式越難讀，作者越厲害。

但原文直接戳破了這個幻覺：「Excel精通度的衡量標準，曾經是看你能把多少函數塞進一個單元格，但這個標準已經站不住腳了。」

正方：復雜公式的合理性

支持復雜公式的人有一套自洽邏輯。

第一，效率優先。某些場景下，一個嵌套公式確實能替代十步手動操作。數據清洗、條件匯總、動態查找——這些任務用單層函數往往搞不定。多層嵌套是技術現實的妥協。

第二，個人掌控感。原文提到那種「獨特的多巴胺刺激」，本質是認知負荷解決后的獎勵。能駕馭復雜結構，說明對函數邏輯有深度理解。在技能展示層面，這確實是一種信號。

第三，歷史路徑依賴。很多資深用戶學Excel時，工具版本老舊、輔助功能有限。那時候沒有動態數組、沒有LET函數、沒有Lambda，復雜問題是唯一解法。這種習慣延續至今，不能簡單歸為炫技。

第四，單一文件交付場景。如果表格從不流轉、永不修改，作者本人長期使用，可讀性代價確實有限。技術債務不會立即兌現。

反方：可讀性崩潰的真實代價

但原文的核心論點站在對面：「現代工具已經改變了游戲規則——曾經看起來像天才的嵌套公式，往往只是偽裝起來的技術債務。」

第一，溝通斷裂。原文明確指出：「Excel表格是處理數據的共享系統，當邏輯 buried 在層層括號和嵌套函數中時，溝通就中斷了——即使數字技術上正確。」

注意這個精準描述：技術上正確，但溝通失敗。財務模型、運營報表、預算系統，價值不在于算出數字，而在于讓團隊理解數字怎么來的。一個沒人敢改的公式，等于一個沒有文檔的黑箱。

第二，維護成本指數級增長。原文提到「這種傾向有個名字：技能信號（skill signaling）」。在Excel里，它表現為「設計用來給人印象深刻的、不必要的復雜公式」。關鍵詞是「不必要」。必要復雜度和炫技復雜度有本質區別，但現實中兩者常被混淆。

第三，錯誤隱蔽性。嵌套層數越多，括號匹配越難檢查，邊界條件越難覆蓋。原文沒有給出具體錯誤率數據，但邏輯很清楚：「看起來令人印象深刻的，往往正是后來拖慢所有人的東西。」

第四，協作排斥。新員工、跨部門同事、外部審計——這些人不會為你的函數功底鼓掌。他們只會默默繞過你的公式，建立平行計算，制造數據版本混亂。

我的判斷：工具進化倒逼標準重置

這場辯論的勝負，不取決于道德立場，而取決于工具演進。

原文的轉折點在這里：「現代工具已經改變了游戲規則。」這不是修辭，是技術事實。Excel 365引入了LET函數，允許命名中間變量；引入LAMBDA，允許自定義函數；動態數組讓 spill 范圍自動擴展。這些功能的核心設計目標，就是把「一個單元格里的復雜度」轉化為「結構化、可命名的、可復用的模塊」。

這意味著什么？過去必須用七層嵌套解決的問題，現在可以用三步清晰表達。繼續寫長公式，不再是「不得不」，而是「選擇不學習新工具」。技能信號的發出對象，也從「不懂的同事」變成了「懂行的審閱者」——而后者一眼就能看出你是在解決問題，還是在制造問題。

原文的終極判斷值得完整引用：「如果你仍然認為復雜度等于專業能力，你就和其他所有人一樣，陷入了構建不可讀表格的同一個陷阱。」

這不是對復雜度的全盤否定。復雜業務邏輯需要復雜表達，但復雜表達不等于混亂表達。可讀性不是「簡單」的同義詞，而是「結構清晰、意圖明確、易于驗證」的同義詞。

對于25-40歲的科技從業者，這個判斷有遷移價值。你們接觸的工具鏈比Excel復雜得多——Python腳本、SQL查詢、數據管道配置、API編排。同樣的陷阱無處不在：用一行列表推導式炫耀技巧，用嵌套三元運算符壓縮邏輯，用正則表達式解決本該用解析器的問題。每一行「看起來厲害」的代碼，都是未來的調試噩夢。

Excel是這個模式的簡化標本。它的可視性讓問題暴露得更直接：一個單元格能裝多少字符，肉眼可見；公式欄的縮進和著色，直觀展示結構質量。從這個標本學到的，是如何在「能運行」和「能維護」之間做權衡。

原文沒有給出具體操作指南，但邏輯指向明確：拆分長公式，使用命名區域，添加注釋，利用新函數重構。這些動作不增加功能，但降低認知負荷——而認知負荷，才是團隊協作的真實瓶頸。

技術債務的可怕之處，不在于它讓你現在多花時間，而在于它讓你未來不敢改動。一個不敢改動的系統，會僵化、會繞過、會并行替代，最終數據一致性崩潰。Excel表格的「技術債務」聽起來小題大做，但想想那些因為公式錯誤導致的財務重述、預算偏差、決策失誤——源頭往往就是一個三年前沒人敢碰的單元格。

所以，那個讓你頭皮發麻的公式，到底是杰作還是債務？

判斷標準很簡單：三個月后，你自己還能在三十秒內理解它的邏輯嗎？

不能的話，它就不是在解決問題。它是在解決你。