一、從功能規劃進入實作

在 Day 21，我先規劃了 AI 避雷探針的訪客與會員功能，決定讓訪客不需要登入就能使用核心分析功能，而會員則可以儲存及查看過去的避雷報告。
到了今天，開始將這些規劃實際做出來！
原本的 AI 避雷探針已經可以搜尋 Google Maps 店家、取得評論，再透過 AI 分析評論內容並產生避雷報告。不過，使用者每次分析完店家後，如果想再次查看之前的結果，就需要另外保存報告。
為了解決這個問題，我決定開始實作會員登入功能，並新增歷史紀錄頁面，讓使用者可以透過帳號管理自己過去的分析結果。
今天的重點是讓網站開始具備基本的會員使用流程。

二、實作會員登入功能

首先，我完成了會員登入功能，讓使用者可以透過帳號登入網站。
這次使用 Firebase Authentication 作為會員驗證工具，協助處理使用者的註冊、登入、登出及登入狀態。

• 會員登入：已經註冊的使用者可以登入網站。
  
• 會員註冊：尚未有帳號的使用者可以建立帳號。
  
• 登入狀態：系統右上角會顯示會員名稱可得知是否已登入。
• 會員登出：使用者可以主動按右上角登出按鈕登出帳號。
  
• 登入後可儲存報告
  

這些功能看起來很基本，但對網站來說相當重要。因為當網站開始提供個人化功能時，就需要知道目前是哪一位使用者，才能將不同人的資料分開管理。

三、保留訪客使用方式

在加入會員功能的同時，我也希望保留原本的使用方式。
AI 避雷探針的主要目的是幫助使用者快速整理 Google Maps 店家評論。如果使用者只是臨時想查詢某間店家，卻必須先註冊帳號，反而會增加使用門檻。
因此，我採用訪客與會員並存的設計。
訪客可以直接使用店家搜尋、評論取得及 AI 分析功能，不需要先註冊帳號。

這樣一來，即使沒有帳號，也不會影響使用者體驗核心功能。
當使用者希望保存報告或再次查看過去的分析結果時，就可以選擇登入或註冊會員。

四、新增歷史紀錄頁面

除了登入功能之外，今天另一個主要成果，就是完成歷史紀錄頁面。
這個頁面的目的是集中管理會員之前保存的 AI 避雷報告，避免使用者每次想查看舊報告時，都需要重新搜尋店家並進行分析。

歷史紀錄頁面主要規劃以下資訊：

• 店家名稱
• 店家地址
• 報告建立時間
• 查看報告的操作入口

使用者可以透過這個頁面，快速找到自己過去分析過的店家，並進一步查看對應的報告內容。

對我來說，這是 AI 避雷探針從單次分析工具走向個人化網站的重要一步。網站不再只是讓使用者輸入資料、取得分析結果，而是開始考慮如何讓分析結果被保存、整理及再次使用。

五、規劃會員帳號與歷史報告的關聯

在設計會員功能時，我也開始思考登入系統與歷史報告之間的關係。
登入功能負責確認使用者的身分，而歷史紀錄則需要知道每一份報告屬於哪個帳號。
因此，後續的資料設計會以使用者的 UID 作為關聯依據，將會員帳號與保存的報告連結起來。
例如，當會員登入後產生一份新的避雷報告，系統就可以將報告內容與對應的使用者 UID 一起保存。之後會員再次登入時，便能讀取屬於自己的歷史紀錄。

六、今日心得

Day 22 是 AI 避雷探針開發過程中，從單純的評論分析功能，逐步走向會員管理的重要一步。
之前的開發重點大多放在 Google Maps 店家搜尋、取得評論、串接 Gemini API，以及將 AI 分析結果呈現在網頁上。
而今天開始加入會員登入與歷史紀錄功能後，我需要思考的不再只有 AI 能不能正常產生報告，也包含使用者如何管理自己的資料，以及如何讓網站提供更完整的使用體驗。
我也發現，開發一個網站時，功能之間的連結相當重要。即使每個頁面都能獨立運作，也需要透過適當的流程與資料設計，才能讓整個網站真正好用。