昨天畫了三條 AI 不能越過的線，其中兩條由 hook 守住，AI 繞不過。

因為有了 SKILL 這個助力，規則寫在文件裡，但現實是 我完全不知道 AI 有沒有 100% 遵守。

所以我想要把明確固定規則、擁有較主觀思維規則 進行拆分

第一種：腳本檢查

腳本檢查的價值在於穩定，而且不用燒 token。

這兩點是非常非常之重要啊！！！

• 穩定：人 review 第一份很仔細，第八份就開始滑。腳本掃第八十份跟第一份完全一樣。
• 不燒 token：這類規則不需要理解語意，一段普通程式碼就查得出來。同樣的事讓 AI 判斷一遍，每次都要花 token，還不保證結果一樣。

ex.

• 檢查固定 Coding style：大小駝峰、順序、專案參數、架構位置
• 檢查是否有測試報告
• 檢查 Test Case 格式：符合 markdown 格式、步驟預期結果不空值、按照 1/2/3 ... 進行步驟排序
• ...等等

第二種：派 AI Review

通常是「該不該抽共用」「是不是過度設計複雜」這類問題。

但想必大家用 AI Code Review 這件事情早就已經有使用過了吧！

不過我們要做的是一個 「獨立」的 agent 把要審查的要點、規則都放進去

建議也可以再寫讓 AI 扮演唱反調的角色去 Review。

核心只有一件事：它必須是 「獨立、乾淨」。

因為如果直接問剛剛跟你工作的那個 AI「你剛剛做得對嗎」，它通常高機率會說對並附和你的做法跟觀點。
因為它繼承了整段對話的所有前提，包括你們一起踩過的地雷和你的種種習慣。

所以要派一個沒看過這段對話的新 agent，只給它「這次的改動」跟「規範」，讓它從頭重新看一次。

流程其實也很單純：

我的程式碼 → AI Reviewer → 達成共識 → 交給人拍板

但要記住，AI 也不是永遠都對，在前幾篇文章應該充分說明這件事情

所以備注寫「唱反調的 AI」價值不在於對錯，在於可能會問出我沒想到的情況。

畢竟開發最常遇到的就是「當下我覺得這樣寫肯定沒問題」XDDD

兩層加起來，省的是什麼

• 腳本檢查：省的是成本，寫一次，之後零成本。

• AI Reviewer ：省的是人為時間 以及 找出隱藏的漏洞 的價值

不過這兩層都不是為了取代人為 Code Review 哦！只是把 Review 的入口守住

把一看就知道不該過的東西先擋掉，讓真正需要人看的東西才走到人面前。

簡單說就是分層測試：

• 單元測試擋基本錯誤
• 整合測試擋串接問題
• 最後才輪到人做探索性測試、更高維度團隊架構設計等等。