如何避免用 AI 用到失去技術判斷力?

最近在社群中有一位在美國 Cornell 大學讀電腦科學的博士生，在微軟實習時遇到一個尷尬的狀況。她提到「我的合作夥伴好像太依賴代理工具了，什麼問題都想叫它修。結果他們自己也說不清楚系統到底怎麼運作，甚至對於我卡在哪裡，也缺乏一些基本理解」。

不僅如此，在要解決問題時「他們雖然有主動說可以約線下見面，幫我一起解決問題。但真的見面之後，情況就變成：他們在旁邊提示自己的代理工具，而我尷尬地一起看；或者換成他們叫我提示我的代理工具，然後他們尷尬地一起看」。

什麼是認知投降 (Cognitive Surrender)?

這讓人想到前陣子賓州大學做的一個關於認知投降 (cognitive surrender) 的研究。所謂的認知投降，是指使用 AI 的人，直接把 AI 的輸出當成自己的輸出，在過程中沒有去檢驗，也沒有加入自己額外的觀點。

具體來說，在這個研究中，研究者找了受試者來進行實驗。在受試的過程中，他們請受試者完成一些不同的題目與任務，其中有一部分受試者可以使用 AI 助手，另一部分則不行。當然，這兩個組別有做好隨機控制，所以能夠確保真正被介入的變因，就是過程中一組可以使用 AI，另一組不能使用 AI，其他條件基本上是均等的。

在實驗過程中，實驗者偷偷把 AI 提供的某些解答，透過提示詞讓 AI 回答成錯誤的答案。他們在這個過程中發現，當 AI 的答案是錯誤的時候，那些使用 AI 的人的答案也會跟著變錯。

換句話說，這些人使用了 AI，也同時吸收了 AI 的錯誤。

但更讓人擔心的是，當他們回答了這個錯誤答案之後，研究者進一步評估他們對這個回答的信心程度有多高。結果發現，他們的信心程度反而比沒有使用 AI 的人還要更高。這是因為 AI 往往會使用一種非常篤定的語氣來做解釋。而這些受試者在看完 AI 給出的、非常篤定又完整的解釋之後，就相信了它的解釋，並且因此覺得這個回答是正確的，所以他們會很有信心。

大家可以試想，如果這樣的事情發生在實際工作中，會是非常可怕的。

以工程師的工作來說，假設你請 AI 代理幫忙寫了某一段程式碼，然後出現像這個實驗中提到的認知投降徵兆。你直接把這段程式碼當成自己的輸出，在過程中沒有對這段程式碼做任何 code review。接著，因為 AI 在寫這段程式碼時，它的輸出與描述自己如何寫的過程都非常篤定，所以你也就相信了。

最後，很可能你會提交一段錯誤的程式，然後自己還很有信心，覺得自己提交了一段品質非常好的程式。因此，有認知投降這樣的徵兆，是非常危險的。

越來越多工程師失去技術判斷力

不僅是在微軟，近期 Reddit 上有另一位網友分享，自己的技術主管以前是那種會在白板前花好幾個小時，畫複雜系統設計的人。他會解釋每一個取捨，確保大家都理解每個決策背後的原因。結果現在都「直接貼進 ChatGPT，叫它解釋就好」。

而在他的團隊上週有一個競爭條件 (race condition) 的問題漏進了正式環境。當原 Po 指出這件事時，他的主管卻回說「可是 AI 說它是執行緒安全的 (thread safe) 的」。

在這兩個案例都能看到，即便 AI 代理能力越來強，也不代表能完全什麼都不管，讓自己進到認知投降的狀態。不過，從團隊的角度來看，可以怎麼做? 能建立什麼機制，確保使用 AI 時有效率，從中該有的理解與學習卻不會被犧牲?

如何避免認知投降?

要避免認知投降的方法有幾種，其中最推薦之一的是一位曾在 Notion 工作的工程師分享的做法，非常值得推廣。他在每次要提交 AI 寫的程式碼之前，會請 AI 根據這次的改動出幾道問題，除非他能答對這些問題，否則他不會提交。透過這個過程，他確保自己對 AI 產出的每個細節都真正理解，而不是在不明就裡的狀況下就把東西送出去。

這件事不只適合個人實踐，更推薦引入到整個團隊。現在很多團隊會用 AI 來寫 Git 提交訊息，或直接讓 AI 幫忙發 PR，可以把這個小測驗機制直接整合進相關的指令中。每當成員要用 AI 發起提交或建立 PR，AI 會先提出幾道問題，只有成員通過測驗後，AI 才實際執行提交或發出 PR。透過這個機制，就能確保每位成員在提交 AI 寫的程式碼之前，都真的弄懂了改動背後的細節。

另一個值得借鑒的做法，來自 Amazon 在經歷上述事故後所採取的應對措施。他們導入了一個機制，任何 PR 合併之前，都必須經過人工簽署的流程，類似於 code review 中要求特定人員核可才能合併的慣例。對於 AI 代理產生的改動，Amazon 要求必須有人類工程師實際審核並簽署，才能讓 PR 被合併進去。

這個簽署機制和前面談到的「負責任文化」互相呼應。光是口頭要求大家為 AI 的產出負責，效果可能有限；但如果今天合併進去的改動上面印著你的名字，情況就不同了。一旦發生事故，所有人回頭一看，就會清楚看到這個問題是由哪位工程師簽署核可的。這個機制本身就會讓成員更有意識地嚴格審查 AI 的產出，避免自己成為那個沒有盡責把關的人。

閱讀更多

除了上面提到的方法，如果對這個主題感興趣，我們在 E+ 的《AI Coding 201:從實戰到最佳實踐》課程有詳談。歡迎加入 E+ 觀看與交流。