從四篇 2025–2026 論文洞察 AI 的極限與邊界

前言

近期無論是在企業內部或技術社群，「利用 AI 提升效率」已成為顯學。我們頻繁地看見各種成功案例分享，卻鮮少有人深入探討：

AI 的邊界究竟在哪裡？

當正向言論成為主流，工程師反而容易陷入一種集體焦慮——擔心自己落後或是被取代，卻又在實務中感受到 AI 的力有未逮。我認為，要最大化 AI 的工具價值，關鍵不在於掌握多少 Prompt 技巧，而在於對其「極限」有清醒的認知。

在被各種 AI 成功案例洗版的同時，我開始好奇這些工具背後有沒有「極限」。為了不被社群的熱度帶風向，我翻了一下最近幾篇指標性的論文，想從數據中找出 AI 的真實邊界。比起盲目跟風，我更想知道哪些方向才是正確的道路。

這篇文章主要會引用到四篇論文：

1. How AI Impacts Skill Formation, Judy Hanwen Shen, Alex Tamkin, 2026：Anthropic 發表的論文
2. SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration：阿里巴巴發表的論文
3. What Types of Code Review Comments Do Developers Most Frequently Resolve?：墨爾本大學跟 Atlassian 一起發表的論文，發表於 AES 2025
4. LLM-as-a-Judge for Software Engineering: Literature Review, Vision, and the Road Ahead：研究團隊主要來自中國的西安電子科技大學，發表於 ACM Transactions on Software Engineering and Methodology (TOSEM)

---

How AI Impacts Skill Formation

核心問題

這篇論文主要探討一個核心問題：當工作者（特別是軟體工程師）過度依賴 AI 輔助來完成需要「學習新技能」的任務時，是否會阻礙他們自身專業技能的發展？

論文實驗

研究團隊進行了一項隨機對照實驗，讓工程師學習使用一個全新的 Python 非同步程式庫（Trio）來完成指定的程式開發任務。實驗組配有 AI 助理（基於 GPT-4o），對照組則只能依賴官方文件與網路搜尋，任務結束後雙方皆須接受涵蓋「除錯、程式碼閱讀、概念理解」的技能測驗。

論文重點

論文的主要發現與結論可以歸納為以下幾個重點：

1. 使用 AI 會顯著損害技能學習

研究發現，使用 AI 輔助完成任務的參與者，在概念理解、程式碼閱讀與除錯能力上都明顯退步。在最終的技能測驗中，AI 組的平均分數比無 AI 的對照組低了約 17%。這顯示參與者將思考的負擔轉嫁給了 AI，導致他們沒有真正學會這個新工具。

2. AI 並未帶來顯著的整體效率提升

儘管 AI 助理能直接生成完整的正確程式碼，但在這項需要學習新概念的任務中，AI 組完成任務的速度在平均上並沒有顯著快於對照組。主要原因是參與者將原本用來寫程式的時間，轉移到了「構思如何寫 prompt」以及「與 AI 互動」上，有人甚至花了長達 11 分鐘在構思問題與等待回應。

3. 「遭遇錯誤並獨立解決」是技能形成的關鍵

對照組之所以能取得較高的學習成效，是因為他們在編寫程式的過程中遭遇了更多與 library 相關的錯誤，並且必須獨立解決這些問題。相反地，AI 組因為過程太過順利，錯失了從試錯中建立深層理解與除錯能力的機會。

4. 不同的 AI 互動模式決定了學習成效

論文觀察參與者的行為，將其歸納為六種不同的 AI 互動模式。

總結

這篇論文得出一個結論：「AI 帶來的表面生產力提升，並不能作為獲得真實能力的捷徑」。企業與工程師在將 AI 導入工作流程時必須非常謹慎，特別是在安全關鍵（Safety-critical）的領域中。如果人類工程師為了貪圖速度而放棄了主動思考（Cognitive engagement），未來將會缺乏驗證、監督以及除錯 AI 生成內容的核心能力。

---

SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration

目前 AI 的核心問題

這篇論文明確指出了目前 AI（LLM-based agents）在軟體開發與程式碼維護上的幾個核心限制。這些限制主要體現在面對「長期演進」與「多輪修改」時的不足。

1. 傾向累積技術債，缺乏長期架構規劃能力

目前的 AI 在「快照式（Snapshot-based）」的單次靜態修復任務中表現優異，能快速產出通過測試的程式碼。然而，AI 往往會為了短期的成功，採用 hard-code 等脆弱的修復方式來應付當下的測試，而不是編寫乾淨且具備未來擴充性的程式碼。

