積沙成塔，滴水穿石

 由於公司用的是Laravel 10版，以框架新增的方式做新增刪修改DDL，那目前有個麻煩之處是 不知道哪個檔案執行過、哪些檔案只在哪個prod 執行、檔案散亂。 於是我就做了一個migration版本 的work Queue。 N個migration.php > 集合在 migration-sites.php > 再做內容的篩檢、正確性 > 登記在 待執行清單 list，由於順序性很重要就是FIFO 先進先出。 做事方式: 零散 > 集中整理 > 篩檢 > 登記清單 > 部署。

進公司一陣子之後，近期幫公司推動的是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」，而是：沒有人真的「驗證現實」

 最近設計了以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 有自己的實驗室，不用擔心互相影響， 只需存新工作目錄的檔案，不需...

 剛好拿到了新的model - MIMO v2.5 PRO 在試用，就用它做一個小產品observability-tool。 observability-tool 觀測 ------------------------------------------////**題目要求**///---------------------------------- 以下 請使用環境為 php 7.2.34 composer 1.10.15 Project - Server ∙ 功能 1 ： 設定 webhook /setWebhook?url=${url} ∙ 功能 2 ： 每 1-15( 隨機 ) 秒傳送一筆訊息訊息內容為 {"text": "Something is wrong", "env": "A1"} ∙ 功能 3 ： 設定功能 2 觸發測試 /setTesting?test=true ， 此設定會將秒數固定為 7 秒、設定為 false 則取消固定 7 秒 ∙ 功能 4 ： 功能 2 中的 env 共有三種 A1, A2, A3 頻率不可相同 ， 若遇隨機相同時可忽略 Project – Client ( 設定為 Server Webhook 對象 ) ∙ 功能 1 ： 以 env 為單位 ， 若 7 秒 ( 包含 7 秒 ) 內收到 {"text": "Something is wrong", "env": "A1"} 連續 5 分鐘後收取將跳出一個 Telegram 通知 ， 通知須顯示時間、 Env 、 text ∙ 功能 2 ： 根據功能 1 需具有插隊功能範例 :{"text": "Something is wrong", "time": "2025-12-31 23:59:59"} 。若插隊導致可觸發功能 1 時後續皆會觸發 ∙ 功能3 ： 需具有頁面查詢所有request並且查詢內容及時間 <備註> for Project – Client 功能1 -Tel...

問題 1：Channel denied access based on given capability 現象：Ably 訂閱被拒絕，401 錯誤。 根本原因：Channel 命名格式錯誤。 ❌ 錯誤：env-{env_id}   → capability: env-* ✅ 正確：env:{env_id}   → capability: env:* Ably 的 wildcard capability 只支援冒號分隔，env-* 是非法格式，Ably 伺服器無法匹配，每個訂閱都被拒絕。 解法：把所有 channel 命名和 capability 從 - 改成 :。 問題 2：PHP SDK v1 createTokenRequest + JS SDK v2 不相容 現象：Token 格式問題，authCallback 各種嘗試都失敗。 根本原因：JS SDK v2 移除了 callback-based API，authCallback(tokenParams, callback) 的 callback 方式在 v2 已不支援，必須用 Promise 或 authUrl。 解法：改用 authUrl 方式讓 Ably SDK 自己打後端取 Token，繞過 callback 格式問題。 問題 3：authUrl 打後端時沒有帶 X-UI-Key header 現象：authUrl 設定了 authHeaders，但 Ably SDK 不保證每次都帶，導致後端 401。 解法：把 /api/ably-token 從 UI_KEY 驗證中移除，TokenRequest 本身有 HMAC 簽名保護，就算公開也只能 subscribe，不能 publish。 問題 4：requestToken vs createTokenRequest 現象：試用 PHP requestToken 產生 TokenDetails，Ably REST 回 201 但 JS SDK 還是連不上。 根本原因：PHP SDK v1.1 的 requestToken 產生的 TokenDetails 格式，JS SDK v2 無法直接使用。 解法：改回 createTokenRequest（產生 TokenRequest），讓 Ably SDK 自己去換 Toke...

我用了一個新專案，用xiaomi mimo-v2.5-pro 來開始專案。 就做了一個簡易的cmd 介面: 百萬億申請token 過了之後，用的是tp- 開頭的金鑰，api 後台:  https://platform.xiaomimimo.com/console/plan-manage 之前有用到sk，那個就是要費用的，那百萬億計畫token 用的是tp   目前用下來~~ 還算很順，很快😄 用roo 的方式 ，很快。roo 的麻煩是 有的時候 聊天室窗的對話模式 會多開視窗混淆。 多開視窗 同時間 code、architect 的時候，另一邊就有可能產生卡點。 使用roo +MiMo  ，再讓他調取 mimo-cli 他會等cli 執行完 才會繼續進行任務，無法在使用roo 中 做平行 ---- 用了MiMo  5hr 之後 發現他的效能比意外還要好。 目前用了codex，要用0.80 版

