指令複利效應

資料來源#

• Claude Code Changelog
• Enable on-demand expertise with Agent Skills in Genkit Go
• Prompt Design at Scale: How Format, Instruction Count, and Context Length Shape Instruction Adherence and Hallucination in Large Language Models
• Prompting Claude Opus 5
• User awareness in frontier models

摘要#

告訴模型做某件它本來就會自然做的事，這種提示指令不會變得多餘，而是會疊加作用。模型的原生傾向加上這條指令，會讓行為超出有用的程度，結果比單獨存在的任一因素都差。Anthropic 的 Claude Opus 5 提示指南是第一份將此作為核心建議的廠商文件：針對四種不同行為，建議的修正方式都是刪除，而不是改寫。

證據說明。 vendor-claim — Anthropic 自家的模型提示文件，未提供任何測量數據。驗證這個案例有獨立佐證：system card 中的 empirical effort-inversion 結果（Unproductive Self-Verification）；審查門檻與標籤洩漏案例則只依據廠商主張。

文件記載的四個例子#

應刪除的指令	它重複的原生行為	疊加後的結果
「對任何不簡單的任務加入最後驗證步驟」、「使用 subagent 進行驗證」	Opus 5 不用提醒就會驗證自己的工作	過度驗證；Anthropic 表示，移除這些指令「能減少浪費的 token，品質不受影響」
「再次檢查你的答案」、「回覆前重新驗證」	未受提示就會發現並修正自己的錯誤	自我修正迴圈會「與模型自身行為疊加，增加成本卻不改善結果」
「只回報高嚴重性問題」、「採取保守態度」（程式碼審查）	單次審查就能有高精確率與高召回率	模型「可能照字面遵循該指令，因此回報更少」
系統提示規定不要思考或推理	思考預設為開啟	關閉思考時，反而會讓 <thinking> 標籤更常洩漏到可見輸出

同一項建議也適用於 harness 程式碼，不只適用於提示：「同樣原則也適用於會加入個別驗證步驟的舊版 harness 腳手架。」

Anthropic 接著把這項原則用在自家的 harness#

Claude Code changelog（vendor-claim；滾動更新文件，快照日期為 2026-08-03，涵蓋 v2.1.200–2.1.220）顯示，指南提到的這種不對稱兩面，在幾週內都成了產品預設：

• 刪除了請求。 v2.1.215 的發布說明只有一句：「Claude 不再自行執行 /verify 和 /code-review 技能；需要時請呼叫 /verify 或 /code-review。」這是在更上一層實踐指南的建議——不是「從你的提示中移除驗證指令」，而是廠商移除自家 harness 的自動驗證路徑；而同一家廠商的文件指出，該模型即使沒被要求也會自行驗證。這也從結構上落實了指南文字所述的界線（「不要使用 subagent 驗證或再次檢查自己的工作」）：模型不再能遞迴呼叫自己的審查技能。v2.1.218 則另外將 /code-review 移至背景 subagent——這是另一項作法，透過隔離 context 而非刪除，目的是避免審查工作「繼續佔據你的對話」。
• 界線以數字形式推出。 下方項目符號清單中的委派上限不再只是建議：v2.1.212 新增每個工作階段預設最多 200 次 subagent 啟動（CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION，「避免委派失控迴圈」），並為 WebSearch 設定相同的 200 次呼叫上限；v2.1.217 則新增同時 20 個的上限。詳見 Parallel Agent Orchestration。

視為趨同，而非證據。 changelog 沒有說明理由、沒有測量數據，也完全沒提到提示指南；推出一項預設設定，並不能驗證本文描述的機制。它能證明的是：指南區分的兩類指令——應刪除的請求、應保留的界線——正是廠商在自家 harness 採取的兩種作法。

為何這比 harness 縮減更值得重視#

Harness Shrinkage as Models Improve 指出，隨著能力內化，腳手架會變得不再必要——Cat Wu 的做法是每次啟動時讀完整份系統提示，刪掉模型已不再需要提醒的內容。節省的是 token 和維護成本。

指令複利效應則是更棘手的情況：這條指令不只是沒有作用，而是會主動造成傷害。若團隊因為「留著也不會有壞處」而保留過時的驗證指令，那就錯了——它會降低原本想保護的輸出品質。這讓精簡工作從例行維護變成正確性義務，也表示每次發布後，不精簡的代價都會增加，而非維持不變。