這些糟糕的早期架構決策會形成「技術債」，隨著專案的不斷演進與修改，技術債的成本會急遽增加，導致 AI 在後續的迭代中越來越難以修改程式碼，最終無法跟上軟體的演進步伐。

2. 難以控制程式碼的「衰退」

在長期的軟體維護中，修改程式碼時非常容易不小心破壞掉原本運作正常的功能，這種現象被稱為「衰退」。

研究實驗指出，目前的 LLM 在經歷長期、多輪的程式碼維護任務時，依然極度缺乏控制衰退發生的能力。在測試中，絕大多數主流模型維持「零衰退（Zero-Regression）」的比例低於 25%。這代表 AI 在反覆修改程式碼的過程中，有極高的機率會陷入「為了修復 A 而不小心改壞 B」的困境。

3. 無法勝任完全自動化、多回合的真實軟體開發場景

真實世界的成熟軟體開發，通常奠基於複雜的需求變更與長期的功能迭代，這需要經歷數十輪的 CI 循環。研究結論強調，儘管 LLM 在單次程式碼修改的能力上已有顯著提升，但如果要把 AI 投入到完全自動化、長期且多回合的真實軟體開發與維護場景中，仍面臨巨大的挑戰。

目前各家模型都容易讓程式衰退

儘管模型整體能力提升，但在長期的程式碼維護中，絕大多數模型的「零衰退率（Zero-Regression Rate）」依然低於 25%（代表極容易在修改新功能時破壞掉原本正常的舊功能）。

即使是表現最好的 Claude Opus 系列，零衰退率最高也僅有 76%。這表明目前的 LLM 要勝任完全自動化、長期的真實軟體維護，依然面臨挑戰。

AI 最大的限制在於：AI 擅長寫出「當下能運作」的程式碼，但還無法穩定產出「經得起長期修改與時間考驗」的程式碼。

論文貢獻

這篇論文的核心貢獻是提出一個全新的評估基準與機制，來「測量並暴露」這個過去被評估機制忽視的嚴重問題。

透過 EvoScore 指標引導 AI 重視長期架構設計

論文指出，要避免未來的程式碼衰退，AI 必須放棄為了快速通過當下測試而寫出「脆弱、hard-code」的捷徑，而是應該編寫乾淨、具備擴充性的程式碼。為此，論文設計了 EvoScore，並引入了「未來加權平均（Future-Weighted Mean）」的計算方式。當參數設定為後期權重較高時（γ > 1），這個評估機制會：

• 獎勵那些願意犧牲短期開發速度，但寫出乾淨擴充性佳、有利於後續演進的 AI。
• 嚴懲那些貪圖短期見效，但累積大量技術債，導致後續修改困難並引發程式碼衰退的 AI。

利用雙 Agent 模擬 CI 流程讓衰退更容易被發現

為了解決單次生成無法觀察到衰退的問題，研究設計了「架構師-程式設計師（Architect-Programmer）」雙 Agent 協作協議：

• 架構師會負責統整測試失敗的原因，並產出漸進式的高階需求文件
• 程式設計師則依據文件去修改程式碼

這種模擬真實軟體團隊 CI 的機制，在連續修改中反覆經歷測試，讓 AI 早期錯誤決策造成的衰退現象完全暴露出來。

---

What Types of Code Review Comments Do Developers Most Frequently Resolve?

核心問題

這篇論文主要探討了大型語言模型（LLM）與人類在 Code Review 評論上的差異，以及哪些類型的 LLM 評論最容易被工程師實際採納並解決。

人類與 LLM 評論的差異

研究指出，LLM 與人類審查者具有高度的互補性，且兩者關注的焦點會受專案環境（內部或開源）影響：

• 在企業內部專案（Atlassian）：LLM 產生的「bugs」評論比例是人類的 2.8 倍，且「維護性」評論也比人類多出近 1.4 倍，不過在「可讀性」上的關注則低於人類。這顯示在標準化的環境中，LLM 能更有系統地找出錯誤與維護問題。
• 在開源專案（OSS）：LLM 生成了更多的「維護性」評論，但極少提出「程式碼設計」建議。此外，人類常留下用於溝通、肯定的「no issue」評論（佔 9.0%），而 LLM 幾乎不會產生這類社交互動（僅 0.6%）。

