AI 生成程式碼的效率債務

資料來源#

• Characterizing the Quality Profile of AI-Generated C++ in Production
• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild

摘要#

Tran、Lewis、Yang、Thakur、Kini、Patil、Hashemi 與 Ranganathan（Google，arXiv 2608.06640，2026 年 8 月）進行了此資料庫首次正式環境規模、以人類為對照的 AI 撰寫程式碼品質測量：在單一企業 C++ monorepo 中，十二個月（2025-04-01 至 2026-04-01）共 352 萬筆已提交變更，具備撰寫時的位元組層級來源追蹤，並以人類撰寫的群組作為比較。

本頁命名所指的發現，是資料庫其他地方都沒有的結論。AI 生成的 C++ 帶有原始碼層級的命令式偏向——它自行在本地完成工作，而不是交由其他元件處理——而這種偏向在部署後代價高昂。這條測量鏈在同一份資料集中首尾相接：

1. 上游（提交的程式碼）：迴圈結構約 2.0 倍，標準函式庫/API 呼叫少 30-40%，map 存取與容器插入警告約 2.0 倍，缺少 move 的警告為 1.39 倍。
2. 下游（正式環境剖析）：AI 占比高的函式，總 CPU 週期中直接在 CPU 上執行的比例增加 +3.46%，呼叫共用最佳化函式庫（absl/gtl）的比例則減少 -1.08%。
3. 成本：AI 占比高函式的中位數正規化運算量，相較基準成長至 1.31 倍；人類函式則為 1.25 倍（相對增加約 5%）。記憶體則分別為 1.36 倍與 1.25 倍（約 8%）。

機制比百分比更重要。IPC 與 MIPS 沒有明顯退化——程式碼不是執行得比較慢，而是執行了更多工作。這是工作量稅，不是編譯或排程問題，因此所有只監測吞吐量、不監測資源分配的工具都看不見它。

證據說明。 empirical，而且其測量規模與儀器配置都相當罕見——採用撰寫時來源追蹤，而非事後歸因；設有真正的人類對照組；並將審查、CI、sanitizer、回退與正式環境剖析的結果串接起來。每個數字都伴隨四項限制。(1) 利益衝突是結構性的：Google 工程師在 Google 的 monorepo 中測量 Google AI 程式碼工具的輸出，發表的結果整體上令人安心，討論將弱點歸因於「歷史上的預設系統設定」，而非模型。論文為雙盲審查在內文中將公司匿名化，但作者列名仍揭示公司身分。(2) 這是觀察性研究，明確非因果研究——作者如此聲明：AI 生成比例可能與任務難度、repo 情境、作者經驗或審查慣例相關，而且分層群組比較「不會將研究轉變為因果估計」。(3) 模型組成遭到遮蔽。 蒐集時已彙總並移除個別模型識別資訊，因此論文無法判斷這些問題是否普遍存在，或主要由早期、較弱的模型造成——同一期間開發者提示詞熟練度也有所提升，因此早期提交混淆了模型品質與人類引導品質。(4) 單一語言、單一 monorepo，設有審查閘門、成熟的靜態分析與函式層級運算可觀測性。作者自行說明了研究結果的適用邊界。

上游特徵：額外問題實際集中在哪裡#

靜態分類法將行級發現歸入五種品質屬性。AI/人類比率並不一致，五項中有兩項甚至低於持平水準：

品質屬性	AI/人類比率
效率與資源使用	1.23
可維護性與可讀性	1.08
現代性與 API 演進	1.04
正確性與安全性	0.94
政策、可攜性與環境適配	0.92

兩個類別——介面與耦合負擔及複製與配置開銷——占正向絕對比率差距總量的 82.21%。其他部分都接近持平或為負值。具體機制也足夠明確，能直接設定目標：misc-include-cleaner 加上 misc-definitions-in-headers 占介面與耦合負擔的 98.95%，而 runtime-missing-move 占複製與配置開銷的 51.60%。

應將組成欄與比率欄分開閱讀，因為論文兩者皆有報告，回答的是不同問題。以比率差異來看，額外問題集中在效率與耦合。以審查者實際遇到的項目占比來看，介面與耦合負擔占 AI 加權發現的 43.96%，人類則為 40.36%；API 誤用與無效呼叫占 29.49%，人類為 30.05%——兩者合計占 AI 發現的 73.45%，人類則為 70.41%。某個類別可能相對失衡，卻不會主導審查負擔，反之亦然。

