開賽時我是希望每天先把該跑的實驗跑完，再依據跑出來的結果寫當天的文章，但實作的內容真的跑太久了，常跑到深夜或是需不間斷的時間才會出來結果，有幾天因為API額度耗盡而完全沒有產出，也只能靠既有紀錄硬撐，相反先決定今天要論證什麼，再去找支持它的數據——會讓整個系列平順許多，讀起來大概也更像一個有規劃的研究。
這三十天裡真正有價值的發現，沒有一個是推論出來的，全部是某個實際跑出來的數字與預期不符，追查之後才浮現，如果先有結論再找數據，這些發現不會出現，因為我根本不會去看那些看起來不重要的執行紀錄。
現在回頭看，發現自己在這過程中更認識CaMeL架構與實測的方式，看見自己許多沒有預期的東西，研究做久了很容易只看自己想看的部分，這次30天讓我每天有個非交不可的東西，這個過程反而強迫我把跑出來的結果從頭看一遍。
剛開始執行時我把AgentDojo報表中的security解讀為防禦成功率，寫了一整篇論述CaMeL未能擋下攻擊，結果實際上是攻擊成功率，雖然拿時候搞不清楚數字意義而寫錯，但這件事改變了我對**「看懂數字」**這件事的標準，養成每次要引用一個數字之前，先去原始碼確認它是怎麼算出來的習慣，後面能抓到測量錯誤，也是因為養成這樣習慣而帶來的。
因為需要每天更新文長，以及是公開的資料，會讓自己有壓力在文章上的準確度要提升，如果我只是在自己的筆記裡寫，錯誤大概只會被改掉，不會留下痕跡，也不會變成深入去探索與被解釋，畢竟現在AI太方便了，很多時候AI能完成的東西我們都會省略，但過程的內容可能也是很重要的知識點。
每次數字不對，我的第一反應都是回去看設計哪裡沒想好，而實際上該先看的是對照組到底跑了什麼，花太多時間在懷疑設計上，有一部分本來可以省下來。
問題是如果同樣的錯誤讓數字對我有利，我感覺我就不會進一步去研究確認原因，只對結果有沒有利有關，數字看起來合理的時候，我就不會做追查的動作，所以我發現應該要固定去確認基準組做的事情內容，不管當天的數字好不好看。
還有在基準組沒掛政策的錯誤，在單一任務的對照上一直表現為一兩格的差距，跟抽樣波動分不開，直到16個任務出現4格落差才發現，這讓我對「先在小樣本驗證，確認沒問題再放大」這個看起來穩健的流程有了保留，小樣本不只藏得住雜訊，也藏得住測量錯誤，而在藏住的那段時間裡，我只覺得自己已經驗證過了。
這一個月的力氣大多花在權限判斷上，拆開看之後才發現真正貢獻相當的是另一個我只當成補救措施的機制，被擋下來之後給一次重新規劃的機會，我最小心處理的威脅等級幾乎沒在工作，也沒花到特別多力氣在中間層。
鐵人賽是每天一篇，多數日子衝突可以吸收，修好一個缺陷、跑出一組乾淨數據等等，但有些時候實驗結果是受攻擊執行中完全未觸發，當天可能就沒有任何可供論述的正面材料。
這30天我選擇按照實際記錄，實際執行結果數據很少對讀者的資訊量影響不大，這樣可以界定了這套機制的適用範圍，也調整了後續所有受限的條件。
先確認這個場域有沒有可改善的空間：這套系統的攻擊成功率是0，而0就是地板——防禦側沒有任何東西可以改善。這個結論在我讀懂那個指標的當天就已經完整，不需要任何額外實驗，我卻又花了十幾天繼續量防禦側。
先確認基準組真的在做你以為的事：我的基準組整整一週沒掛政策引擎，比的是「無政策」而不是「靜態政策」，掛政策那條路的管線叫+camel+secpol，基準組叫+camel，而那就是log的目錄名稱，列一次目錄就看得出來不是同一個東西，我沒有一開始就去看，因為我相信自己傳進去的旗標，至於「跑一次看有沒有拒絕發生」這種檢查，在單一任務上完全無效，多數任務本來就不觸發政策，要到全suite規模才有診斷力。
固定回頭看手上已經有的資料：這三十天我一直在產生新資料，卻很少去翻舊的，直到最後才發現裡面早就有我以為量不到的答案。
三件事都和新知識或新工具無關，是沒有回去看那些我以為早就確認過的前提，其實都沒有驗證過，而越基礎的前提，我會在下次實作時優先學習驗證。
三十天累積出一份對CaMeL政策層的缺陷分析、一套完整的動態權限實作，以及一個只驗證了一半的主張。
我原本預期三十天結束時會有一個比較完整的結論，結果實際得到的是一連串修正、一次讓一週工作需要重新解讀的基準錯誤，以及幾個「真正掌握在動態權限的重點」發現。
我對自己工作的判斷，在測量方式、注意力分配、以及資料是否已被使用這幾個層面上，都出現過系統性偏差，而且每一次都需要外部證據才被發現，未來要花更多時間在思考過去已經做過的東西上。
設計上的細節會隨著題目換掉，但「我的判斷會在哪些地方系統性地偏掉」這件事，接下來也將繼續往此研究繼續下去，希望大家看完也能對此方向有些認識，對於較新的主題的研究也希望我能一路進修，那就到這邊啦！
這30天十分充實，再次謝謝有看到這裡的人！
iThome鐵人賽
看影片追技術