當AI能寫程式碼時，如何教授程式設計？

長期以來，程式設計教學一直依賴學生編寫的程式碼來了解他們的思維過程。錯誤、程式碼結構、笨拙的解決方案——所有這些都揭示了學生的推理方式和卡住的地方。但這扇窗戶從來不是完全透明的：學生總是會抄襲、臨時抱佛腳，甚至提交他們不完全理解的作品。然而，程式碼仍然留下了線索。生成式AI改變了這一切：一個完成的程式現在更多地反映學生的提示詞而非他們的想法。更令人不安的是，程式碼看起來越好，我們反而越難判斷學生真正學到了什麼。

這引出一個更大的問題：如果AI能寫程式碼，我們還應不應該教程式設計？我認為答案是肯定的，至少對某些學生和情境來說。但那是另一個話題。這裡我想聚焦下一步：如果我們繼續在AI時代教程式設計，如何才能知道學生是否真的在學習？

一些學校的回應是試圖抓住學生。他們使用AI檢測器、監控工具、鎖定瀏覽器、更嚴格的規則和更明確的榮譽準則。這導致了更多的猜疑。這些方法中有一些是合理的。教師想保護學習，學校想保持公平。但把檢測作為主要評估手段是脆弱的。斯坦福大學的研究人員發現，流行的AI檢測器經常誤判非英語母語者的寫作，一項研究中61.22%的託福作文被標記為AI生成。OpenAI甚至在2023年停用了自己的AI文本分類器，因為它不夠準確。如果創造工具的公司都無法可靠檢測AI，那麼基於它制定榮譽準則大概不是好主意。

但檢測不是真正的問題。即使我們有完美的檢測器，我們問的問題仍然是錯的。我們應該問的不是“如何阻止學生使用AI？”，而是“如何在AI時代教程式設計，利用它的好處，同時還能看到學生是否在學習？”

從工作室借來的方法

我們在德克薩斯大學奧斯汀分校的藝術與娛樂技術系（AET）遇到了這個挑戰。雖然我通常在電腦科學系，但AET隸屬於美術學院，那裡提供了許多其他學習和評估方式：工作室、批評、排練、修改和表演。在藝術領域，最終作品從來不是全部。一幅畫並不解釋其背後的選擇。表演不揭示排練。設計板不展示放棄的版本。作曲不會告訴你學生在何處掙扎或最終學會了什麼。

藝術教育發展出聚焦可見進步的做法。學生帶來草圖和草稿，討論影響、修改和失敗，並在作品進行中排練、表演和相互批評。在AET，我們教授創意程式設計，即用程式設計創作藝術、設計、遊戲或體驗。這不意味著為詩人程式設計。我們的學生——遊戲設計師、網頁開發者和程式設計師——從零開始學習，使用Processing和p5.js等工具。在創意程式設計傳統中，程式通常被稱為“草圖”，借用藝術世界的術語。它意味著臨時、探索性和開放修改——是你製作、測試、修改和分享的東西。

因此在創意程式設計中，我們已經傾向於工作室模式的草圖、實驗、迭代和批評。現在我們正進一步推動這一點，重新思考在AI時代如何教程式設計。以下是我們已經在使用或正在開發的三種方法。

公開工作

我們把課堂當作工作室。最重要的部分需要在教室中看到。學生展示他們的程式碼，包括錯誤開始、修改、做出的選擇和背後的理由。作業不再只是提交的東西——它們成為你在公開場合開發的專案。AI在課堂上不被禁止。相反，它被視為學習的有益助手。學生分享提示詞和技術。他們可以使用AI、Google、Stack Overflow、同學或任何其他資源。但你仍然需要對自己的工作負責。如果你提交或展示它，你必須解釋程式碼的功能、你為什麼做出那些選擇以及它是如何工作的。如果我需要問你的AI來理解你的程式碼，那就出問題了。尋求幫助沒問題，但躲在幫助背後是不行的。你不能把整個房間看著你構建的工作外包給AI。

一個真正的工作室需要學生每天在房間裡一起大聲交談。這也有助於解決另一個問題：很多人說現在的學生比以前更安靜。雖然這主要是基於傳聞而非長期研究，但這些傳聞很普遍且一致。各個校園的教職員工都在談論沉默的教室和猶豫不決的學生，尤其是自2020年以來。無論原因是什麼，這種沉默可以改變，解決方法和AI挑戰一樣：鼓勵學生參與。溝通是任何職業中最重要的技能之一，包括即時解釋想法、捍衛選擇和說服他人。學生僅僅透過線上提交AI引導的工作是培養不出這些技能的。當他們公開分享工作時，不僅能防止AI濫用，還能幫助他們建立最需要的技能。

角色反轉：AI作為教師和評估者

