積沙成塔，滴水穿石

  讓 AI 從自己的錯誤中學習——一個保守但可信的記憶系統 你有沒有想過： AI 助理做錯了事、改了又改、最後終於解決問題——這個過程，能不能被「記住」，讓下次遇到類似狀況時直接用上？ 這正是我們在設計的系統想解決的問題。 問題從哪裡來？ 現在的 AI 助理（例如 Claude、GPT）每次對話都是全新的開始。它不記得上次踩過什麼坑、哪個做法最後有效。每次都得重新試錯，效率很低。 但「讓 AI 記憶所有東西」又太危險——它可能記到錯的東西，甚至把偶然成功的歪路當成正確方法。 所以我們的核心問題是： 怎麼讓 AI 只記住真正有用、可信的經驗？ 兩種層次：「看到了什麼」vs「學到了什麼」 我們把記憶分成兩個層次，這是整個設計的核心： 第一層：Observation（觀察） 「發生了什麼事。」 系統掃描 AI 的工作日誌，找出以下訊號： 工具執行失敗 同一個檔案被反覆修改 某個問題一直沒被解決 這些通通記下來，但 不做任何判斷、也不告訴下一次的 AI 。觀察只是原始素材。 第二層：Experience（經驗） 「什麼做法有效。」 Experience 要嚴格得多。它必須滿足： 有一個清楚的「失敗 → 修改 → 成功」的流程 修改的內容和失敗的原因 語意上有關聯 （不只是時間上緊接著） 不是純粹靠重試、也不是環境自己好轉 只有這樣的 Experience，未來才能在適當時機告訴 AI：「上次在類似情況下，這個方法有效。」 為什麼這樣設計？三個關鍵原則 1. 寧缺勿濫 有些「成功」其實是運氣：重試了幾次、伺服器剛好恢復、換了個環境。這種成功如果被記成經驗，下次 AI 就會學到錯誤的教訓。 所以我們設了嚴格門檻： 只有「確認語意相關」的修復，才算真正的學習。 2. 原始資料不動 AI 的工作日誌（JSONL 檔）是唯讀的。系統只讀取、不回寫，確保每次分析的基礎永遠可靠。 3. Shadow Mode 啟動 初期系統在背景靜默運作——只建立觀察和候選經驗， 暫時不影響任何對話 。等系統夠成熟、累積夠多可信證據，才開始把高品質的經驗「注入」給下一次的 AI。 一個比喻：老醫師的病歷系統 想像一位醫師，每次看診都把情況記在病歷上（Observation）。但不是每個記錄都會變成「臨床建議」——只有當他確認： 某個症狀、某個用藥、某個結果 之間有明確因果關係時，才會整理成下次...

  AI 策略分析

 自從開始在教小朋友後，成為老師這個腳色也是一種學習。 如何與他們相處、如何和他們有話題、如何破冰、在他們身上會看到自我的反射。 你的一舉一動、你說出來的話，會戴上了放大鏡。 我也很常叫錯學生的名字，發生一些笑話。 有堂課有位同學在拆解積木的時候，會亂丟甚至會亂甩 我：「瑞宇，這樣的行為很危險，不能這樣做，東西要好好放，如果掉到地上，你不小心踩到，滑倒是會受傷的！」 學生：「老師，我不是瑞宇，我是瑞凡」 我：「😂😂 拍謝，可是瑞凡~我回不去了」 帶小朋友很開心也很快樂，也同樣是學習相處之道，如何說話讓小朋友聽得懂，不是一直說不行，而是要讓對方明白這樣做的處境+後果

Risk Engine 概念（核心定義） Risk Engine = 一個把「AI 的可信度」從主觀語言，轉換成可驗證、可計算、可阻斷的決策系統 它不是模型，也不是 prompt，而是： 一個位於 AI Worker 與 Git / 系統執行之間的「信任閘門（Trust Gate）」 Risk Engine 的作用是： 把「AI 說它做了什麼」變成「系統驗證它做了什麼」，再決定要不要讓它進入 production。  AI Agent 系統的問題不是「會不會寫錯 code」，而是：沒有人真的「驗證現實」

 最近設計了以git worktree為基底的多工agent 合作的模式，git worktree 的概念讓每個branch 有自己的空間，不會互相汙染branch，在這樣的方式下每個agent 有自己的branch 可做事，不會互相汙染和複製多份共有的大型圖片，參考GIT LFS概念用硬連結的方式來做指向，在不同的worktree 能將大型資源指向master 的位置 。 我自己的個人習慣是多工agent 來進行開發，每個agent 都是一個小組長，agent 各有自己所屬的分支。 換句話說 各自agent 不打架。 master AI (claude)  > master  sub agent (codex)  > chore  sub agent (grok)  > fix   效果還不錯，再搭配agent branch 調度管理器 Dispatch的workflow ，能同時管理多分支狀況。 一開始約束規則沒寫好，每個agent 在更新git 有的時候會切錯worktree branch。 git branch 的保護守則要寫好 ，可用 branch rule先做一層防護 pre-push、pre-commit。 遵守 master 只做合，不做任何更新、異動commit，可以確保 master（或 main）分支始終保持乾淨、穩定，且直接對應到上線的程式碼。

Architecture · AI Agent · Git Worktree-based Runtime Orchestrator for Multi-Agent Development 當多個 AI Agent 同時在同一個 repository 開工，傳統的 git 分支切換模式開始崩潰。 這篇文章介紹一套以 Git Worktree 為核心的開發流調度規範——用三個平面解耦邏輯、資產與 Runtime， 讓每個 Agent 擁有獨立的物理工作空間，同時共享同一個執行環境。 🗂️ Git Worktree Architecture ⚡ Runtime Orchestration 🤖 Multi-Agent Dev 1. 問題是怎麼來的 當工作流開始用 worktree 做多工處理，在做 git 追蹤的時候，多工 agent 就會遇到 branch 環境污染的問題。 想像四個 Agent 同時在跑： A agent → fix/something_wrong B agent → chore/design_system C agent → feat/realtime-sync-design D agent → doc/readme 在同一個 workspace 做 git checkout ，就會造成環境混亂——AI 的路徑索引失效、任務互相干擾、 Docker 需要重啟。這就是 Git Worktree 派上用場的地方。 git worktree allows you to have multiple branches of the same repository checked out simultaneously in separate directories。 換句話說，每個 Agent 有自己的實驗室，不用擔心互相影響， 只需存新工作目錄的檔案，不需...