鳥毅的Blog

 最近一陣子沒有更新 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

 最近在公司都使用 Gemma4 做為 地端的主要模型，但接 Claude Code 常出問題，在深入的 coding 後終於發現問題了。

今天趁著連假，在家沒事就拿起 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盡可能拉大，這樣才會跑得順。

直接破題，若已經使用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 的進步實在太快，想寫些什麼又怕誤人子弟。但一直拖著沒寫又怪怪的，就寫點心得吧。

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

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