接受後的編輯行為

資料來源#

• Learning from 53.6K Real-World Developer Edits of AI-Generated Code

摘要#

Liang、Bairathi、Chi、Talwalkar、Subramani 與 Chen（Carnegie Mellon，arXiv 2607.25130，2026 年 7 月）發布了 DECODE——收錄 1,141 位開發者的 5,831 條編輯軌跡，共 53,614 組編輯前後的程式碼配對。這些資料是在 IDE 內，開發者修補 Python、JavaScript 與 TypeScript 的 AI 程式碼完成內容時擷取的。

這是這組資料中首次測量人類接受 AI 生成程式碼後實際做了什麼的來源。這裡其他研究測量的都是已經通過該步驟的產物：已提交的變更、拉取請求、審查意見、正式環境設定檔。DECODE 測量的是那個步驟本身，而且這個步驟並不小——已接受完成內容的中位數保留率為 63%，而 31% 的軌跡包含意圖是直接移除完成內容的編輯。

這項測量工具的形式，是閱讀這篇研究的全部理由，也是不要過度解讀的理由。引用任何數字來對照代理程式遙測之前，請先看下方的界線章節。

證據註記。 empirical，每個數字都附帶三項限制。(1) 這些完成內容不是 2026 年前沿模型生成的程式碼。 樣本中的 20 個模型來自 2024 至 2025 年初——gpt-4o-mini-2024-07-18、codestral-2405、gemini-1.5-pro-002、claude-3-5-sonnet-20240620/20241022、claude-3-7-sonnet-20250219、deepseek-coder-v3-fim、兩個匿名項目——因此測量的是前一代模型的行內自動完成修補情況，而非代理程式多檔案差異的修補情況。(2) 研究範圍僅限已接受的完成內容。 作者明確說明：遭拒的完成內容、人類撰寫的程式碼，以及在擴充功能外輸入的內容都不納入，因此無法從這份資料集計算接受率，也無法與人類撰寫程式碼的基準行為比較。(3) 參與者自行選擇加入，可能不具代表性。 資料來自明確同意透過多模型 VS Code 完成內容擴充功能分享程式碼的開發者。論文未說明擴充功能名稱，但模型名單（包含 anonymous-titan 與 anonymous-q）、共同作者名單，以及分類提示詞「直接取自 Copilot Arena」的說法，都讓 Copilot Arena 成為幾乎可以確定的來源——也就是安裝模型比較工具的志願者，而非隨機抽取的工作開發者樣本。擷取品質本身經過驗證：125 組人工標註配對中，流程召回率為 94.7%，與人工擷取編輯的重疊率為 88.1%；在 120 組配對中，LLM 編輯類型判定器與人工評分者的一致率為 94%。

測量工具的界線——不要和代理程式遙測混為一談#

這點重要到值得在研究結果之前先說明，因為同一週彙整的另外四個來源，測量的是相鄰但完全不同層級的事情。

來源	觀察單位	階段
DECODE（本文）	一次已接受行內完成內容的編輯快照	提交前、IDE 內
Tran et al.	monorepo 中的一項已提交變更	提交後、正式環境
Dipongkor et al.	一個代理程式產生的拉取請求	PR
Cynthia et al.	代理程式在 PR 上撰寫的一則審查意見	PR 審查
Greptile	一個已標註的 PR	PR 審查

其影響是算術上的，而非修辭上的。在此被移除的內容，根本不會成為拉取請求。 資料集裡所有 PR 層級的分母——變更行數的測試涵蓋率、每個代理程式 PR 的安全性問題、每個差異中的審查意見——都是以 DECODE 所測量的篩選後存留內容為計算基礎。Tran et al. 在其採用趨勢分析中明確將此列為限制（「開發者會在生成文字進入已提交程式碼分析前大量篩選」），但沒有測量工具；本文提供的正是這種測量工具，只是研究對象不同，模型世代也較舊。

反過來說，這裡也沒有任何內容能說明代理程式撰寫的 PR、無人看管的迴圈或多檔案重構。已接受完成內容的中位長度為 97 個字元，或 9 行，其程式碼上下文的中位長度為 2,949 個字元。那只是建議，不是變更。

