這部落格為何而寫？

我們其實不缺答案，但是忘了怎麼思考

隨著科技進展，你可以使用搜尋引擎或是大語言模型，使得各種問題被快速回答：股價為什麼下跌？某個現象為什麼發生？身體哪裡出了問題？資訊很多、解釋很多、觀點也很多。但如果停下來看一眼，會發現一件有點不太舒服的事，我們無法分辨這些答案的正確性，而且大多是在問題還沒被理清楚前之前就出現答案。

我們很擅長取得回覆，但不太擅長思考與抽象化問題

之所以會得到錯誤的答案，不是資料不夠，也不是分析能力不足，而是更前面的一層：在回答之前，我們很少去問，這問題是不是已經被定義清楚了，我思考問題本身有沒有結構。 當習慣於只用單點方式思考問題，容易變成我們只看到一個現象，就試著替它找原因；看到一個結果，就急著把它連接到某個問題上。這樣的方式很自然，也很有效率，但同時也很容易忽略到現實世界幾乎從來不是單點運作的。 事情通常是一起發生的。變化是有層級的。原因往往不在被觀察的那個點上，而是在更外層的結構裡，但缺少抽象化的能力與結構性思考，就會問錯問題。當我們進行抽象化討論時，甚至會不時地出現這種想法：「要解決實際的問題，而不是在做研究。這些抽象思考對解決問題真的有幫助嗎？」 事實並非如此，沒有這樣的能力，不會有今天的深度學習，不會有今天的語言模型，也沒有啟蒙運動與科學革命，可能我們還停留在中世紀的黑暗時代裡。

我思故部落格在

當我們直接從單一觀察跳到解釋，中間其實少了一個把觀察「排列起來」的過程。 這個部落格不是提供答案，而是試著把「在回答之前，思考應該怎麼被結構化」這件事寫出來。

how thinking should be structured before answering why

在問「為什麼」之前，思考應該先有結構，需要把真正的問題給找出來。 這裡不太會有確定的答案。在這裡問題會被拆開，有些情況會保留多種可能。過早有確定的答案，往往會掩蓋掉原本應該被看見的東西。 我想要邀請你，一起在一個問題還沒被簡化之前，看看它原本長什麼樣子；或者，在各種解釋出現之前，觀察思考本身可以如何被組織，這會很有趣。 我會把「解法出現之前的思考」，與定義問題過程留下來。試著拆解問題，就像是拿到了一把能解開所有鎖的萬能鑰匙，而不僅僅是一次大腦體操。 但這並不代表我只思考而不解決問題，只是現在要解決問題，有太多種方式，也很快速。只要問題被定義清楚，對症下藥的解法就會有。這大概也是為什麼會有人在學 prompt engineering 的原因吧！

願你閱讀愉快，思考愉快