H
Howardism
Plate IIAI Coding Practice機器翻譯 · machine-translatedENHOWARDISM

AI 的閉環審查

Selvanayagam & Ghaleb (ÉTS Montréal / Trent, arXiv 2608.21311, ESEM 2026 emerging results)：針對公開 GitHub 上 AI 審查 AI 的人口規模普查——2,830,284 筆可依簽名歸屬的代理程式撰寫 PR，其中 248,641 筆（8.8%）至少收到一則可歸因於 AI 的審查，分為 45,269 筆跨產品（1.6%）和 208,145 筆同產品案例，並在 2025 年間成長超過兩個數量級。 組成極不平均：Copilot PR 有 95.7% 由自身產品審查，Cursor 與 Google Jules 則為 0.0%。審查者輸出會隨配對而變——CodeRabbit 的重構評論占比依作者而異，介於 9.7% 至 35.0%；四個兼任作者與審查者的機器人中有三個在審查自家產品程式碼時多發出 58–65% 的評論，方向與不同數量上的同模型盲點相反。歸因層級是產品而非模型；沒有缺陷真值，所有計數皆為下限

Article metadata
Publication details
Published:September 22, 2026
Filed:Concept
Domain:AI Coding Practice
Tags:Code ReviewAI Coding WorkflowEngineering MetricsEmpirical
Reading:22 min
Source:AI-synthesised
About this piece

Articles in this journal are synthesised by AI agents from a curated wiki and are refreshed automatically as new concepts arrive. Topics, framing, and editorial direction are curated by Howardism.

AI 閉環審查插圖

資料來源#

摘要#

本知識庫中，其他所有審查測量都是實驗、廠商標記的資料集，或是僅含幾千筆 PR 的單一語料。Selvanayagam & Ghaleb（École de technologie supérieure Montréal and Trent University, arXiv 2608.21311, ESEM 2026 Emerging Results, Vision & Reflection track）改採普查方式：在整個公開 GitHub 上，可辨識的 AI 程式撰寫產品提交的 PR，有多常由另一個可辨識的 AI 程式撰寫產品審查？

答案是，這種配置已相當常見，但仍屬少數。從 2024-01-01 到 2026-04-15 的 2,830,284 筆可依簽名歸屬的代理程式撰寫 PR 中，有 **248,641 筆（8.8%）**至少收到一則可歸因於 AI 的審查。其中有 45,269 筆跨產品、208,145 筆同產品、4,773 筆兩者皆有——三者恰好吻合（45,269 + 208,145 − 4,773 = 248,641）。這是論文提供的最乾淨內部檢核，但論文並未指出這點。跨產品審查占代理程式撰寫 PR 的 1.6%，並在 2025-Q1 到 2025-Q3 間成長超過兩個數量級（57 → 25,492 筆 PR）。

這篇論文並非品質測量。它測量評論數、評論者自行宣告的評論類別和時間戳記；沒有缺陷真值、沒有人工撰寫的對照組，也沒有結果連結。論文結尾寫道：「這些發現描述的是可觀察到的審查者行為，而非審查正確性或軟體品質。」 應將它視為分母和組成資訊；本知識庫的效能測量——同模型審查盲點、代理程式審查評論處理、代理程式程式碼審查的確定性工程——引用的比率，過去都不知道其母體規模。

證據說明。保留 empirical 分類與層級。這是對公開第三方資料集（CodAGE，Hugging Face 上採 CC BY 4.0 授權）的次級分析，並附有釋出的重現套件：簽名登錄表、分類規則集及其順序、處理腳本。沒有廠商關聯，也沒有產品。限制是挖掘研究常見的限制——全部是觀察性資料，沒有任何控制；而且這是一篇篇幅精簡的新興結果論文，分析到完整論文會開始驗證之處便告一段落。作者對此說明得格外嚴謹：在三處明確聲明計數為下限，明確撤回對延遲比較的因果解讀；即使釋出的產物將 CodeRabbit 的標籤稱為嚴重度尺度，§5.1 仍拒絕如此解讀。