請留意因果方向，很容易搞反：移除驗證指令的建議，是因為模型的驗證能力已經達到或超過適當程度，而不是因為它能力不足。系統卡視為 Opus 5 招牌失誤的行為，正是這些文件視為一種不應重複要求的能力的行為。

不對稱之處：界線仍然有效，行為要求則否#

規則並不是「少寫提示」。在同一模型上，限制而非要求的指令仍然有效：

• 範圍。「交付所要求的內容，並符合預期範圍……不要採取明顯超出要求的行動。」系統卡也獨立指出，一條簡短的留在範圍內指令能挽回 Opus 5 在 FrontierCode 上的大部分損失（Unproductive Self-Verification）——行為要求會適得其反，界線卻能發揮作用。這是透過提示表達的Least Agency。
• 委派上限。「只有在任務規模大且確實獨立時才委派給 subagent……不要使用 subagent 驗證或再次檢查自己的工作」，或以確定性方式限制啟動次數（Parallel Agent Orchestration）。
• **另設一個篩選步驟。**在審查情境中，取代「採取保守態度」的建議是要求列出所有項目，再事後篩選——把門檻移出偵測步驟（Review as the Control Point）。

另有兩項發現指向相同方向，關乎指令的形式：

• 正面範例勝過禁止事項。「你想要的溝通風格，提供正面範例通常比指示哪些事不要做更有效。」
• **一般規則勝過具體點名。**對於標籤洩漏，「點名思考標籤的指令不如一般性表述有效，因此避免明確點名。」指出失誤會讓它浮現。

合在一起看：描述目標狀態與界線；不要要求某種行為，也不要禁止某種失誤。

關閉思考時出現的產物#

Opus 5 預設開啟思考功能，而且只有在 effort 為 high 或更低時才能關閉——這是 API 層級的限制，不是提示選項。關閉思考時，可見輸出偶爾會出現兩種產物：

• **以文字呈現工具呼叫。**模型將工具呼叫寫在面向使用者的文字中，而不是輸出結構化的 tool_use 區塊。回合會正常完成，但呼叫從未執行；在代理式迴圈中，洩漏的文字會留在對話歷史裡，因此也會影響後續回合。在搜尋等高度使用工具的工作負載中最常見。這是看起來像成功的失誤——沒有任何錯誤，逐字稿看起來也像是工具已執行。
• **內部 XML 標籤。**可見回覆中出現 <thinking> 或其他內部標籤；系統提示若規定不要思考（上表第四列），情況會更嚴重。

Anthropic 對這兩者的主要緩解方法不是提示，而是：保持思考開啟，並用較低的 effort 控制成本，因為「以 low effort 開啟思考的表現，優於成本相近時關閉思考的表現」（Large-Scale Test-Time Compute）。若必須關閉思考，一條整合式指令可透過提供可行選項而非禁止事項，涵蓋這兩類產物——允許在工具呼叫前先說明、不符合工具用途時提供不呼叫工具的替代方式，以及一般性的不得輸出內部標籤規則。

指令複利效應背後的能力下限（Eliav，2026 年 7 月）#

上述內容討論的是哪些指令有害。Eliav 2026（arXiv 2607.19257，empirical）測量的是另一個正交面向——提示最多能承載多少條指令——並發現，不論如何改善每一行指令的寫法，都無法突破某個上限。

設計：一組包含 N ∈ {10, 20, 40, 80, 120, 160} 條可由程式驗證的同步規則（字數範圍、指定首字、必要結尾句、禁用／必須使用的字詞、段落數），以四種格式呈現（markdown／純文字／散文／markdown 表格），放在系統提示或使用者回合中，每個條件格進行 20 次試驗，每個模型呼叫 960 次。五個模型：Claude Sonnet 5、Claude Haiku 4.5、Gemini 3.5 Flash，以及兩種自行託管的 Qwen 尺寸（27B、35B）。評分採用 regex 與字詞邊界比對——完全沒有使用 LLM judge。

完美回應率（所有 N 條規則都符合），按格式與放置位置合併計算：

模型	N=10	N=20	N=40	N=80	N=120	N=160
Sonnet 5	0.938	0.750	0.238	0.000	0.000	0.000
Gemini Flash	0.919	0.825	0.312	0.019	0.000	0.000
Claude Haiku	0.850	0.594	0.119	0.000	0.000	0.000
Qwen 35B	0.725	0.450	0.100	0.000	0.000	0.000
Qwen 27B	0.588	0.350	0.094	0.006	0.000	0.000

