前言
「為什麼這裡要用這個型別？」
當同事這樣問我的時候，我脫口而出的只有「我先去查一下」。明明是我負責實作的，卻沒辦法當場順暢地說明。它能運作，測試也都通過了，但一旦被問到為什麼要這樣寫，就會語塞。自從 AI 程式編寫工具普及之後，AI 參與的實作越來越多，這種副作用也開始一點一點浮現出來。
自從開始使用 AI 程式編寫工具後，生產力確實明顯提升了。導入新函式庫、解決錯誤，過去可能要花半天的工作，現在幾十分鐘就能完成。而這些也都是事實。但我開始意識到，自己正逐漸變成一個「不是自己寫得出程式，而是覺得自己像是能靠 AI 生成程式來寫程式的工程師」。
為什麼會產生「好像懂了」的感覺
回頭看我的情況，主要是以下四個因素疊加在一起。
- 上下文不足
在沒有理解正在使用的函式庫設計理念，以及那個工具為什麼採用那樣的 API 設計之前，就直接問 AI，並讓它依照需求規格幫忙做出來。表面上能跑，也沒有錯誤，但缺乏根本性的理解。 - 把「能跑」誤認成「正確」
沒有錯誤、測試通過。僅僅因為這樣，就誤以為自己「理解了」。但沒有錯誤，和能不能說明為什麼這個實作是對的，完全是兩回事。 - 把思考外包
原本在實作新功能時，工程師應該先自己思考：「要怎麼設計比較好？」「這種資料流適合哪一種模式？」但從開始使用 AI 之後，這個過程整個被替換成「把 issue 丟給 AI，讓它規劃，再讓它參照規則統一實作格式」的流程。
我做的已經不是設計判斷，而是在替 AI 打造一個能順利運作的環境。問題拆解與設計判斷這些本來應該透過實務經驗逐步培養的能力，不知不覺間被我交給 AI 了。
- 不花時間回顧
這可能是實務上最嚴重的因素。工作有期限。「能跑就好」之後就接下一個任務，沒有保留回頭檢視自己寫過程式的時間。在有交期壓力的情況下，如果不刻意安排時間去加深理解，那這段時間永遠不會自己出現。結果就是，對於「大概能運作」的程式，只是模糊地覺得自己懂了，卻沒真正成為自己的能力。
海外也有相同的討論
有這種問題意識的不只是我。海外也在研究、討論同樣的主題。
Anthropic 的實驗：AI 使用者的分數低了 17 分
InfoWorld 的文章介紹了 Anthropic 研究團隊針對 52 位初階開發者進行的實驗。
實驗中，研究團隊將開發者分成「AI 使用組」與「AI 未使用組」，讓他們完成一項使用陌生 Python 函式庫的任務，之後再進行理解度測驗。結果顯示，AI 使用組的測驗分數比 AI 未使用組低了 17 分。 尤其在除錯與程式閱讀能力方面，差距特別明顯。
有趣的是，AI 使用者自己也意識到了這種狀態。他們回報說「變得懶散了」「對理解還有很多落差」。另一方面，沒用 AI 的組別則覺得這項任務「很有趣」，並實際感受到自己對函式庫的理解加深了。
不過，並不是所有使用 AI 的人分數都低。那些不只讓 AI 生成程式，還會問「為什麼要這樣寫」這類概念性問題的開發者，維持了較高的分數。 也就是說，問題不在於使用 AI 本身，而在於使用方式。
「智能低電壓」的概念
Rithwik Shetty 的文章介紹了 Andrej Karpathy 提出的「智能低電壓（intelligence brownout）」這個概念。
這指的不是 AI 系統完全停止，而是部分無法使用的狀態；但在那個時候感受到的不只是單純的不便，而是連自己的判斷力都開始動搖的感覺。
當 AI 無法使用的瞬間，才會發現自己失去的不只是打字速度，連靠自己思考與判斷的能力也一起流失了。這不是「工具不能用的不便」，而是「思考依賴」的問題。所謂「AI 不只是單純的工具，而是會影響判斷流程的存在」這個指摘，分量很重。
你現在在哪個階段？
看到這裡，應該也有人會覺得「我好像也有同樣的情況」。以下是用來衡量自己對 AI 的依賴程度與理解程度的指標。請從上往下確認，看看自己現在處於哪個階段。
Stage 1：理解可視化
- 檢查： 你能把 AI 寫出的程式，連同每一行的意思都用口語說明出來嗎？
「這個變數為什麼需要」「為什麼選這個型別」「例外情況會怎麼處理」。如果無法回答這些問題，那你還處在「好像懂了」的階段。可以先從自己替 AI 產生的程式加上註解開始。
Stage 2：拆解
- 檢查： 你有讀過正在使用的函式庫的內部程式碼或文件嗎？
如果一直把函式庫當黑盒子使用，就還停留在表層。閱讀官方文件、確認型別定義、看看內部實作。這些步驟能成為脫離表面使用的起點。
Stage 3：重新實作
- 檢查： 不靠 AI，你能自己寫出同樣的功能嗎？
「寫不出來」是最明確的「你還沒有理解」的訊號。不需要逐字逐句完全重現同樣的東西，但能否用偽程式碼寫出處理流程，或用不同方法實作，會是重要的試金石。
Stage 4：設計思維
- 檢查： 你能說明的不只是程式碼本身，還包括設計意圖嗎？
「為什麼這樣分工責任」「為什麼這樣安排目錄結構」「為什麼這樣設計相依關係」。當你能從架構層級來談，而不只是單一程式碼時，理解的品質就會再往上一階。
Stage 5：批判（目標）
- 檢查： 你能立刻指出 AI 產生的程式有什麼問題嗎？
「這段未來會壞掉」「無法擴充」「耦合太高」「難以測試」「不具型別安全性」。能根據自己的經驗與知識做出這些判斷，就是最終目標。達到這個層級後，AI 會不再是威脅，而是放大器。
總結
AI 毫無疑問是非常強大的工具。它能提升生產力、涵蓋各種模式，也能教你以前不知道的方法。
但是，只要你持續把它當成「生成機」，自己的技術力就不會真正累積起來。找不到 bug 的原因、無法說明設計、面試時卡住。這些問題在剛開始使用 AI 時不容易看見，但會確實地慢慢累積。
最終應該追求的不是「讓 AI 幫你寫程式的人」，而是「能夠審查 AI 寫出來的程式的人」。
為了做到這件事，不需要什麼特別的訓練計畫。重點是不把生成結果照單全收，而是去驗證、去理解。舉例來說，在讓 AI 寫完程式之後，立刻丟下面這些提示詞，也會大幅改變你的理解程度。
請告訴我這段程式在設計上的取捨（優點與缺點）。這個實作最容易漏掉哪些考量？為什麼你推薦這種做法，而不是其他方法？
InfoWorld 文章中介紹的一句專家發言，讓我印象很深。
The risk of skill atrophy is real, but it’s not inevitable. It’s a choice
如果翻成中文，大概可以表達為：「技能退化確實是真實存在的風險，但那不是無可避免的，而是一種選擇。」
重新檢視自己與 AI 的相處方式，也是在重新檢視自己作為工程師的樣子。
參考文獻
- AI use may speed code generation, but developers' skills suffer - InfoWorld
- Relying on AI without losing yourself - Rithwik Shetty
- Measuring AI's impact on coding skill acquisition - Anthropic Research
株式会社シンシア正在招募沒有實務經驗的工程師與學生工程師實習生，並一起工作。
※ 關於在シンシア的工作方式，請見這裡
在シンシア，每年大約有 100 位沒有實務經驗的人申請並接受技術面試。
透過這些經驗，我們會在這裡介紹希望沒有實務經驗者特別培養的技術能力（文法）。
原文出處：https://qiita.com/jinxin4869/items/786af70f2697dfac4329
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