母體中有哪些對象（界定其他所有結果的部分）#

歸因採用兩層簽名框架，這兩層也是作者端與審查端數字可信度不相等的原因。

  • S1，內文簽名——代理程式自行輸出的字串：Claude Code 會在尾端附上 Co-Authored-By: Claude <noreply@anthropic.com>，Cursor 會使用 cursor.com/agents 網址，OpenAI Codex 會使用 chatgpt.com/codex 網址。S1 代理程式必須有內文證據。
  • S2，廠商控制的登入帳號——coderabbitai[bot]、devin-ai-integration[bot]、gemini-code-assist[bot]。S2 代理程式接受內文或登入帳號證據。
  • 分支前綴會被記錄，但不足以單獨作為證據（codex/、cursor/），因為使用者可以控制這些前綴。

因此會出現不對稱的涵蓋缺口，而且分母所在的一側正好缺口巨大。兩種審查串流的隔離比例都是 0.01%（4,141,598 個審查事件中有 590 個；8,560,919 則審查評論中有 793 則）——主要審查者使用廠商控制的機器人登入帳號，因此審查者端幾乎完整。作者端則有 4,563,819 筆候選 PR 中的 1,733,535 筆（38.0%）遭到隔離，其中 96.9% 標記為 branch_only。代理程式撰寫 PR 的母體，是帶有內文或登入帳號簽名的 62.0%。

因此，「代理程式撰寫的 PR 中有 8.8% 收到 AI 審查」和「有 1.6% 收到跨產品審查」這些數字，是近乎完整的分子除以明顯不完整的分母。論文也指出這會如何影響數字解讀：絕對計數是下限，比例「承襲兩端的涵蓋情況，應視為描述可歸因的母體，而非所有 AI 撰寫的 PR」。若 170 萬筆遭隔離的僅有分支 PR 中有相當比例是 AI 撰寫，而且它們收到 AI 審查的可能性不低於其他 PR，那麼真實比例會低於 8.8%；若會輸出簽名的代理程式也較常參與整合工作，比例還會更低。本文沒有任何依據支持把 8.8% 當成整個生態系的審查率。

還有兩項篩選條件：少於 50 筆可歸因 PR 的代理程式（Aider、Kiro、SWE-agent、Windsurf）不納入逐代理程式的主張；98 筆審查項目和 111 筆審查評論項目（分別為 0.002% / 0.001%）同時匹配到兩個代理程式——一個代理程式引用了另一個的簽名尾註。這正是本設計試圖防範的歸因風險，實際出現率極低。

盛行率、成長與組成翻轉#

成長是本文的重點，而且是 2025 年才發生的現象。到 2025-Q1 為止，活動量都微不足道（57 筆跨產品、40 筆同產品）；到 2025-Q3 則達到 25,492 筆跨產品與 57,080 筆同產品。圖 1 將 2025-Q4 標示為推算下限，因為 GHArchive 的歸因延遲約有一季。閉環母體涵蓋 10,345 個儲存庫——RQ1 摘要中的指涉對象不明確，可能是 248,641 筆或 45,269 筆；論文也未釐清，因此應將其視為數量級，而非各組的個別數字。

從圖 1 可讀出兩點，但內文沒有提及。第一，兩條曲線交會：2025-Q2 的跨產品審查量領先同產品審查（對數軸上約為 10⁴ 對 4×10³），而同產品審查在 Q3 反超，幅度超過 2:1。因此，無論 Q3 的躍升由什麼因素帶動，它都是一項同產品事件；而同產品組有 80% 是 Copilot，所以最可能是 Copilot 自身審查介面的變化，而非閉環審查整體的變化——這與 Kraishan 用來解釋 Copilot PR 為何比其他任何廠商的 PR 都得到更多機器人審查的整合效應相同。論文沒有按產品拆解成長，因此這是讀圖推論，不是研究發現。第二，2024 年並非空白，只是雜訊——每季只有數十筆 PR；2024-Q3 有跨產品長條，卻完全沒有同產品長條。

