鳥毅的Blog

今天幫同事把 他用到的最短路徑套件修復多執行緒問題，原本是 .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達成。