偷確定性層：否決整套 AI 工具後，還能帶走什麼
最近 alibaba/open-code-review（後面簡稱 ocr）衝得很兇。我 2026-06-06 評估它的時候才 3,160 顆星，18 天後的今天（2026-06-24）已經衝到 9,046。
熱度爬成這樣，照常理該裝來試試。但評估那天我否決了它的本體，到現在理由一個都沒變。
不過這篇不是要講這個工具好不好。我想講一件更通用的事：用三題篩掉一個工具的本體之後，它身上「不靠 AI 的那一層」通常還能拆下來帶走。這層移植成本最低，是整個評估裡最值得帶回家的部分。
下面三個案例，那一層的形態一個比一個輕，從完整的工程機制，到一組詞彙，到只剩一個設計想法，但每個都帶得走一點東西。
先說三題篩選在問什麼
評估那種「判斷全交給 AI」的工具，我固定問三題：
- 判斷是不是全交給 AI？ 如果是，這工具的天花板就是它用的那顆模型，你換不了。
- 能不能只借它的外殼，塞自己的 agent 進去？ 多數這類工具是整包綁死的，拆不開。
- 能不能搭我已經付的訂閱？ 第三方工具多半不在官方訂閱的白名單裡，得另外掏錢買 API。
三題篩完，本體多半否決。但工具裡還有一層不靠 AI 的東西，純粹是資料和規則比對，我叫它確定性層。這層不綁模型、不用登入，搬到哪都能跑，移植成本最低。
ocr 是最豐富的案例
ocr 三題都不過：它是一支獨立程式，判斷全靠它自己綁的那顆模型；外殼和模型整包綁死，沒辦法只借一半；走的是計費 API，搭不到我已經付的 Claude 或 Codex 訂閱。
但否決本體之後，它身上那層確定性工程漂亮得很。最值得帶走的兩塊：
- 覆蓋保證：審一個大改動時，先用程式把檔案清單建好，不靠 AI 自己回想，再逐一確認每個檔案都被審過。AI 面對幾十個檔案容易悄悄漏掉後面幾個，這層邏輯專門補這個洞。
- 行號定位：每個發現都附上一段原文，事後在目標檔裡精確比對，釘回真正的行號。AI 自己報的行號在改動情境裡經常漂掉，這層把「猜位置」改成「比對位置」。
這兩塊全是純資料加比對，不靠 AI。我把它們做成自己 code review 流程裡的兩個步驟，試用了 16 天。
試用期數字，分母一起擺，不能只給好的：
| 機制 | 分母 | 結果 | 能推出什麼 |
|---|---|---|---|
| 覆蓋保證 | 2 個跑過的小型 PR | 兩個都沒漏檔 | 在小 PR 上跑得通；2 個樣本太少，不能說「保證不漏」 |
| 行號定位 | 同 2 個 PR 共 11 個發現 | 11 個全比對成功 | 初步可用；分母 11 偏小，還不算穩 |
| 大 PR 強制分批審 | 試用期達到門檻的 PR = 0 個 | 一次都沒觸發 | 完全沒驗到（不是沒用，是沒碰到夠大的 PR） |
真正讓我決定留下的，是另外兩件事
原本我想把「偷來的版本」和「原版」並排跑、比比看誰好。但 16 天下來，同一個改動兩版都跑的次數是 0，並排太麻煩，我自己都忘記要做。所以「偷來的版本比較好」這個假設，其實沒真正被驗證過。這點要老實講。
最後讓我決定把這兩個機制併進原版的，是另外兩件事。
一是分叉的副本會跟不上原版。我 fork 出來的這 16 天，原版自己加了 4 個新功能，我的副本一個都沒同步。整包換掉等於把這 4 個新功能退回去，所以正確做法是把更新嵌進原版，不是整包取代。
二是這兩個機制本身是確定性邏輯，不靠 AI，站得住，不需要並排對比也成立。
所以這次「偷確定性層」成功了，但「並排驗證」沒做成。兩件事分清楚：我不能說「試用證明了偷來的更好」，只能說「機制合理、值得併進去」。連自己偷東西的驗證都要老實標分母，這正好是我在講的事。
brooks-lint，本體我用不上，但詞彙帶得走
hyhmrright/brooks-lint（1,144 顆星，2026-06-24 核）把 12 本經典工程書編成 code review 範本，每條發現都走「症狀 → 書本出處 → 後果 → 解法」的格式。
它最響亮的數字是「94% vs 16%」。但這數字量的是「輸出有沒有守住那個格式」，不是「找 bug 有多準」，作者自己也這樣說。而且數字背後沒給樣本量和量法，只能當格式一致性的參考，不能推成「裝了更會抓 bug」。漂亮的百分比沒有分母，就不能拿來推結論。
三題篩它，第一題就否決：純提示詞，品質等於模型，確定性層薄到幾乎沒有。我的 code review 流程已經是更完整的設定，本體對我沒有加分。
但它身上還是有一樣東西帶得走：把書本出處剝掉之後，剩下的純詞彙。像是「一個函式扛太多事」「同一個改動散在十幾個地方」「模組太愛伸手碰別人的資料」這類程式碼變爛的典型模式。這 6 個詞彙我已經嵌進自己最常用的 reviewer 裡了。
詞彙要放進真的會被呼叫的地方
這裡有個反直覺的點。我有 4 個 reviewer，去翻六週的使用紀錄（2026-06-09 的快照），看它們各自被實際呼叫幾次：
| reviewer | 被呼叫的次數 |
|---|---|
| code reviewer | 88 |
| TypeScript reviewer | 41 |
| architecture reviewer | 2 |
| TDD reviewer | 0 |
對比一下，我平常派工最兇的通用 agent 是 875 次。
brooks-lint 還有另外 6 個「測試變爛」的詞彙，概念上最對應的就是那個 TDD reviewer。但它被呼叫 0 次。把詞彙放進一個從沒被用到的 reviewer，等於放著沒人用，所以我刻意不放。詞彙要放進真的會被呼叫的高頻路徑，才會真的發揮作用。「概念對應」不等於「真的會被用到」，這正是我把詞彙放進 88 次那個、而不放進 0 次那個的依據。
last30days，這次帶走的是一個想法
mvanhorn/last30days-skill（46,293 顆星，2026-06-24 核）打一個指令，就跨 Reddit、X、YouTube、HN 等 12 個來源，平行搜某個主題近 30 天的內容。
對我每天的摘要工作來說，它沒有加分：我固定的來源全撈、排程推送、再合成加查證，這套已經是更完整的版本。
但它補上了一個我還沒有工具的場景：開會前臨時想查某個人或某個產品，跨平台掃一遍最近的動態。所以我對它是條件採用，不是全盤否決。這個場景一週出現幾次才值得裝，一個月不到一次就記住有這工具、用到再說。
它身上值得記下來的，是一個設計想法：它會先解析「這個主題要去哪幾個平台、搜什麼字」，再開始搜。我的來源是事先固定好的，用不到這個動態規劃。但哪天我想做「指定主題、臨時決定去哪搜」，這個想法有參考價值。帶走的是概念，不是裝本體。
確定性層永遠帶得走
三個案例擺一起：
| 案例 | 確定性層有多豐富 | 帶走什麼 | 實作了嗎 |
|---|---|---|---|
| ocr | 最豐富（完整工程） | 覆蓋保證 + 行號定位 | 已嵌進 code review 流程 |
| brooks-lint | 幾乎沒有（純提示詞） | 6 個變爛模式的詞彙 | 已嵌進常用 reviewer |
| last30days | 一個設計想法 | 「先解析再開始搜」的概念 | 記下來，還沒做 |
確定性層帶得走的根本原因：它不靠 AI、不用登入、不綁環境，純粹是資料和規則。帶不走的是整包綁死 AI 判斷的本體；完全偷不到的是「搭訂閱」這件事，那在伺服器那端就擋住了。
所以下次遇到三題都過不了的工具，與其可惜「不能裝」，不如多問一句：它身上不靠 AI 的那一層是什麼、有多豐富、我的工具缺不缺這個。多半都能帶走一點什麼。
這篇是上一篇談採用率的自然接續：把「老實看數字」這套紀律放到評估工具上，連偷來的那一層，分母也要標得清清楚楚。