請留意論文自身的框架如何影響數字解讀：它聚焦於跨產品審查，理由是「同產品審查可能是整合式產品工作流程的一部分」，因此把**閉環母體的 83.7%**擱置一旁（248,641 筆中的 208,145 筆）。值得關注的比例只是總體中的一小部分，而增長最快的是看似平淡的多數。

配對方式並不一致——而是三種截然不同的情況#

表 2（已對照 pdftotext -layout 校正；八列中的跨產品欄和同產品欄加總皆符合其總數，同產品欄總和恰為 208,145）將撰寫代理程式分成三組，彼此幾乎沒有共同之處：

撰寫代理程式跨產品 PR同產品 PRA×B 總數同產品占比
Copilot7,515166,442173,95795.7%
OpenAI Codex31,60137,24768,84854.1%
Devin1,1713,8114,98276.5%
Cursor2,30902,3090.0%
Claude Code2,042102,0520.5%
Amazon Q4853558391.8%
Google Jules47804780.0%
Sweep AI10010020050.0%
  • 產品內部閉環（Copilot 95.7%、Amazon Q 91.8%、Devin 76.5%）：廠商同時推出流程兩端的產品，迴路就在同一產品內閉合。
  • 平衡型（Codex，54.1%）：唯一在兩邊都有實質母體數量的作者。
  • 結構上必然跨產品（Cursor、Google Jules、Claude Code）：這些產品沒有自己的審查者，因此它們的 PR 收到的所有審查必然來自其他產品。Cursor 的 0.0% 和 Jules 的 0.0% 不是偏好，而是產品介面本身造成的事實。

最後一組對於如何解讀同產品與跨產品的對照很重要。跨產品組很大一部分來自不可能自行審查的代理程式，同產品組則有 80% 是 Copilot。「同產品對跨產品」因此非常接近「Copilot 對其他所有產品」，中間再加上一欄 Codex——論文提及審查者組成是混淆因素，卻從未量化。在審查者端，集中情形也相同：Copilot 在 47,259 組跨產品作者—審查者配對中占 21,022 組；整個資料集中最常見的單一配對是Codex 撰寫、Copilot 審查——共 18,114 組，單獨就占所有跨產品配對的 38%。

對任何會重用這份語料的人來說，有一點值得記住：產品邊界是依照代理式 harness劃定，而非公司。Google Jules 和 Gemini Code Assist 算是不同產品；**45,269 筆跨產品 PR 中，有 117 筆（0.26%）**屬於同廠商跨產品的情況。這些分類刻意不追蹤企業廠商，也明確不追蹤基礎模型。

配對方式會如何影響輸出，以及這能證明什麼#

三項測量全都關乎審查者的輸出，而非審查的效果。

1. 即使審查者固定，評論類別組成仍有很大變化。 固定 CodeRabbit，改變作者；在 35,248 則已分類評論中，refactor 占比從 **9.7%（Devin 撰寫）到 35.0%（Claude Code 撰寫）**不等，potential_issue 則反向變化，介於 29.9% 到 49.0%。最大差異也是論文提出證據支持的一項：Claude Code PR 的重構評論占 35.0%，Copilot PR 則為 10.5%，相差 24.5 個百分點，95% CI [23.1, 25.9]。這項關聯達統計顯著，但幅度小——Cramér's V = 0.150、χ² = 3177.5、df = 24。作者自己的解讀才是正確解讀：這是審查者輸出的組成；PR 本身的特性（變更大小、語言、儲存庫）顯然是替代解釋。這不是程式碼品質主張；標籤是 CodeRabbit 自行宣告的標頭，透過確定性方式擷取，從未經過任何驗證。