在所有模型、所有格式、兩種放置位置中，到了 N=80 時完美回應率都幾乎為零，並在 N=160 前維持持平。這是下限，不是漸近值。論文自己的建議是最可行的作法：「將約 40 條同步指令視為重新設計的起點，而不是調校起點」——超過這個範圍後，換句話說或重新排版同一組指令都不太可能有幫助；剩下唯一可行的槓桿，是把指令拆到不同回合、工具或驗證步驟中。

先讀懂指標，再看數字。「完美回應」採嚴格合取——單次輸出必須符合 N 條規則中的每一條。即使每條規則的遵守率很高，N 個獨立檢查的合取結果仍會以幾何級數下降（每條規則遵守率為 97% 時，N=80 的整體比率為 8.7%）；因此，下限有部分是算術造成的，而不代表模型把整組指令丟在一旁。論文刻意選用這個指標，並說明原因：規則組成會隨 N 改變（五條硬性結構規則在 N=10 時佔一半，在 N=160 時只佔 3%），所以整體平均遵守率會因規則組成而偏移；論文另行驗證，僅看固定的結構規則子集，到了 80 條時出現下限的結果依然成立。研究證明的是，同時有約 80 條規則時，無法可靠地產出完全遵守所有規則的輸出，並非模型停止閱讀提示。

格式不是可用的槓桿。Markdown 相對純文字的遵守率差異維持在 2.1 個百分點以內，而且五個模型中有四個的差異方向不一致。整個實驗中，最明確、方向一致的格式訊號，反而違背這份 wiki 自身 context 檔案採用的慣例：Qwen 35B 在六個 N 值中的五個偏好純文字，到了 N=160 時差距擴大至 4.8 個百分點。詳見 Scale-Dependent Prompt Sensitivity。

**放置位置比格式更有影響，而且效果方向因模型而異。**將完全相同的規則組從系統提示移到使用者回合，在 N=160 時對五個模型中的四個造成的影響都大於格式（95% Wilson 信賴區間）：放在使用者回合中對 Claude Haiku（+6.6 個百分點）和 Qwen 35B（+5.1 個百分點）有利，對 Gemini Flash（−8.7 個百分點）和 Qwen 27B（−1.8 個百分點）不利，而 Sonnet 5 的差異在統計上與零無異。Logistic knee 擬合也一致——Haiku 的 knee 在使用者回合放置時由 N≈98 移至 N≈104，Gemini Flash 則由 N≈82 移至 N≈46。沒有「系統提示效果比較好」這條規則可套用。

**這對本文主張有何影響。**指令複利效應與能力下限是不同機制，值得加以區分：

• 指令複利效應是逐行品質問題——某一條指令重複要求原生行為，會讓輸出變差。刪掉那一行即可修正，而且逐行測試（ablation non-inferiority）可以找出它。
• 能力下限是整組指令的承載能力問題——這裡的每條規則都各不相同、沒有重複，且個別都能滿足（N=10 時完美率為 85–94%），但整組仍然會崩潰。逐行 ablation 找不到問題，因為沒有任何單獨一行有錯。

因此，本文確立的精簡義務必要但不充分：每一行都通過 ablation 的 context 檔案仍可能太長；真正的限制單位是同步指令數量，不是 token 數。這就是對 Claude Code Best Practices 長期以來關於 CLAUDE.md 長度問題的實證解答——請參見其 Resolved Questions。

架構上的解答及其限制#

若限制單位是指令數量，修正方式就不是縮短檔案，而是採用一種設計，讓大部分指令在符合情境前都不進入 context。這就是漸進式揭露的作法；截至 2026 年 7 月，第二家廠商已將它做成 SDK 原生功能，而不是一種紀律：Google 的 Genkit skills middleware 在初始化時只注入各個 SKILL.md 的 frontmatter，並在請求符合條件時，透過一次 use_skill 工具呼叫載入內文（Enable on-demand expertise with Agent Skills in Genkit Go，vendor-claim；運作細節見 Agent Context Files）。它提出的理由是 token 預算，而非指令數量——但實際上受到影響的是指令數量，因為每次生成時生效的指令，是單一技能內文，而不是所有已安裝技能的總和。

