資料夾導覽 · 三層記憶 × 四層防線
分工不是「AI負責寫、我負責看」，是AI產出、我設閘門與決策，閘門的正確歸宿不是文件裡的一條規則 —— 是一支會擋下來的機器檢查。
01 — 全景
上半是三層記憶（解決「agent 每次開新對話就失憶」）， 下半是三個迴圈與四層防線（解決「它產出之後，誰來證明那是對的」）。 兩者由第三個迴圈接起來：每一次事故的產出，是記憶層裡多出來的一條規則、或多出來的一支機器檢查。
02 — 這個資料夾長什麼樣
正文回答「為什麼這樣設計」，templates/ 給你可直接複製的骨架，
prompts/ 給你可直接貼的指令。只有 30 分鐘的話：讀
README 的〈三個核心概念〉→ 跳到 07 的「第 1 天」。
依序讀。每一章都可以單獨讀懂，但 01 先讀比較省力。
精簡到能立刻用的版本。角括號 <...> 是要你填的地方。
整段複製就能用。只做得了一件的話，做 03。
03 — 為什麼規則要往下推
直覺會說「規則寫清楚一點就好了」。但規則正文是每一次對話都要付的成本， 而且它擋不住復發。
| 層 | 誰執行 | 每次對話的成本 | 忘得掉嗎 | 所以它該放什麼 |
|---|---|---|---|---|
| hook | 執行環境 | 0（不觸發等於不存在） | 不會 | 指令樣式、檔案事件、時間 |
| 守衛腳本 | 我，提交前 | 1 行（原始碼不進上下文） | 會忘記跑 | 「做完了也不會知道出錯」的事 |
| 規則正文 | AI，每次被動載入 | 行數 × 每一次對話 | 非常容易 | 只有機器接不住、必須靠判斷的 |
| 事故記錄 | 需要時才讀 | 0 | — | 症狀、結構性根因、現在誰接住它 |
可指認的反證：某條規則白紙黑字寫在規則檔裡，還是連續發作三次。 三次都不是不知道規則 —— 自動載入 ≠ 自動遵守。一條規則躺在 700 行裡，注意力份額趨近於零。 ⇒ 判準：同一條規則被違反第二次，就不要再改規則的寫法了，去問「機器怎麼接住它」。
04 — 踩到之後怎麼辦
那句話不可證偽，所以它擋不住第二次。要問的是結構原因： 為什麼這個系統讓人容易犯這個錯。然後由上往下分流，接不住才往下掉一層。
接得住 · 第一順位
指令樣式／檔案事件／時間
變成一條 hook。由執行環境跑，你想忘也忘不掉，不觸發時零成本。
必附反向案例
接得住 · 第二順位
「做完了也不會知道出錯」
變成一支 守衛。它的 PASS 必須附覆蓋率數字 —— 沒有數字的 PASS 只是「沒去看」。
必配一支故障演練
接不住
只能靠判斷的
才留在 規則正文裡。壓縮成「判準句 ＋ 一行指標」，全文放別的地方。
最貴，所以最後才考慮
誠實記著
沒有人接得住
例如「需求本身就錯」。照實寫「沒有人」，不要硬塞一個接不住的守衛進去。
假的答案＝下一次事故的形狀
誤報比漏報更危險。誤報會讓人乾脆把守衛關掉，然後你連漏報都不會知道。 真實案例：一條規則的正則寫得太粗，連續誤報六次 —— 它擋掉了偵測器自己的程式碼，也擋掉了正在解釋這條規則的文件。 ⇒ 判準：偵測「值」，不要偵測「描述值的樣式」。
05 — 怎麼開始
它長成現在這樣，是因為那個專案踩了 17 次特定的坑。你的坑不一樣， 所以你的 hook 和守衛也應該不一樣。可以直接拿走的是三個結構： 三層記憶的分工、四層成本結構、教訓迴圈。
06 — 誠實邊界
先講，比被發現好。