過去幾個月，我讀了很多關於 AI 依賴後果的文章，其中一個很明顯的發現是 認知退化。換句話說，就是因為過度依賴 AI，導致技能逐漸退步。
大多數領悟都和 不直接解決問題 有關。軟體工程師會本能地先問 AI 該怎麼做，而不是先自己思考解法。這代表跳過了至關重要的 思考 過程。這也是我選擇上面這張圖的主要原因：《盲人領盲人》（1568），出自 彼得·布勒哲爾（Pieter Bruegel the Elder）。
畫面描繪一排盲人被另一位同樣失明的人帶領，最終一個接一個跌倒。這幅數百年前的作品，至今仍映照著當代世界正在發生的事。唯一的不同是，我們是在刻意讓自己失明
提示 > 接受 > 重複
注意，這裡沒有審查步驟。這就是問題所在。你可能會覺得這個流程沒什麼問題。你可能會說：「只是小改動而已，真的沒什麼好擔心的。」 直到你一遍又一遍地重複這個過程，而這些 「小改動」 最終慢慢累積起來。把時間拉長來看，你就會慢慢發現，沒有 AI 你甚至已經不會 「寫程式」 了。
我們其實已經刻意不再看 AI 產生的程式碼了。
AI 產生的程式碼既乾淨又具有欺騙性。介面看起來很好，測試（也是它生成的）也通過了。彷彿整個程式碼庫都是由彩虹和陽光組成的。難怪工程師只是接受變更然後往下走。但我們不只是如此。
技能退化並不是這個產業獨有的現象。任何沒有 नियमित 使用的技能，最終都會退化。你總是比較容易先 口述 要做什麼，直到你自己 親手做 為止。很多時候，單純「描述」一件事，並不等於真的把任務實作出來。
親自執行任務會迫使大腦思考。你會找到正確的邊界案例，會更在意使用者體驗，會思考哪些測試才合理，會分辨哪些程式碼更重要。這就是親自動手、再把 AI 當作重複性工作的輔助工具的美好之處。但如果我們把所有思考都外包給 AI，事情就完全不同了。
當然，你可以說人寫的程式碼也不完美。我們大多數人都不是 天才程式設計師，我們的程式碼經常有 人為錯誤。但這正是它已經有價值的原因。
因為背後有一個人。
已經有人承擔了決策。已經有人負責。已經有人具備脈絡。當出現錯誤時，那個人已經有基礎，不是從零開始。他們本來就寫了這段程式碼，也就有能力修正它。掙扎、做出錯誤假設，最後找到正確解法，這些都是建立真正理解的關鍵步驟。下次遇到同樣的問題時，他們很有可能這次能自己解決，效率也會更好。
用 AI 來學習，讓它刻意暴露你的知識缺口。去質疑它、檢視它，同時也驗證它。這才是使用 AI 更健康的方式，而不是把思考過程本身交出去。但如果你打算把所有工作都丟給它，那你不如直接宣告自己是 AI 的 按分頁機器人。
盲目信任會造成骨牌效應
當未經審查的 AI 生成程式碼被送進 PR 審查時，骨牌就開始倒下。菜鳥信任 AI，資深工程師信任菜鳥，最後程式碼進到正式環境。這不只會造成認知退化，還會產生一種虛假的信任感。
我們怎麼會讓自己走到這一步？
速度從來就不是衡量優質程式碼的最佳標準。程式碼庫本來就很脆弱，一直都是。一次錯誤的實作就可能引發一連串錯誤。
AI 會產生看起來完全可信的程式碼。作者看到後，容易陷入「它應該可以運作」的幻覺，而沒有真正理解內容。當這段新程式碼被推送出去的那一刻，脈絡就已經流失了。你是在一開始就賭它會成功，而不是透過 真的看過它 來刻意提高成功機率。
與其讓資深工程師去問這是不是一個好的變更，他們可能反而會先懷疑菜鳥是不是其實根本不懂自己送出了什麼（或者甚至根本沒讀程式碼）。
誰會想讀 1000 行以上的一坨爛東西？
閱讀 AI 生成的程式碼具備某種 傳染性，以至於審查者也可能一起偷懶，直接接受變更而不去審查。
畢竟這是人性。如果一次引入太多變更，品質檢查就不會被一致地執行。這會誘惑審查者直接略過整個變更，只快速掃過重點，或者更糟的是，再疊加 AI 審查代理來處理。這只會增加更多不確定性。
AI 很好，但前提是把它當作 輔助，而不是 替代品。它是一個應該被正確且負責任使用的工具。你沒辦法強迫所有人都採用這種工作流程，但你可以從自己開始。送出前先閱讀、理解 PR、帶著意圖去推送。
重點是讓你的 PR 成為 「可供審查」。它不必完美。最重要的是，那是你的，而且當審查者問起時，你能立刻捍衛它。你可以清楚解釋程式碼的內外細節，最終回答那個問題：「為什麼？」
下一步就是讓另一雙眼睛來看過你的程式碼，做一些潤飾、一些小修正（或大修正），或要求進一步重構。透過討論這些變更，脈絡才會 自然地傳遞 給團隊成員。
如果做得對，大家最終會跟上；如果沒做好，至少你已經讓自己免於 認知退化。
人類的大腦需要被挑戰
為了對抗認知退化，我們必須想辦法挑戰自己的大腦。資料顯示，現在的工作流程還不夠。我們需要鍛鍊大腦。
就我個人而言，我做的事情是每天至少解一道程式題，錄下自己解題的過程，並且像在教別人一樣，一步一步解釋我的思考流程。下面是我目前的影片收藏，內容就是對著鏡頭講話並展示螢幕。
這會暴露我的知識缺口，而我喜歡這樣。每次回顧錄影時，我都能很容易記下自己卡住的地方，以及在解釋時停頓的地方。錯誤和停頓總是能讓我回到自己當前技能水準的現實。但這套做法最棒的地方在於，它讓我有具體可改進的目標，同時也讓大腦保持活躍，並形成新的連結。
我確實看到了明顯的進步。
當我拿第一次錄製的內容和現在的解說方式相比，我可以明顯感受到自己更犀利了，也對正在使用的語言與概念有更深的理解。這讓我有了真正的比較，而我個人很喜歡這樣。就像玩遊戲一樣，當我看到角色屬性隨時間提升時，我總會更有動力繼續農下去。
除了程式挑戰之外，我也會透過再次確認最佳實務與方法來仔細檢視自己的工作。我覺得先上網查文件、範例以及不同做法很有幫助。先形成 自己的想法 之後，我再用 AI 來補充那些知識，幫助我更深入理解主題。
也有幾次我抓到 AI 建議使用已棄用的方法。
如果我沒有先自行盡責地研究主題，我根本不會注意到這件事。那我把這點指出來之後，AI 的回答是什麼？
「你完全正確！」
對啊……那時我才意識到 AI 有多麼 不可靠。
這種東西就是碰運氣。起初你對主題知道得越少，就越容易漏掉東西。我的意思是，它們甚至在我們輸入提示之前就已經先提醒我們了。
不過總的來說，以上是一些對我有效的做法，對你來說可能不同。重要的是，你要持續挑戰自己的大腦，而且要挑戰到足以維持敏銳的程度。
當你決定把思考外包出去的那一刻，認知退化就已經悄悄開始了。直到你發現自己 在沒有 AI 幫助的情況下，已經無法像以前那樣寫程式，你才會真正意識到它。
紀律是最高形式的自我尊重
是的，我不會假裝清高地告訴大家，我一次都沒有嘗試過使用 AI 生成的程式碼。我試過，而且我不喜歡。我打開本機的 localhost，迎接我的是一堆 bug。讓我沮喪的不是那些 bug 本身，而是我根本不知道該從哪裡下手。
無力感與缺乏主導權的感受，壓得人喘不過氣。
程式碼不是我寫的，是 AI 寫的。所以我繼續嘗試再下提示。它給了我大概三到五個需要先檢查的前置動作，才能解決問題。這真的很累。 這個工作流程不適合我。當 bug 依然沒修好時，它又給我另一組前置檢查和可能的修法，等於一再重新生成另一個解法。
你可以說我還沒有足夠經驗，也沒有正確的提示，或者我沒有適合用來描述架構與額外脈絡的 markdown 檔案。這些說法都合理。
但如果我們願意為了讓 AI 寫出「能用」的程式碼做到這種程度，那我們乾脆自己寫就好了。
好吧，我自己來。於是我真的自己做了。
我大約花了 15 到 30 分鐘除錯、反覆嘗試、研究、修正、弄壞、再修正，最後做出我需要的元件。過程中確實有掙扎，但那是我知道自己正在前進的那種掙扎。那種感覺就像真的在爬梯子。這種掙扎是具體可感的。
更重要的是，我知道得比之前更多了。程式碼是我自己的。錯誤是我自己的。解法是我自己的。最後，我所獲得的理解也是真正能留下來的。
在這種情境下，我唯一的敵人就是我的紀律。
我曾經讀過一句關於紀律的話：「紀律是最高形式的自我尊重。」 我一讀到就記住了，而我認為這句話非常適用於這裡。
在一個每天寫程式都越來越容易的世界裡，仍然有紀律地學習、不走捷徑，是一種 超能力。基礎知識永遠存在於我們遇到的每一件事之中。透過正確的紀律去投資它們，會默默贏得你的自我尊重，並最終贏得你周圍工程師的尊重。
張開你的眼睛
解法很簡單。
要對抗認知退化，我們應該更多靠自己思考。越常鍛鍊大腦，就越能保留那些我們辛苦建立起來的技能。
我不是說我們應該完全拋棄 AI。那會浪費一個可用的資源。我想說的是，要負責任地使用 AI。把它當作工具、當作輔助，讓它進一步提升我們的思考，而不是取代思考。
AI 很強大，但還不到應該接管軟體開發中每一個決策的程度。那樣只會直接通往認知退化。請記住，AI 會放大控制它的工程師身上正面與負面的做法。和任何工具一樣，如果使用不當，最終產出的結果就會走偏。
到了最後，成為新一代仍然重視品質的軟體工程師的一份子吧。不必完美，也不必交付得很快。重要的是，你要擁有它、能捍衛它、能在出錯時修復它，並且最終持續在自己的道路上進步。不要讓便利成為把思考外包出去的理由。
所以，張開你的眼睛。
感謝閱讀。這篇比我預期的還長。我最後一刻才決定加入這張《復仇者聯盟：末日之戰》預告片裡的史詩級圖片。我覺得它很適合結尾。掰掰。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
