用同一框架比較兩個 Crypto AI 專案

共同規格要在第一列之前就先凍結

大多數比較在開始之前就已經壞了。一方由這週才發布的 Demo 代表，另一方由一年前最後一次更新的文件代表。這兩份材料從來不在回答同一個問題，而建立在它們之上的任何表格，重複的只是材料的差距。

所以先把規格凍結，再把兩個專案放進去。下面這張表是第一列被填上之前，必須先談好的最小形式。

這份例外清單和結果一樣重要。看到某一列是空白的讀者，需要知道這個空白代表失敗，還是代表從來沒有機會測。

自主性用同一組案例與同一次故障來測

自主性在行銷頁上讀不出來。它要從「被呼叫的工具在中途死掉之後發生了什麼」讀出來。跑一個正常案例、一個落在 Demo 腳本之外的變體，以及一次刻意注入的工具故障——兩個專案照完全相同的順序來一遍。

測試過程中要記下的是：

• 下一個工具是誰選的，系統還是人；
• 中間結果不如預期之後，計畫有沒有自己被改掉；
• 系統在哪個點要求澄清，那個要求合不合理；
• 系統在哪個點停下，這個停是設計好的還是碰巧；
• 為了把任務做完，人一共要介入幾次。

這一步最容易弄反的一件事：更高的自主性本身並不是加分。對於會動到資金的動作，早一點停下來的系統往往比一路跑下去都不問的系統更合適。兩邊的 trace 並排保存，這個說法才能被別人覆核。

權限與最大損失是各自獨立的硬門檻

權限這個維度不和其他維度一起平均。最大損失、簽章路徑、額度上限、撤銷權限的能力，以及對 Prompt Injection 的抵抗力，都是必須通過的門檻，而不是可以被其他維度補償的分數。

理由很簡單：漂亮的 Demo 不會在無限 allowance 被濫用時減少損失，也沒有任何能力分數能抵銷一把由單人保管的國庫金鑰。一個重大權限缺陷直接否決該列，然後照實寫進摘要。

若其中一方拒絕展示自己的權限結構，該列維持未知。未知不是安全的同義詞，也不是糟糕的同義詞——它只代表目前沒有東西可供檢查。

證據品質在兩邊通過同一道門檻

用到的門檻有四個：證據離聲明有多直接、證據有沒有綁到特定版本、能不能被重做、以及是誰做出來的。這四項對兩個專案以同樣的嚴格程度施加，包括對你自己比較偏好的那一個。

有兩個陷阱反覆出現。第一，內容對不到正在運行的部署版的開源 repo，常被當成自動勝過有完整 trace 的閉源 Demo——可是一邊是開放但不相關，另一邊是封閉但相關。第二，來自專案團隊的同一份報告，因為被轉引到好幾個地方，就被當成好幾次確認來計算。

檔案註記：每一份證據都保存來源類型、所引用的版本、重做是否成功、已承認的限制，以及它現在的狀態。

完整成本與淨收入放在同一個期間

經濟數字只有在分母相同時才可比。拿一個真正被接受的任務當單位，兩邊用同一個日曆期間。單價便宜的模型可能因為需要大量重試而更貴，而那些重試照樣要付錢。

1. 收集所選期間的真實用量、失敗次數與人工工時，再乘上有日期的費率。
2. 把 Token 出售、補助與補貼從產品收入那一行拿出來；兩者都可以呈現，但不放在同一行。
3. 拿不到的資料寫成帶最壞假設的區間，而不是四捨五入成一個看起來很整齊的數字。

誠實的經濟比較，結局經常是兩個互相重疊的區間。那是合法的結果，而且比「一邊用最好假設、另一邊用最壞假設」拼出來的百分比差距更有用。

判定逐維度書寫，不硬選出一個冠軍

這份檔案的結尾不是一張排行榜。對每一個維度——能力、證據品質、經濟、安全、區塊鏈必要性與 Token 必要性——寫下哪一方較強、這個差異會影響到什麼樣的讀者，以及還有什麼仍然未知。

結果分裂反而是最常見的正確情況。一個專案的行為可能更有證據，但它的 Token 很難說得通；另一個專案的權限控制可能乾淨得多，卻完全還沒有收入證據。硬把這兩欄壓成一個贏家，丟掉的正好是讀者要找的資訊。

最後，寫下會讓判定翻轉的條件：下一個版本、簽章結構的變動，或一次失敗的獨立重做。少了這些條件，這份比較還沒寫完。

驗證工作簿

這一節把上面的研究換成別人可以重做一遍的紀錄。檢查按「什麼時候做」分組：比較開始之前、兩個系統運行期間，以及結果被收攏的時候。其中沒有一項會產生建議。

比較開始之前

這個階段要找的只有一件事：站在同一列的材料，時間與直接性是否相近。測試方法是把截止日期、版本或輸入在兩邊互換；互換之後就消失的優勢，來自規格，不是來自專案。任務或權限範圍不同會製造出假的優勢，這種列不產生勝負——要報告的是規格本身。

兩個系統運行期間

同一案例下的行為必須能逐步並排。刻意讓工具失敗，再把請求帶出 Demo 腳本之外。如果剩下可比的只是行銷材料上的自主性標籤，那測試其實還沒真正跑過。要記下的是第一個需要人介入的點，而不是曾經看到過的最高自主程度。

在同一組測試裡，也把最壞損失路徑跑一遍：allowance、更換簽章者、撤銷權限，以及 Prompt Injection。重大權限缺陷必須出現在摘要，而不是埋在腳註裡；只寫在文件上、從未在故障條件下跑過的控制，不算控制。安全底線優先於加權分數：一個重大缺陷就否決該列。

結果被收攏的時候

同類的 artefact 要在兩邊通過同一道門檻。檢查證據在另一個版本上、或在第三方手裡是否仍然成立，並數一數同一份團隊材料被重複用作「看起來獨立」的確認幾次。重做失敗會降低確定性，但不會同時降低能力評價。

單位經濟用同樣的方式處理。從已公布的數字重算一次，再在另一個期間與高重試情境下重算，然後拒絕「成本取最佳情況、收入也取最佳情況」的混合。要呈現的是帶最壞假設的區間，不是單一數字。

最後，每一個被報告的差異都必須能回推到共同規格。用不同的順序再讀一次各個維度，或者請別人讀一遍；一旦多維結果變成投資排名，這份檔案就已經偏離軌道了。寫下會讓判定翻轉的條件，因為少了這一步，判定還沒完成。

常見問題