鳥毅的Blog

 有鑑於最近 AI 產生的詐騙 Email 越來越多，而且越來越像真的，所以我做詐騙信偵測程式 -- AntiPhishing ，同時提供 GUI 版本與 CLI 版本，AI偵測是加值功能，就算沒有AI也有基本防護。 程式在 Github 上，歡迎自行編譯，若需要Windows版 binary 也可以用 Release 裡的版本。 雲端 AI 用今年的Flash以上都夠，我用非常便宜的 MiniMax-M3 效果非常好；若有足夠 AI 算力可以直接用本機的 Qwen3.8 27B，我測試過 Gemma4 26B效果不夠好，希望 Google 明年能夠釋出超越千問的開放權重模型。 GUI版本內建設定功能，可以不需要手動編輯  config.toml ，不過仍然建議先使用 config.example.toml 複製為 config.toml，避免錯誤，畢竟我沒有花很多時間測試。 本詐騙信偵測程式可以設定自動過濾或逐一審核，我個人偏愛逐一觀看，因為公司的 Spam Filter 過濾掉 80% 的 Spam，剩下 20% 的靠 AI 過濾幾乎沒有漏網之魚。提供給有需要的朋友、長輩們。以 Apache授權放出，可商用，完全無限制，修改 Fork 都允許。 本文使用工人智慧摘寫，故完全不流暢，不吸引人，特此聲明。

 最近一陣子沒有更新 Blog，主因是沒有辦法在第一時間發出與眾不同的消息，畢竟不是靠炒知名度賺錢的網紅，有些業務相關的又不方便發表。另一點則是覺得AI文缺乏靈魂，自己寫的文章雖然粗鄙，卻有人味兒，所以要有時間再來寫點真實的感受。 話說公司的Jetson Thor相容機因為研華的 Firmware 與原廠不相容，所以我還不能使用多媒體功能，而 LLM 推論速度之前一直上不去，直到最近幾個月受到開放原始碼的進步，終於達到勉強可用的程度。而公司內部的產品則是使用 5090 在推論。 我測試上週出現的 Qwen 3.8 27b 以體感來說，能力相當 Claude Opus 4.6 的程度，用 5090跑的速度可接受，也可以達到  120 tokens/sec，不使用 Subagents 的話，地端 coding 完全沒問題，可以不靠雲端LLM也可以 happy coding。因為主要拿來開發公司的內部系統，就不方便貼圖，有興趣的人自己弄2張 3060 Ti 16GB 也有類似的效果。 目前我主要用 Jetson Thor 跑 Qwen 3.8 27b長時間 code review 與 refactoring ，因為速度太慢，即時coding則不建議用 Jetson Thor 或 DGX Spark，還是用 5090 比較合適。 逛Ollama 時看到  huihui_ai/Qwen3.8-abliterated  似乎很猛，於是拿來叫它分析一些平時會被阻擋的內容，例如 分析網路攻擊後的server log，或是反編譯 apk 之類的研究工作，也可以做寫點NSFW的小說，實在是太方便了。若不是現在 DGX Spark 漲到 17萬一臺實在買不下手（RTX 5090一張也漲到17萬），真想去買一臺在家跑 Qwen 3.8 27b + MiniMax H3 自己做些有趣的影片呀～  

今天幫同事把 他用到的最短路徑套件修復多執行緒問題，原本是 .net 4.0，我改成 .net 10，讓AI修復整個套件。  原本的 YanQi 演算法是用 Java 版改過來，.Net版 裡有 bug，所以後來我再去抓原始的 Java 程式，結果 Java 程式裡又是用別人的 Jar， 所以再去找原始 YanQi Jar 的原始碼來修。現在 AI 很強，直接找出他改錯的地方，再用其他方式修正原本 Dictionary 不是 Thread Safe 的問題。 原本的演算法及語法都修復，並且從 nUnit 改為 xUnit。 至於到底修了多少，請自行去看 git log。 https://github.com/tenyi/adapters-shortest-paths-dotnet

今天趁著連假，在家沒事就拿起 Macbook M1 Pro 16GB RAM的舊筆電，執行 ollama launch claude --model gemma4:e2b ，這樣的記憶體需求小，但為了怕 context 不足，在執行 Ollama 時要設定 OLLAMA_CONTEXT_LENGTH=65536 ，至少要設定 32768才足夠寫程式。 雖然筆電不快但是使用Gemma4最小的模型，能夠讓 Claude Code 自主使用 Rust 寫出Native GUI 的 貪食蛇，真不是普通的強。有興趣的朋友，可以在有8GB 以上VRAM的顯卡試試，這代表著地端Coding時代到了！ 以我的 Macbook 16GB 為例，執行 Gemma4:e4b 沒有壓力，效果比e2b更好一些。 無論使用何種模型， 想要LLM Coding效果好必須要留足夠的RAM給作業系統與Context，Happy Coding！ 後記：看到 Agentic Coding 基準測試 排行，可證明我說的沒錯，Gemma4相當能打，在Jetson Thor上跑Gemma4-31B就是地端的首選。若使用5090搭配Gemma4，我會選擇26B模型，把 Context盡可能拉大，這樣才會跑得順。

很多人可能不太懂，為什麼我老是強調 AI 模型的「指令遵循性」（Instruction Following）有多重要。昨天剛好發生了一件血淋淋的慘案，決定寫下來作為證明。

