LLM 輔助的灰色文獻理論建構

資料來源#

• 3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse

摘要#

Agarwal、Miller、Kästner 與 Vasilescu（CMU、arXiv 2607.07980）論文中這篇「偽裝成方法論論文的方法論論文」——也是他們的程式碼審查理論背後的次要貢獻。在軟體工程中，紮根理論的建構通常是從一個小而深入分析的基礎提煉而來（幾十場訪談、少數幾個團隊，至多幾百篇經篩選的論文）。這篇論文則把規模擴展到數千份實務工作者文件，將機械性步驟委派給 LLM，同時讓研究人員保留詮釋核心，並將這套流程（附帶公開的複現套件）作為未來儲存庫挖掘與理論研究的範本。

可移植的成果是一種分工：LLM 擅長高勞力、以引文為錨定的部分（語料庫建構、相關性篩選、開放編碼）；它們不擅長詮釋性綜合（軸心＋選擇性編碼），而嘗試自動化這一步產生了垃圾結果。

流程#

1. 語料庫建構（38,709 份文件）。 兩種來源，一套 AI 與審查詞彙表。Reddit：透過公開的 arctic shift 封存庫，取得 7 個分層中 43 個 subreddit 的 2020–2026 全部歷史資料，以詞界「review」閘門保留，不套用人氣篩選器（否則會壓制主題分析所需的少數觀點）→ 31,079 個討論串，每個都是包含留言樹的 Markdown 文件。網路：使用 Exa neural search engine，透過 68 個自然語言查詢，每個查詢都將一個方向性問題與其相反立場配對（「AI 如何改變審查」對上「為什麼審查沒有根本改變」），以避免語料庫偏斜；分三輪搜尋（開放網路／完整 Feedspot 部落格排名／類別平衡的機構網域）→ 來自 1,437 個網域的 7,630 篇文章。
2. 相關性篩選（LLM 判定器）。 透過 Gemini 2.5 Flash at temperature 0，對 23,631 個候選項目執行單一中立、具版本控管、推理優先的評分規則，保留 13,469 個（57%）；更強的模型重新判定隨機樣本後，在 Cohen's κ = 0.75 達成一致（實質一致）。接著將編碼限制在 2025–2026 年，因為代理撰寫的 PR 在此期間成為實際受到關注的議題。
3. 開放編碼（Thematic-LM）。 從來源分層的隨機樣本中抽取 3,100 份文件，使用 Thematic-LM 編碼。Thematic-LM 是一種先前經過評估的多代理 LLM 歸納式主題分析實作，其代碼本會隨資料到來而建立與修訂。三個編碼代理為每個片段附上 1–3 個簡短代碼（每個都附有逐字引文）；聚合器合併近似重複項；審查者則透過嵌入相似度維護一份具版本控管的代碼本。輸出為：來自 2,669 份文件、以 109,951 條引文為基礎的4,838 個代碼。所有步驟合計的成本約為每份文件 US$0.35。
4. 代碼 → 理論（人工）。 作者經過多次迭代，手動完成軸心與選擇性編碼，只使用模型來組織與擷取證據——將代碼本當作搜尋引擎，查詢實務工作者文本中與假設的構念或關係相關的內容，再加以確認或修訂。結果是 26 個構念、67 個關係，每一項都以編碼文本為基礎（有爭議的連結也帶有相反證據），並附上一份只能追加的清單，透過穩定識別碼（例如 G2935）追溯每條引文所屬的文件。

透過設計管理偏誤：三種極化的編碼者視角#

最銳利的方法論決策。作者沒有把三個編碼代理視為一般性的「觀點多樣性」，而是為這場極化的辯論具體化三種視角：中立歸納視角、關注代理／自動化審查可能如何削弱審查的批判視角，以及關注它們可能如何強化審查的欣賞視角。樂觀與悲觀的解讀是透過設計而非模型預設進入代碼本——這具體回應了人們對 LLM 編碼者會依自身先驗，將一場有爭議的論述壓平的擔憂。

承擔核心的負面結果：自動化在綜合階段失敗#