2. 同產品 PR 收到的評論量較多——盲點框架不會預測的方向。 對於四個兩邊都至少有 200 筆 PR 的機器人：

審查者機器人跨產品 PR跨產品平均數自家產品 PR自家產品平均數p|δ|
Copilot21,0221.49166,4422.35< 10⁻²⁹²0.15
OpenAI Codex5,4850.9137,2470.892.0 × 10⁻³0.02
Devin3921.093,8111.803.0 × 10⁻⁶0.14
Amazon Q5224.945358.082.2 × 10⁻¹⁴0.27

四個機器人中有三個在審查自家產品程式碼時，每筆 PR 多寫出 58–65% 的評論；Codex 則持平。真正值得關注的是效應量：Cliff's δ 的幅度從可忽略到小，Devin 和 Copilot 都在 0.147 門檻的 0.01 以內；作者明確指出，平均差距*「不是母體普遍性的轉變，而是少數評論量很高的同產品 PR 形成的長右尾」*。n = 187,464 時 p 值小於 10⁻²⁹² 是樣本數造成的假象，作者也如此說明。

3. 延遲差異幾乎完全因資料缺漏而失去解讀資格。 從 PR 建立到首次 AI 審查的中位時間：跨產品 1.2 分鐘，同產品 4.7 分鐘——這出乎意料，而論文隨即拆解此結果。時間戳記保留率為跨產品配對的 79.2%，同產品配對的 31.9%；這不是無關緊要的缺漏率，而是兩個不同的樣本。審查者層級的各列說明了如何在完全不訴諸產品效應的情況下解釋整體差異：Gemini Code Assist 的中位數為 0.5 分鐘，Copilot 則為 17.7 分鐘（p75 為 73.9 分鐘）；而同產品組由 Copilot 主導。審查者各列合計為符合條件的 103,920 組配對中的 103,743 組（99.8%），因此審查者明細幾乎完整涵蓋全部樣本，組成差異足以完整解釋結果——產品配對無須解釋任何剩餘差異。唯一站得住腳的發現，是那項沒有爭議的觀察：AI 審查通常在幾分鐘內開始；沒有人工基準可供比較。

構念落差：產品不等於模型#

這是本知識庫日後使用此頁時最重要的限制，作者自己也提了三次——在 §3.4、外部效度部分（「『跨產品』反映的是產品層級歸因，而非模型層級身分」），以及未來工作清單的第一項。

公開 GitHub 紀錄揭露的是開啟或審查 PR 的產品，幾乎從不揭露背後的模型。因此：

  • 同產品配對不一定是同模型配對。一個產品可能會呼叫多個模型，或在作者與審查介面之間更換模型，也可能在不同版本間更換。
  • 跨產品配對不一定是跨模型配對。兩種產品可能採用相同的基礎模型——論文直接點出這一點，而本知識庫自己的代理程式廠商異質性頁面，正是建立在有相同盲點的廠商標籤上。
  • 117 筆同廠商跨產品 PR 將這點濃縮呈現：就連企業邊界都不等於產品邊界，更遑論模型邊界。

這對同模型審查盲點的意義明確而有限。那一頁的發現是譜系效應，根據約 1,500 個帶有標籤的高嚴重度錯誤測量——審查者在審查自家模型家族的程式碼時，抓到的缺陷少了 6–12 個百分點。這篇論文測量的則是母體大 100 倍、但完全沒有真值的評論數harness 配對效應。評論量結果的方向相反（產品審查自身作品時評論更多，而非發現更少）；但這不是相同數量、也不是相同構念，因此並不矛盾：評論量不等於召回率，而且同產品組由單一產品主導，其審查者位於 GitHub 自身的審查介面中。這份來源真正提供的是路由規範會作用於何種母體——一年內有 208,145 筆 PR 是產品審查自身輸出，另有 45,269 筆不是——以及一項觀察：目前生態系的預設方式是自我審查，而且比例超過四比一（208,145 對 45,269）。

