——最危險的不是答錯問題，而是把它收斂成工具剛好能回答的樣子，然後以為回答了它

先說定位：這是一篇工程觀點文，不是技術教學——沒有 code、沒有 step-by-step。它從一個真實的系統設計失誤出發，談一件比工程更大的事：我們怎麼用工具，把問題悄悄殺掉。讀的時候別找「怎麼做」，找「有沒有戳中你」就好。

做 fibon 的記憶系統時，我犯了一個錯，當時還覺得自己做得很漂亮。

我把「記憶」這件事乾淨俐落地收成一條管線：讀進一串事件（發生過什麼），推論出當下的狀態（現在是什麼），寫成一張卡，收工。事件 → 狀態，可建、可測、可上線。我那時很滿意，因為它具體、它硬、它能跑。

直到一個讀者問我：「這些事件累積之後，系統本身變成了什麼？」我回頭翻自己的程式碼才發現：我答不出來。因為我把「事件 → 狀態」當成了全部，系統算出最新狀態就把中間丟了——它記得「你現在是什麼」，卻完全不記得「你正在變成什麼」。那條「變化」本身，被我當成中間產物倒掉了。

關鍵不在我少寫了一個功能。關鍵在：我用「我的工具做得到什麼」（鑄一張狀態卡），把一個真問題（傾向是怎麼長出來的）給定義掉了。 我不是答錯了「系統會變成什麼」——我是讓這個問題消失了。系統很有效率地回答了它做得到的那一半，而我誤以為那就是全部。

這件事讓我看見一個比記憶系統大得多的東西，而工程只是它最容易被看見的地方。

設計裡最危險的，往往不是解錯問題，而是把問題收斂成工具剛好能回答的樣子，然後以為自己回答了它。

實作不只是「回答問題」——它有一種更隱蔽的能力：消滅問題。當你把一個還開放的抽象（一件事「要解決什麼」，還沒綁定「怎麼做」），塌成一個具體實作（一張表、一個指標、一條程式路徑），你同時做了兩件事：你讓它變得可操作，你也讓它變得不再被追問。前者是你要的；後者是免費附送、而且常常沒人注意的副作用。

所以每一次「收硬」——我用這個詞指「把抽象塌成實作」那個動作——之後，都值得問一句：原本那個問題，是被回答了，還是被消失了？ 被回答，是好的收硬；被消失，是你拿工具替問題挖了個墳，還插了塊「已解決」的牌子。

這就是為什麼層級越高的人，在動手前越愛在抽象那層磨蹭。不是他們愛空談——剛好相反，是他們被「過早收硬」燒過。急著動手的人往往分不清抽象跟實作是兩回事：對他們來說「想清楚要什麼」跟「把它做出來」糊成一團，所以多停一秒在抽象，看起來都像在拖。

拿「做一個登入功能」當例子。實作優先的人三十秒就定了：開一張 users 表、存帳密。看起來很有效率——但他已經把「登入」這個抽象（身份驗證），收成了「一張使用者表」。而那一收，可能就把真正的答案埋了：也許這個身分根本不該由你存，那張表打從一開始就不該存在。他沒有答錯「怎麼做登入」，他是讓「我們到底該不該自己管身分」這個問題，在一張表底下消失了。抽象之所以值得多待一會，就因為它是你還看得見問題、還沒把它塞進某個工具形狀的最後一刻。一旦塌成實作，你現有技術棧的形狀，就會回頭決定哪些問題「有資格存在」——而你渾然不覺。

而這件事一旦你看見了，就到處都是，遠遠不只工程。

「怎麼讓學生學得更好？」收硬成「考試分數」。分數可以提高、可以排名、可以發獎狀——非常可操作。但「學習」這個問題，是被回答了，還是被一張考卷消失了？

「怎麼衡量一個員工的價值？」收硬成 KPI。KPI 可以達標、可以打考績、可以發獎金。但「價值」是被回答了，還是被三個數字消失了？

每一個讓你能行動的工具——一張表、一個指標、一條 KPI——同時也是一次把問題收成可操作形狀的塌縮。塌縮讓你動得了，這是它的恩賜；但它也讓你不必再問，這是它的帳單。而帳單，總是比恩賜晚很久才寄到。

但這篇要是收在「所以別收硬、別量化、別 KPI」，那就成了另一種廢話，而且是更沒用的那種。你不可能永遠待在抽象裡。不塌縮，你就是那種只會在高空盤旋、永遠不落地、什麼都量不出來也什麼都做不出來的人（工程圈叫他「架構太空人」）。要行動，你必須把問題收成工具抓得住的形狀。收硬不是罪，是必要。

真正的本事，不在「拒絕收硬」，而在收硬之後，還把原來那個問題留在身邊——這樣當你的代理指標（那張表、那個分數、那條 KPI）開始跟原問題悄悄分岔時，你看得出來。

那條怎麼收都收不乾淨、塌縮不掉的一小塊——學習之於分數、價值之於 KPI、「正在變成什麼」之於我那張狀態卡——不是雜訊，是地圖。它就是那個還活著、還在追問的問題，站在你下一個真問題的門口。

fibon 現在記得你是什麼、不記得你正在變成什麼。那塊收不乾淨的殘渣，正是我當初讓它消失、如今又重新看見的問題。而我學到的，說到底只有一句話——它在程式碼裡成立，在課堂、在考績表裡成立，在任何你用一個工具去回答一個問題的地方，都成立：

每次工具給了你一個答案，都再回頭問一次——它是被回答了，還是被消失了？