積沙成塔，滴水穿石

進公司一陣子之後，近期幫公司推動的是CICD、git flow開發流程。 長期下來這是有必要的，能讓開發流程更順、也能省下不少時間。公司是以main 做為開發分支但並沒有訂好開發流程，一個git commit 打片天下無敵手，這樣弊利於多。就我看到的現象「大致上很多改動都是以上傳FTP 為主、檔案在開發時互相蓋來蓋去，也很難找回覆蓋的部分。dev 分支有好幾個、開發的環境和dev無法對齊、main 隨時會因為一個git commit 爆、沒有PR 的習慣、沒有回朔版本」。 1. 訂下gitflow→ Trunk-Based Development  (TBD) 進來的時間就推動git flow 流程，定主線main 、 開發分支dev、branch 保護原則:main、dev，合併前都必須發PR、合併採merge squash。 到後期改採TBD( Trunk-Based Development )比較符合短快準的開發流程，啟因「git flow 流程上dev的某功能被同步於main佈署上去 但未完成測試 以至於 正是產品爆掉了」，所以後來改採 沒問題就正式放到main 、開發的副本 一率從main 切，減少開發分支不穩定。 2. 設定branch 保護的rulest 由於git commit，由於main 、dev 沒有保護 變成任一merge 都能改變main，main 的時間線會變得很亂，於是就加了rulest 保護原則。 3. CICD 自動佈署 DEV自動佈署到測試環境加速自動開發、MAIN 佈署到正式環境。 以往MAIN 佈署是由同事→組長→佈署更新正式。 現在是環境測完沒問題，同事→佈署更新正式，那git 上會自動留存一份佈署的PR紀錄、誰佈署了什麼功能都能追查、減少了組長的工作、同事的等待時間。 main 自動同步到 dev，能確保dev 與main 對齊。 發PR 會有說 目前是合到哪個分支的自動留言

前陣子有人跟我提了 openAB ，最大的特色是可以透過一個介面看到A agent 和 Bagent聊天，一樣的觀念，我自己就做了一個agent-room，想加多少agent 就可以持續聊天。 jsonl 記下了 多位agent 的對話。 在做問題討論的時候很有用，也能自己完成任務。 心得分享： 在做AI 持續對話 時，要設立 最多第幾輪對話停止、定義共識的默契、定義何時要停、定義 調配者(派工代理) 或 調配機制、AI 腳色的定位

  讓 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」，而是：沒有人真的「驗證現實」