date time comments 0 pageviews

在大飛的YouTube 影片看到 Anthropic 今年 1 月底發表的論文：How AI Impacts Skill Fomration，設計了一場對照實驗研究 AI 工具如何影響程式設計師學習新技能，感覺很有意思，便找了論文來看。

實驗找了五十多位有 Python 開發經驗的開發人員(年資不一，分成 1-3 年、4-6 年、7年以上三類)，要求他們學習一個冷門的 Python 高階非同步程式庫 - Trio，研究評估指標實作任務耗時及測驗成績。

人員被分為兩組進行對照，「手動組」只允許查官方文件、Google 爬文，禁止使用 AI；「AI 組」則可自由使用基於 GPT-4o 的 AI 開發輔助工具，可以問答、寫 Code、Debug，甚至直接 Vibe Coding，光提需求不看 Code。

實驗設計為：所有受測者先有 10 分鐘的暖身練習，接著要在 35 分鐘內完成兩道程式設計題目(計時器實作及記錄檢索功能)，最後進行一項 25 分鐘的測驗，測驗共有 14 題，包含三類：單選概念題、閱讀程式碼推理執行結果、Debug 有錯程式等，測驗過程禁止使用 AI 工具。

結果有點意外，原本預期前半段的實作任務中，擁有自動化武器的 AI 組應該要輾壓使用冷兵器的手動組，但並沒有! AI 組的平均完成時間是 23 分鐘、手動組為 24.7 分鐘，只快了 1.7 分鐘!

測驗結果，AI 組的成績平均比手動組低了 17%，而 Debug 項目是落後最明顯的部分。

研究團隊深入分析，依 AI 組受試者使用 AI 的方式，將其區分為六種類型：

後段班 (測驗成績低於 60%)

  • AI Delegation 無腦搬運組 (4 人)
    完全複製貼上 AI 生成結果，不管內容，這群人完成速度極快，平均 19.5 分鐘完成實作練習，但測驗成績僅 40%
  • Progressive AI Reliance 半途而廢不想努力組 (4 人)
    實作第一題還有詢問 AI 深究，第二題放棄丟給 AI 做，平均完成時間 22 分鐘，測驗成績 35%
  • Interactive AI Debugging 有錯就問錯了再問組 (4 人)
    遇到錯誤訊息就丟給 AI 除錯，再出錯再丟給 AI，可能會歷經 5 - 15 次提問。這個群組最慘，實作練習平均 31 分鐘，測驗成績低到 24%

前段班

  • Conceptual Inquiry 打破砂鍋組 (7 人)
    會向 AI 提問觀念問題或要求 AI 解釋原理，主要靠自己完成任務並獨立排除錯誤，雖然過程出現較多錯誤，但速度表現不差，耗時 22 分鐘(僅次於全權委託組)，測驗成績 65%
  • Hybrid Code-Explanation 索取說明書組 (3 人)
    要求 AI 生成 Code 時要附上解釋，有點像買 3C 產品要求附上說明書，說明未必有幫助，但閱讀解釋會多花一些時間，實作時間 24 分鐘，測驗成績 68%
  • Generation-Then-Comprehension 思考理解組 (2 人)
    跟索取說明書組不同，受測者一開始只要求 AI 生成程式碼，複製貼上後再針對疑惑發問。其複製貼上程式碼方式分跟無腦搬運組一樣，差別在他們會先思考再詢問 AI 以理解程式碼，算是一種有腦搬運。這種方式的實作時間 24 分鐘，但測驗成績極好，高達 86%

