不知不覺，30 天就結束了！
終於來到鐵人賽的最後一天了！
這 30 天，我從一開始只有一個想法，到慢慢做出可以搜尋店家、分析評論的 AI 網站，中間還加入了會員登入、歷史報告和雲端資料庫。
原本以為只要功能做出來就差不多了，沒想到實際測試後，還是遇到不少問題。
像是網站部署後 Gemini 無法使用、換裝置登入看不到歷史紀錄，到最近串接 Firestore 後，又發現報告會重複儲存，而且無法刪除。
所以最後一天，除了回顧這 30 天的成果，也要整理目前還有哪些問題，以及之後可以怎麼改善。

一、修正歷史報告重複儲存與無法刪除的問題

Day 28 測試時，我發現換一台裝置登入同一個會員帳號，竟然看不到原本的歷史報告。
後來在 Day 29 串接 Firestore，終於讓不同裝置可以查看同一個帳號的紀錄。
原本以為這樣就差不多完成了，沒想到接著又發現兩個問題：歷史報告會重複儲存，而且刪除後重新整理，資料又會跑回來。

所以這次我決定直接檢查程式碼，找出問題發生的原因。

1.歷史報告會重複儲存

檢查後端寫入 Firestore 的程式碼後，我發現原本使用的是 .add() 方法。
這個方法每次執行時，都會建立一筆新的文件，並自動產生新的 Document ID。
也就是說，即使是同一家店，例如「Hi飲吧」，只要重新分析或再次儲存，系統就可能再新增一筆資料，最後歷史紀錄就出現好幾張相同的店家卡片。

【實際操作圖 1：修改前：歷史報告出現重複資料】

我的修改方式：使用 placeId 識別店家

既然重複資料是因為每次儲存都建立新文件，我就想到能不能使用 Google Maps 提供的 placeId，讓系統知道這次儲存的是哪一家店。
這樣一來，如果同一家店已經有對應的文件，就可以更新原本的資料；如果還沒有，才建立新的文件。
不過，這種做法代表同一個會員、同一家店會共用一筆歷史紀錄。如果未來想保留同一家店每一次分析的不同版本，就需要另外設計資料結構。

【實際操作圖 2：修改後的歷史紀錄】

2. 資料按刪除後，沒有消失

當時按下刪除按鈕，畫面看起來好像成功了，但只要重新整理，剛剛刪除的報告又會重新出現。
一開始可能會以為是畫面沒有更新，後來才發現問題可能不只是前端顯示。
我進一步檢查瀏覽器的 DevTools，特別是 Network 面板，確認按下刪除按鈕後，網站到底有沒有真的送出刪除請求。
排查後，發現需要注意兩個地方：
第一，前端刪除了資料，不代表雲端資料也被刪除。
如果程式只移除 localStorage 裡的資料，卻沒有呼叫後端刪除 Firestore 文件，那麼重新整理頁面時，系統還是會從雲端把原本的紀錄抓回來。
第二，刪除按鈕不一定有正常觸發程式。
因為歷史報告卡片是動態產生的，如果事件監聽器沒有正確設定，按下按鈕時可能根本沒有送出刪除請求。

我的修改方向：讓刪除功能真的作用在 Firestore

要解決這個問題，就不能只刪除畫面上的卡片，而是要讓前端和雲端資料庫同步。
後端可以新增一個 deleteHistoryItem Cloud Function，接收要刪除的文件 ID，再刪除對應的 Firestore 文件。
另外，前端也可以使用「事件委派」（Event Delegation），由外層容器統一監聽點擊事件，處理動態產生的刪除按鈕，減少重新渲染後事件監聽器失效的問題。

【實際操作圖 3：刪除前】

【實際操作圖 4：刪除成功後】

這次除錯讓我發現，資料能存進資料庫，只是完成了第一步。 還要考慮資料如何識別、更新和刪除，以及前端畫面與雲端資料是否一致，才能讓歷史報告真正穩定運作。

二、實際測試整個網站

除了處理資料問題，我也重新整理了網站目前的主要功能。

【實際操作 ：完整操作流程】
1. 會員登入

2. 搜尋店家

選擇第1個店
3.開始分析

4. 顯示 AI 避雷報告

5.儲存報告(跳出成功通知)

6.去查看歷史紀錄

7. 將報告另存為 PDF