有兩項限制值得記住。每個已安裝技能的說明在初始化時都已載入，因此上限只是轉移到目錄大小，沒有消失，而且沒有人測量上限會落在哪裡。Google 也沒有公布任何數據——依據本節所建立的機制，這是一種理應有效的架構，卻不是證明其確實有效的示範。

**坦誠說明範圍。**單一作者、單一實驗室（Machine Human Intelligence Lab）、未經同儕審查的 arXiv 預印本，每個條件格進行 20 次試驗。論文自己劃定了界線：可移植的主張是質性模式（存在硬性下限，格式無法改變它），而「N=80」是這五個模型的特性。而且每條受測規則都是套用在單次生成上的硬性輸出限制——Limitations 一節明確表示，這種模式不一定適用於無法透過精確字串比對檢查的指令，而真實 context 檔案中的大多數內容都屬於這一類。

延伸閱讀#

• Harness Activation and Adherence — 同一條能力範圍軸線另一端的情況；兩者合看比單看任一端更有用。本文討論的是強模型對指令的遵循程度過高，超出有用範圍，這也是 Anthropic 為何刪除給 Opus 5 的驗證指令；Lin et al. 測量的是弱模型正確載入指令後仍遵循不足，在單一軌跡中從 0.52 漂移至 0.13，而強模型層級則是從 0.89 漂移至 0.80。由此得出的兩項建議——在頂端寫更少、更強的指令，在底端訓練呼叫與長期遵循能力——是一條曲線的兩端；為錯誤端點撰寫的 context 檔案會在相反方向失效

• Impose Values, Not Disciplines — 指令失效並非因為複利效應，而是完全無法持續遵循：即使要求代理程式嚴格採用 TDD，它們仍會回到先寫函式再測試；本文的遵循下限是三個可能解釋之一

• Latent vs. Deterministic Space — Robert C. Martin 根據相同觀察提出的解方：徹底將持久規則移出提示，而非重新改寫

• User Awareness — 評分規準中有一項長度效應，原始來源無法解釋，而本文的上限是顯而易見的候選原因。研究測試四份由模型撰寫的評分規準能否彌合身分造成的評分差距：長度為 2,912–5,000 個字元的三份成功彌合，7,607 個字元的那份則沒有。一份評分規準是一大組套用於單次生成的同步指令，正是本文測量的能力下限；不過四份規準的內容和長度皆不同，因此這是待驗證的假設，而非複製實驗

• Harness Shrinkage as Models Improve — 背後的整體變化：能力內化時，腳手架會縮減。本文指出其尖銳的一面——有些腳手架不只是失去作用，還會造成傷害，因此精簡工作是必要措施，而非整理工作

• Unproductive Self-Verification — 兩個最重要案例的核心行為；廠商指南提供了緩解方式（刪除指令），用來處理系統卡測量到的失誤

• Output Length Calibration — 同一來源中的鏡像案例：由於預設行為已經改變，你現在必須新增指令要求模型做某些事。指令複利效應表示別再要求模型做它已經會做的事；校準則表示開始要求模型做那些它做過頭的事

• Large-Scale Test-Time Compute — 說明緩解方式為何是 effort 設定而非提示：以低 effort 開啟思考，表現勝過以相近成本關閉思考，因此預算旋鈕可取代關閉開關

• Review as the Control Point — 審查情境中的例子：原本要提高回報門檻的指令，反而降低偵測率，因此門檻應放在獨立的篩選步驟

• Least Agency — 仍然有效的指令類型：模型可採取行動的限制仍有效，行為要求則會產生疊加效應

• Parallel Agent Orchestration — 委派是另一種應設定上限，而非加以鼓勵的行為

• Agent Context Files — 指令複利效應逐漸累積的地方：CLAUDE.md / AGENTS.md / system prompts 正是只會不斷新增內容的檔案。能力下限的架構性解方也在此：漸進式揭露讓大多數指令在符合情境前不載入，而且第二家廠商（Genkit）如今已將其做成執行期原生功能，將同步指令數量降至「所有說明加上一份內文」，而非完全消除

• Failures That Look Like Success — 關閉思考時工具呼叫洩漏就是典型案例：回合正常完成，逐字稿看起來乾淨，工具卻從未執行

• Claude Opus 5 — 這篇文章所談的模型

• Cat Wu — 本文要求採用的精簡紀律