何時編輯：前 15 分鐘，接著是漫長的尾端#

• 72% 的編輯發生在接受建議後一天內。
• 50% 發生在最初 50 分鐘內。
• 整體編輯量呈現急遽衰減，轉折點在 15 分鐘（直接檢視圖 3a——曲線從約 130K 的累積 Levenshtein 距離，在 15 分鐘時降至 40K 以下，之後三小時趨平至約 10K）。

軌跡本身的中位時間為 49.7 分鐘，中位快照數為 4，從初始完成內容到最終狀態的 Levenshtein 編輯數中位數為 329；但尾端極長：從 1 秒到 283.5 天、從 1 到 424 個快照。中位數才是重點；平均值沒有意義。

編輯內容：四種修補類型，而占主導地位的那一種無人能預測#

研究先從 30 條軌跡（85 個快照）中的每項編輯手動建立分類法，再以 gpt-5-mini 作為判定器擴大標註。研究報告了兩種不同分母，很容易混淆：

編輯類型	占編輯快照的比例	包含該類型的軌跡比例
變更程式碼功能	56%	76%
改善程式碼品質	14%	40%
自訂程式碼	10%	25%
移除	9%	31%

（快照欄合計為 89%；標註分類法還有第五類 unchanged，但未報告其比例。）

主導的修補是語意層面——新增方法、變更控制流程、改用不同的 API——而非表面修飾。只有 10% 的編輯快照屬於變數重新命名與字面值微調這類「AI 有 90% 做對」敘事所預期的類型。

雙峰分布：完整保留或直接丟棄，很少介於兩者之間#

單看 63% 的中位保留率幾乎毫無意義，因為分布呈現雙峰（直接檢視圖 3b）。幾乎所有資料都集中在兩端：100% 留存處有一個尖峰（約 1.4K 條軌跡，是較高的尖峰），0% 處也有一個尖峰（約 1.2K），中間則是一條低而平的底線。開發者新增程式碼的分布更加偏斜——最終程式碼平均有 20% 是開發者撰寫的，但 36% 的最終狀態中，開發者新增程式碼不到 5%；圖 3c 則是在 0% 處形成單一高塔，之後幾乎沒有資料。

把兩個圖表一起看，實際上的主張是：開發者不是幾乎原封不動地採用完成內容，就是把它丟掉；無論哪一種情況，他們都很少在其上加入大量自己的程式碼。 論文對此的說法很有用——應偵測的特性是可編輯性，也就是「程式碼能多容易地被改編，即使它無法立即使用」，這與正確性正交，而且目前沒有任何指標能測量它。

一項值得保留的精確區分。 常被引用的 31% 指的是包含移除意圖編輯的軌跡。摘要較寬鬆的說法（「在 31% 的編輯軌跡中，AI 完成內容最終遭到移除」）讀起來像是在描述終點，而圖 3b 中剩餘率為 0% 的長條更接近軌跡的 ~21%。包含移除編輯與最終剩餘率為零是不同的數量，只有前者是 31%。

編輯順序：先自訂是完成內容將被丟棄的徵兆#

這是最鮮明的單一結果，也是最直接關係到人類選擇的結果。閱讀每條軌跡的前兩步（圖 4，從圖像還原——轉移百分比在正文中完全沒有出現）：

接受後的第一次編輯： 變更功能 47.9%、移除 21.4%、改善程式碼品質 18.9%、自訂 9.9%。

第二次編輯，依第一次編輯類型分類：

第一次編輯	→ 移除	其他常見後續編輯
自訂程式碼	23.4%	—
改善程式碼品質	14.0%	→ 變更功能 14.9%、→ 自訂 11.8%
變更功能	12.2%	—
移除	—	→ 變更功能 40.3%

一開始先自訂完成內容的開發者——微調名稱與字面值，採取盡可能小的介入——接著刪除它的可能性，大約是先變更其功能的開發者的兩倍。作者的解讀是：「與開發者意圖或程式設計脈絡存在細微落差的 AI 完成內容，難以讓開發者改編。」而「移除 → 變更功能」的 40.3% 邊則說明刪除之後會發生什麼事：開發者改寫自己的實作。

