製作動機：作為每一分錢都想精打細算著使用的大學生，在購物網站上看到心儀的商品，但有許多不同商家標有不同價格販售相同或相似商品，總是希望能找到最便宜的價格。因此希望能透過這個機會試試看做出這個比價小幫手！

預期效果：用戶輸入商品關鍵字或一段敘述，AI Agent 協助判斷關鍵字並進入蝦皮網站（預設只有蝦皮，因為自己比較常在蝦皮購物，也是在蝦皮遇到同樣商品卻有許多不同價格的狀況）搜尋與比對，最後回覆給用戶的是最便宜的商家網址連結。

開始製作初遇到的核心問題：（以下是請 AI 分析的結果）

• 電商平台的反爬蟲與防禦機制：這種大型且存在許久的電商平台通常部署了嚴格的 Cloudflare、驗證碼（CAPTCHA）或登入驗證。當自動化工具（如 n8n 的 HTTP Request 或網頁爬蟲節點）發送請求時，往往會被系統識別並阻擋，導致無法取得動態渲染的完整商品列表與即時價格。
• 動態網頁渲染（JavaScript Rendering）：現代電商網站大多採用前端框架（如 React、Vue）進行動態載入。單純的 API 請求或基礎 HTTP 抓取通常只能拿到空白的網頁骨架，無法直接解析出透過 JavaScript 動態生成後的各家店鋪價格與排序。
• 缺少即時視覺與瀏覽互動能力：AI 模型本身（如 OpenAI Chat Model）具備強大的文字理解與推理能力，但它在背景執行時是一個文字處理核心，並不具備像人類一樣實際開啟真實瀏覽器、點擊分頁、捲動頁面、比對不同賣家運費與折扣券的完整瀏覽器操作環境（除非搭配專門的瀏覽器自動化工具如 Puppeteer 或 Playwright，且仍需克服上述的反爬蟲限制）。

→因此，我的總結是，短時間內不可能，需要克服重重障礙，未來會持續邊學習邊嘗試！也是因為想做這個專案，遇到了這個問題，才知道一個網站要設計的好用且安全，其中細節和眉角還有許多需要學習的！
→→後續的調整：改成「多平台比價」，詢問用戶平時常用的購物平台，官方會記憶（這裡透過 Google Sheets ），後續用戶輸入關鍵字，就會去搜尋這幾個平台相應的商品與售價，點擊連結會進入到商品搜尋頁。（完整流程在下面截圖呈現）

調整方向後仍然有遇到的困難：（與 AI 討論後以及請他整理後的分析）

• 資料無法持久化與記憶機制失效：可能原因是初期的 Simple Memory 無法長久保存設定，且 Google Sheets 讀寫順序顛倒（先寫入空白變數導致舊資料被清空）；解決辦法有將架構改為平行分支，主流程先讀取（Get row），背景流程再寫入（Update row），並確保變數正確傳遞。
• 執行時間過長導致 LINE 回覆超時：可能原因是串聯了過多 AI 與試算表節點，且 Get row(s) 一次讀取過多資料（如 19 items），導致耗時超過 LINE Reply Token 的 30 秒限制；解決辦法有改用 LINE Push API 突破時間限制、將 Get row(s) 設為只回傳 1 筆（Return First Matching）、將背景寫入拆分出來，以及更換為生成速度較快的 gpt-4o-mini 模型。
• 訊息回覆冗長且帶有技術性贅字：可能原因是早期的 AI 提示詞缺乏明確的輸出規範；解決辦法有生成結構化的 System Message，規範 AI 的回應語氣、平台清單邏輯與防呆機制。
• If 節點報錯（Wrong type: expected string）：可能原因是條件設定中，選取的變數是包含整個 JSON 的物件（Object）而非純文字；解決辦法有將表達式具體點選到文字欄位，例如使用 {{ $json.body.events[0].type }}。
• If 節點條件判斷永遠走向 False：可能原因是比對值（Value 2）誤填了用戶傳入的對話變數（如 {{ $json.body.events[0].message.text }}），導致系統拿「事件類型」去跟「用戶對話內容」做比較；解決辦法有將 Value 2 直接改為純文字 message。
• Get row(s) in sheet 節點查無資料（No output data）：可能原因是 Sheet 欄位誤填為變數（user ID），且 Filter 設定錯誤（將 Column 設為變數，或是加了不必要的 Filter 2）；解決辦法有在 Sheet 欄位正確選擇工作表名稱，並將 Filter 1 的 Column 設為試算表標題 user ID，Value 設為 LINE 傳入的 user ID 變數。
• HTTP Request 節點報錯（Bad request）：可能原因是 LINE API 的 JSON Body 格式有誤（如文字換行導致 JSON 破裂）或 replyToken 帶錯/失效；解決辦法有使用 {{ JSON.stringify($json.output) }} 來處理文字轉義，並確認 Header 驗證正確。
• AI 回覆張冠李戴（錯認暱稱與平台）：可能原因是 Append row 產生了多筆重複資料，而 Get row(s) 抓到了舊的那一筆；解決辦法有將寫入邏輯改為 Update row （或設定降序排序），確保每次讀取的都是最新偏好。
• 工作流執行到一半卡住停擺：可能原因是誤將 Update row 又接回 Get row(s) 造成無限迴圈，或是 AI Agent 底下的 Model/Memory 節點連線有誤，亦或是 Get row(s) 回傳 0 筆資料導致斷流；解決辦法有確保平行分支絕對不回接、確認 Model 的 Credential 設定正確，並將 Get row(s) 開啟「Always Output Data」。
• AI 無法辨識商品關鍵字（將商品誤認為設定指令）：可能原因是 AI Agent 在接收試算表資料時，發生了節點覆蓋，導致無法直接接收到 Webhook 的對話文字（變數變成空白）；解決辦法有在 Prompt 中明確鎖死變數路徑，例如強制使用 {{ $('Webhook').item.json.body.events[0].message.text }} 來抓取當下文字，並簡化邏輯規則。
• 新用戶第一次發送訊息時，感覺沒存到資料：可能原因是加入好友時的歡迎訊息會走 If 的 False 路線，而用戶發送第一句話走 True 路線時，讀取與寫入平行啟動，導致「讀取節點」當下抓不到還在「背景寫入中」的資料；解決辦法有在 AI Agent 的提示詞中加入 Fallback 機制，當試算表變數為空時，指示 AI 直接從當前對話訊息中提取暱稱與平台來應答。

用戶完整操作流程：
Line 官方歡迎訊息（指示用戶輸入希望被稱呼的暱稱以及平時常用的平台）→用戶輸入暱稱與平台（可以多個平台）→系統提示輸入想查詢的關鍵字→用戶輸入→系統搜尋並提供回覆（包含稱呼用戶暱稱以及各平台的連結）

總結心得與未來展望：
這次從《詠唱師》開始打底學習與練習和 AI 對話，根據不同需求而配合不同的「招式」，非常有趣。之後再進入到 n8n 自動化流程一步一步的學習，最後進到正題與 Line 官方結合，光是學習的過程就非常有趣，時間飛快的過去都沒有發現><真正進入到實作之後其實遇到許多困難，想做的東西很多但不知該如何呈現，反覆與 AI 互動交流，也是頗有趣頗有成就感的過程。
未來想繼續精進的部分是：希望能嘗試解決電商平台本身的限制（但說實話不知道這樣是不是合法的...？應該是需要透過合作或去申請才可以這麼做）、用戶介面的升級，以及回覆的語氣用詞更加完善符合人性。繼續努力！