變更結構對照。 AI 變更規模較大，但其中的函式較小：變更行數中位數為 89 行 [IQR 27-230]，人類變更則為 33 行 [8-122]（Cliff's delta 0.284）；涉及檔案數為 3 對 2；新程式碼比例為 0.83 對 0.60——同時函式 LOC 中位數為 AI 11 [5-26]、人類 15 [7-31]（delta -0.118），中位複雜度則相同。變更較大、較新，但由較短的函式組成。下游比較會依變更大小及其他共變數分層，因此下方的結果比率並非單純由規模造成。(表 2 已逐行與 PDF 第 9 頁核對；表 4 已與第 10 頁核對。)

可靠性結果分歧，論文也部分掩蓋了這點#

這項發現使資料庫既有敘事變得複雜，因此值得精確陳述，而非沿用論文摘要中的措辭。

• 建置失敗率：AI/人類比率在十二個月內始終高於持平水準，中位數約 1.3 倍（圖 4 的箱體很窄，約 1.17-1.35——這是穩定效果，不是雜訊造成的波動）。
• Sanitizer 發現：中位數約 1.3 倍，但每月波動範圍寬得多（約 1.07-1.84）。
• 回退率：中位數約 0.9 倍，低於持平水準——AI 生成程式碼的回退頻率低於人類撰寫程式碼。每月箱形圖的上鬚確實越過 1.0（約 1.07），因此這是中位數的主張，不是普遍現象。
• 審查摩擦，所有指標都高於持平水準：阻塞討論串 1.92 倍、評論總數 1.39 倍、審查者迭代次數 1.24 倍、合併所需時間 1.19 倍、提交嘗試次數 1.07 倍。

論文自己的摘要低估了自己的測量結果。 第 4.3 節報告建置失敗比率為「約 1.3 倍」；兩段之後的 RQ3 摘要卻稱之為「建置失敗率相近」，同時稱 0.9 倍的回退比率「更優」。依論文自己的標準，偏離持平 0.3 是一方向的研究發現，另一方向卻成了四捨五入的誤差。應引用測量結果，而非修飾說法。

站得住腳的解讀，是討論段落真正支持的那個：負擔並非急性故障。 既有自動化閘門與人類審查者會在部署前或部署期間攔下致命錯誤——額外的建置失敗與較低的回退率共同表明了這點；存續下來的是慢性問題：耦合負擔、配置開銷與運算足跡。

虛無結果指出修正位置#

作者探查了審查者疲勞的說法，卻沒有找到支持證據。他們測試常見審查指標——冗長的審查時間、較多的迭代次數——是否與低效率 AI 生成 C++ 的存續相關，假設原因可能是審查者疲勞或過度信任。沒有明確相關性。

對此資料庫而言，作者的結論是關鍵所在：傳統的人力投入代理指標「無法充分反映評估 AI 生成程式碼時的認知摩擦」，而且由於「無論審查深度如何，人類審查者都難以持續攔截這些局部低效率」，上游自動化介入是必要的，而不只是比較便宜。

由此可得兩點。第一，這是正式環境規模的虛無結果，與《審查作為控制點》中 P1（負荷增加使審查深度下降，進而使品質下降）最簡單的解讀相左——對這類結果而言，控制點根本不在審查，因為在正確函式中漏掉 std::move，不是多花心力就一定能找出的問題。第二，這是資料庫中最有力的非廠商證據，支持 Faros 所主張的「問題出在撰寫，而非審查」論點，而且是從相反方向得出：Faros 主張審查不應是解方；這份研究則測量出，對一種缺陷類別而言，審查無法成為解方。

RQ4：緩解措施有效，但沒有消除差距#

這項介入將 RQ2 的特徵回饋給程式碼生成器。研究選取 50 個至少各有一項目標類別發現的 C++ 函式，保留其函式簽章後重新實作，分成三個提示階段（基礎／一般回饋／類別專屬回饋），每階段獨立執行三次，共 450 次實作；評分依據為目標靜態發現，以及 R_eff——一項基準分數，其中相對原始實作1 = 改善、0.5 = 持平、0 = 退步，指令數的權重是記憶體的兩倍。