論文沒有考慮另一種競爭性解釋，而且這個解釋並非明顯錯誤：願意投入心力自訂的開發者，已經仔細讀過完成內容，足以發現其中的問題，因此這個順序可能是閱讀深度效應，而不是可改編性效應。兩種解釋都預測相同的轉移矩陣。請參閱開放問題。

整體時間資料支持這個順序（Kruskal-Wallis H = 394.5，p < 0.001）：移除編輯最早發生（μ = 23.6 分鐘），接著是品質修正（28.3）、自訂（49.3），最後是功能變更（59.2）。論文將其解讀為一種決策程序——先決定是否保留，再修正錯誤，接著改編，最後擴充。請留意測量構念的轉換：這是各類型編輯彙整後的平均時間排序，不是單一軌跡內的順序；它與轉移矩陣並列，而非從轉移矩陣推導而來。

由哪個模型撰寫，影響幾乎微不足道#

在全部 20 個完成內容模型中，AI 程式碼剩餘比例（H = 31.5，p = 0.04）與開發者新增程式碼（H = 57.3，p < 0.001）的差異具有統計顯著性，但效應大小可忽略：eta-squared 分別為 0.002 與 0.007。編輯類型也有差異（chi-squared = 320.7，p < 0.001），但 Cramér's V = 0.05。

在這種樣本規模下，取得統計顯著性幾乎毫不費力，而作者也謹慎地同時報告效應大小。解讀是：在一組 2024 年世代的完成內容模型中，是哪個模型生成建議，幾乎無法解釋人類會怎麼修改它。 顯而易見的下一個問題是，若模型能力差距明顯，這個結果是否仍然成立——全部 20 個模型的能力範圍相當接近，而且沒有任何一個是 2026 年的前沿模型。

編輯集中在接縫處#

完成內容中的編輯位置大致均勻分布，但開頭與結尾的頻率較高（圖 6），且與時間無關（Pearson r = -0.12）。作者將這些接縫視為整合工作——將完成內容接到周圍程式碼，並延伸超出原本停止的位置。這與完成內容中位長度為 9 行相符：在這種長度下，大多數摩擦都在邊界，而非內容本身。

預測部分，以及摘要數字無法吻合之處#

第二項貢獻是把 DECODE 轉化成兩項任務的基準：分類完成內容最後會被刪除 [0, 0.1]、維持不變 [0.9, 1]，還是修改過 (0.1, 0.9)（透過過度取樣使類別平衡；隨機基準 F1 = 0.33）；以及生成最終編輯狀態。

以少樣本方式測試時，所有模型的表現都接近瓶頸。（以下所有數值均從 PDF 還原——docling 對摘要表格的解析結果已塌縮，見來源。）

少樣本基準	分類 F1	生成 Lev. Sim.
Claude Sonnet 4.6	0.37	0.36
DeepSeek-v3.2	0.35	0.37
GPT-5.2	0.32	0.37
Qwen3-Coder-Next	0.31	0.32
Llama3.3-70B-Instruct	0.27	0.35
Devstral-2512	0.26	0.41
Qwen2.5-Coder-7B（基礎版）	0.21	0.30
Llama3.2-3B（基礎版）	0.23	0.21
Qwen2.5-Coder-3B（基礎版）	0.19	0.26
+ DECODE 微調，3B	0.42	0.41
+ DECODE 微調，7B	0.45	0.43
+ DECODE 微調，Llama3.2-3B	0.44	0.43

微調帶來的提升確實存在，但與前沿模型的比較被誇大了。 相較於各自的基礎版本，以 DECODE 進行 LoRA 微調可帶來 +0.23 F1 與 +0.18 Levenshtein 相似度——三個模型家族都有一致且顯著的效果。相較於同一表格中最佳前沿基準，這些模型只提升 +0.08 F1（0.45 對 Sonnet 4.6 的 0.37）以及 +0.02 Levenshtein（0.43 對 Devstral 的 0.41）。摘要所說的「在生成程式碼編輯（+0.17 Levenshtein 相似度）與分類開發者是否會編輯 AI 完成內容（+0.17 F1）兩方面都顯著超越前沿模型」，只有在以六個前沿基準的平均值比較時才吻合，但論文沒有說明這一點。引用直接對戰的數據。

