30天前我在簡介裡寫了一句話。
在工作中我已經大量的使用 AI，我希望透過這30天的挑戰找回我的思考。
現在來回顧看看我是否有達成我的初衷。
我以為「找回思考」是讓我重新鍛鍊，少用一點 AI、多自己想一想，想的更深，然後腦袋會回到某個比較好的狀態。
但其實，這30天不是這樣，我用 AI 的量一點都沒有減少。
實際上是為了每天寫一篇，我被迫回去回憶每個專案的細節，然後把當初憑直覺下的判斷，一條一條寫成白紙黑字的規則。
而寫出來之後，結果大致可以分成兩種。
這一種是我把判斷攤開之後，發現它雖然不算錯，但旁邊還有一條我當初沒看見的路。
考核那個專案，我面對過一個問題，這一步要不要留給人做我在這一題上想得很仔細，哪幾步可以全自動、哪幾步不行、停在哪一層最合理，我都有理由。
然後我把它結案了。
另一個問題我沒有想，那就是我留下來的那個人，需要什麼才做得了這個判斷。我當時覺得那是後面的事，是實作細節，等做到那裡再說。
寫 Day 23 的時候，我把三個專案並排看，才發現這兩個問題根本是同一題。你決定把一個人留在流程裡的那一刻，就需要同時提供他判斷的資源。 你沒給他，那個「留人」就只是在流程上多一顆按鈕，他按下去，可是他沒有判斷的依據。
而我的錯不在實作，在我把一件事切成了兩件，切開的那一刻，第二件就注定會被忘記，因為它看起來像是下一個階段的問題。
Day 29 那兩次數字對不上，我的判斷是錯在我的串接，所以我往回追。
這個判斷是對的，確實是我的串接有問題，而往回追也確實會找到答案。
但我沒有想到還有另一條路，會計每個月都在產那個數字，她不需要懂我的 API，看一眼差額就能說出它大概是哪一類，我自己對照是在整份資料裡找，她看一眼可以把範圍縮到一小塊。
我當初沒有考慮這條路，而且不是因為我排除了它，是因為它根本沒有出現在我的選項裡。我判斷這是技術問題，技術問題我自己修，整條推理每一步都說得通，所以我一路走到底。
判斷對了，不代表方法對了。 這種錯特別難發現，因為它沒有任何一步看起來是錯的。
我本來以為這一類的問題是我想得不夠深，後來覺得更準確的說法是，我在下判斷的當下，腦袋裡只有一條路。
直覺的特性就是這樣，它給答案給得很快，而且一次只給一個，快到你不會發現它只給了一個。
然後因為那個答案通常可行，我就照著做了，整件事順利結束，沒有任何一刻會讓我停下來問還有沒有別的做法。
而寫的時候我得說明「為什麼要這樣？」，要回答這一題，我就必須把它跟某個別的做法放在一起比，平常我不用比，我只要做得出來就好，我不需要進一步去思考，這就是我思考退化的主因。
有一些我寫完之後，判斷結果沒有改變，它本來就對，我要補的是為什麼會這樣判斷。
這裡要講清楚一件事，缺這些背景知識的不是我，是其他人 ，我知道這個流程為什麼長這樣、這個數字為什麼卡在這裡、這一步為什麼不能自動，但它們只存在我腦袋裡，沒有任何人拿得到。
Day 26 我寫那個 ERP 填單工具，花了好幾個星期，換算下來一年省三小時，那篇文章讀起來像是一筆划不來的投資。
但那不是全部。
我當初願意把那麼多時間花在測試上，是因為我要的不只是「我自己能用」。我希望這個東西之後可以交給其他人，讓他們自己做出自己工作流程的 RPA。而一個只有我會用的工具，測到我能跑就夠了；一個要交給別人的工具，得測到別人亂按也不會出事。
這兩件事的測試成本差很多，而我選了後者。
問題是，這個理由從頭到尾都在我腦袋裡，它決定了我的做法，但它沒有出現在任何地方，讓別人知道我為什麼會這麼做。
我的判斷沒有問題，問題是支撐它的那個前提沒有被說出來。
我以前也記過東西，但那種紀錄多半是一句結論，例如這個欄位要用 A 不要用 B。
結論沒有前提，所以下一次情況變了，沒有人知道它還成不成立，包括寫的人自己。
Day 16 我吃過這個虧，一份上個階段留下來的筆記，上面寫著一句結論，我把它當成事實帶了好幾個月，因為那句話旁邊沒有任何東西可以讓我判斷它還準不準。
一篇有架構的文章跟一條筆記的差別就是它會逼我交代完整的背景。 一篇文章要站得住，我得說清楚這個判斷在什麼情況下適用、依據是什麼、換一種情況會怎樣，這些東西平常不會有人問我，我自己也不會主動想，是文章的形式把它們逼出來的。
而這才是我真正要的東西。
一條散的經驗只能用在同一件事情上，有架構的判斷可以被 SOP 化，而 SOP 化之後它才是一套方法論。
方法論的價值不在它比較聰明，在換一個人來做，結果還是一樣的。
我現在做的判斷，正確率我覺得不算低，但它的一致性接近零，因為它只存在一個人身上，而且那個人連自己都沒辦法保證每一次都想到同一件事。
Day 20 那個區分就是一個例子，我敢讓程式自動寄信給幾十個人，卻不敢讓它按一下儲存，這個差別我一直都做得出來，但沒有人能從我的程式碼裡看出依據在哪，寫成一句「錯了多久會有人發現」之後，它才變成一條別人也能用的規則，下次碰到一個全新的流程，他可以自己算出同樣的答案。
Day 28 那六個問句也是，我本來就在問，只是它們散在不同的專案裡，從來沒有被收成一張清單。
一個正確但只存在某個人腦袋裡的判斷，它不是一套方法，是一種個人習慣。
第一種處理的是判斷本身夠不夠好，藉由寫出來，我才會被迫把它跟另一個做法放在一起比一次。
第二種處理的是判斷能不能離開我，寫成有架構的東西，別人才拿得走，才會有一致的結果。
這兩種思考缺一不可。
只做第一種，我的判斷會越來越好，但它還是只有我能用，公司得到的是一個越來越可靠的人，不是一套越來越可靠的做法，而人會離開。
只做第二種，我會非常有效率地把一個不夠好的判斷複製給所有人，一致性本身沒有價值，一致地做對才有，把一條從來沒被比較過的判斷 SOP 化，等於讓所有人穩定地做同一個次好的選擇，而且因為它變成了標準，之後更難改。
前面提到的兩種思考看起來是兩件事，但其實成因是同一個。
我不需要講給任何人聽。
公司裡沒有第二個人做這件事，所以我不用寫需求、不用說服工程師、不用在會議上被追問，以前一個想法要落地，中間一定有一段「講給另一個人聽」的過程，那一段在我這裡消失了，因為我自己就能做出來。
做出來就是答案。
而不用講出來，判斷就不會被比較，也不會被傳出去，第一種跟第二種，就是這兩件事各自的後果。
AI 沒有拿走我的思考，它只是將我思考的過程靜音了，所以我不是找回思考，我是把它從靜音狀態拿出來，變成別人聽得到的東西。
Day 1 的標題是，我做了一年，還是不確定自己做得對不對。
30 天後我還是不確定。
但有一個地方不一樣了，我現在知道我是在哪幾件事情上不確定，而且我能把它們一條一條講出來。
不確定是一樣的，但它從一種感覺變成了一張清單。
感覺沒有辦法被處理，清單可以。
最後的最後，感謝每一個點進來的人，謝謝你願意跟我一起走完這段釐清思緒的路！
iThome鐵人賽
看影片追技術