arXiv
版本控制歷史讓 AI 生成的程式碼不再無跡可尋
AI 可以讓每名學生提交的程式看起來都不一樣，但程式碼的建置過程可能留下有用的線索。Argus 分析了普渡大學六次 C 課程開課中的 42,695 份作業提交，利用不尋常的程式碼特徵和快速新增的內容，將需要人工審查的案例交給教職員。在大學程式設計實驗室裡，如果課程保留詳細的歷史紀錄並訂有清楚的 AI 協助規則，教師就能在採取行動前檢視一串可疑的編輯紀錄。
程式設計教師通常只能看到學生提交的程式。這讓教師有可能抓到兩名互相抄襲的學生，因為他們的程式碼可能看起來很相似。但要判斷學生是否先用 AI 助手完成作業，再在繳交前修改結果，就困難得多了。在大型班級裡，沒有人能讀完每一份草稿。錯誤的指控可能損害學生的學業紀錄和身心健康。
檔案並不是全部故事
傳統的程式碼抄襲工具會搜尋學生提交內容之間的相似之處。當一名學生抄襲另一名學生時，這種方法有效。當 AI 為每名學生產生不同的解法時，這種方法就不太奏效。即使學生沒有獨力完成解法，最後的檔案仍可能看起來是原創的。
版本控制歷史紀錄下檔案如何隨時間改變的過程，有點像是看見一幅畫每次儲存時的階段，而不只是最後的畫面。它可以顯示程式碼是逐小步出現，還是以一大塊內容加入。它也能顯示完成這份作業花了多久。但這樣的紀錄本身並不是證據。學生的程式設計風格可能反映其過去的經驗，而遇到困難的學生也可能更容易尋求外部協助。不尋常的程式碼歷史與較低考試成績之間的關聯，並不能證明 AI 導致學習成效較差。
從無形線索到審查清單
Argus 的設計目標，是把這些歷史紀錄轉換成一份供人員檢視的清單。它將程式碼中的不尋常特徵，與版本控制紀錄中的行為結合起來。它的指標包括課程沒有教過的進階 C 特徵、不符合課程慣例的風格、較短的開發時間，以及至少新增 30 行、速度達到每分鐘 15 行以上的爆發式新增內容。如果某項指標在全班很常見，Argus 就會降低它的權重。
這套系統用於普渡大學的一門大學部 C 課程。每當學生執行 make 時，課程伺服器就會自動提交程式碼，而學生也被告知了這項安排。在 2020 年及 2022–2026 年的六次春季開課中，Argus 分析了 3,893 個學生—學期組合，以及 42,695 份作業提交。2026 年春季，伺服器在 7,769 份提交內容中記錄了 381,748 次提交。
這些數字沒有被當作判決。教職員各自審查得分最高的學生，再取得共識。他們審查了累計分數最高的 300 名學生，以及某一份作業得分前 150 名的學生。三名教職員各花了約八小時。在得分前 150 名的學生中，審查人員認為其中四起案例的證據不足。
Argus 的平均分數從 2020 年春季的 1.1 和 2022 年春季的 0.5，上升到 2025 年春季的 4.2 和 2026 年春季的 11.9。2026 年春季，在完成第一次期中考的 584 名學生中，有 267 名——45.7%——在人工審查後被標記。被標記學生三次考試的平均成績為 61.9%，未被標記學生則為 73.5%。平均分數與考試表現之間的相關係數為 -0.537。這些數字可以幫助教職員決定從哪裡開始檢視，但不能解釋任何一名學生為何有這樣的表現。
程式設計實驗室可能看到的情況
如果這種方法成立，大學程式設計實驗室中的一份作業，就不會只根據期限前上傳的最終程式碼來評判。教職員可以檢視編輯的順序，把注意力放在一段可疑的貼上內容上，然後決定某個案例是否值得進一步處理。自行完成作業的學生，也不會那麼依賴教師只抓出抄襲同學解法的情況。
這樣的未來需要的不只是偵測器。課程必須收集詳細的開發歷史，並清楚說明哪些 AI 協助是允許的。人工審查人員必須繼續對指控負責，而證據也必須足夠有力，才能保護學生免受錯誤指控。在這種情況下，AI 使用偵測會成為分流工具：它是用來分配有限的審查時間，而不是自動化的紀律處分系統。