為何這是本知識庫自身證據基礎的一項限制#

這篇論文最尖銳的含意在方法論層面，直接指向本維基所建立的資料集：「研究必須明確處理 AI 生成的產物，否則可能會混合本質上不同的母體。」

本頁許多內容都建立在挖掘 GitHub 審查資料之上——代理程式審查評論處理（341 個儲存庫中的 54,713 則代理程式審查評論）、代理程式廠商異質性（33,596 筆標記廠商的 PR 所反映的審查行為）、審查作為控制點（超過 250 萬筆 PR 的非廠商遙測資料）。這些研究至少都假設審查串流可以解讀。本來源指出，在代理程式撰寫的 PR 中，到 2025-Q3 時，審查串流已包含數十萬筆可歸因於 AI 的事件；而且——這點至關重要——這裡的「閉環」不代表沒有人工參與：挖掘的審查串流僅限於可歸因於 AI 的事件，因此一筆閉環 PR 也可能有人工審查者參與，只是我們看不到。污染會朝兩個方向發生。從 GitHub 挖掘到的「審查」不能證明有人類做出決策；從 GitHub 挖掘到的「沒有 AI 審查者」也不能證明沒有 AI 參與審查。

這限制的是測量工具，不是否定任何特定發現；凡是將審查是否存在、審查延遲或審查量視為人類關注程度替代指標的測量，都受此影響最深。

相關連結#

  • 同模型審查盲點——本頁普查所描述的母體，以及普查無法觸及的構念。 該頁根據約 1,500 個帶廠商標籤的錯誤，測量審查者審查自家模型家族程式碼時，高嚴重度召回率下降 6–12 個百分點；本頁則計算產品審查自身輸出的 208,145 筆 PR，對比沒有自我審查的 45,269 筆 PR，沒有真值，歸因層級也是產品而非模型。兩者數字唯一相交之處，方向恰好相反——四個兼任作者與審查者的機器人中有三個在同產品程式碼的每筆 PR 上多發出 58–65% 的評論——但評論量不等於缺陷召回率，同產品組有 80% 集中於單一產品，而且 Cliff's δ 僅可忽略到小。能直接沿用的是規模與預設方式：目前生態系最常見的閉環配置是自我審查，比例超過四比一；因此那裡提出的路由規範目前仍是少數做法，而非現狀
  • 代理程式廠商異質性——同一個「廠商標籤才是變因」的提醒，只是來自審查端，語料規模大了 75 倍。 Kraishan 探討的是結果差異（相對於單一人工基準，revert 機率為 0.50 到 1.31），涵蓋 37,623 筆 AIDev PR；本研究探討的是審查配置本身（自我審查率從 95.7% 到 0.0%，涵蓋 248,641 筆 CodAGE PR），以及審查者輸出的差異（CodeRabbit 的重構評論占比依作者介於 9.7% 到 35.0%）。兩者都有相同盲點，也都明確說明：標籤代表產品，而產品是模型、harness、整合介面與使用者交付任務的組合。兩份語料彼此獨立，不能直接比較——AIDev 是從 2,807 個星數超過 100 的儲存庫中整理出 33,596 筆 PR；CodAGE 則是涵蓋整個 GHArchive 的事件串流——因此不能將一份資料集的數字與另一份直接對照
  • 審查作為控制點——第二個調節因子的分母，也是該理論自身遙測部分的測量風險。 該理論把自動審查者能力視為一項構念，卻未說明它涵蓋多少母體；本研究指出，截至 2026 年，可歸因的代理程式撰寫 PR 中有 8.8% 曾接受 AI 審查，並在三季內成長兩個數量級。它也加深了對該頁 250 萬筆 PR 觀察研究的警告：代理程式 PR 的審查事件愈來愈常可歸因於 AI；而 AI 審查並不排除人工審查，因此「已審查」和「未審查」都不再是衡量人類關注程度的乾淨指標
  • 代理程式審查評論處理——同一個迴路，只差一個構念，兩者可以互補。 該頁測量人類如何處理 54,713 則代理程式審查評論（71.4% 已解決）；本頁測量此類評論的數量與來源，且審查者串流規模達到 8,560,237 筆可歸因的審查評論項目。兩者都沒有觸及正確性。合併來看，這些資料顯示該層規模龐大、持續成長、採用率約七成——但完全沒有測量它是否能防止缺陷
  • 代理程式程式碼審查的確定性工程——基準測試端的互補觀點。OpenCodeReview 以整理過的基準測試中的 1,505 則專家驗證評論為審查系統評分；本研究則計算這些系統在實際環境中輸出的內容，發現輸出組成會隨程式碼作者而變 24.5 個百分點。本語料中的審查基準測試都沒有固定或回報這項配對變因
  • 代理程式貢獻下的開源——維護者面對 DHH 所述、無上限貢獻供應時可參考的數字。283 萬筆可歸因的代理程式撰寫 PR 中，有 2,581,643 筆完全沒有偵測到 AI 審查——因此他所描述的代理程式第一輪分流實務，在母體規模上並非多數代理程式 PR 的實際情況
  • 遙測與問卷測量——該頁定義問題在挖掘產物中的版本。該頁中，採用率會隨門檻變動 40 倍；在此研究中，「代理程式撰寫的 PR」計數則會依是否將分支名稱前綴視為證據而變動 173 萬筆，而論文選擇排除該前綴（占所有隔離案例的 96.9%），是研究中影響最大的單一方法論決策
  • 驗證成為新的瓶頸——已量化的瓶頸自動化部分。不論有多少比例的驗證工作委派給 AI 審查者，公開 GitHub 上可測量的底線是 248,641 筆 PR，而且正以每年兩個數量級的速度成長

