搜尋

用 AI 快速調整實作跟重構還蠻方便的，這系列初期也有不少這樣使用的地方。目前的經驗上，大多數情境先從手寫開始，找出一些規律後慢慢讓 AI 加進去幫忙，通常都會比較穩定可控。側欄 Use Case - Clean Architecture in TypeScript

（廢文救卡馬？）最近在整理東西，簡單算了一下 GitHub 上 Contribution（Commit + PR 等等）和 WakaTime 總寫 Code 時數的比例2023 年約 3.x/hr2024 年約 6.x/hr2025 年月 8.x/hr這個變化蠻有趣的，因為 2024 年開始使用 Copilot 的補全，而 2025 年開始用 Coding Agent 輔助開發也就是說 Coding Agent 帶來的提升可能沒有一個好的 AI Completion 多，另外一年我大概只能達到 950 小時左右的寫程式時間，即使有 AI 也沒有變多或者變少

使用 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

昨晚看到 GPT-5 發布的消息，才想到要確認一下 GPT-OSS 的狀況，看完 Aider 的評測資料才發現 120b 有接近 Sonnet 3.5 的表現也就是說，這系列文章前半部使用 Aider 的部分應該都有機會用 GPT-OSS 實作出來，也許很快就不用能在本機用 AI 開發介面規劃 - Clean Architecture in TypeScript

tsyringe 是我在 TypeScript 最喜歡用的依賴注入選項，本身輕量也不複雜，在大部分的情境都可以輕鬆使用tsyringe 套件 - Clean Architecture in TypeScript

Hono 算是近期我很喜歡在 JavaScript 環境使用的框架，大部分的功能都很精簡，但已經足夠滿足需求，內建像是 RPC / JSX 等機制，幾乎可以在沒有外部依賴的前提下實作大部分簡單的應用Hono 框架 - Clean Architecture in TypeScript

這系列寫到一半 Claude Code 推出後，原本目標設定的「半自動」又更加接近全自動的狀態，在很多實作上也不用再跟系列前半部的做法給那麼明確的指示，才能很好的實作功能。目標設定 - Clean Architecture in TypeScript

原本以為很快就能寫完，結果這系列到現在還在寫。決定加入使用 AI 協作開發後，又更難寫，現在回過頭來看覺得除了實踐方式外，內容都快要跟 Clean Architecture 無關了 😅連載介紹 - Clean Architecture in TypeScript

因為很有趣截圖一下 XD主要是我看到「pollution」這個單字好奇意思，然後查了一下是「污染」或者「公害」會做這個調整是前一步他的計劃說他會把東西放到 TUI Handler 套件裡面，結果他塞去根目錄下面。我跟他說明 main.go 應該是進入點，他應該把 config.Monitor 注入給 Handler 負責處理比較合理，結果用「污染」形容自己搞出來的東西⋯⋯

中壢的紅綠燈怎麼了？為什麼要一直讓車跟行人放空

昨天在 Ruby Taiwan 的 Discord 啟用了新的頻道，透過 AI 收取 Ruby Core 的 Mailing List 信件，將 Ruby 語言最新的資訊摘要成容易閱讀的版本。之前使用一陣子Hacker News Active + 100 繁體中文後，發現減少很多以往閱讀上的阻力，從偶爾看變成有空就會看，得到的情報也更豐富，所以在 RubyKaigi 後也對 Ruby 社群做了類似的功能來幫助大家獲取資訊。

最近在實作一些小專案時會想，東西很簡單還需要去切分 Use Case 這些嗎？後來隨著實作還是做了切分，因為這對未來做抽換或者重複使用某些功能（如：不同端點）都很有幫助，以長期維護的角度是很值得投資的。資料庫抽換 - SQLite（一） - Clean Architecture in Go

這篇文章紀錄我對近期參與爭議事件的看法，剛好昨晚 RubyJam 主辦讓因感冒在家的我能線上聽台灣的社群夥伴分享 RubyKaigi 的經驗也呼應日本 Ruby 社群一直以友善風氣自豪，包括研討會有托育服務、從小問題開始修正，逐步成為語言貢獻者等經驗，都建構在友善的環境下才能發生我希望看到的開源社群

早上跟醫生說我感冒會持續低燒，醫生不知道開了什麼藥給我，現在會一直冒汗然後體溫似乎有下降

昨天我家伺服器壞掉，原本用 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 寫程式