研究團隊分析 AI 互動方式得到一些結論：

  1. Interaction Tax 人機互動稅
    AI 生成 Code 很快，跟 AI 溝通卻極花時間。有些 AI 組受測者花了 11 分鐘跟 AI 互動，甚至有 30% 時間被用來構思和撰寫 Prompt，部分受測者會反覆斟酌修改，光一個 Prompt 就花了六分鐘... (註：這我完全能想像，大家應該也有過類似經驗吧)
    BUT，斟酌如何提問(例如重新閱讀指令、修改查詢)雖然會多花時間，但受測者付出認知努力 (Cognitive Effort)，有助於理解與技能養成。目前興起的 Agentic AI 將剝奪人類構思提問過程，不利於技能養成。
  2. 提問類型是關鍵
    研究將受測者提問分為五大類：解釋、生成、除錯、能力確認與感謝。
    21/25 受測者會要求解釋，代表受測者有很高的學習參與度。16/25 的人要求 AI 生成 Code，成績墊底的 8 人中，有三個人只要求生成 Code，從頭到尾沒要求解釋。
    而過度依賴 AI Debug 的受測者，不但實作任務要花更多時間，測驗成績也最差。
  3. 看著程式碼打字不會讓你變強
    有一群受測者選擇不複製貼上，而是看著 AI 生成的程式自己手動輸入一次，而這番謎之操作除了拖慢時間，對測驗成績沒有任何幫助。事實證明光是打字並無助於理解，大腦得付出認知努力才會有效果。
    (我想起多年前強調「肌肉記憶」的開發培訓班...)

最後有點值得一提 - 「抓蟲除錯讓你變強」! (大家快，茶包射手當起來~~~)

手動組比 AI 組在實作過程遇到更多錯誤，被迫進行更多深入思考，釐清程式碼運作原理、學習新工具的正確用法。遭遇並解決錯誤在程式設計技能養成扮演重要角色，此一推論可解釋手動組測驗成績較好，而完全依賴 AI 除錯的受測者測驗成績爛到一塌糊塗。

但，處理的錯誤類型關鍵，花時間解決變數、函數名稱敲錯之類的低級錯誤不會帶來任何幫助，真正有學習價值的是與新程式庫核心機制相關的錯誤(像是忘了加 await、傳錯物件導致的 TypeError)，這些錯誤強迫開發者深入理解非同步程式設計的底層邏輯與概念。雖然 AI 組也會遇到錯誤，但 AI 生成程式很少會犯這類新程式庫專屬的高學習價值錯誤，喪失了珍貴的學習機會。

最後說說我自己的心得。

這個研究的規模不大，只有 50 位受測者用一個程式庫當對象，過程也只有一個多小時，其結果應無法涵蓋所有學習新程式技能的情境，但研究觀察結果及許多分析合乎邏輯，可以被理解與想像，能帶來一些啟發。

同樣是用 AI 寫程式，每個人的使用方式不同，目標也不同。有些人想要從此擺脫寫程式這檔事，有些人則想靠 AI 更快學習與掌握程式開發技能。

如果你是前者，這篇關於 AI 影響技能養成的研究與跟你的關係不大(咦，你怎麼會在這裡？)。若你是後者，想用 AI 輔助學習程式開發技能，則有幾點原則可以把握：

  1. 用 AI 產生 Code 再理解內容，可以獲得最好的學習成效
  2. 抓蟲除錯讓你變強(茶包射手當起來!!)，千萬別直接丟 Error 給 AI 解，會平白浪費學習機會，處理效率又差
  3. No Pain No Gain，要想學會東西，就必須付出認知努力。躺著不會變壯、不燒腦別想變強

這篇研究只聚焦 AI 與學習新技能的關係，若是在已具備開發能力的任務上使用 AI 加速，可能又是另一回事，但其中「人類必須透過認知努力成長(或維持現況不萎縮)」原則應可適用所有 AI Coding 情境。

我想到的簡單檢測方法是 - 只要你覺得這樣寫 Code 好輕鬆，代表你正在自廢武功；至於未來人類還需不需要會武功，是否仍要動腦寫程式，大家信仰不同，討論不出什麼結果，各自朝自己嚮往的方向前進便是。


Comments

Be the first to post a comment

Post a comment