• Claude Code Best Practices — 本文機制出現前就有的嚴格精簡建議；能力下限也解答了該頁關於 CLAUDE.md 長度的問題

• Scale-Dependent Prompt Sensitivity — 同一實驗中格式的部分：沒有任何格式穩定勝出，方向因模型而異，而且唯一明確的訊號不利於 markdown；同一篇論文也記錄了長 context 中格式效果反轉的情況

• Context Window Smart Zone — 同一篇論文中的第二項實驗：recall 在 64–128k 內維持穩定，之後便依各模型自身的有效上限而衰退；接近上限時增加的是拒答，而非捏造

• What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful? — 說明偵測指令複利效應的特徵（ablation non-inferiority + 反向劑量反應，並將原生行為基準測試作為前置篩選），並把指令複利效應放進存續者分類法中：只有請求形式的指令會產生複利效應，因此精簡過程可跳過限制形式的指令

• What Makes a Self-Improvement Artifact Transfer? — 跨解題器的對應情況：指令複利效應就是解題器適配型產物在時間軸上的表現（解題器在過時修正下進步）；HarnessBank 的跨模型匹配定律則是同一種失誤在移植軸上的表現——一條規則（「產物能轉移的範圍，取決於它所編碼規律的適用範圍」）涵蓋兩者

• Harness Value Is a Product, Not a Score — Why the Artifact-Payoff Questions Keep Returning Partially Answered — 從結構角度解釋為何每次發布的精簡清單仍需人工整理：偵測特徵的兩部分都是介入措施（ablation、劑量提升），因此無法從部署設定的軌跡中計算出能填補缺口的答案；唯一的觀察捷徑——要求模型讀取自己的提示——又被本文自身「點名會讓失誤浮現」的發現排除。此文也將能力下限（寬度）與 Harness Activation and Adherence 測得的軌跡內遵循漂移（深度）配對討論

尚待解答的問題#

• 審查案例與過度驗證是同一種機制，還是兩種？「採取保守態度」降低偵測率，看起來像是高度忠實地照字面遵守指令；過度驗證則像是行為相加。可以測試較弱的驗證指令是否仍會導致過度驗證，以區分兩者。
• Anthropic 每次發布都會手工整理清單。是否存在可偵測的訊號——來自 eval 差異、token 數，或模型自行閱讀系統提示的結果——能標示哪些既有提示指令已開始產生複利效應，讓精簡不必靠人工重讀？部分已回答：What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful?——其特徵已經存在：有害指令會呈現ablation non-inferiority（移除後品質持平或提升，同時減少 token——這是 Anthropic 自己採用的標準，也是決定性的逐行測試），以及反向劑量反應（加強指令會使指標惡化——Unproductive Self-Verification 的 effort-inversion 特徵，可從 eval 差異偵測，無須進行 ablation）。以原生行為作基準測試（模型不受指令時是否已會這麼做？）可為候選指令排序，而且只有請求形式的指令需要測試（限制不會產生複利效應）。應避免的訊號是模型自行閱讀提示——點名失誤會讓它浮現。剩餘問題：現有資料中沒有任何流程將此自動化；每次發布的清單仍是人工整理。2026-09-18 再次部分解答：Harness Value Is a Product, Not a Score — Why the Artifact-Payoff Questions Keep Returning Partially Answered——自動化的剩餘問題是結構性限制，而非工程缺口。特徵的兩部分都是介入措施（ablation non-inferiority 需要無該指令的實驗組；反向劑量反應需要提高指令強度的實驗組），因此，任何從部署設定軌跡中挖掘資訊的工具都無法還原這些特徵——在那些軌跡中，指令總是以同一強度存在。唯一的觀察捷徑——要求模型閱讀自己的系統提示——已被本文自身「點名會讓失誤浮現」的發現排除。可以自動化的是執行 ablation，而非不做 ablation 就偵測問題。重新標記為 #oq/now → #oq/source：若有來源描述已建置的 ablation harness，便能回答此問題；另一篇綜整文章則不能。
• 指令複利效應是否要求指令點名模型已具備的行為，還是任何重複指令都會降低輸出品質？可以用固定 eval，一次移除一條指令來驗證。由 Prompt Design at Scale: How Format, Instruction Count, and Context Length Shape Instruction Adherence and Hallucination in Large Language Models（empirical）從另一面部分解答，2026-08-04：即使完全沒有重複指令，也會造成退化。該研究中的 10 至 160 條規則彼此不同、沒有重疊，而且個別都能滿足；所有規則的遵循率仍在五個模型上於 N=80 前降至下限。因此，對「任何重複指令都會降低輸出品質嗎？」的回答，受到一項先決事實所限——不論是否重複，指令數量都會使整組遵循率下降；而本文提出的一次一條 ablation，正是看不到這種情況的方法，因為沒有任何單獨一行有錯。重複指令這一部分仍然是開放問題，仍需進行 ablation。