今天有人和我提了一下ulimit，做一下卡片式的筆記。   https://q248269673.pixnet.net/blog/posts/12066596238 https://www.mongodb.com/zh-cn/docs/v8.0/reference/ulimit/ https://www.runoob.com/linux/linux-comm-ulimit.html

當地端的LLM 越來越多，就可分配更多不同的任務，要注意的是 手機 ≠ server node。 然而手機會越來越多，那就做一個類似k8s的概念平台吧，透過一個平台來管理。(架構圖)  Edge AI Orchestrator (架構圖) -------- 實際運作： (未完待續...) --------- 注意事項: 手機 ≠ server node : sleep / suspend thermal throttling network jump (WiFi → 4G) background kill

由於有多的手機，也沒有再用，所以就直接把它當小型地端來跑，那這一台是「華為 -ele29 」。 網路就是在同一個網路，家中 wifi，同個網路 。 這次直接走adb 的方式，也不用Termux。使用 Termux要做的事情太多了，既然都走TCP 連線 ，就可直接用adb 了，本質上就是 scoket  連線 scoket 。(流程圖) 流程圖  ----------- 正文開始 1. 透過adb push llama-cli (圖1) 2. 透過adb push qwen2.5-3b 透過 adb push llama-cli (圖1) 3.  確定要對聯的 tcp 有沒有被佔線。有佔線就kill 。前置作業執行完成後 就可TCP連線了(圖2)。 透過 adb tcp 互聯 (圖2) 4. 看一下 localhost:8080 有沒有成功出現，裝在手機的 qwen2.5 -3b (圖3) localhost:8080 顯示 qwen2.5 (圖3) 5. 寫的test，從master 發測試指令(圖4) 從master 發測試指令 到 p30 (圖4) 執行成果: 

 最近做了google bloger 的 CTA 工具，可以針對文章一鍵編排成html 排版，google bloger html有自己的特定格式，所以在寫html 的scope要寫好，避免bloger 外殼樣式 影響到 內文樣式，內文樣式影響到 外殼樣式、內文的html 一律加 前墜 ${_prefix} ，界定範圍。 換成 wordpress 也是一樣。 ---------- - **外 → 內**：Blogger 主題的 `.post-body a`、`li`、`h2` 等樣式不得影響 landing page - **內 → 外**：landing page 的 CSS 不得外溢影響 Blogger 其他區塊（sidebar、header、其他文章） 關於排版CTA的小工具，我寫了2個版本比較使用差異(圖1)：手動貼prompt  (圖2) 、 背景自動帶prompt (圖3)、 。 2個版本比較使用差異(圖1) 手動貼prompt 手動貼prompt (圖2) 背景自動帶prompt 背景自動帶prompt (圖2) 我用了一些不同openAI  開源的模型 來比較(強弱)， 發現「手動貼prompt 」給openAI 的方式效果回傳的html 比較好。 現在這樣滿方便的 :D  至少不用寫完文章後，於 AI 下prompt 產html ，來回一直改。 可直接一鍵產生了

 由於垂直技能有些薄弱，於是每天要做的事就是強化自我，不是在於工具而是在於底層的馬步有沒有扎穩。 前一陣子先是看了k8s、這一陣子又再重新翻了Linux 、網路七層、nginx， 真的覺得很好玩。 Nginx 的 LB 、HA ，這些在k8s 都有借鑒到相關概念。 義父：專注，把一樣事情做到極致。沉澱才能淬鍊出重量。

💬 Mini Talk 影片 🌐 任意網頁可用 🤖 多 AI Provider 🔧 Tool Use 支援 任何網頁， 隨時問 AI 不用切換分頁 在任意網站叫出懸浮聊天室，支援 Gemini、Claude、OpenRouter，30 秒安裝即用 查看影片 3+ AI Provider 支援 30s 從安裝到對話 ∞ 支援網站數量 實際操作示範 看看 Mini Talk 在真實網頁上怎麼用 © 2026 Mini Talk · Blogger Prompt Helper 工具集 · 以 Tampermonkey UserScript 驅動

AI Google Blogger 排版小工具 使用者目標 痛點 前後對比 使用步驟 AI 自動產生 Blogger 排版 讓寫作更輕鬆 新增bloger 方便的小工具，AI 小工具自動產生。讓簡單的散文、文章，整理成有重點和漂亮排版的工具 查看成果 ≤ 3min 完成一篇文章排版 90% 使用者滿意度 50% 時間節省 使用者目標 身為 Blogger 使用者，我想在不用複雜後台操作下，快速生成美觀的排版，以便專注於內容創作。 「以前手動調整 HTML/CSS 要花費大量時間，現在使用這個工具，3 分鐘內就能完成排版，讓我能更專注在寫作上。」 ✓ 使用者能在 3 分鐘內完成一篇文章的排版 ✓ 90% 的使用者表示排版效果符合預期 ✓ 減少 50% 的排版時間 你是否也遇過這些困境？ 這些日常痛點，正在悄悄吃掉你的寫作效率。 ⏳ 排版耗時 手動調整 HTML/CSS 費時費力，一篇文章的排版可能要花上數小時。 🎨 樣式不...