階段	R_eff	目標發現	相較基準
基準（原始人類程式碼）	—	1.28	—
階段 1（基礎提示詞）	0.294 (±0.041)	1.26	-1.56%
階段 2（一般回饋）	0.342 (±0.041)	1.22	-4.69%
階段 3（類別專屬回饋）	0.385 (±0.043)	1.12	-12.50%

主要宣稱的 11.1% 降幅，是階段 3 相較階段 1；表格本身的 Reduction 欄則是相較基準（12.50%）。兩者都正確，分母也不同。六個數字在算術上彼此一致，並在正文中再次說明。

論文沒有說出的發現：即使是緩解效果最好的輸出，平均而言仍是退步。 階段 3 的 R_eff 平均值是 0.385，而與原始人類實作持平的分數是 0.5。分類法導引的回饋將重新生成函式從明顯退步（0.294）推進到仍然整體退步（0.385）——相對改善確實達到 31%，但始終沒有損益兩平。儘管如此，討論段落仍總結說，只要系統設計提供充分的架構指引，「模型偏向命令式迴圈的傾向便會消失」。發現減少 11.1%，效率分數低於持平水準，並不足以支持「消失」這一說法。測量結果支持的是「可緩解」；論述框架宣稱的卻是「已解決」。

為何這是第四種債務軸，而非重述其他債務#

資料庫已收錄三種對代理程式撰寫程式碼後果的描述。這是第四種，也是唯一以部署後金額衡量成本、而非以風險或工程師工時衡量的描述：

債務軸	債務所在位置	表現方式
代理式技術債務	架構——每次工作階段都要重新推導意圖	被迫重寫
代理程式生成程式碼的安全債務	CI/容器基礎設施（87.6% 的異味）	憑證遭到利用
代理程式生成測試的品質	測試環境，以及測試與差異之間的落差	CI 可靠性衰退；未經測試的迴歸進入發行版本
效率債務（本頁）	函式主體——局部自行完成工作，而非交由函式庫處理	運算與記憶體帳單的成長速度快約 5-8%

它們共同指向一個特徵：代理程式能妥善處理正在考慮的程式碼，卻不擅長處理程式碼運作的環境——CI 沙箱、容器、周邊架構，如今還包括機器本身。論文對成因的假設，與另外三項研究得出的結論相同：「通用型 LLM 缺乏內部企業 monorepo 結構的高度特定情境」，並提出以知識庫將相關情境注入提示詞作為解方——這正是從剖析資料獨立推導出的 CLAUDE.md 解方 與 Faros 的「情境引擎」。

採用情況，留作紀錄#

RQ1 並非本頁主題，但提供了分母，也是資料庫中規模最大的非廠商採用趨勢序列。主要語言中，AI 生成程式碼占已提交程式碼的比例，從 2025 年 4 月的 28.99% 升至 2026 年 3 月的 68.62%；C++ 中 AI 占多數的變更從 27.65% 升至 59.69%，人類占多數的變更則從 72.10% 降至 40.04%；整體 C++ 月份占比從 28.56% 升至 62.80%。各組織的採用程度不一——Machine Learning & AI 達到 70.19%，Consumer Products/Apps/Devices 為 67.45%，某些切分在初期採用後便趨於停滯。完整討論見《AI 作為主要作者》。

延伸閱讀#

