課程設計截止前一晚，宿舍燈還亮著。電腦屏幕上的網頁登錄功能一直報錯，電腦前，一名同組的同學先翻教程，又在群里請教他人。最后，他只能把報錯信息發(fā)給人工智能(AI)。幾分鐘后，頁面跳轉成功。大家都松了一口氣，但他卻盯著屏幕說：“程序跑是跑起來了，但我不知道AI改了哪里?！?table border=0 cellspacing=0 cellpadding=0 align=left class="adInContent">

　　這一場景讓身為計算機相關專業(yè)學生的我印象深刻，因為它說出了我們正在經歷的尷尬——AI能幫我們更快地寫完代碼，卻未必能讓我們真正理解代碼。我自己也會用AI查報錯、理思路、看示例，它確實有用，但越是有用，越容易讓人跳過編程學習中最慢、最笨也最關鍵的部分。

　　如果一門編程課最后只看程序能不能運行，問題隨之而來——這個分數到底是在評價學生的能力，還是在評價AI生成結果的完成度？過去，如果代碼寫不出來，知識的薄弱處便暴露得很明顯；而現在，一份AI輔助完成的作業(yè)可能格式規(guī)范、注釋完整，甚至比學生本人寫的代碼更“像樣”。但表面質量的提高卻遮掩了真實理解能力的不足。學生可能連“我其實沒懂”這件事都沒來得及意識到，就把作業(yè)交了上去。

　　編程課訓練的從來不只是語法能力，還有把模糊問題拆成清晰結構的能力。一個管理系統為什么要分表？為什么要做輸入校驗？函數為什么這樣封裝？異常情況如何處理？這些問題如果答不上來，即使代碼能夠運行，也只是一份完成了的作業(yè)，而不是長在學生身上的能力。

　　這影響的不只是一門課。如果編程課中的理解被“完成度”掩蓋，后續(xù)的數據結構、數據庫等課程都可能建立在一種并不牢固的能力假象上。彼時，學生缺的不是某個知識點，而是面對問題獨立拆解、驗證和修改的能力。

　　所以，AI寫代碼之后，編程課不應只問“這段程序能不能跑”，還要問學生“能不能說明它為什么這樣跑”。想象一節(jié)課上，老師不再只是收走代碼，而是隨機點開一份作業(yè)，請學生講清某個函數的作用；臨時改一個需求，看他能否調整結構；給出一段AI生成的錯誤代碼，讓他判斷問題出在哪里……這樣的考核也許不如統一提交作業(yè)方便，卻更能鍛煉學生的真實能力。

　　學生依舊可以提交設計說明、調試記錄和AI使用標注，但這些材料本身也可能由AI生成。因此，問題的關鍵不是多交幾份文件，而是讓學生在課堂追問、現場修改和口頭解釋中重新面對自己的代碼。那一刻，代碼不再只是屏幕上的結果，而變成了學生必須說清楚、改得動、擔得起的東西。

　　AI會寫代碼并不意味著大學生不必學編程。恰恰相反，它提醒我們，編程教育不能再滿足于培養(yǎng)“能交作業(yè)的人”，而是要培養(yǎng)知道該讓AI寫什么、知道AI哪里可能寫錯，也知道自己為什么這樣寫的人。

　　我后來常想，如果那個晚上，老師就站在我們身后，指著那段被AI改好的代碼問一句“它到底改了哪兒”，也許那個跑通的頁面才會真正變成一堂編程課。

　　作者：趙星皓 來源： 中國科學報

　　(作者單位：中央民族大學海南國際學院)