雙方都加入編輯歷史後，差距進一步縮小。提供前 k 次編輯作為上下文（表 7 與表 8，皆已還原）：

• 所有模型的生成表現都提升。 經微調的 Qwen2.5-3B 在 k=0 到 k=4 間由 0.41 升至 0.52；Claude Sonnet 4.6 少樣本則在相同範圍內由 0.36 升至 0.48，絕對增幅更大。在 k=4 時，微調模型比獲得最佳上下文的前沿模型高 +0.04。
• 分類表現沒有提升。 微調模型從編輯歷史中提高約 0.06 到 0.08 F1（Qwen2.5-3B 從 0.42 升至 0.51）。Claude Sonnet 4.6 則毫無提升：k = 0 到 4 時依序為 0.37、0.36、0.35、0.35、0.36。觀察開發者最初四次編輯，無法讓前沿模型判斷完成內容最終是否會被保留——但相同的上下文明顯有助於它重現這些編輯。

表現天花板落在最重要的類別。 依編輯類型區分的 Levenshtein 相似度（表 10，解析乾淨）是論文中最有用的表格：

編輯類型	最佳少樣本	最佳微調模型	快照占比
自訂	0.73（Devstral）	0.76	10%
改善品質	0.58（Sonnet 4.6）	0.65	14%
變更功能	0.44（Sonnet 4.6）	0.49	56%
混合	0.46（Sonnet 4.6）	0.49	—

所有模型，不論經過微調或屬於前沿模型，都能很好地預測表面修補，卻難以預測語意修補；而語意修補占了資料集的一半以上。微調將最困難類別的分數從 0.44 提升到 0.49——確實有所進步，但仍是表格中最低的數值。開發者決定變更程式碼做什麼的依據，無法從完成內容及其周圍檔案中還原。

微調不會犧牲一般程式碼生成能力：三個模型在 HumanEval 與 MBPP 的 pass@1 持平或提升 0.00 至 0.02。（該表有一個數值不可用：Llama3.2-3B 的 HumanEval 與 MBPP pass@1 分別報為 0.94 與 0.96，高於相同基準上的 Qwen2.5-Coder-7B。這個數字在表 3 與表 9 中相同，因此是論文原始數字而非解析錯誤；本文不將它引用為能力主張。）

這篇研究確立了什麼，又只是讓哪些問題更清晰#

論文自己的結論是對基準測試的批判：HumanEval、MBPP、SWE-Bench 與 BigCodeBench 上的 pass@k 測量的是正確性，而這份資料集揭露的失敗模式是是否符合開發者意圖——完成內容可能正確，卻仍可能在 23 分鐘後被刪除，因為它不合用。這與 Measuring Beyond Accuracy Saturation 從基準測試角度提出的論點相同，只是本文從使用遙測資料得出。作者提出的替代指標值得注意，因為它們是行為指標，而非靜態指標：程式碼保留率與 AI 完成內容棄用率。

這篇研究沒有衡量人類辨別得是否正確。保留率記錄的是人類做了什麼，而非他們是否判斷正確——完成內容遭刪除，可能是因為程式碼品質不佳而遭正確拒絕，也可能是開發者未能認出優質程式碼；DECODE 無法分辨兩者。把這些數字解讀為判斷品質的證據，就是超出了測量工具的範圍。

關聯文章#

