昨天寫了三個我踩過的坑。今天先交代一下，我現在到底在用什麼，不然後面一直出現 agent、review、issue、知識庫，很容易看不懂它們之間的關係。

這套東西不是我一開始就設計好的。最早只是讓 AI 幫我做教材和一些校務工具。東西越做越多，我開始遇到同樣的問題：這次改過的規則，下次換一個 AI 就不知道；一個 agent 說完成了，我也不知道該去哪裡確認；幾個 session 同時工作時，還可能做到同一件事。

我遇到一個問題，就補一個東西。補到現在，大致可以分成五個部分。

我每天會碰到的五個部分

第一個是知識庫。我把開發規則、做過的決定和踩坑紀錄放在裡面。開始改東西以前，agent 應該先查這裡，避免每次都從零開始，也避免已經做過的決定過幾天又重新討論。

第二個是 coding agent，也就是實際改程式的 AI。我目前會用 Claude Code、Codex、Cursor 和 Grok。它們能力和習慣不太一樣，但讀的是同一套基本規則。

我不是工程師，不可能只靠閱讀每一段程式碼來確認它們有沒有改對。這也是我後來一直補驗收、review 和紀錄的原因。這些工具除了幫我做事，也要讓我看得懂目前做到哪裡，以及它們用什麼方式證明結果可以使用。

第三個是 review。我會讓另一個 agent 檢查這次修改，找出測試沒涵蓋的地方、前後矛盾的規則，或我和 coding agent 都沒想到的風險。後面有六天會專門寫這個部分。

第四個是工作帳本。它記錄哪個 agent 正在做什麼、做到哪裡，以及下一步是什麼。我曾經讓兩個 session 接到同一份工作，兩邊都做完後才發現互相蓋到檔案。工作帳本就是在那次之後慢慢做出來的。

第五個是 GitHub。程式碼、issue、PR、commit 和檢查結果最後都留在這裡。知識庫可以記我事後怎麼理解一件事，GitHub 則保留當時實際發生的紀錄。

2026 年 9 月 10 日盤點時，跟這套系統直接相關的三個主要 repo，合計有 557 張 issue 和 575 個 PR；知識庫裡約有 1150 篇筆記。這些數字只能說明東西已經累積不少，不能用來判斷系統是不是可靠。

實際工作時怎麼串起來

理想的流程是：agent 先從知識庫取得背景，把需求整理成有驗收條件的 issue，再開始改程式。改完後交給另一個 agent review，通過測試才合併，最後把這次的新發現寫回知識庫。

我現在確實有在使用這些部分，但還不能說整條流程已經完全自動化。

負責觀測的 agent 還需要我在 Discord 上叫它，它不會自己定期醒來。知識庫的其中一套檢索工具，目前主要跑本機測試資料，還沒有接到正式環境。最重要的是，我還沒有做完一次範圍明確、從開工一路驗證到實際運作的端到端測試。

所以後面的文章會分開寫「規則已經訂了」、「工具已經裝了」和「我真的跑過並拿到證據」這三種狀態。它們不是同一件事。我自己整理這個系列時，也曾經把設計完成寫得像已經完整運作，回頭對照紀錄才改回來。

這也是我想留下文章和證據的原因。我不想只展示最後畫好的架構圖。我會把哪些地方已經能用、哪些地方仍靠人工，以及哪些問題到現在沒有答案，一起留下來。

明天

明天會寫一個目前還沒解決的問題：規則要求 CI 通過，但放置規則的其中一個 repo 根本沒有 CI。