工程師最常解決的 LLM 評論類型

研究團隊追蹤了 Atlassian 內部 4000 則 LLM 評論的實際解決率（即工程師後續是否有提交程式碼來修改該問題）：

• 高解決率領域：工程師最常採納並解決的 LLM 評論依序為 readability（43.3%）、bugs（41.9%）與 maintainability（36.2%）。這顯示這三類生成的建議對工程師來說具備高度的實用與可執行價值。
• 低解決率領域：程式碼設計（Code Design）的解決率最低，僅有 28.6%。由於設計問題通常涉及複雜的架構考量與大範圍修改，工程師往往不願在缺乏進一步討論與上下文的情況下直接採納 LLM 的建議。
• 未解決的原因：整體而言，仍有 60% 至 70% 的 LLM 評論未被工程師解決，這主要歸咎於評論缺乏清晰度、不夠精簡，或與當前審查的代碼缺乏關聯性。

提升自動化代碼審查工具的未來方向

研究也為未來的 LLM 工具開發提出了具體建議：

• 提高 Bugs 評論的生成比例：過去研究顯示 bugs 類評論對工程師最具實用價值，且解決率極高，但目前 LLM 生成 bugs 評論的比例依然偏低，未來應調整模型以更專注於找出 bugs。
• 優化評論的清晰度與關聯性：大量未被解決的評論是因為內容不夠清晰、過於複雜或與代碼缺乏關聯性，改善這些缺點是提升工具實際影響力的關鍵。

---

LLM-as-a-Judge for Software Engineering

核心貢獻

這篇論文主要探討如何利用大型語言模型（LLM）作為「裁判」，來自動化評估軟體工程中的各種產物，並為該領域至 2030 年的發展提出了詳細的研究路線圖。

隨著 LLM 被廣泛應用於生成程式碼與軟體產物，傳統的人工評估面臨耗時、高成本與評估者疲勞等挑戰。同時，傳統的自動化指標（如 BLEU 或 Pass@k）過度依賴標準答案，需要耗費人力設計測試環境，且難以捕捉「可讀性」或「實用性」等細微的軟體品質維度。

因此，具備強大推理與程式碼能力的「LLM 裁判（LLM-as-a-Judge）」典範應運而生，它不需強制執行程式碼，也不必然依賴參考答案，便能進行多面向的評估。

LLM 裁判在軟體工程的四大應用領域

論文系統性地回顧了 42 篇相關文獻，總結出 LLM 裁判目前主要應用於軟體開發生命週期的四個階段：

1. 需求工程：評估需求文件、系統規格與用戶故事的品質（如一致性、是否模稜兩可）。
2. 程式碼輔助：在無需執行代碼或缺乏標準答案的情況下，評估生成的程式碼、程式碼摘要、跨語言翻譯代碼，以及軟體工程問答的回覆品質。
3. 品質保證（QA）：評估 Bug 報告的標題與摘要、測試案例的覆蓋率，以及漏洞解釋的邏輯清晰度。
4. 軟體維護：評估 git commit 訊息的質量（是否解釋了更動的 "What" 與 "Why"）與 code patches 的正確性。

當前領域面臨的九大限制

論文指出，目前的 LLM 裁判研究仍處於早期階段，並面臨以下九項核心限制：

1. 缺乏大規模且高品質的人工標註基準測試

目前評估 LLM 裁判的研究多依賴只有數百個樣本的小規模資料集來衡量其與人類判斷的一致性。這種高品質資料的稀缺性威脅了研究發現的泛化能力，也是導致各研究實證結果不一致的核心原因。

2. 忽略了評估中的不確定性、主觀性與偏好

現有的驗證方法通常錯誤地假設主觀的軟體工程任務中存在單一且客觀的「黃金標準」，並強制將多位專家的意見合併為單一標籤。這抹煞了軟體工程評估中固有的多元觀點、評分者間的合理不確定性，以及團隊的慣用偏好。

3. 傳統對齊指標的不適用性

目前常用來衡量 LLM 與人類一致性的指標（如 Krippendorff's α 或 Spearman's ρ）原本是為評估人類評分者而設計的。這些指標建立在「存在單一正確答案」的錯誤前提上，且無法有效應對 LLM 產生的系統性、可重複的錯誤。

4. 實證研究結果不一致

受限於資料集選擇、提示詞策略以及模型配置的差異，目前學術界充斥著互相矛盾的結論。例如，部分研究指出傳統指標在衡量代碼摘要時優於 LLM 裁判，但也有研究得出相反的結論。