最具可移植性的發現，是自動化在何處停止運作。Thematic-LM 通常會在第二次自動化處理中發展主題，但面對近 5,000 個代碼時，這項假設失效；而從代碼走向因果理論的步驟，正是研究的詮釋核心。為了衡量自動化能走多遠，他們在一次由下而上的處理中，直接從代碼本擷取因果陳述——結果得到15,029 條陳述，但它們既膚淺、重複，又彼此重疊，因此他們改以人工建構理論。

失敗原因帶來的一般性教訓是：實務工作者使用的術語並不一致，而且同一術語可能指涉不同事物。有一度，單一的「review rigor」構念混淆了現在所稱的 review efficiency、review effectiveness、review depth 與 reviewer skill——將它們分開需要持續的詮釋工作。「這項區分確實有用，但並非文件中固有的內容；我們必須透過在脈絡中閱讀來加以建立。」詮釋仍由人類分析者負責。 這正是 LLM-wiki pattern 所劃出的相同界線——LLM 負責簿記；綜合／判斷才是人類仍須承擔核心作用的地方。

誠實的限制#

• 來源是生成式 AI 時代的文本，部分內容可能由 LLM 部分或完全生成；本研究探討的是關於審查的論述，將其視為實務工作者的論證，而非經驗證的第一手實務。
• LLM 編碼／篩選可能誤編、遺漏或幻覺生成內容——研究透過三個獨立編碼者、每個代碼背後的逐字引文、另外驗證過的相關性判定器，以及作者對每個關係的稽核加以緩解，但殘餘錯誤仍然存在。
• 代碼→理論步驟在每個結構性步驟上都依賴作者判斷（這是刻意的設計——軸心／選擇性編碼就是詮釋核心），因此不同團隊可能會畫出不同的構念；將每個構念都建立在編碼文本上，可以限制但無法消除此問題。
• 灰色文獻過度代表發聲積極的早期採用者，並帶有供應商倡議與事後事件回顧的偏見——研究透過數千個獨立來源的廣度加以抵銷，但並未消除。
• 飽和點很可能已被超過——作者推測遠少於 3,100 份文件就已足夠（「我們只是因為做得到才擴大規模」），但由於綜合階段是人工完成，他們無法指出飽和點究竟何時出現。

相關連結#

• Review as the Control Point — 這套方法產出的理論（也是論文的主要貢獻）
• LLM-as-Compiler Knowledge Base — 相同的架構界線：LLM 將原始文件編譯成結構化、互相連結且以引文為基礎的知識產物，但詮釋性綜合仍是人類承擔核心作用的地方；這個知識庫執行的是編譯側，而本文執行的是同一理念的理論建構側
• LLM-as-a-Judge — 相關性篩選器是典型的 LLM 判定器部署（中立且具版本控管的評分規則、Gemini 2.5 Flash、temp 0），在此作為語料庫閘門，而非輸出評分器
• LLM-Judge Validation — 本文正好實踐了該稽核所規定的做法：報告與更強的重新判定模型相比、經機率校正的 Cohen's κ = 0.75（而非原始的精確匹配一致率），作為其 LLM 判定器的可靠性數值

開放問題#

• 作者無法找到飽和點，因為綜合階段是人工完成——實際上最少需要多少文件？成本更低的樣本能否產出與 3,100 份文件理論相當的結果？
• 使用天真的由下而上提示來自動化代碼→理論步驟失敗了；這是提示／鷹架的限制，還是 LLM 對數千個代碼進行詮釋性綜合的真正上限？
• 三視角設計能管理編碼者偏誤，但相關性判定器與片段切分器都使用單一模型——這些上游閘門是否會對進入代碼本的內容施加自身的系統性偏向？

資料來源#

• 3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse — Agarwal、Miller、Kästner 與 Vasilescu（CMU、arXiv 2607.07980、2026-07-08），empirical。§III（方法：語料庫建構、相關性篩選、編碼、代碼本→理論）、§III-A.1（限制）、§VI（擴展灰色文獻分析的優點／限制、15,029 條陳述的負面結果、飽和度）、附錄 2–5