• AI as Primary Author — 為「接受」這個構念補上底線。 該頁面持續追問的是，當代理程式直接套用變更時，「接受」代表什麼；本文測量的則是更下一層，即使是肯定採用的案例也還有後續。接受一段完成內容不代表採用它：31% 的軌跡包含移除編輯，保留率呈雙峰分布，而完成內容中位數在一小時內已失去自身的 37%。所有接受率數字——Faros 的 20% 到 60%，以及取代它的來源占比——都只是仍在變動狀態的快照。本文也從另一面印證作者身分的轉變：開發者撰寫了最終程式碼的 20%，而在 36% 的案例中，開發者新增部分不到 5%；因此只要完成內容仍保留，留下來的就是 AI 的文字
• Design by Selection — 首次有母體資料指出選擇之後會發生什麼。 該頁面的做法是「要求十種選項，再重新混搭」，這預設人類能可靠辨認出好選項；本文在單一候選內容上晚一步測量同一個人類，發現辨認往往很晚才發生。先嘗試最小幅度改編（自訂）的開發者，接著最可能刪除內容（23.4%，功能變更後則為 12.2%）——在已經選定選項之後才選擇失敗，而不是選擇當下。槓鈴兩端的後段都完整保留下來，並呈現具體樣貌：最後一哩路確實存在，長達 15 分鐘；「小型呼叫以目視判斷優於文字描述」的主張，也得到 10% 的編輯屬於字面值與名稱微調的佐證
• Outsource Your Thinking, Not Your Understanding — 對依賴面的量化，精細到按鍵層級：開發者幾乎不會在 AI 完成內容上加入自己的程式碼（最終程式碼的 20%，而 36% 的最終狀態中不到 5%），這是理解債務疑慮的行為痕跡，而非對理解程度的測量。這也提醒我們注意測量工具的限制——本文是這組資料中最接近 Thawar 缺少的理解指標的研究，但它依然無法看見理解。保留率記錄開發者做了什麼，而非他們是否理解；仔細讀過而完整保留 100% 的完成內容，和未仔細閱讀而完整保留的內容，在資料中是同一列
• Planning / Execution Division of Labor — 用行為測量工具檢驗該頁面根據逐字稿推論的構念。 該文的開放問題是「決策歸因」取決於逐字稿記錄了什麼，而敷衍蓋章的界線正是最難推論之處。編輯軌跡不是推論結果：開發者是否重寫完成內容的控制流程，是可直接記錄的位元事實。DECODE 所觸及的僅是已接受完成內容的執行層——沒有說明誰負責規劃——因此它只是部分測量工具，但不涉及推論。它的編輯類型組成也能直接對照 80% 執行交給 Claude 的數字：56% 的編輯會改變程式碼做什麼，這是人類收回的一項執行決策
• Review as the Control Point — 該理論所建模一切的上游修補層。其驅動因素是工作量、表面可信度與意圖流失；本文在沒有審查者、作者是唯一讀者的階段測量相同力量。這帶來兩個結果：接受後 23 分鐘就被移除的完成內容，根本不會進入審查系統，因此該理論中的結果構念都以通過此篩選為條件；而「先自訂再移除」的路徑，正是表面可信度機制（P4）作用在作者而非審查者身上的情況——程式碼讀起來足以讓人改編，接著卻不合用
• Efficiency Debt of AI-Generated Code — 該論文指出但無法測量的篩選過程。 該文的 RQ1 限制是，開發者「在生成文字進入已提交程式碼分析前會大量篩選」，因此 68.62% 的來源占比測量的是通過人類篩選後的內容。本文以自己的資料集測量這道篩選：雙峰保留率、31% 的移除編輯率，以及完成內容中位數保留率 63%。研究對象不同、粒度不同、完成內容模型也較舊——因此本文限制了該項限制的範圍，但無法解除它，而且方向符合該限制所暗示的結果。另請注意關於模型的鏡像發現：Tran et al. 完全無法區分模型世代，而這裡的 20 個模型則以 eta-squared 0.002 的幅度區分
• Agent-Generated Test Quality — 同一個分母問題的另一端。該研究發現，既有測試在 Python 中只執行了代理程式變更行數的 27.0%，而 64.8% 的 PR 完全沒有執行任何變更行；本文則指出，相當一部分 AI 生成程式碼一開始就到不了 PR，因而也不會進入未測試狀態。兩篇研究共同框定了存留路徑：IDE 中遭移除的內容，以及合併後未經測試的內容
• Agent Review Comment Resolution — 兩種測量人類如何處置機器產出的行為工具，粒度相反，指向相同結論。該文中約 71% 的代理程式審查意見獲得解決，而最常見的真正拒絕原因是代理程式無法看見的專案脈絡（23.8%）；本文中最可能遭刪除的完成內容，則是那些「與開發者意圖或程式設計脈絡存在細微落差」的內容。一項缺陷，兩種產物——而且兩者測量的都是採用情況，從未測量正確性
• Same-Model Review Blindness — 同一盲點的另一個面向。該頁面測量模型未能在自己家族生成的程式碼中發現錯誤；本文測量模型完全無法預測人類會修改 AI 程式碼的哪些部分——Claude Sonnet 4.6 對刪除／修改／未修改的分類 F1 為 0.37，隨機基準為 0.33；觀察開發者最初四次編輯也沒有帶來任何提升。兩者都不是程式碼生成能力的主張；兩者都顯示，模型對 AI 撰寫程式碼的判讀能力不如其撰寫能力
• Agentic Coding Work-Composition Shift — 使用組成的轉變在更下一層、也早一代模型上測得的情況。該文中，工作階段從修復損壞程式碼轉向端到端委派；本文則顯示，單一完成內容內的修補工作仍以功能性變更為主（56% 的編輯），而非表面修飾。兩者相容，而測量工具之間的落差正是重點：工作階段層級的分類看不見接受之後隨即發生的 15 分鐘修補高峰
• Telemetry vs. Survey Measurement — 為該頁面分類法補上第三種測量工具形式：提交前的編輯器遙測，位於問卷自陳與 SDLC／PR 遙測之下，而且兩者都看不見。它的獨特性在於所觀察的產物往往會被銷毀——31% 的軌跡包含移除編輯，這些程式碼之後不會存在於任何儲存庫中，無法再供問卷調查或抓取。相應的弱點在於參與者：自願加入的模型比較擴充功能所形成的樣本，是自行選擇而來；monorepo 的完整歷史則不是。該頁面也收錄本文所屬的控制組論點：DX（vendor-claim）宣稱採用率超過 90% 後，AI 與非 AI 的控制組已失去意義；而 DECODE 沒有人類撰寫組——但原因並非如此。研究範圍是已接受的完成內容，因此依研究設計排除了人類輸入的程式碼，無論採用率多高都一樣；解決方式是設計選擇（把開發者自己的編輯納入另一個群組），而非人口統計事實
• Failures That Look Like Success — 以可能的最小尺度呈現的類別，發生在任何評分者或審查者介入之前。一段讀起來足以被接受、接著被自訂，並在下一次編輯時遭刪除的完成內容，在開發者能看到的每個表面訊號上都顯得合理——先接受、再投入，最後反悔。這個資料集層級的對應說法，是論文對基準測試的批判：pass@k 測量的不是此處真正失敗的事物
• Verification as the New Bottleneck — 瓶頸中成本最低的階段，也是資料集中最短的回饋迴圈：完成內容的一半驗證工作在接受後 50 分鐘內完成，而且當時人類仍是唯一讀者
• Measuring Beyond Accuracy Saturation — 同一論點從使用資料而非基準測試構念效度得出：正確性基準測試在某個維度上已趨於飽和，但決定生成程式碼能否留存的並非這個維度。本文提出的替代指標是行為指標——程式碼保留率與棄用率；這與可靠性／效率／基礎架構分解是不同的做法，兩者互補

