今天主要針對「AI 避雷報告」的版面進行優化。
前幾天已經完成 Google Maps 店家評論的取得，以及將評論交給 Gemini 進行分析。不過在實際測試網站的過程中，我發現 AI 產生的報告雖然已經可以正常顯示，但當評論內容比較多時，報告會變得很長，有些內容也會全部擠在一起，閱讀起來比較不方便。
因此今天主要針對報告頁面進行幾項調整。

1. 優化餐點／服務的顯示方式

原本餐點與服務的內容可能會連續顯示在同一行，當文字比較多時，會變成一大段內容。
因此這次將不同內容分行顯示，並保留適當的間距，讓使用者可以更容易閱讀。
修改前

修改後

這樣可以讓不同類型的資訊更容易區分，也比較容易快速找到自己想看的內容。

2. 增加報告頁面的滑動功能

除了文字排版之外，我也發現有些店家的評論內容比較多，因此產生的 AI 報告也會變得很長。
如果所有內容都直接放在頁面上，整個網頁會變得非常長，使用者需要一直往下滑才能看完。因此這次加入可滑動的內容區域，讓使用者可以在固定的報告版面中上下查看完整內容，同時保留原本的卡片式設計。
這樣即使分析內容比較多，也不會讓整個頁面看起來太凌亂。

3. 實際測試時遇到 API 配額問題

不過在今天實際測試的過程中，也遇到了一個比較大的問題：目前只有找到gemini-3.5-flash的模型跑得動，還沒找到其他的，然後今天Gemini API gemini-3.5-flash模型的免費配額已經使用完畢，因此測到一半就沒有辦法繼續正常執行，增加功能有限。
目前測試到的配額狀況為：

RPM 已經達到每分鐘的上限，而 RPD 也已經超過每日限制。也就是說，目前使用的 Gemini 3.5 Flash 已經用完當天可以使用的免費 API 次數，因此網站再次送出分析請求時，伺服器會回傳 429 Too Many Requests，導致 AI 避雷報告無法正常產生。
這也讓我發現，實際開發 AI 應用程式時，除了模型本身能不能正常運作之外，API 的使用額度也是需要考慮的問題。如果在開發過程中一直重複測試相同功能，很容易在還沒有完成專案之前，就先消耗掉大量的 API 請求次數。
因此今天先確認問題來源，確定不是網站程式碼本身出錯，而是 API 配額已經達到限制。後續會再思考如何減少不必要的 API 請求，例如測試時減少重複分析、保留已經成功產生的結果，或研究其他模型與 API 的替代方案。

今天學習

今天除了完成報告版面的優化，也讓我了解到「能夠成功串接 API」和「能夠穩定使用 API」其實是兩件不同的事情。
這次調整後，原本的報告內容在排版上更加清楚，評論較多時也可以透過滑動查看完整內容。不過在實際測試過程中遇到的 API 配額問題，也讓我開始思考之後如何處理 API 使用限制，以及當 AI 暫時無法使用時，網站是否需要提供適當的錯誤提示或備援機制。