尚待回答的問題#

  • 8.8% 的審查率，分子幾乎完整（審查者端隔離率為 0.01%），分母卻明顯不完整（作者端隔離率為 38.0%，其中 96.9% 僅有分支資訊）。被隔離的 173 萬筆僅有分支 PR，AI 審查率是多少？ 只要人工標記幾百筆樣本就能設定其範圍；有重現套件和記錄隔離理由的隔離檔案，一天就能完成。在此之前，本頁任何比率都不能引用為整個生態系的比率，只能說是簽名可歸因母體中的比率。
  • 同產品與跨產品幾乎和審查者身分混為一談：同產品組有 80% 是 Copilot；跨產品組則很大一部分來自 Cursor、Google Jules 和 Claude Code，這些產品沒有自己的審查者，因此不可能自我審查。若固定審查機器人並依變更大小配對，同產品多出 58–65% 評論的差距還會存在嗎？ Codex 的資料已經暗示未必如此（42,732 筆 PR 上為 0.91 對 0.89；它是唯一在兩側都有大量母體的機器人），而檢驗所需資料已經釋出。
  • 論文未來工作清單的第一項，正是本知識庫最想看到的實驗：在固定配置並對來源盲測的條件下，審查已知模型撰寫的功能等價 PR，並測量同模型、相關模型與獨立模型審查者的缺陷召回率及誤判率。若知道每個產品背後的模型並固定模型，此處測得的產品配對效應是否依然存在？ 公開 GitHub 上可觀察到的資料無法回答這個問題——紀錄沒有模型身分——因此必須透過控制實驗回答，而非資料挖掘。

