目前我已經逐步完成 AI 避雷探針的基本網站介面、Google Maps 店家搜尋、評論資料取得，以及 AI 避雷報告的產生功能。
不過，隨著網站功能逐漸增加，我開始思考一個問題：如果使用者想要再次查看之前分析過的店家，或是保存自己感興趣的避雷報告，該怎麼辦？
因此，今天決定開始規劃網站的登入與會員功能。
這次不會急著修改原本的分析程式，而是先從使用者需求、功能設計及操作流程開始，確認訪客與會員之間的差異，再決定後續的實作方式。

為什麼需要登入功能？

一開始開發 AI 避雷探針時，我希望使用者打開網站後，就能直接輸入店家名稱並查看分析結果，不需要經過太多步驟。
如果一開始就要求所有人註冊帳號，可能會增加使用門檻，讓只是想臨時查詢店家評論的人感到不方便。
但如果完全沒有會員系統，使用者也可能遇到一些問題，
例如：

• 想重新查看之前產生的避雷報告，卻找不到紀錄。
• 分析過多間店家後，難以整理過去的分析結果。
• 換一台電腦或使用不同瀏覽器時，無法方便地查看原本的報告。
  因此，我決定採用「訪客與會員並存」的設計。
  訪客可以直接使用核心分析功能，會員則可以享有歷史報告儲存與查看功能。
  這樣既能降低使用門檻，也能讓有長期使用需求的人獲得更多便利。

規劃訪客與會員的功能差異

在設計登入功能之前，我先整理兩種使用者可以使用的功能，避免後續開發時出現權限不清楚的問題。

這次規劃的重點，是將「使用核心功能」與「個人化管理功能」分開。
即使沒有帳號，使用者仍然可以完成一次完整的店家分析；如果希望保存報告、日後再次查看，就可以註冊成為會員。
至於訪客產生的報告，如果沒有另外下載或自行保存，之後是否還能找回，就不會有保證。因此，後續也需要設計清楚的提示，讓使用者知道登入會員後才能保存歷史紀錄。

規劃登入、註冊與登出的介面

接下來，我開始思考登入功能應該放在網站的什麼位置。
我希望登入功能不會影響原本的操作流程，因此不打算讓登入頁面成為使用網站的必要條件，而是將它設計成一項額外功能。

1. 尚未登入時

在網站首頁右上角放置「登入／註冊」按鈕。
訪客可以直接搜尋店家、取得評論並產生避雷報告。如果使用者想要保存報告，也可以在報告頁面看到「登入會員以儲存報告」的提示。

2. 登入後

使用者成功登入後，右上角可以改為顯示會員狀態，並提供以下功能：

• 歷史避雷報告
• 會員帳號資訊
• 登出
  會員產生報告後，可以選擇儲存至自己的帳號，未來再從歷史紀錄中查看。

3. 註冊與登入頁面

登入頁面預計提供電子郵件與密碼欄位，以及登入按鈕。
如果使用者還沒有帳號，可以切換至註冊頁面；如果已經有帳號，就可以直接登入。
初期先採用簡單的電子郵件與密碼登入方式，避免一開始就加入太多額外功能。

設計使用者操作流程

為了讓整個網站的操作更清楚，我將流程分成訪客與會員兩種情境。

訪客操作流程

訪客進入首頁後，可以直接搜尋店家、選擇店家、取得評論，接著開始 AI 分析，最後查看避雷報告。
如果想保存報告，系統再提示使用者登入或註冊。
首頁 → 搜尋店家 → 確認店家 → 取得評論 → AI 分析 → 查看避雷報告 → 選擇下載或註冊會員

會員操作流程

會員登入後，可以使用原本的店家分析功能，也可以進入歷史報告頁面，查看過去保存的分析結果。
首頁 → 登入 → 搜尋店家 → 取得評論 → AI 分析 → 查看避雷報告 → 儲存至個人帳號
另外，會員也可以不進行新的分析，直接從歷史報告頁面選擇先前保存的報告。
這樣可以減少重複操作，也能讓網站逐漸具備個人化管理的功能。

選擇使用 Firebase Authentication

完成需求規劃後，接下來要選擇適合的登入工具。
目前決定優先研究 Firebase Authentication。
Firebase 是 Google 提供的開發平台，其中的 Authentication 可以協助網站處理使用者註冊、登入、登出及登入狀態等功能。
如果自行開發完整的帳號驗證機制，還需要考慮密碼安全、驗證流程及使用者狀態管理等問題。使用 Firebase Authentication，可以減少這部分需要自行處理的工作。
目前預計採用以下工具：

• Firebase Authentication： 處理會員註冊、登入、登出及登入狀態。
• Cloud Firestore： 儲存會員的歷史避雷報告。
• HTML、CSS、JavaScript： 維持原本的網站介面與操作方式。
  需要注意的是，Authentication 主要負責帳號驗證，並不會自動替我們儲存歷史報告，因此還需要搭配資料庫，才能完成會員報告管理功能。

規劃 Firestore 的歷史報告儲存方式

除了登入功能之外，我也先思考了歷史報告應該如何保存。
每份避雷報告都會包含店家資訊、分析結果及產生時間。如果會員分析過很多間店家，系統就需要能夠區分不同使用者的資料。
初步規劃每份報告保存以下資訊：

其中，userId 是很重要的欄位。系統可以利用它識別報告所屬的會員，讓使用者只查看自己的歷史紀錄。
例如，會員 A 儲存的報告不應該被會員 B 查看。因此，後續除了在網站介面進行判斷，也必須透過 Firestore Security Rules 設定資料存取權限，不能只依賴前端 JavaScript 隱藏資料。
至於原始評論是否需要一併保存，還需要考慮資料量、實際需求及 Google Maps 相關服務的資料使用規範。目前先以保存店家資訊及分析結果為主，之後再視情況調整。

今天的成果與心得

今天主要完成的是功能規劃，而不是直接修改程式碼。
透過整理訪客與會員的差異，我發現登入功能不只是多放一個按鈕，還會影響整個網站的使用流程、資料儲存方式及使用者權限。
如果沒有先規劃清楚，就直接開始撰寫程式，後續可能會遇到訪客無法使用原本功能、登入狀態判斷錯誤，或是會員之間的報告資料沒有妥善隔離等問題。
因此，我決定先保留原本已經完成的店家搜尋與 AI 分析功能，再逐步加入會員系統。
接下來會先研究 Firebase Authentication 的基本設定與操作方式，再思考如何將登入狀態整合到現有網站，最後才進一步串接 Firestore，實作歷史報告的儲存與查看。