衍生文章#

• Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping? — 該文的三分接受分類（肯定採用／審查後未還原／單純未還原）將肯定採用視為人類套用建議的明確案例。本文指出，這類情況本身也不是終點：人類明確套用的建議，有相當比例後來遭移除，其餘多數也經過編輯，因此即使是該分類中最強的接受訊號，也只是軌跡上的一個點，而非終點

開放問題#

• 完成內容樣本來自 2024 至 2025 年初的行內自動完成，中位長度為 9 行。雙峰保留形狀、15 分鐘轉折點，以及約 31% 的移除編輯率，在 2026 年代理程式尺度上是否仍成立？此時觀察單位是開發者從未看著它寫成的多檔案差異。判別方式是對代理程式編輯而非完成內容執行相同的軌跡擷取。
• 「先自訂再移除」的路徑（23.4%；功能編輯後則為 12.2%）被用來支持「細微不合意的完成內容難以改編」的說法。閱讀深度的解釋也預測相同矩陣：自訂需要仔細閱讀完成內容，而仔細閱讀時才會發現真正的問題。若要區分兩者，需要編輯流以外的訊號——依完成內容長度劃分的首次編輯時間，或眼動追蹤、停留時間等替代指標。究竟哪個機制正確，決定了解決方式是改善生成品質，還是更早強制檢查。
• 原則上能否預測完成內容是否會留存？微調只能將分類 F1 提升至 0.45，隨機基準為 0.33；而在占主導地位的編輯類型（變更功能，占快照 56%）上，所有測試模型的生成相似度最高只有 0.49 Levenshtein 相似度。訊號要麼存在於模型未取得的上下文中（儲存庫、任務歷史、開發者的其他檔案），要麼保留率是意圖本身的特性，任何數量的程式碼上下文都無法包含——而論文提出的「在展示前偵測低可編輯性的生成結果」產品，取決於哪一種解釋成立。

