上一階段我們透過 DESIGN.md 根據設計風格限定的 TailwindCSS Design Token 初步完成了 Hono JSX 的對話介面，接下來我們需要將假資料移動到後端，使用 Hono RPC 來處理前後端的整合。

透過 AI 協力開發，我們可以節省許多以往需要花費力氣的時間。不過開發的流程並不會有太大的變化，這次我們會採用可以馬上確認成果的方式進行開發，因此會從前端的介面開始著手。

今年（2025 年） ThroughWorks 的 Technology Radar 中提及了 AI-friendly code design 的概念，討論以往軟體開發的優良實踐，也能夠對 AI 協力開發產生幫助，因此列入的評估的範圍中，在為來可能會成為採用的選項之一。

即使我們仍不確定未來會如何變化，但是在良好的軟體架構跟實踐為基礎，仍可以幫助我們更好地應用 AI 來進行開發。

這一次會有前端跟後端的實作，雖然都會透過 AI 來輔助開發，但我們仍需要對功能的規劃和需求有一定理解，因此我們需要先針對介面做簡單的規劃，用於後續開發時使用。

這一系列會預設在 Cloudflare 相容的環境下運行，在前端開發的部分會以 Vite 搭配 Hono 來使用，這幾個工具有很不錯的相容性，很適合在這次的情境中使用。

tsyringe 是微軟維護的一款輕量依賴注入（DI，Dependency Injection）容器，可以幫助我們很輕鬆的管理物件的依賴注入，在 Clean Architecture 的實踐中我們會將許多物件細分職責，此時有依賴注入的機制可以幫助我們在測試、開發上更加順手。

這一系列我們會使用 Hono 這一個近幾年才出現的框架，跟 Node 生態系常使用的 Express 框架不同，Hono 最初是以 Cloudflare Worker 環境運行設計，後來逐漸發展成適合 Serverless 環境的框架。

跟以往不同的地方在於，加入 AI 到產品與開發流程過後，許多以往的思考方式會有所改變。因此這一次我們的目標除了原本實現的功能外，還要考慮新型態的軟體開發方式。

寫完 Clean Architecture in Go 系列後，原本預定是要探討 Ruby 相關的主題，然而剛好遇上大量的 AI（人工智慧）應用出現，加上手邊正好使用 TypeScript 做了一些實驗，才有了這一系列的出現。

我們討論了不少 Clean Architecture 在 Golang 實踐的方式和技巧，然而我們是否真的有必要在 Golang 使用，以及使用之後我們能獲得怎樣「實質」的優點。我們經常會聽到 Clean Architecture 的優點，卻很少有實際的案例討論。