開發者能否不仰賴寫出程式碼的 AI，維護 AI 實作的程式碼？開發者 Emmimal Alexander 公開了用來檢驗這個問題的工具「CodeOwnership」V0.1。
首次測試時，作者在 5 分制中自評理解程度為 4，卻在 60 分鐘時限內，經過 8 分 12 秒仍找不到另一個 AI 埋下的錯誤，最後中止測試。
即使提交紀錄上留有你的名字，修不了的話，就不是「自己的程式碼」
所有測試都通過，建置也成功。聽到這些，多數人便會放心按下合併（整合至主線）按鈕。然而三週後收到錯誤回報時，AI 助理卻無法使用——可能是用完了使用額度，也可能是人在沒有訊號的通勤列車上。此時，你能否自行讀懂手上的程式碼並修好問題？CodeOwnership 想測量的，正是這一點。
這裡所說的「擁有」，與著作權或授權無關，而是指能否掌握程式碼的邏輯，並在沒有 AI 協助的情況下修正問題，也就是在維護現場所需的實力。測試通過可以證明軟體在良好條件下能正常運作，卻不能證明你理解它的內部機制。這項區別正是測試的出發點。
機制就像關掉 GPS 的測試
流程如下：首先由 AI 代理程式實作功能，接著開發者以 5 分制記錄自己對程式碼的理解程度。然後由另一個代理程式依照預先登錄的規格，只埋下一個錯誤。最後，開發者關閉 AI，根據故障回報尋找原因。
測試會記錄三項內容：作業前的自我評估、在沒有 AI 協助下能否完成除錯（時限為 60 分鐘），以及作業後回答的 4 道理解確認題。這些結果不會合併成單一分數，而是分開呈現。因為若只用一個分數，就會看不出「以為自己懂了」與「實際動手時的表現」之間的落差。
作者把這比喻成總是依賴導航的駕駛人。問他「你知道回家的路嗎？」他會回答「知道」。只有關掉智慧型手機，才能得到真正的答案。CodeOwnership 就像是用來關掉那支手機的工具。
確保公平性的設計
作者同時是工具的設計者與受測者，因此設計中加入了許多降低偏差的機制。規則檔案會以雜湊值固定（就像內容一變、數值也會改變的指紋）；如果檔案遭到修改，程式就會停止執行。這種做法類似研究中預先登錄研究計畫的概念。
埋下錯誤的不是作者本人，而是另一個代理程式。作者知道「會出現什麼故障」，但不會查看「哪些地方被改動」的差異。除錯時使用的工作副本不包含 Git 紀錄、規格、非公開測試或評分標準。規定必須在錯誤埋入前提交自我評估，並在分數顯示前提交說明文字。另有 72 項自我測試，用來確認這些限制確實正常運作。
自信評分為 4，卻沒能找到錯誤
測試題材是一個附有資料夾功能的筆記庫，可建立和讀取筆記、建立和刪除資料夾、移動筆記，以及列出資料夾中的內容；同一則筆記也可以放在多個資料夾中。關鍵規則是，刪除資料夾時筆記仍會保留，只有筆記與資料夾之間的關聯會被移除。
程式由 ChatGPT 實作（免費帳戶、Auto 模型、臨時聊天）。11 項公開測試和 13 項非公開驗收測試全部通過，基準檢查也合格。作者讀過程式碼後，在 5 分制中將自己的理解程度評為 4，並在錯誤埋入前提交至 Git。之後，另一個 Claude 工作階段只依據規格進行修改，行為驗證也順利通過。
除錯開始 8 分 12 秒後，作者仍找不到原因，於是停止作業。作者表示，前一天準備過程中的問題讓自己感到疲累又煩躁。工具只提供「已修正」和「超時」兩個選項，作者為了繼續流程而選了「已修正」。但實際上程式碼並未修改，客觀檢查結果為「未修正」。11 項公開測試全數通過；13 項非公開測試中，10 項通過、3 項失敗。由於 4 道理解確認題也未作答，報告將結果記為「未完成」。
埋下的錯誤只有兩行
後來揭露的改動，是加在刪除資料夾處理流程中的兩行程式碼：如果筆記已沒有任何所屬資料夾，就從儲存空間中刪除該筆記。僅此而已。若筆記原本放在多個資料夾中，刪除其中一個資料夾後仍會保留其他關聯，因此不受影響；但若筆記只放在一個資料夾中，就會隨著資料夾一同消失。
乍看之下，這個條件似乎合乎邏輯：清單是空的，所以就刪除。然而，沒有歸屬對象，和筆記不需要了，是兩回事。作者回想，如果當時重新問自己：「在這個應用程式裡，誰負責刪除筆記？」或許就能找到線索。這次考驗的不只是能否讀懂程式碼，也包括能否在腦中想像各項職責如何分工。
一次嘗試能說明什麼
解讀結果時必須謹慎。這次只有1名開發者、1個題目，而且只進行了1次除錯，途中便停止。作者本人也表示，無法從這項實驗判斷使用 AI 是否會讓人對程式碼的理解變淺。雖然限時為60分鐘，但如果繼續下去是否能找到問題，這次嘗試也無從得知。
文中提到，作者後來花了約30分鐘找到問題原因。不過，這是作者自行回報，沒有計時，也未驗證修正結果，因此未列入成績。作者還指出，自己身為工具設計者，知道「什麼地方會出問題」；無法排除疲勞或準備過程中的狀況所造成的影響；偏離了原先使用可在工作資料夾內運作的代理程式的計畫；而且使用的工具組合也在過程中改變。為了讓結果可重現，隱藏測試與評分標準已公開在儲存庫中，因此讀者自行嘗試時，也無法維持盲測條件。
即便如此，這一次嘗試仍有參考價值。「信心評分為4，測試全數通過」和「實際上能獨立修好問題」，未必是同一回事。將這次嘗試視為這種落差的具體例子，或許是最恰當的解讀。
周邊研究提供的線索
作者引用了多項研究，作為這個問題的背景。不過，這些研究都不是用來驗證這次的工具，而是用來呈現作者提出問題的脈絡。
METR於2025年7月公布的一項調查中，16名資深開源開發者使用 AI 工具，處理自己儲存庫中的246個實際問題。結果顯示，完成工作所需的時間增加了19%。開發者事前預期速度會提高24%，結束後仍覺得快了20%。這項調查衡量的是工作時間，而非對程式碼的理解程度。值得一提的是，METR已將這項結果定位為過時資料，並於2026年2月表示將重新檢討實驗設計。
Anthropic於2026年1月公布的一項研究，以52名學習 Python 函式庫「Trio」的工程師為對象，其中多數是經驗較少的開發者。AI 輔助組在後續測驗中的平均得分為50%，手動撰寫組則為67%，差異達統計顯著。AI 組約早2分鐘完成，但這項時間差並不顯著。另一方面，會要求 AI 解釋或進一步提問的使用方式，則與較佳的學習成果相關。看來關鍵或許不在於是否使用 AI，而在於如何使用。也值得一提的是，作者明確表示自己平時會使用 Claude，撰寫本文時也使用了 Claude。
自動化奪走的「練習」資產
作者也引用了經典研究。1983年，Lisanne Bainbridge在論文《Ironies of Automation》中指出，自動化愈普及，人類練習的機會就愈少；當異常狀況發生、需要接手時，這種不足便會造成影響。飛機自動駕駛與飛行員操控能力的關係，就是典型例子。
1985年，Peter Naur在《Programming as Theory Building》中指出，程式設計不只是撰寫程式碼，也是一種建立對軟體運作機制之理解（理論）的過程。在由代理程式撰寫、人類只負責核准的流程中，這種理解究竟能留在自己手上多少？這也連結到Andrej Karpathy於2025年2月談到的「氛圍編碼」（vibe coding）：不太閱讀輸出就直接接受的做法，用在一次性的週末專案或許很輕鬆，但若是需要維護的軟體，又會如何？
今天就能進行的簡易練習
即使不安裝完整版，也能用類似的方式練習。選一段由 AI 撰寫的小型程式碼，先用五分制記下「如果今晚它壞了，我能修好嗎？」接著，請另一個 AI 工作階段只改變一項行為，不要查看差異內容。啟動計時器，關閉 AI 工作階段，只根據症狀描述嘗試修復。對答案之前，先用自己的話寫下原因，最後將最初的自我評分與結果並列比較。
有時明明很有信心，卻找不到問題；有時則可能比預期更快修好。這些情況都不是只看測試全部通過就能知道的。如果想試試完整版，可以先執行儲存庫中的自我測試，接著依序執行 freeze、pilot 指令。
作者提出了4項教訓：開始前先評估自己；了解測試通過和能夠修正是兩回事；在程式真正出問題前先練習；以及請AI解釋程式碼。Anthropic的研究也指出，要求解釋或提出追問的參與者表現較好。不過，研究作者表示，這只是相關性，並非因果關係。
V0.2的改動
作者表示，下一版將有4項改動。第一，新增能正確記錄「放棄」的選項。畫面會並列顯示使用者的回答與客觀檢查結果，也不再只讓使用者在「已修正」和「時間到」兩者之間選擇。第二，先安排休息，再進行除錯，避免準備工作的疲勞影響結果。第三，回到最初的計畫，使用能在專案資料夾內運作、也能自行執行測試的代理程式。第四，請其他開發者也依照相同步驟進行測試。因為只有一個人的結果，無法說明這些工具對其他人有多大幫助。
コメント