• 加速效應的反噬——同一來源中的矛盾與佐證。 它以非廠商正式環境遙測資料佐證審查摩擦的一面（阻塞討論串 1.92 倍），但幅度小得多（合併所需時間 1.19 倍，相較 Faros 審查中位時間 +441.5%）；它也與正式環境結果相矛盾：Faros 測得每個 PR 的事故增加 +243%，而本研究測得回退率約 0.9 倍，低於持平水準。請參閱該頁的矛盾段落。
• 代理程式生成程式碼的安全債務——該頁第一個未解問題要求的人類對照組，這份研究在不同問題集合上提供了答案：AI 生成 C++ 的正確性與安全性發現為 0.94 倍，是反駁「AI 程式碼普遍較不安全」先驗，以及未經佐證的 2.7 倍弱點數字的直接證據——但本研究測量的是應用程式 C++ 中的 clang-tidy 類別，而不是 CI/IaC 的安全異味，因此它提供反向權衡，卻無法定論。
• 代理程式生成測試的品質——姊妹研究，但面臨相反的測量工具問題：該研究的人類群組因解析落差而不完整，本研究則在正式環境規模下具有人類群組，卻無法區分不同模型世代。兩者都指出債務存在於環境，而非邏輯。該研究的覆蓋率切分也直接關係到本頁第二個未解問題——低於持平水準的回退率究竟是程式碼本身的特性，還是周遭閘門的結果。在非審查閘門控管的 monorepo 中，最常被假設存在的閘門是測試套件；而在開放原始碼專案的代理式 PR 上，Python 變更行只有 27.0% 會執行測試，另有 64.8% 完全沒有測試，因此當提交前閘門較弱時，可靠性狀況可能更差，是有具體理由可循的。
• 代理程式供應商間的異質性——本頁最意外結果在 monorepo 外的重現，以及本頁看不見的變數。 Kraishan 在公開 GitHub 上也發現低於持平水準的回退率（合併值約 0.64，Codex 為 0.50），這表示本頁約 0.9 倍並非 Google 提交前檢查流程造成的假象——請參閱本頁第二個未解問題。但以單一基準比較時，各供應商的範圍為 0.50 至 1.31，兩側都涵蓋 0.9：單一「AI 生成」群組彙總了組織工程師恰好使用的各種助理，報告的是混合結果，而混合比例在本研究中不可觀測。兩項研究在設計上幾乎互為對照——一方是在單一審查閘門控管的 monorepo 中，以位元組層級撰寫來源追蹤 352 萬筆 C++ 變更；另一方則是在 2,807 個公開 Python/JS/TS repo 中追蹤 37,623 個標記供應商的 PR，並依提交訊息偵測回退。
• 代理式技術債務——效率債務是本頁以運算量計價、描述同一種情境缺失機制的方式；論文提出的解方（知識庫在提示詞階段注入 monorepo 情境），正是根據剖析資料推導出的 CLAUDE.md 解方。
• AI 作為主要作者——作者身分變化背後的非廠商採用趨勢序列，以及 Faros 的 PR 層級框架看不見的互動模式組成。
• 審查作為控制點——正式環境的虛無結果，反駁最簡單的 P1 解讀：審查時間與迭代次數無法預測哪些低效率會存續，因此對這類缺陷而言，控制點完全位於審查上游。
• 遙測與問卷測量——一種新的測量方式：第一方工程遙測資料並設有對照組，這正是 Faros 缺乏的跨客戶採用深度比較；廠商誘因也指向相反方向，因為測量程式碼的組織，就是打造撰寫程式碼工具的組織。該頁如今也收錄了本研究這個直接反例：DX（vendor-claim）在 2026 年 7 月宣稱，採用率超過 90% 時，「將 AI 使用者與未使用者對照組比較，已不再是可行的測量策略」——然而這個人類對照群組正是在採用率幾乎全面普及的族群中進行測量。飽和的是誰在使用 AI；沒有飽和的是這次變更由誰撰寫，在研究期間結束時，約十分之三的提交仍由人類撰寫。關鍵差異在於撰寫時的來源追蹤，這是程式碼產生前就做出的儀器配置決策，而不是事後才有的分析選擇。
• Agent Review Comment Resolution——同一種情境缺失診斷，出現在另一個迴圈。 本論文將 AI 的命令式偏向歸咎於「通用型 LLM 缺乏內部企業 monorepo 結構的高度特定情境」，並建議在提示詞階段注入 repo 情境；另一項研究發現，代理程式審查意見遭拒的主要原因也是同一落差——代理程式將團隊有意為之的決策誤判為缺陷（470 則以卡片分類、且具爭議的討論中占 23.8%，對比 4 起明確幻覺）。同一種情境缺失，在撰寫與審查兩端呈現不同症狀，解方也相同。這同時是證據類型上的反向權衡：本頁設有人類對照群組，該研究則沒有，因此「代理程式審查者是否比人類審查者差」仍未經測量。
• Same-Model Review Blindness——審查調節鈕不起作用的兩個理由，解方方向相反。 本頁的虛無結果顯示，審查時間與迭代次數無法預測哪些 AI 低效率會存續，並得出結論：無論讀者審查多深入，都看不見這類問題，因此解方應上移到撰寫階段。Greptile（case-study）發現，若由不同模型家族進行同一輪審查，高嚴重性問題召回率可多出 6–12 個百分點，解方因此是橫向切換——改變查看者的身分，而非投入多少心力或提早多久審查。兩者也對同一不對稱現象提出互相競爭的解釋：Tran et al. 將 AI 撰寫缺陷歸因於通用模型缺乏 monorepo 專屬情境，並建議注入情境；Caridad 則將審查落差歸因於各模型自身的設計直覺，並建議跨廠商分流。只有第一項研究有對照組，而兩種解方可以並行，不相衝突——若任何審查者都看不出某類缺陷，切換審查者也無濟於事。
• 驗證成為新的瓶頸——瓶頸無法吸收的缺陷類別：問題不在審查容量不足，而是審查工具不適用，因為注意力無法找出缺漏的 move 建構子。
• Post-Acceptance Edit Behavior——本論文指出、卻無法測量的篩選步驟。 RQ1 自己也提醒，開發者「在生成文字到達提交程式碼分析之前，已大幅篩選」，因此 68.62% 指的是人類篩選後存留下來的比例。DECODE 直接測量了這個存續步驟：5.36 萬筆 IDE 內接受完成內容後的編輯、雙峰保留分布、完成內容中位數有 63% 留存，且 31% 的軌跡包含移除編輯。它依照該提醒暗示的方向界定其影響範圍，但沒有消除疑問——研究對象不同（選擇加入的擴充功能使用者，而非單一 monorepo），分析粒度不同（9 行完成內容，而非已提交變更），使用的完成模型也較舊。值得參考的是其鏡像式方法論觀察：本論文完全無法區分模型世代，而另一研究中 20 個模型以 eta-squared 0.002 至 0.007 區分結果，這是模型遮蔽成本可能低於表面觀感的微弱證據。
• 由執行回饋強化學習（RLEF）——本頁未解問題所詢問的流程，以及預期它在此處可能無效的理由。RLEF 的獎勵是測試通過，對執行時成本毫無反映；而其消融分析中唯一未解釋的發現是，RLEF 訓練在減少錯誤答案的同時，產生了更多逾時錯誤，這正符合修正語意問題、卻忽略複雜度的模型表現。
• 已提交成品鏈——本頁數據所關乎的解方。Anthropic 的 Applied AI SDLC playbook（vendor-claim，2026-08-21）預測，「一旦測試抓到以往由審查者抓出的問題」，每個 PR 的審查時間就會下降；此處測得的 1.92 倍阻塞討論串比率，是它預測要改變的現況，而本頁的虛無結果——審查深度無法預測哪些低效率會存續——則是更棘手的問題，因為該 playbook 對審查負荷的解答，是在同一個串接流程中增加更多、更好的審查輪次。兩者都認為解方應位於審查上游，也就是撰寫出的內容；但對所提機制是否真能達成目的，意見不同。
• 程式碼品質的收益以 token 為索引——反例指出，程式碼品質問題並非純粹由 token 預算造成：本頁的債務不會累積到必須重寫，而是每月以運算費用計價，因此更大的情境預算也無法將它化解。