資料來源#

• User awareness in frontier models — Zhong、Raghunathan、Laidlaw 與 Steinhardt，Transluce，2026-08-06（empirical）：Figure 9 的評分規準長度結果：測試四份由模型撰寫、長度為 2,912–7,607 個字元的評分規準，能否彌合身分造成的評分差距；較短的三份成功，最長的一份則失敗。本文將其視為指令數量上限的候選案例，而非複製實驗——四份規準的內容與長度皆不同，來源也沒有提出相關機制。完整討論見 User Awareness

• Prompting Claude Opus 5 — Anthropic 平台文件（2026-07-25 取得，vendor-claim）：「Task scope and over-verification」、「Self-correction」、「Controlling subagent spawning」、「Capability improvements」（程式碼審查）、「Running with thinking disabled」

• Prompt Design at Scale: How Format, Instruction Count, and Context Length Shape Instruction Adherence and Hallucination in Large Language Models — Netanel Eliav（唯一作者，Machine Human Intelligence Lab；arXiv 2607.19257，2026-07-21，empirical，預印本，未經同儕審查）。§4 實驗 1 全文：Table 4 的完美回應下限（本文完整引用，並逐格對照 PDF 核實）、§4.2 對「下限而非漸近值」的解讀，以及說明為何完美回應是主要指標的註腳、Table 5 的 markdown 減純文字差異、§4.4 的放置位置效果與 logistic knee 擬合、§8 實務建議第 1–3 點、§9 限制。解析警告：原始 markdown 中的 Table 1（模型名單）儲存格發生合併——五個模型的識別名稱、託管者和 context 上限全被空格串接到單一儲存格中，因此自動化 table-collapse 檢查對它回報漏報；本文未引用 Table 1 任何一列；各模型的 context 上限改取自論文內文。Tables 3–9 已逐一核對，內容正確。其他地方只有外觀受損：全篇的 en/em dash 都被壓平成連字號，Table 7 和 Table 9 中標示最佳表現者的粗體符號遺失（兩處的周邊文字都點名了贏家）

• Claude Code Changelog — Anthropic，Claude Code CHANGELOG（vendor-claim）。滾動更新文件，快照日期為 2026-08-03，涵蓋 v2.1.200–2.1.220；原始文件的 published: 刻意留白，線上檔案此後也已更新。只有發布說明——沒有理由、沒有測量，也沒有提到提示指南。本文用於說明 v2.1.215（Claude 不再自行呼叫 /verify 和 /code-review）、v2.1.218（/code-review 移至背景 subagent），以及 v2.1.212／v2.1.217 的委派上限

• Enable on-demand expertise with Agent Skills in Genkit Go — Daniela Petruzalek，Google Developers Blog，2026-07-31（vendor-claim）。僅用於說明設計——Genkit 初始化時注入中繼資料、單一 use_skill 啟用工具、執行內文與資源——作為降低指令數量之架構的例子。該文沒有測量任何項目：沒有 token 節省、遵循率數據、預先載入的基準比較；讀起來像結果的那句話，其實是圖說

• Claude Opus 5 System Card — 驗證案例的 empirical 佐證：FrontierCode 上的 effort inversion，以及能挽回大部分損失的留在範圍內指令。解析風險：這份 PDF 的原始 markdown 表格列有錯位——§4 safeguards 表格（4.1.1.A、4.2.B、4.3.1.B、4.3.2.A、4.4.2.B、4.4.3.B）、§5.1 agentic-safety 表格（5.1.1.A–5.1.3.A）與 Table 8.13.6.A 中，模型名稱被移到數值欄；若照字面解讀，可能把一個模型的分數錯配給另一個模型。本文引用的圖表數據已於 2026-08-03 對照 PDF 核實，並有內文或圖表佐證；不可引用未核實的原始 markdown 表格列