我們知道通常的模式：學生提問，AI回答，學生複製。我們試圖反轉這一點。在我們的新方法中，AI與學生一起討論一組主題，進行他們必須導航的對話，並最終評估他們對材料的理解程度，從而給出成績。這個想法在ChatGPT之前就有研究基礎。像Betty's Brain這樣的可教代理系統表明，解釋——即使是對軟體代理——會迫使學生組織知識、使連線清晰並發現漏洞。我們的模型不同地使用了這一洞見。學生不是在教機器人。相反，學生與它對話，學習、討論、辯論並展示他們理解的內容。

我們是如何做到的？透過相當簡單的提示工程，我們建立了Vera Molnár（1924–2023）的化身聊天機器人，她是演算法藝術的先驅。機器人扮演Molnár的角色，吸引學生討論隨機性、計算、生成藝術和創造性選擇。她的實踐正好位於創意程式設計學生需要思考的地方：在規則和變化、系統和選擇、計算和視覺判斷之間。系統提示設定要討論的主題和要問的問題型別。機器人與學生一起走過這些要點，對不清楚的回答要求更多細節，並持續追問直到有理解的證據。最後，它根據評分標準檢查對話，為我們提供清晰的記錄，顯示學生覆蓋了哪些想法，在哪裡掙扎，以及改進的程度。

除了通常準確的評估外，對話記錄變成了一種不同的證據，顯示了典型作業可能隱藏的內容。學生注意到了什麼？他們誤解了什麼？他們能否將概念與程式碼聯絡起來？他們能否捍衛自己的選擇？當被質疑時，他們能否修改自己的解釋？當我們交換角色時，一些令人驚訝的東西出現了：一份完成的提交無法展示的東西——一個學生在大聲思考。

讓理解成為表演：讓學生表演

程式設計從來沒有表演的傳統。音樂家、畫家和舞者有。現場程式設計正在改變這一點。每學期在AET，來自不同學科的學生一起舉辦一場演算法狂歡（algorave）——演算法銳舞的簡稱。音訊集、投影作品、遊戲演示、雷射、無人機、體驗設計。創意程式設計課程將即時視覺帶入現場程式設計傳統：程式碼即時編寫和修改，螢幕被投影，觀眾看著編輯器變化，而視覺對其他學生演奏的音樂做出反應。沒有預渲染。沒有隱藏機制。

2004年由TOPLAP撰寫的現場程式設計宣言包含一句適合AI時代評估的對話：“晦澀是危險的。顯示你的螢幕。”這不僅是表演倫理，也是評估策略。一個學生走上舞臺。投影螢幕是他們的編輯器。房間裡的每個人都能讀懂。音樂開始。他們在螢幕上構建一行程式碼。這是即時生成視覺的JavaScript。FFT、鏈式函式、高階操作。當你在舞臺上那樣操作程式碼時，你最好知道你在做什麼。AI可以幫助你準備。好。讓它來。但一旦你上了臺，問題就從“你能複製貼上程式碼嗎？”變成了“你能控制它嗎？”你可以把程式碼貼上到檔案中，但你無法透過貼上度過三分鐘的公共除錯，同時整個投影變成米色矩形。在現場構建中，理解無處可藏。你能閱讀程式碼、有目的地修改並在意外發生時恢復嗎？這就是流利度：在系統仍在執行時知道下一步做什麼。非常難抄襲恐慌。

關於評估的說明

到目前為止，我們的結果基於自己的觀察。我們沒有進行對照研究或比較不同群體，所以看到的可能只是早期變異而非廣泛適用的模式。目前，這些努力是實驗，不是最終答案。工作室和現場表演環境中的評估總是主觀且以人為本。它依賴於監控學生的進展、提供反饋以及觀察他們如何處理挑戰。我們不打算改變這一核心方法。對於Molnár對話作業，學生使用AI系統討論Molnár。AI隨後生成對每個學生理解的總結和分析。助教審查這一分析，進行自己的評估並打分。在我們的實驗中，使用評分標準的AI評估與助教自己的評價高度吻合。我們還使用AI幫助給期末編碼作業打分。在這個專案中，學生透過新增啟發式方法、搜尋演算法和學習行為來改進一個物件導向的遊戲。由於我們的助教在物件導向程式設計方面經驗有限，我們制定了一個詳細的評分標準，並讓AI模型用它評估每個提交。AI的分析作為支援提供給助教。它幫助他們看到每個專案的結構，發現重要的OOP設計選擇，並更自信地使用評分標準。助教仍然做出自己的評分決定。我作為OOP專家回答他們無法解決的問題。據我觀察，這在很大程度上幫助助教理解和評分學生的OOP設計工作。更廣泛地說，這兩種方法似乎能夠以難以達到的規模提供實質性反饋。