待解決的問題#

• 命令式偏向與避免使用函式庫的模式，是否能推廣至 C++ 以外的語言？論文結尾提出了 Rust、Go 與 Java，而答案將決定這是生成程式碼的一般特性，還是 C++ 特定的慣用模式空間所致（在該空間中，「正確」呼叫是某個特定的 absl/std API，而通用模型對其先驗知識薄弱）。
• 低於持平水準的回退率，究竟是 AI 生成程式碼的特性，還是周遭閘門的結果？此處所有可靠性數字都來自設有審查閘門、且靜態分析成熟的 monorepo，也符合論文自己的解讀：閘門會攔下致命錯誤。辨別方法是在提交前檢查較弱的組織中進行相同測量——Faros 的事故數字便來自這類環境。大致已於 2026-09-22 回答，答案是「程式碼的特性，或閘門上游某處的特性」：Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild（Kraishan，Texas Tech，arXiv 2609.17598，empirical）在公開 GitHub 上執行了最接近的可用測量版本——橫跨 2,807 個 repo 的 37,623 個具來源標記的 PR；人類 PR 僅取自同時包含代理程式 PR 的 810 個 repo，使用相同時間窗，並依 repo 設上限。這些 repo 沒有集中式提交前檢查流程。90 天回退率方面，人類為 11.5%，Codex 為 6.1%（OR 0.50），Devin 為 14.5%（OR 1.31）；Copilot、Cursor 與 Claude Code 則和人類無法區分；合併計算約為 7.7%，OR 約 0.64（根據表 2 的算術計算，論文未報告此值）。因此，離開 monorepo 後，低於持平水準的回退率仍然存在，而且差距更大——這是反駁「由閘門造成」解釋的證據，至少對閘門較少的環境而言。三個理由說明為何是「大致」而非「完全」回答。 回退指標定義不同且較弱：作者只看 PR 變動最多檔案中的回退式提交訊息，並指出此方法會漏掉沒有明確記錄的重寫；Google 使用的則是內部回退紀錄。研究對象與其說是閘門不足，不如說是閘門條件異質——擁有超過 100 顆星的公開專案仍會執行 CI 並進行人類審查，而且此處計入的每個 PR 都已通過某種閘門。論文提出的另一種機制也與閘門或程式碼無關：「引導它們的人可能會指派界定清楚、範圍有限的任務」，這種選擇效應無論閘門強度如何都會造成此結果。**本研究增加、而本頁無法提供的結果：**供應商間的差異。相較單一基準，回退勝算介於 0.50 至 1.31，從兩側涵蓋本頁的約 0.9 倍——因此 Google 單一 AI 群組彙總工程師使用的各種助理後，報告的可能是混合結果，而非某項單一特性。
• 階段 3 的 R_eff 平均值 0.385 低於0.5 的持平標準，所以緩解效果最好的再生成結果，平均仍劣於它所取代的人類原始版本。是否有任何回饋模式——作者提出的 RLEF 流程，或從 monorepo 注入情境——能將 R_eff 平均值推升至 0.5 以上？還是對一般通用模型而言，在效能敏感的程式碼上，低於持平水準的效率就是其下限？

