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

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

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

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

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

最近 Hono 框架推出了 Hono CLI 工具，我很快的就幫 Claude Code 製作了 Hono Plugin 加入 Agent Skill 支援使用 Hono CLI 查詢文件。

同時我也想到，我很少使用的 ri（Ruby Information）命令，跟 Hono CLI 提供的功能非常相似，因此提早將 Ruby Plugin 製作出來，提供 ri 技能。

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

最近看到 n8n（自動化工作流程平台）的更新中加入了 LINE Messaging 的社群節點，花了一點時間研究才發現好心人竟然是自己。

因為已經有 n8n Line Messaging 社群節點教學以及 n8n Line API 串接教學：從零開始，打造你的專屬 AI 通知機器人兩篇文章介紹使用方式，這篇文章就來聊一下作者角度的看法。

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

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

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

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

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