資料來源#

• Learning from 53.6K Real-World Developer Edits of AI-Generated Code — Jenny T. Liang, Mihika Bairathi, Wayne Chi, Ameet Talwalkar, Nishant Subramani & Valerie Chen (Carnegie Mellon, arXiv 2607.25130, 2026-07-27), empirical，35 頁。§3（資料集建構、四步驟流程、94.7% 召回率的人工驗證、PII 遮蔽、IRB）、§3.2（資料集統計、語言與任務脈絡細分、軌跡與完成內容長度分布）、§4.2（四種編輯類型、時間結果、雙峰分布、Kruskal-Wallis 排序與跨模型效應大小）、§5.1–5.2（兩項任務、基準模型、LoRA 微調與結果）、§6（對基準測試的批判、可編輯性與以開發者為中心的機器學習論點）、附錄 A.1（模型名單、比對門檻、排除不足 2% 的檔尾項目）、A.2（品質驗證）、B.2（編輯位置）、B.3（分類法建構與 gpt-5-mini 判定器達成 94% 人工一致率）、C.1–C.2（超參數與完整結果表格），以及列出的限制。
• 解析警告。 docling 回報 verify: warn，並標示 table-collapse（1 個儲存格）與 table-shift（7 個儲存格）；這些損壞確實存在，而且會影響關鍵結果。表 2 每兩列合併一次——GPT-5.2 的列在每個儲存格中都同時包含 GPT-5.2 與 Claude Sonnet 4.6 的數值，導致 Sonnet 自己那列留下 DeepSeek-v3.2 的 F1（0.35），而它的正確值是 0.37；Qwen3-Coder-Next 的列則與 Llama3.3-70B-Instruct 合併。若照表格表面內容讀取，數值會被錯誤歸給不同模型，而非直接遺漏。表 3 將基礎版與微調版的 pass@1 合併到每個基準的一個儲存格中。表 7 與表 8 的列發生位移：Edits 數值移入模型名稱儲存格（Sonnet 4.6 (Few-shot) 1 2、Qwen2.5-3B (Fine-tuned) 1 2、Qwen2.5-7B (Fine-tuned) 2），導致受影響的列少了一格且標籤不完整。**表 1、5、6、9 與 10 解析正常。**本文引用的所有模型層級數值均以 pdftotext -layout 還原，並與表 5、表 6 交叉核對；表 5、表 6 是表 2 的乾淨完整版本。本文沒有引用任何損壞表格中解析出的儲存格。圖 3、4 與 6 是依圖像雙重檢視規則直接檢查的——圖 4 的轉移百分比（首次編輯 47.9 / 21.4 / 18.9 / 9.9，以及第二次編輯轉移 23.4 / 14.0 / 12.2 / 40.3）除了三個四捨五入後的數值外，正文沒有其他描述；圖 3 的雙峰形狀及兩個峰的相對高度，文字也完全沒有說明。兩項內部不一致源自論文本身，而非解析結果：§4.2 表示「23% 的編輯軌跡會立即移除 AI 完成內容」，但圖 4 中 Accept→Remove 的邊為 21.4%；而摘要中的「相較前沿模型，+0.17 F1 / +0.17 Levenshtein 相似度」只有以六個前沿基準的平均值計算才相符，若與論文自家表 2 中的最佳模型直接比較，則分別是 +0.08 與 +0.02。表 3 與表 9 中 Llama3.2-3B 的 pass@1 為 0.94（HumanEval）／0.96（MBPP），對 3B 模型而言高得不合理，也高於相同列上的 7B Qwen；該數值在兩張表中一致，因此是論文原始數值而非解析錯誤，本文未引用它。