指南
一次變更，從頭到尾
一次變更之後，你的分數上升了。本頁跟隨一次真實的變更，走過 Oloproof 在允許它發布之前提出的每一個問題：評審是否可信，變更本身是否達到門檻，依評審和依人的判斷它是否優於被取代的版本，以及下一步該嘗試什麼。系統是一個根據 40 份文件作答的小型客服機器人，在你的機器上以本地模型執行；下面的每個數字都是引擎印出來的。從 examples/one_change 複製它，然後執行 REVIEWER=yourname ./run_demo.sh。
變更
基準提示詞要求機器人保留確切的數字、名稱和單位。候選版本要求一兩句溫暖、自然的句子。兩者在同樣的 120 個問題上執行，搭配一個確定性檢查（answer_correct，答案是否包含預期的事實）和一個本地模型評審（judge_correct，是否以同一事實作答）：
oloproof run --policy release.yaml
oloproof run --config candidate.yaml --policy release.yaml答對的比例從 80.0% 升到 82.5%，評審的通過率從 82.5% 升到 83.3%。這就是表面上的改進。兩次執行目前都還不決定任何事：發布規則讀取評審，而評審尚未經過檢查，所以規則給出 INSUFFICIENT_EVIDENCE，原因是 evaluator_not_validated。
評審可信嗎？
人對候選版本答案的一個盲隨機樣本加上標註，看不到評審的判定，引擎再以這些標註來量測評審：
oloproof review CANDIDATE --criterion judge_correct --by you在記錄的工作階段中，評審在 79 個已標註案例中的 77 個上一致（97.5%，下限 91.2%），偏差為 -2.5 個百分點，在預設門檻之內（一致性 0.70，偏差 0.35），因此通過驗證，可以做決定。在那次工作階段中，標註由一個代替審閱者的代理給出，這展示了工作流程，並不是人的判斷；當你執行時，審閱者就是你。
候選版本本身達到門檻了嗎？
release.yaml 要求評審通過率至少為 80%：
oloproof gate CANDIDATE --policy release.yaml --config candidate.yaml83.3% 的區間為 75.4% 到 89.6%，橫跨 80%，因此規則為 INSUFFICIENT_EVIDENCE，引擎表示大約 592 個案例可以做出決定。可信的評審並不會讓一個接近的結果變得明確。
它比基準更好嗎？
compare.yaml 提出兩個問題。依評審，候選版本是否更好，且僅當人證明評審在兩個提示詞上犯錯方式相同時（judge_bias_bar: 0.10）才保留這個結論？以及依人自己對同一案例兩個答案的標註（people_pass_diff，一個 human_difference 指標），它是否不比基準低超過 10 個百分點？
oloproof review CANDIDATE --against BASELINE --criterion judge_correct --by you --sample 40
oloproof compare CANDIDATE BASELINE --policy compare.yaml --config candidate.yaml審閱把兩個答案顯示為 A 和 B，順序由擲硬幣決定，不標出是哪次執行。在記錄的工作階段中，評審的差異為 +0.8 個百分點（-5.1 到 +7.3）：INSUFFICIENT_EVIDENCE，大約需要 3,690 個配對案例才能決定。在 40 對中，人讓候選版本通過 36 次、基準通過 35 次：+2.5 個百分點（-11.1 到 +17.7），所以「不差於 10 個百分點」也是 INSUFFICIENT_EVIDENCE。閘門擋下了它。這次變更是分數幾乎察覺不到的風格變更，而 120 個案例無法區分 1 個百分點的變化和沒有變化。
它為什麼在失敗的地方失敗？
oloproof diagnose CANDIDATE --intervention gold-context --criterion answer_correct --config candidate.yaml引擎把正確的段落交給模型，重新執行了 21 個失敗案例，並在不提供段落的情況下再執行一次作為對照。對照一個也沒有恢復；正確的段落恢復了 14 個：7 個是檢索從未找到該段落，7 個是找到了但排在前 3 名之後，另有 7 個無論如何都失敗了。它提出更大的 top_k 作為假設，然後在同樣的案例上進行了測試：
oloproof diagnose CANDIDATE --intervention top-k --top-k 8 --criterion answer_correct --config candidate.yaml7 個排名落後的案例全部恢復，而對照一個也沒有恢復。
後續
followup.yaml 是帶 top_k: 8 的候選版本，一個完整執行的新系統版本：
oloproof run --config followup.yaml --policy release.yaml
oloproof compare FOLLOWUP CANDIDATE --policy followup_compare.yaml --config followup.yaml它的評審通過率為 90.0%（83.1% 到 94.8%），因此 80% 的下限為 PASS。與候選版本相比，答對更多（+3.3 個百分點）仍為 INSUFFICIENT_EVIDENCE，而評審通過率不差超過 5 個百分點為 PASS。評審是在候選版本的答案上檢查的，而不是後續版本的答案，也沒有人標註過後續版本的配對，所以那裡人的差異不決定任何事。
這無法告訴你的
一個小機器人、一次變更、120 個案例和本地模型。它展示了引擎如何在一次真實變更上得出每個決定；它對其他系統什麼也沒說。本地樣本屬於善意：只有工作區抽取的樣本才會在那裡得到檢查。包含每個執行 id 的完整記錄是 docs/audits/DOGFOOD_LARKSPUR_2026-10-26.md。參見 評審、比較規則、RAG 評估 和 限制。