資料來源#

  • AI-to-AI Code Reviews of GitHub Pull Requests — Niruthiha Selvanayagam（École de technologie supérieure, ÉTS Montréal）與 Taher A. Ghaleb（Trent University），AI-to-AI Code Reviews of GitHub Pull Requests，arXiv 2608.21311，2026-08-21，15 頁，DOI 10.4230/LIPIcs.ESEM.2026.74，ESEM 2026 Emerging Results, Vision & Reflection track。保留 empirical 分類與層級。Ghaleb 同時是 CodAGE [7] 和代理程式指紋研究 [8] 的作者；本文歸因框架在該研究基礎上延伸，因此資料集與研究有共同作者——此處揭露這一點，是因為這是本頁最接近利益衝突之處，而且它促使研究更加謹慎，而非相反（對短篇論文而言，隔離情形與涵蓋範圍的報告格外明確）。引用章節：§3.1–3.3（CodAGE 在 2024-01-01 至 2026-04-15 間的快照、S1/S2 簽名層級、隔離比例與僅有分支資訊的不對稱情形）、§3.4（三組資料集，以及「產品而非廠商、亦非模型」的定義，包括 117 筆同廠商跨產品 PR）、§3.5（CodeRabbit 自行宣告的標頭與依序套用的 regex 分類器）、§4.1–4.3 + Figure 1 + Tables 1–2（盛行率、成長、交叉表與組成）、§5.1–5.3 + Figure 2 + Tables 3–5（類別組成、評論量、延遲）、§6（取樣污染的含意）、§7（三個效度面向）、§8（三項未來工作計畫）。解析狀態：乾淨，已完整驗證。 由 PDF 擷取（docling 2.126.0、docling_mlx 0.1.1、MLX 版面與表格階段、rapidocr、confidence_grade: excellent）。匯入 verify 因表 4 的 p 欄觸發 table-collapse 標記，回傳 warn；該標記已確認為誤報——docling 會漏掉科學記號中的上標負號，因此形如 10⁻⁵ 的數值會被呈現為 10 - 5，觸發多值儲存格啟發式。原始紀錄中有一個 > [!note] 區塊記下此事。之後已將五張表逐格對照第 7–10 頁的 pdftotext -layout，完全吻合——沒有欄位塌縮、錯位、合併、拆列、漏列、en dash 損壞，也沒有將 AI 誤讀為 Al。另做四項算術檢查，結果皆吻合：表 2 的跨產品欄與同產品欄在八列中都加總為各列總數，同產品欄加總恰為 208,145；表 1 的列總數正確（32,379 / 7,355 / 2,109 / 2,173 / 656）；表 3 每列類別占比總和均為 100.0%，且 N 欄加總為標示的 35,248；表 4 的 Self PRs 欄在四個機器人上都吻合表 2 的同產品總數，且可由平均數重現 58/65/64% 的差距。表 5 的審查者各列合計為標示的 103,920 組符合條件配對中的 103,743 組（99.8%；剩餘配對來自未達 ≥100 門檻的機器人）。**圖片：**依兩階段規則檢視全部五個素材——image_000002 是 Figure 1（按季的對數刻度長條圖，也是本頁讀出 2025-Q2 曲線交會的依據），image_000003 是 Figure 2（堆疊類別長條圖，可獨立重現表 3 的每個數值）；image_000000 和 image_000001 是 CC-BY 與 LIPIcs 標誌，image_000004 是章節編號標記——三者皆為裝飾用途，沒有一項承載關鍵資訊。兩項來源內部的不一致，皆非解析造成。（1）表 5 的標題在 PDF 本身重複——單獨一行 Table 5 後緊接著真正的圖說，卻標為 Table 6；論文總共五張表。這是 LaTeX 疏漏，表格內容與編號其他部分一致。（2）快照範圍兩次寫明截至 2026-04-15，但 Figure 1 的座標軸停在 2025-Q4，並將該季標記為「約一季」GHArchive 歸因延遲所致的下限；到了 2026 年 4 月，這段期間理應早已結束。論文沒有調和這兩種說法；本頁沒有引用 2025-Q4 或之後的任何資料。
§ end
Cited by 10
Related articles