直接破題，若已經使用Gemini CLI建立 memory 的話，至少幾千個，我建立不少 rules，再加上 MCP Server，所以花了一萬八千多個 tokens，有圖有真相。

 最近在試著用 LLM 做一些事情，希望能夠做一些原本是人在處理的事情，發現LLM的智力差別很大。

 今天看到 Rails 大師 DHH 的一篇文章 Coding should be a vibe!  ，Google 翻譯得不夠好，因此請 Gemini 幫忙翻成更像 Coding 大師的語氣，看起來多了幾分人味。

 在軟體開發的世界裡，「技術債」（Technical Debt）是一個令人頭痛卻又無處不在的議題。它像是看不見的成本，起初微不足道，隨著時間推移卻可能累積成巨大的負擔，拖慢開發速度、增加維護成本，甚至導致專案失敗。傳統開發模式下，技術債往往因時程壓力、需求變動、或缺乏完善規劃而悄悄積累。 然而，隨著人工智慧（AI）在程式開發領域扮演的角色日益重要，一種新的開發思維正在浮現——我們稱之為「AI Vibe Coding」。這不僅僅是讓AI自動寫程式碼，更是一種以「規劃先行，協同創造」為核心的方法論。本文旨在探討，如何透過嚴謹的產品需求文件（PRD）作為地基，結合與AI的深度協作（AI Vibe Coding），有效避免技術債的產生，打造功能完善且易於理解的程式碼。

 最近有個很紅的AI編程工具，叫 TRAE ，用 VS Code 源碼改出來的，把它想成類似  Cursor  或  Windsurf  就對了。

 這兩年 AI 的進步實在太快，想寫些什麼又怕誤人子弟。但一直拖著沒寫又怪怪的，就寫點心得吧。

 昨天試本地 AI 小模型翻譯後，今天聽到朋友說他覺得 Gemini 的文法比較好，所以就拿 Gemma 2來試看看。 模型改用 gemma2:latest 後，翻譯效果比 llama3.1:latest好，有興趣的朋友可以看看，若有更好用的小模型也請各方高手留言。

 最近在上一門線上課程，該課程有提供英文字幕檔，所以我就寫一個簡單的Python程式將該文字檔利用 Google Translate API 翻譯成中文。但是因為在下是免費黨，希望在自己的電腦就能提供還可以的翻譯，不要把Google 的免費額度用光，非必要的翻譯使用本地LLM達成。

 最近幾週發現家中的光世代會瞬斷，最長不到3分鐘，最短2秒就回復，通常1~2小時才斷一次，很難發現。找了市面上的監控程式沒有符合需求的，所以就叫LLM來寫。 我使用免費的Gemini和ChatGPT 4o來做，比較後Gemini的程式比較好，所以僅摘錄Gemini產生的回應。以下是我下的Prompt： 我的網路偶爾會中斷幾秒又恢復，需要紀錄斷線時間，你寫一個監控程式給我。   上圖是Gemini產生的程式，已經可以顯示目前網路狀態。但這是不夠的，所以我再下指令。 幫我把日期時間格式改為 yyyy/MM/dd HH:mm:ss 看起來舒服多了，但要的是記錄，所以得儲存到檔案。於是再下 Prompt： 請再增加斷線時，將斷線資訊另存一份到名為 network-down.txt 檔案 接下來就差不多完成了，我最後再下一次Prompt： 恢復連線與Offline時間的資訊，也請寫到 network-down.txt  這樣就收工，程式請自行產生，就不附在後面占篇幅，而且應該會寫得越來越好，敬請期待。其實我稍微有再花幾分鐘修改，這程式不太需要修改也能執行。唯一要注意的是它用 Linux / Mac 的ping呼叫方式，所以在 Windows 環境時建議使用 WSL 執行。 後記： 我執行此程式之後，就記錄約2小時斷一次，每次1~2秒，整晚有2次斷線2分鐘，若沒有程式記錄真是難以追查。種花在我報修後，隔天就來換光纖數據機，非常有效率。

因為Fyodor Yarochkin在SyScan提到Knowledge Machine，讓鳥毅回想起年少時學人工智慧的經驗，剛好最近沒啥主題寫Blog，就來簡單介紹一下目前已不受重視的 專家系統 。 Fyodor用的 KM 算是很簡單的RBES（Rule Based Expert system），leeym的指導教授謝尚賢在 這 有提到專家系統從RBES發展到CBES（Case Based Expert System）。CBES是以案例訓練的專家系統，"理論上"不用自己去找出法則，但實務上應該還是 類神經網路 （又稱人工神經網路）比較常見。類神經網路計算時，仍然要自己找出各種因子，以矩陣運算找出相關係數矩陣。 在台灣人工智慧/專家系統的書籍應該是葉怡成教授著作最多，印象中他擅長類神經網路。記得交大以前有個人工智慧實驗室，不過現在找不到了。 人工智慧最常用的程式語言應該就是LISP，現在應該是GNU CLISP 最常見，還有FSF之父RMS寫的 Emacs ，其他的請參考 這 。 Emacs 本身除了是編輯器外，也是LISP的interpreter，按ctrl-x ctrl-e就可以執行目前的LISP片段，在撰寫LISP時非常好用，初學LISP也不用裝 CLISP ，只要 Emacs 就足夠。據鳥毅所知淡江大學 王人牧 教授的LISP功力深厚。 另一個常見的人工智慧語言是Prolog，Prolog特別之處就是內建推論引擎，現在似乎是 SWI-Prolog 比較強，在下沒用過，請自己玩。 最後介紹一個真正有完整功能並Open Source的專家系統 CLIPS ， CLIPS 原本要研究單位或付費才能取得source code，現在改到sourceforge，成為NASA的public domain software。CLIPS也是採用LISP語法，本身有推論機。對CLIPS有興趣的朋友，可以與 王人牧 教授討論，他有好幾年的CLIPS開發經驗。