昨天我家伺服器壞掉，原本用 No Code 工具搞的旅遊機器人就不能用。

剛剛認命乖乖寫程式處理，在想命名時發現 Gemini 2.5 Pro 竟然會講台語

剛下飛機一個多小時我家的網路疑似死光，所以我家到底怎麼了 🤔

以前會覺得區分這麼細實作功能不是很方便，但知道原理跟習慣之後，就會發現這類技巧一定程度上可以幫助我們在調整或者改寫功能時省下非常多時間。

gRPC Server 實作 - Clean Architecture in Go

不知不覺這系列也差不多到了一半左右進度，原本的 REST API 基礎功能已經完成，接下來就可以從加入像是 gRPC 和資料庫來看到 Clean Architecture 整理過後，能更好擴充的特性。

gRPC Server 準備 - Clean Architecture in Go

之前一直猶豫要不要寫，最近算是有一個相對完整的心得就寫了一篇來討論以專業工程師的角度會怎麼看這件事情。

如果以更高層次的角度思考，大概是「知識」已經變成可以規模化的東西，但我們怎麼運用跟維護會是個挑戰，例如我雇用了 10 個頂尖工程師，但我的管理超爛的只能發揮 1 個普通工程師的效果，用 AI 大概也是一樣 XD

身為工程師，我在 2025 年如何用 AI 寫程式

這系列差不多半年前寫，到現在就從「怎麼寫」變成「如何讓 AI 寫出來」的差異，不過深入思考中間的不同，本質還是出自於知道有這樣的應用方式，並且明確的告訴 AI 我想要有這樣的機制，以及要用怎樣的方式實現。

Token 內容加密 - Clean Architecture in Go

最近在測試 AI 協作開發時，不時會覺得如果開發的規範夠明確，在 AI 進行處理的時候也會比較準確，那麼許多實作跟設計的方式就不能靠經驗，而是要有系統的紀錄跟建構。

在 Lookup Order 實作 Token 機制 - Clean Architecture in G...

當初在該把 Tokenization 設計成商業邏輯一部分，還是在底層作為細節，最後是選擇明確地將這個流程呈現出來，從另一個角度去思考，也可能會判斷這是一種設計的細節而不這樣實作，這大概是軟體開發有趣的一個地方。

在 Place Order 實作 Token 機制 - Clean Architecture in Go

寫這篇文章時剛好遇到工作上在處理個資保護問題，現在回來看這篇覺得可能還有其他做法可以選。以最近的經驗來舉例，可能會在思考 Tokenization 的處理是具體流程還是實作細節，再去判斷怎麼設計。

Tokenization 機制設計 - Clean Architecture in Go

Place Order 做完後，就可以來實作 Lookup Order，這樣後續測試也就比較能做更完善驗證行為。

另外，最近開始實驗使用 AI 輔助開發能做到哪些事情，這類實作未來很高機率可以交給 AI 處理，但我們仍需要有對應的知識去檢查成果是否符合預期。

Lookup Order 功能 - Clean Architecture in Go