Firebase

為什麼要自己做工具？ 備戰 2026 台東 CT226 全超鐵（226km）的過程中，補給計畫一直是我最頭痛的環節。 騎車 180km、跑步 42.2km，總時間預計超過 11 小時，補給稍有失誤就可能在賽道上「爆缸」。我查過很多資料，也研究了 Maurten、SiS 等品牌的補給計算器，但問題很明顯：那些工具都是以國外補給品為主，台灣常用的 GA 太空膠、碳水炸彈、UP FAST 根本找不到。 每次備賽前我都要打開 Excel，手動排每小時補給什麼、幾分鐘一次，然後還要確保咖啡因不過量、鈉補給足夠。這個流程很繁瑣，而且每次改一個參數（例如調整平均功率的假設）就要全部重算。 所以我決定自己做一個。 工具介紹：三鐵補給規劃 網址：https://bike-power-calculator.web.app/nutrition.html 這個工具的核心功能是：根據你的體能數據、賽事條件、還有你手邊有哪些補給品，自動排出分鐘級的補給時間表。 輸入什麼 體重、排汗率、環境溫度與濕度 FTP（功能性閾值功率）和預計平均功率 跑步配速 賽事距離（51.5、113、226 等） 進階選填：每小時碳水目標（g/hr）、鈉目標（mg/hr） 輸出什麼 一張詳細的補給時間表，包含： 每個補給點的時間（分鐘） 補給項目名稱 累積碳水攝取 累積鈉攝取 累積咖啡因 備注（是否開放咖啡因窗口、電解質補充等） 計算邏輯 碳水需求 根據運動強度（以 FTP 百分比計算），工具會估算每小時碳水消耗量： 騎車：依據平均功率與體重換算消耗 跑步：依據配速估算強度 如果你已知每小時要攝取多少碳水（例如你相信自己能消化 90g/hr），可以直接在進階設定裡覆蓋自動計算值。 補給間隔計算 補給間隔用這個公式計算： interval = 60 / (carbPerHr / leadProduct.carbs) 然後 snap 到最接近的合理值（5、10、15、20、25、30、40、45 分鐘），避免出現「18.7 分鐘補一次」這種不實際的排程。 果膠輪替 一開始我設計的版本永遠都補同一個果膠，後來發現這樣比賽中會吃到膩。改進後加入輪替機制：每次補給後 rotationOffset + 1，讓你選的所有果膠輪流出現，避免一種吃到厭。 咖啡因窗口 咖啡因不是從一開始就可以用，研究指出太早使用效果會打折扣： 騎車段：完成 60% 後才開放 跑步段：完成 30% 後才開放 開放後才會在排程中安排咖啡因補給品（UP 綠茶咖啡因膠囊、可樂）。 ...

fom Freepik 為什麼要自己做網站？ 身為一個熱愛騎自行車的上班族，我經常需要計算爬坡時需要多少功率，或是分析 GPS 軌跡檔案來規劃騎乘時間。特別是工作上常常需要分析電輔腳踏車的性能，要多少瓦數才能爬什麼坡，市面上雖然有一些工具，但總是缺少我想要的功能，而且大多是英文介面。 於是我想：「不如自己做一個？」 這個想法讓我開始了一個有趣的學習之旅。從完全不懂網站架設，到現在有了一個自己用得順手的專業工具，這個過程不僅讓我學到了技術，更重要的是學會了如何將工作需求變成實用工具。 我做了什麼？ 🚴‍♂️ 自行車功率計算器 我的網站主要功能很簡單： 輸入你的體重、功率，就能算出在不同坡度能騎多快 反過來，輸入目標速度，就知道需要多少功率 可以上傳 Strava 或 Garmin 的 GPX 檔案，自動分析整條路線需要多久時間 特別針對電輔腳踏車的功率需求進行分析 聽起來很專業？其實核心就是一些物理公式的計算，任何人都能理解。 🌟 與眾不同的地方 為什麼不直接用現有工具？ 大部分工具都是英文，台灣騎士用起來不方便 很少支援 GPX 檔案直接拖拉上傳分析 計算結果不夠詳細，看不出各種阻力的影響 沒有針對台灣常見路線（像武嶺、陽明山）優化 缺乏電輔腳踏車的專門分析功能 所以我做的不只是一個計算器，而是專為自己（和可能有同樣需求的人）設計的實用工具。 技術選擇：簡單就是美 💻 為什麼不用複雜的框架？ 一開始我也想過要用 React 或 Vue 這些熱門框架，但後來發現： 載入更快：沒有多餘的程式庫，網頁開啟飛快 SEO 更好：Google 更容易理解和收錄 維護簡單：不用擔心框架版本更新問題 成本更低：不需要複雜的建置流程 最終我選擇了最簡單的技術：HTML + CSS + JavaScript，但這不代表功能陽春。 🚀 為什麼選擇 Firebase？ 在比較了各種主機服務後，我選擇了 Google 的 Firebase： 費用考量 完全免費（每月 10GB 流量） 對個人工具來說綽綽有餘 目前流量不大，免費額度就夠用 技術優勢 全球加速，台灣用戶載入很快 自動 HTTPS 安全連線 與 Google 服務整合完美 未來彈性 ...

如何透過 AI 協助快速建立一個支援多人協作、即時同步的點餐網站 專案背景：解決真實痛點 相信大家都有過這樣的經驗：公司要訂飲料，負責人在群組裡貼了菜單，然後大家開始接龍，結果… 接龍接到被別人刪到訂單 忘記打甜度冰塊 知道想喝甚麼，但還要去看菜單多少錢 要接龍的時候，被別人搶先 不知道總共有幾杯，還要慢慢算 即使大家都乖乖地照格式打，還是必須手動整理、算錢，這樣的混亂又麻煩的場面是否很熟悉？身為一個工程師，我決定用技術來解決這個日常問題，減少沒有飲料喝的日子。 我不會寫網頁所以我用Claude來開發。總共花了3個小時就從構思到部屬完成。 AI 輔助開發：從想法到實現 第一次對話：需求分析與架構建議 我的需求： 我想要一個網頁，大家可以點飲料，有很多選項像甜度冰塊那些，然後大家都能看到其他人點了什麼，最後可以統計總金額” Claude 的技術建議： Claude 主動分析需求並建議了最適合的技術架構： GitHub Pages（免費網站託管） Firebase Firestore（即時資料庫） 純前端架構（簡化部署） 第二次對話：成本考量與安全防護 我的關切： 這樣會不會需要付費？有什麼成本風險？ Claude 的解決方案： 詳細的免費額度分析：計算實際使用量 vs 免費限制 成本控制建議：密碼保護限制使用者、用量監控設定 多層防護方案：Firebase 安全規則 + 前端限制 第三次對話：功能優化 持續迭代需求： 可以加上甜度、冰塊選項嗎？還有加料的價格計算？ Claude 立即： 擴展菜單資料結構 實作動態價格計算 優化使用者體驗流程 AI 協作的關鍵優勢：上下文理解 整個開發過程中，Claude 始終記得： 專案的技術選型原因 之前討論的成本考量 每次功能迭代的背景 用戶體驗的優先級考量 工程師視角的 AI 協作指南 💡 高效的 AI 協作技巧 ✅ 清晰的需求描述： ❌ 「幫我做個網站」 ✅ 「我想做一個點飲料的網頁，需要有菜單選擇、客製化選項、多人即時協作功能」 ❌ 「加個功能」 ✅ 「我希望加入密碼保護，只有知道密碼的人才能使用系統」 ...