5. 針對 LLM 裁判「認知偏見」的研究不足

LLM 裁判容易受到多種偏見影響，例如「冗長偏見」（傾向給較長的答案高分）、「自我中心偏見」（偏好評估自己生成的內容），以及因為引入參考答案等外部脈絡而產生的「輔助資訊偏見」，但這些議題目前在軟體工程領域尚未被充分探討。

6. LLM 缺乏深度的軟體工程領域知識

儘管 LLM 在基礎編碼上表現出色，但在涉及軟體架構設計、形式化驗證或從零開始建構完整函式庫等複雜任務上，其評估能力依然不足，且經常無法準確分辨不同替代方案間的細微差異。

7. 過度集中於「單一模態」的評估

軟體開發高度依賴 UML 圖表、GUI 截圖與架構草圖等多模態的視覺產物，但目前的 LLM 裁判幾乎完全只專注於處理純文字與原始碼。這種單一模態的限制使其在將視覺產物「扁平化」為文字時，流失了關鍵的結構資訊。

8. 與外部軟體工程工具的整合有限

早期的 LLM 裁判過度依賴其內部知識，缺乏與外部開發工具（如靜態分析器、程式執行環境、效能分析工具或形式化驗證框架）的深度整合，限制了其進行全面性軟體評估的潛力。

9. 對抗性威脅與防禦機制的研究不足

目前關於 LLM 裁判安全性的研究大多只關注如「提示詞注入」這類明顯的攻擊，卻忽略了更具威脅性的「保留語意之竄改攻擊」（例如攻擊者刻意混淆變數命名或採用複雜但功能正確的邏輯來欺騙裁判）。這類隱蔽的弱點仍缺乏系統性的對抗性測試與防禦方法。

面向 2030 年的未來研究 Roadmap

為了解決上述限制，論文提出了具體的短、長期發展軌跡：

短期基礎目標

建立多元且大規模的基準測試，並制定能包容「主觀性與分佈情況」的全新評估協議，同時進行大規模的實證與偏見分析。

長期發展軌跡

• 提升 Internal Intelligence：加強 LLM 的軟體工程專家知識，萃取人類專家的直覺經驗，並發展「多模態 LLM 裁判（MLLM Judges）」，使其能同時分析 UML 設計圖與實作程式碼、或是比對 GUI 截圖與 UI 設計規範。
• 整合外部洞察工具：讓 LLM 裁判能串接編譯器、形式化驗證等外部開發工具，並建立「Human-in-the-Loop」的協作反饋機制。
• 打造強健的裁判：引入進階的對抗性測試，並透過對抗性微調等方法，強化模型抵禦複雜語義竄改與後門攻擊的能力。

總結

這篇論文的願景是將 LLM 裁判發展為可靠、強健且可擴展的「人類專家替代方案」，使其不僅能自動化評估海量的軟體產物，還能像資深工程師一樣提供多面向、包容多元偏好且跨模態的深度品質審查。

---

初步思考：從論文看 AI 工程的邊界

綜觀這四篇論文，我們發現了一個關鍵事實：

目前 AI 無論在「自動化開發」或「程式碼驗證（Code Review）」領域，仍存在顯著的局限性。

在 AI 自動化沒有辦法完整取代人類的情況下，我們如果盲目地使用 AI，從第一篇論文中會發現，這可能會讓自己的學習能力變得越來越差，導致在未來的幾年中，競爭力大不如前。

儘管當前輿論普遍聚焦於 AI 取代工程師的可能性，或過度強調其對生產力的提昇。但在第二篇、第三篇、第四篇結果顯示，AI 至今仍難以企及人類在高階架構設計與跨域長文本推理（Long-context Reasoning）上的能力。自動化工具或許能處理局部邏輯，卻無法完全理解複雜系統的全局依賴。

在下一篇文章中，我想要探討工程師接下來應該朝什麼方向前進：在 AI 工具普及的當下，我們應如何調整職涯重心？人類與 AI 該如何建構有效的協作體系，以達成能力互補？

---

Reference

1. How AI Impacts Skill Formation, Judy Hanwen Shen, Alex Tamkin, 2026
2. SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration
3. What Types of Code Review Comments Do Developers Most Frequently Resolve?
4. LLM-as-a-Judge for Software Engineering: Literature Review, Vision, and the Road Ahead