資料來源#

• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild — Obada Kraishan（Texas Tech），arXiv 2609.17598，2026-09-12，empirical。§3.1–3.2（配對的 810 個 repo 基準、GitHub 增補資料與 90 天追蹤期間）、§4.3 + 表 2（依規模正規化的變動量與回退結果）、§6（以提交訊息判定回退的限制、任務自我選擇）。此處僅引用於第二個未解問題；表 1 與表 2 已逐格依 pdftotext -layout 核對；單一作者且無出版場地的注意事項記錄於《代理程式供應商間的異質性》。
• Characterizing the Quality Profile of AI-Generated C++ in Production — Tran、Lewis、Yang、Thakur、Kini、Patil、Hashemi 與 Ranganathan（Google，arXiv 2608.06640，2026-08-06），empirical。§3（資料集範圍、來源追蹤與投射、靜態分類法、指標）、§4.1 + 圖 3（採用趨勢與互動模式組成）、§4.2 + 表 2-4（變更結構、靜態問題特徵、原始碼層級效率指標）、§4.3 + 圖 4 + 表 5（審查、可靠性與運算結果、一年 CPU 轉移）、§4.4 + 表 6（分類法導引的回饋介入）、§5（討論、IPC/MIPS 觀察）、§6（效度威脅，包括人機互動的虛無結果）。解析狀態：docling verify: ok，無表格塌縮或位移標記。 表 2 與表 4 仍逐行依本地 PDF（pdftotext -f 9/-f 10 -layout）核對，結果逐格相符；表 5 與表 6 在算術上彼此一致，並於正文中完整重述。一項出自原始來源而非解析過程的內部矛盾：表 4 將標準函式庫使用量標為 ~0.4x，正文則在 §4.2 與 §7 都寫成「少 30% 到 40%」（約 0.6-0.7 倍）。本頁採用正文較保守的數字，未引用 0.4x 儲存格。圖 3 與圖 4 已依兩輪圖片規則直接檢視；本頁與《AI 作為主要作者》中的互動模式占比，都是依圖 3 堆疊面積圖讀取的近似值（約 +/- 3 個百分點）——正文中沒有任何互動模式的數值占比。