使用 Coding Agent 幫忙實作的好處在於不用花時間確認跟閱讀現有的程式碼，如果遇到不熟悉的功能也可以讓 AI 先實作看看

相對的，如果是在開發階段，對程式碼的熟悉度應該不用太多輔助才對，反而是沒寫過的部分幫助會比較大，但怎麼確保品質可能就變困難

購物車側欄 - Clean Architecture in TypeScript

寫這系列時大多還是先手寫一小部分再讓 AI 協助重構，後來使用 Claude Code 後嘗試了以 AI 為主的方式進行，卻發現越來越失控

最近又換回先手寫一部分後，再轉交給 AI 協助的做法，至少在現階段這樣比較能在品質跟速度達到平衡

對話 UseCase - Clean Architecture in TypeScript

AI SDK 算是 JS 生態系中整合 AI 最好用的選項，然而隨著 Gatweay 類型完整（如 LiteLLM、Cloudflare AI Gateway）並不一定要依賴套件來整合

目前新版的 AI SDK 也變成開發 Agent 為主的設計，大概會是近期許多套件的方向

整合大型語言模型 - Clean Architecture in TypeScript

這是我 #COSCUP 演講的內容延伸，原本的做法複雜不少，在評估過後認為從相對簡單的方式開始會比較容易，所以才有這篇文章

文章本身會專注在工具設計的前提和背後的理由，如果對工具有興趣或者測試可以點文章中的連結，目前還沒有展示影片可能有點難理解

也許你的 Claude Code 該檢查自己的實作

前幾個月 Claude Code 開始變很熱門時，我有想過讓完全讓 AI 來實作，最近還是覺得有一些地方由人類來實作會相對穩定不少，或者說某些部分會是「人類需要掌握」的就要評估是否該給 AI 處理

對話紀錄 UseCase - Clean Architecture in TypeScript

朋友剛剛貼這個，當年畢業繼續做是不是就會變成這樣



---

沒記錯當年也是想開放世界跟動作遊戲

批踢踢實業坊 - PlayStation

用一段時間 Claude Code 後，有時候還是會覺得 Aider 能限定編輯的檔案範圍比較穩定，至少不會有太多大量修改檔案的狀況，但這又限制了 AI 能理解的範圍，總覺得還差了一點什麼 🤔

對話紀錄 API - Clean Architecture in TypeScript

因為使用 JSX 風格（Hono JSX）的方式來實現 UI，因為 React 算是非常熱門的套件，訓練資料充足的狀況下這類基礎介面大多很容易能實現

唯一要注意的是 Hono JSX 不是完整的 React 使用一些套件可能會受限，而 AI 有可能會嘗試去使用

助手對話介面 - Clean Architecture in TypeScript

最近好像對某種行為特別敏感 XD
「因為在⋯⋯所以⋯⋯啊！」

覺得在一些人蠻容易不小心會這樣講（包括我自己）但這通常是讓人對（開源）專案參與失去熱情的一句話

這應該算是這幾年比較常用的做法，在規劃這系列的時候也在思考，如果要讓 AI 很好理解如何生成後續的內容，該怎麼做。

如果是比較簡單的方式，其實就是盡可能照常見的軟體開發理論實作，畢竟已經被當作訓練資料了 XD

架構規劃 - Clean Architecture in TypeScript