關於 #Clean Architecture 的內容

因為 LLM 的不確定性，再加上大多數服務都會採取呼叫 API 的方式來使用，我們很難在測試中直接呼叫，比較好的做法是將 LLM 呼叫使用 Mock 方式處理。

如果要測試 LLM 的表現，則會使用 Evaluation（評估）的方式，並不在這系列討論的範圍中

如果直接使用 Vitest 來撰寫測試，我們需要模擬大量的 API 請求和回應的檢查，這會造成單一測試非常不好閱讀，在維護新的功能時也需要反覆的產生大量重複的程式碼。

我們可以模仿 BDD（Behavior-Driven Development）風格的方式，設定「步驟」的概念，來讓測試案例變得容易理解，也能讓 AI 擴充測試時更加穩定。

前面的內容我們都注重在功能的實現，然而使用 AI 開發使用測試來確保功能的穩定也是非常重要的，至少我們不會因為產生的程式碼有一些預期外的改動，而破壞整個功能的完整性。

使用 AI 工具可以讓我們在初期很快地進行開發，大部分物件也不太需要對依賴注入的問題進行管理。然而在測試階段，能夠透過統一的介面切換測試用的物件，對於後續開發還是非常有幫助的。

我們接下來會使用 AI 協助我們一開始設定的 tsyringe 套件，正式導入到專案中。

前面的實作都是將對話編號寫死為 default 接下來我們要讓每個使用者開啟後都能夠產生一個新的對話，而且持續 60 分鐘都可以使用相同的對話串來進行購物。

可以查詢商品後，我們就可以透過對話得到能購買的商品，那麼就可以加入更新購物車商品的設計。基於前面我們已經有很多基礎，加入新功能的速度會快上不少。

撰寫本文時 Claude Code 變得非常熱門，後續的文章會使用 Claude Code 作為範例。

處理完讀取購物車資訊後，我們還需要讓使用者可以取得能購買的商品。因為是對話式的介面，所以需要將查詢商品的功能變成 AI 助手工具的一部分，雖然會因為語言模型的能力影響好用程度，不過以實驗性專案的情境還是蠻有趣的。

購物車側欄第一階段的 API 處理完畢後，我們一樣需要重構為 Use Case 來保持架構的一致性，以及後續的可擴充性，我們會繼續使用 AI 來協力完成這個修改。

目前對話功能除了保存紀錄外，已經是處於可以使用的狀態。接下來我們要繼續把購物車的側邊欄介面實現出來，用來呈現商品列表。

驗證大型語言模型可以順利整合後，我們需要繼續依照 Clean Architecture 的處理方式將物件拆分開來，在對話紀錄的處理上我們已經完成過一次，基本上只要依照相同的方式處理即可。