ExplainThis 全端開發雙週報 #82 如何避免用 AI 反而學不到東西
如何避免用 AI 反而學不到東西
嗨～歡迎閱讀第 82 期 ExplainThis 全端開發雙週報！
在這期的雙週報中，想談一個我們認為近期對軟體工程師來說最重要的話題。我們有為這期的主題做影片版本，推薦感興趣的讀者可以觀看
如何避免用 AI 反而學不到東西
最近在社群中有一位在美國 Cornell 大學讀電腦科學的博士生，在微軟實習時遇到一個尷尬的狀況 (連結)。她提到「我的合作夥伴好像太依賴代理工具了，什麼問題都想叫它修。結果他們自己也說不清楚系統到底怎麼運作，甚至對於我卡在哪裡，也缺乏一些基本理解」。
不僅如此，在要解決問題時「他們雖然有主動說可以約線下見面，幫我一起解決問題。但真的見面之後，情況就變成：他們在旁邊提示自己的代理工具，而我尷尬地一起看；或者換成他們叫我提示我的代理工具，然後他們尷尬地一起看」。
這讓人想到前陣子賓州大學做的一個關於認知投降 (cognitive surrender) 的研究。所謂的認知投降，是指使用 AI 的人，直接把 AI 的輸出當成自己的輸出，在過程中沒有去檢驗，也沒有加入自己額外的觀點。
具體來說，在這個研究中，研究者找了受試者來進行實驗。在受試的過程中，他們請受試者完成一些不同的題目與任務，其中有一部分受試者可以使用 AI 助手，另一部分則不行。當然，這兩個組別有做好隨機控制，所以能夠確保真正被介入的變因，就是過程中一組可以使用 AI，另一組不能使用 AI，其他條件基本上是均等的。
在實驗過程中，實驗者偷偷把 AI 提供的某些解答，透過提示詞讓 AI 回答成錯誤的答案。他們在這個過程中發現，當 AI 的答案是錯誤的時候，那些使用 AI 的人的答案也會跟著變錯。
換句話說，這些人使用了 AI，也同時吸收了 AI 的錯誤。
但更讓人擔心的是，當他們回答了這個錯誤答案之後，研究者進一步評估他們對這個回答的信心程度有多高。結果發現，他們的信心程度反而比沒有使用 AI 的人還要更高。這是因為 AI 往往會使用一種非常篤定的語氣來做解釋。而這些受試者在看完 AI 給出的、非常篤定又完整的解釋之後，就相信了它的解釋，並且因此覺得這個回答是正確的，所以他們會很有信心。
大家可以試想，如果這樣的事情發生在實際工作中，會是非常可怕的。
以工程師的工作來說，假設你請 AI 代理幫忙寫了某一段程式碼，然後出現像這個實驗中提到的認知投降徵兆。你直接把這段程式碼當成自己的輸出，在過程中沒有對這段程式碼做任何 code review。接著，因為 AI 在寫這段程式碼時，它的輸出與描述自己如何寫的過程都非常篤定，所以你也就相信了。
最後，很可能你會提交一段錯誤的程式，然後自己還很有信心，覺得自己提交了一段品質非常好的程式。因此，有認知投降這樣的徵兆，是非常危險的。
重點不在用不用 AI，而是如何用 AI
剛剛上面我們談的是，在使用 AI 代理時要如何保持思考。接下來，我們要談 Anthropic 先前做的一個研究 (連結)，主要是在討論使用 AI 對學習的影響。
他們想衡量的是，使用 AI 對於某個新技能的習得程度，會有什麼樣的影響。在這個研究當中，他們具體做的實驗，是把受試者分成兩個族群。而這兩個族群一樣有透過實驗方法控制變因，確保兩者唯一的差異，就是在過程中能不能使用 AI。具體來說，這兩個不同組別要執行的任務，是去使用一個自己沒有用過的 Python 非同步函式庫。其中一組可以使用 AI，另一組不能使用 AI。
最後，在他們解決完被指定的任務之後，需要做一些相關測驗。這些測驗主要會測量他們對這個 Python 非同步函式庫的概念理解、使用時相關程式碼的解讀能力，以及假設在使用這個 Python 非同步函式庫時遇到一些錯誤，他們能不能有效除錯。
這個實驗最後的結果發現，有使用 AI 的那一組，在對這個新的 Python 函式庫的概念理解、程式碼解讀與除錯能力上，整體分數低了 17%。所以，如果從一個新概念的習得，或者我們平常講的學習角度來看，假如我們單看這樣的結果，使用 AI 反而很可能讓使用者最後的學習成效比較差。
但這篇研究的結論其實不是停在這裡。另一個更值得討論的點是，如果進一步把有使用 AI 的那一組拆得更細，從他們如何使用 AI 的角度去做拆分，會發現使用方式的不同，其實會影響最終分數。
真正會導致概念習得與新技能習得比較差的方式，是直接委派 AI 去做事，也就是直接請 AI 去做，然後直接把 AI 生成的答案當作回答。這其實就對應到我們前面講的認知投降概念。
相對來說，那些即使有使用 AI，但後測分數，包含理解、閱讀與除錯分數仍然能夠維持比較高的族群，他們使用 AI 的方式並不是剛剛談的這種認知投降，而是會請 AI 協助解讀某個他們無法直觀理解的概念。
例如，在使用這個 Python 非同步函式庫時遇到某個錯誤，他們不是直接請 AI 去除錯，而是請 AI 解讀錯誤訊息。接著，他們透過 AI 的解讀理解為什麼發生錯誤，之後再自己去除錯。
又或者，我們看到分數最高的是一種叫做「Generation then Comprehension」的方式。這個族群的人一樣會使用 AI 產生程式碼，但是在 AI 產生完程式碼之後，他們會進一步問 AI 問題，確保自己最後能夠理解所有 AI 產出的程式碼。
所以在這個進一步的區分中，我們可以看到，真正會影響最終理解與除錯分數的，並不是是否使用 AI，而是怎麼使用 AI。假設使用 AI 的方式是認知投降，也就是直接請 AI 做完任務，過程中沒有任何理解，那麼用這種方式使用 AI，對於新技能的習得與理解分數會比較差。
但是，假如在使用 AI 的時候，是用 AI 協助自己理解某個原本不太理解的錯誤，或者 AI 生成完程式碼之後，有進一步請 AI 解釋，確保自己完全理解所有 AI 產生的程式碼，那麼用這種方式，即使使用 AI，對技能習得也不一定會有比較差的結果。
因此，如果你有在用 AI，但不想讓自己因為用 AI 而沒能真正學到東西，務必要確保自己有在用 AI 的過程中，請 AI 解釋讓自己能真的完全懂，而不是直接委派任務，自己卻完全沒有理解。
同時，在使用 AI 的時候，也要自己先想過答案，然後再用 AI 來做相關驗證或試驗。透過這些方式，相信大家即使在使用 AI 提升當下生產力的同時，長期也能夠保持自己的思考能力、問題解決能力與學習能力。
閱讀更多
如果你覺得這期的內容對你有幫助，想閱讀更深入的內容，歡迎加入 E+ 會員。除了有會員專屬的深度文與影片，探討前後端開發、AI 工程、職涯發展，同時有 Discord 社群一同交流與成長。
在 E+ 中的《AI Coding 201:從實戰到最佳實踐》課程中，我們更全面地談如何善用 AI，不僅用得更有效率、更省 token，也談如何幫助團隊。
本期推薦
這週 GitHub 討論度最高之一的開源專案 Ponytail (連結)，正中許多人在用 AI 的痛點。雖然現在 AI 在程式實作上，基本能做出各種想得到的功能，但往往會把 5 行能解決的問題，硬是用 500 行的方式來寫。我們寫了相關的介紹 (連結)
Vicki Boykis 在《Running local models is good now》中，分享她近期用本地模型做開發、寫測試、整理程式與跑代理式工作流的實際經驗 (連結)，對於想評估本地模型現在能做到什麼程度的人，這篇有不少可以參考的細節
Polar 在《Building an LLM safe design system》中，談他們如何設計一套比較不容易被大型語言模型寫歪的設計系統 Orbit (連結) 推薦給正在思考「AI 寫前端後，怎麼維持介面一致性」的人一讀。
《This is why you need Composition over Inheritance》一文用一段難以追蹤的繼承階層，說明為什麼組合通常比繼承更容易推理與維護 (連結) ，解析「把問題拆小，再把能力組起來」的程式設計視角
《Blazing Fast Websites with Speculation Rules》一文介紹如何用 Speculation Rules 讓瀏覽器預先載入或預先渲染使用者可能會點的下一頁 (連結) ，解析為什麼有些網站的載入可以接近瞬間完成
社群討論度最高的新聞，莫過於Midjourney 發表 Midjourney Medical，突然從生成圖片，跳到掃描人體，轉變幅度不是普通的大。為什麼會有這種決策? 背後的核心思維是什麼? 我們寫了一篇文章來討論 (連結)
Google Research 在《A low-carbon computing platform from your retired phones》中，介紹 UC San Diego 如何把回收手機拆出主機板，重新組成低碳運算叢集 (連結)，一探「舊手機不只是回收，而是變成另一種雲端基礎設施」這個觀點的實踐。