從事程式設計工作12年，最近半年，我開始大量使用AI寫程式。
令我吃驚的是，我發現自己的開發能力好像退步了。
所以今天想跟大家分享，工程師在用AI輔助工作時的一些注意事項。
時間分配的變化與建議
首先是時間分配的建議。以前工程師上班時，我認為可以分成四種狀態：學習、實驗、產出和摸魚。
這四種狀態的比例大約是3比3比3比1。
但現在有了像 chatgpt 和 github copilot 這樣的工具後，這比例有時會變成1比1比1比7，運氣不好時可能是2比2比2比4。也就是說，工程師上班摸魚的時間大幅增加，因為事情很快就做完了。
我的建議是，可以隨意調整實驗、產出和摸魚的時間，但學習的時間最好保持不變。
不然會感覺不踏實。久而久之，應該真的會變廢物、會失業。
抽象第一定律
在程式設計中，有一條稱為 抽象第一定律（First Law of Abstraction）的法則。
這條規則指出，在程式設計中，我們經常透過簡化來讓事物更容易使用。例如，當你建立一個套件或框架時，使用者無需了解所有細節即可使用它。然而，抽象雖然能減少工作時間，卻無法減少學習時間。
想像一個初學者學習網頁開發，他可能很開心地用 Vue 寫出一些動態效果，卻不太理解其背後原理。但隨著學習的深入，他終究會遇到無法解決的問題，而這時就需要理解 DOM（文件物件模型）、虛擬 DOM 以及 狀態管理 等基礎概念。
後端開發也是如此。初學者可能會使用 ORM（物件關聯對映） 來輕鬆與資料庫互動。然而，當遇到效能問題或需要執行複雜查詢時，他們仍然需要學習 SQL。
再舉一個例子，當剛開始接觸後端部署時，有些人可能會使用現成的 Docker 映像檔 快速部署服務。但當需要調整設定時，他們仍然得學習 Nginx、Linux、網路架構，甚至資料庫管理。
在軟體開發領域，AI 就像是一個巨大的抽象層。它能大幅減少工作時間，但卻無法縮短學習時間。
如果你完全依賴 AI 而跳過學習過程，短時間內或許能產出許多成果，但長期來看，你的學習成長可能比過去依賴論壇和 Google 搜尋還要少。
詢問研究員類型的問題
我的建議是，雖然我們要維持學習階段的時間，但學習的方向不再是去學用法/語法，而是去學更深的工程思維、設計哲學。我的建議是多提問研究員類型的問題。舉三個例子：
第一，當你碰到一個API、一個套件或框架，有黑箱感覺時，問AI：這個東西底層如何運作？是用什麼方式實作的？能否提供原始碼連結？
第二，如果你覺得某個套件、API 的設計怪異，問AI：為何這樣設計？
第三，看到某些設計讓你不滿意時，問AI：這樣設計是否有缺點，並指出你認為不好的地方，問AI有什麼想法？
這三種問題通常能獲得AI很好的回覆，而這類型問題，以前在 Google 或論壇上很難找到答案，查詢也非常耗時。
在AI時代，這些問題可以快速解決。因此，我們的心態要轉變成像研究員一樣，研究底層設計思維和哲學，而不是僅僅寫出程式碼。現在依靠AI可以快速完成程式碼，我們應該更深入地學習。
結論
我認為軟體工程師/程式開發者的定義已經改變了。
以前的開發者更像是各種套件和工具的使用者，花大量時間在實驗和理解這些工具的使用方式，然後將成果交付。
然而，若現在仍只停留在這個階段，幾年內很快就會被淘汰，這是殘酷的現實。
因此，我們應該自詡為研究員，各行各業皆如此。
AI的出現使我們需要思考哪些事情有意義，哪些事是AI不便處理而需人類完成的。
我們應該持續思考並問對問題。研究員類型的問題能幫助我們學習，也是現代工程師應多發問之處。
我之前舉了三種情況：遇到黑箱、怪異情況、不服氣時，可以提出有價值的問題作為範例供大家參考。
身為工程師，你認為還有哪些你常常詢問 AI、你覺得很有價值的發問方式？歡迎跟大家留言分享。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式