8.手機登入會員同步歷史紀錄

三、這 30 天，我完成了哪些功能？

回到最初的想法，我是希望利用 AI 幫忙整理 Google Maps 上的店家評論，讓使用者不用每次都自己慢慢閱讀。
這 30 天，我逐步完成了以下功能：

• 網站介面：使用 HTML、CSS 和 JavaScript 製作網頁。
• 店家搜尋：串接 Google Places 相關服務，搜尋並選擇店家。
• AI 評論分析：串接 Gemini API，將取得的評論整理成避雷報告。
• 報告呈現：整理整體評價、可能的雷點、餐點與服務、環境、價格、等待時間等資訊。
• 會員登入：加入會員登入功能。
• 歷史報告：使用 Firestore 保存紀錄，讓會員能在不同裝置查看資料。
• 報告下載：透過列印功能，將報告另存為 PDF。
• 網站部署：使用 Firebase Hosting，讓網站可以在線上開啟。
  這些功能都是我一邊學、一邊做，再慢慢補上去的。雖然還有一些細節需要改善，但至少已經從一個想法，變成可以實際操作的網站。

四、開發過程中遇到的問題

這次開發並不是一路順利，以下是我印象比較深刻的幾個問題。

1. Gemini API 一直出錯

串接 Gemini API 時，我遇過 503、404 和使用額度不足等錯誤。
當時需要反覆確認模型名稱、API 設定和錯誤訊息，才慢慢找到可以使用的模型。

2. 部署後無法正常分析

在 localhost 可以執行，不代表部署到 Firebase Hosting 後也一定正常。
網站上線後，Gemini 分析功能出現問題，讓我開始檢查 API 設定和瀏覽器的 Console、Network。
這讓我了解到，部署完成只是第一步，上線後還是需要重新測試。

3. 不同裝置看不到歷史報告

一開始，會員登入成功了，卻不代表資料會自動同步。
後來串接 Firestore，才讓同一個帳號能在不同裝置查看歷史紀錄，但也接著遇到重複儲存和刪除問題。

4. API 取得的評論數量有限

這是我在開發過程中發現的另一個限制。
目前我的 Google Places API 實作一次最多只能取得 5 筆評論，因此 Gemini 分析的內容也受到資料量影響。
即使 AI 可以整理出看起來很完整的報告，也不代表它已經分析過這間店的所有評論。
未來我希望能研究其他可行的資料取得方式，或在報告中標示分析的評論數量，讓使用者知道這份結果的參考範圍。

五、這次專案讓我學到什麼？

我覺得最大的收穫，就是實際體會到開發網站不只是把功能做出來而已。
以前可能會覺得畫面正常、按鈕可以點，就差不多完成了。但真的開始做專案後，才發現還要考慮 API 錯誤、資料儲存、權限設定、跨裝置同步，以及部署後的問題。
這次也讓我更熟悉 HTML、CSS、JavaScript、Gemini API 和 Firebase 之間的搭配。
遇到問題時，雖然有時候會不知道從哪裡開始查，但至少慢慢學會先看錯誤訊息，再一步一步找出可能的原因，而不是一直亂改程式碼。

六、未來還能改善什麼？

30 天結束了，但網站還有一些可以繼續努力的地方：

• 評論數量：目前一次最多取得 5 筆評論，還需要研究其他可行的資料取得方式。
• AI 分析：讓報告內容更完整，也提醒使用者分析結果僅供參考。
• 歷史紀錄：修正重複儲存和刪除問題，讓資料管理更穩定。
• API 安全性：檢查 API Key、權限與使用額度設定。
• 網站介面：繼續改善操作流程和錯誤提示。
  如果之後有時間，我希望能繼續完善這個專案，而不是只停留在目前的功能。

結語：30 天鐵人賽心得

回顧這 30 天，從一開始規劃網站、學習串接 API，到後來加入會員、歷史報告和雲端資料庫，中間真的遇到不少問題。
雖然不是每個功能都能一次成功，但每次遇到錯誤，也讓我更了解網站實際運作的方式。
這次最大的感想是：做出功能只是開始，讓功能穩定運作，才是真正需要花時間的地方。
謝謝這 30 天願意持續嘗試、遇到問題還是繼續找方法的自己，最後才能產出這個系統。
AI 避雷探針的 30 天開發紀錄就到這裡告一段落了！