實作文章
Cursor 兩個月實戰連載（2/6）：工具同服務點揀？Astro、Cloudflare、Auth、郵件嘅迷惘
兩個月內，我唔止寫 code，仲喺桌面開咗成堆「選擇題」資料夾：Supabase 設定、Keystatic CMS、Zeabur 裝 NocoDB、候選郵件供應商、登入方式選擇……多數 唔同日子、分開研究，有啲名好長，每個名背後都係當晚真係卡住。Zeabur 帳戶唔係後期先開；同 4 月開始建立 YouOwnClub 差唔多同期註冊，當時同 Cloudflare 一齊評估過部署平台。
5 月初有一日，我甚至開咗個資料夾，名就係「太多嘢要做唔知做乜先好」。當時主線唔係交功課站，而係預約點做、郵件點揀、Blog 點再推上去一齊搶注意力。如果你而家都係咁，你唔孤單。呢篇唔係工具推薦榜；係我點樣由迷惘行到真正上線。YouOwnClub 係 4 月新建，唔係將舊站搬過嚟。
呢篇你會讀到乜
呢篇會講我點樣揀工具同服務：先鎖定自己想解決乜問題，再揀 Astro 或 Remix、Cloudflare Pages 或 Workers、D1 或 Supabase、登入方案（NextAuth、Lucia Auth、Better Auth、Remix Auth）、寄信（實戰以 Resend 為主）、Keystatic 或 Markdown。文中有一段 5 月中旬揀 Auth 嘅 Cursor 對話示例，文末有 選擇疲勞點樣自救（14 日規則、第一版唔做清單等）。技術名第一次出現會有解釋；你唔使一次記晒，跟住我當時次序就得。
先問自己想解決乜問題
我後期總結出一個簡單問題，每次想加新工具之前都問自己：
我而家最想解決乜問題？
4 月，唔係「有咩要交畀用戶」；而係我想自己起好 Blog、主頁、禮品頁同各 LP，各自 GitHub 專案、各自 deploy，管道先通。所以我只需要 Astro、GitHub、Cloudflare Pages、DNS（域名系統，即網址指去邊部伺服器）。
4 月底至 5 月上旬，Blog 行緊嘅同時，主線反而係預約、郵件同「太多嘢要做唔知做乜先好」；交功課站當時未動工。5 月中旬我先將問題收斂成：為將來學生交功課舖路，唔想再長期靠 WhatsApp 傳檔。動工前我用 Cursor Plan 模式（先同 AI 排計劃、確認步驟先改程式）梳理登入、資料庫、權限同第一版做咩／唔做咩，寫好專案說明文件先至開 GitHub 專案；之後先做交功課站第一版（登入、D1、R2、老師後台）。LP 同禮品頁上嘅表單、追蹤、Email 寄送係跟住一路改，唔係 5 月先由零建 LP。
呢個次序好重要。我資料夾入面真係有太早諗嘅題目：funnel 拖曳介面、購物車、預約系統、會員系統。WhatsApp 作業通知反而唔係早期題目；交功課站最小完整流程跑通先至開始諗。
若果唔先問「而家最想解決乜」，而係見到邊個技術名熱就逐個試（今日 Supabase、聽日 Keystatic、後日 Remix、再後日換郵件服務商），好快會變成：網站未上線，腦入面已經計緊第二版、第三版要加咩。每一輪對話都似「更好嘅架構」，但冇一樣真正 deploy 出去畀人用。先鎖定一個具體問題（例如「4 月先搞掂靜態門面，唔要資料庫」），先至被迫每一階段只加一層；加完驗收通，先至諗下一層。
4 月做 Blog 嗰陣，Cursor 亦唔會無端端逼我開資料庫；我會講清楚今次範圍，例如「今個月只要靜態管道」。偶爾佢會順手推介一整條後端架構（例如 Supabase Auth 加 Postgres 加 Edge Functions），睇落專業，但如果跟晒做，Blog 可能仲未上線；嗰時就要自己收窄返，只取而家呢一步。
4 月：鎖定靜態管道（Blog 先行，唔要資料庫）
我同 Cursor 講得零散，唔係成段一次過貼晒；但下面四件事各自都有做過：
- 4 月先靜態門面，唔要資料庫、登入、CMS 後台
- Astro 加 Cloudflare Pages
- 做完一步就對一對（本機預覽或 GitHub），唔一次跳去上線
- 同 Cursor 講明今次範圍（例如「今個月只要靜態管道」），唔跟晒佢一次過砌完整後端架構
真正貼住逐句問嘅，更接近 第 1 篇 截圖嗰種：「應唔應該先起 Astro 骨架？」「本機預覽通咗先至上載？」
我唔係一開波就問「點樣一次過 deploy 上線」。實際次序同 第 1 篇 寫嘅一樣：先去 GitHub 開專案、推第一版做門牌；再喺 Cursor 逐段問點加 Astro 骨架同 Markdown 文章。
同一個 4 月（尤其 4 月下旬），仲做緊主頁連 Blog、頁首頁尾、外觀／logo／捲動動畫、GA4／Clarity／排除自己、PageSpeed、SEO 等靜態工作（逐項順序同坑見 第 3 篇「第四週」「追蹤同 SEO」）。4 月底至 5 月上旬 預約、郵件、表單防刷亦喺第 3 篇「主站營運線」；同期 用 Workers 接 Blog 開錯站（見下文「部署」；DNS 排查見第 3 篇）。
AI 通常每次只答而家呢一步；我亦唔跟晒佢順手推介嘅工具，只取「Markdown 出文、改完可以本機預覽」嗰部分。
我當時用四關驗收，前後唔會跳步：本機預覽見到改動 → GitHub 網頁見到新版本 → Cloudflare Pages build 成功（詳細設定留 第 3 篇）→ 真網址 yourownclub.com 消除快取後同本機預覽一致。任何一關未過，就唔開下一關；唔會預覽未通就急住接域名，亦唔會 build 未綠燈就當上線。
前端框架：Astro 定 Remix？
4 月揀 Blog 用咩起站，我冇逐個試晒十個 JavaScript 框架。Cloudflare Pages 已定，再喺 Astro、Ghost、WordPress 等內容方案之間揀（對照見 第 1 篇）。Remix、Nuxt 呢啲框架名，係後期規劃交功課站嗰陣先同 AI 查過；當時 Blog 專案已經用緊 Astro，唔會成個轉場。Blog 同 LP 以內容為主，Astro 預設靜態輸出，PageSpeed 對內容站好重要。文章放 Markdown 檔，配合 Cursor 改文好直接；詳細睇 無 CMS 批量改 Markdown。
預約系統：「太多嘢要做」嘅主線之一
Blog 管道行緊嘅同時（大約 4 月底至 5 月上旬），我已經卡住預約：諮詢點 book、點提醒、點同郵件串埋。桌面除咗「太多嘢要做唔知做乜先好」，仲有「預約系統點揀」呢類資料夾。我同 AI 睇過成張比較表：Calendly、Cal.com、Acuity、HubSpot 排程、Setmore、SimplyBook.me……每個都話自己最啱，睇完更加唔知揀邊個。
圖：4 月底至 5 月上旬，Blog 行緊之餘，桌面已有「預約系統點揀」等資料夾；同 AI 對照過 Calendly、Cal.com、HubSpot 排程等十幾個名，越睇越難揀。
郵件又係另一條線。兩個月內實際有用嚟寄信嘅，主要係 Resend（交功課站 Magic Link、作業通知；用途電郵被佔嗰陣，改用另一個電郵開戶就得）。Brevo、MailerLite 做電子報或培育信我只係喺資料夾同比較表睇過，無開通、無用到；唔使為「將來可能出電子報」而「揀其中一個」，Resend 已經夠我而家需求。主站聯絡表過渡仍用 GAS（Google 試算表細腳本）；唔想一次開晒好多郵件服務商帳戶。
預約方面，我揀 Cal.com，一部分係因為聽落開源，以為同自己起後台差唔遠。實際用託管版上線之後先發現：訪客主要係去 Cal.com 嗰套流程預約，唔係喺 yourownclub.com 頁面入面完成成個預約。確認同提醒郵件好多時以 Cal.com 名義 發出，品牌感唔會全喺自己網站；通知渠道我當時亦只可以揀一種，唔可以再加多個。我仍然留佢做最小可行版，因為當月只想快啲有預約連結、跟到來源、缺席同會前提醒，唔想再花一個月自建預約後台；但「開源＝自己掌控」呢個諗法，係整出嚟之後先醒。
5 月上旬 有一晚主站表單被 Cloudflare Bot Fight Mode 誤傷，預約相關流程試唔到；隔日同一條線先順利用上。事後我整理出一點：若只做「預約完成後自動寫入你網站資料庫」、寄信同提醒仍主要靠 Cal 內建，體感會接近「直接用 SaaS」；要似 Resend 咁自己網域發信，或者自己資料庫一定有預約紀錄方便跟進高意向客戶，就要刻意留一項，否則「自建」做到邊度會長期模糊。我喺主站寫死最小欄位（電郵、姓名、預約時間、活動類型、預約編號、狀態）同 Cal 導流流程，但 冇預約時間就做唔到絕對時間會前提醒；查詢表單只適合相對跟進，呢點影響我後來點排郵件優先。
我後期用三條問題幫自己止血：14 日內會唔會令收入或轉化有明顯分別？ 唔做呢個月會唔會有清楚損失？ 可唔可以一兩日做個最小版驗證，而唔係開成大計劃？ 兩個 Yes 先做；一個 Yes 排下一輪；全部 No 就擱置。預約、funnel、會員、購物車好多「想做好」嘅位，都係靠呢套問題先離開選擇疲勞；唔係靠再睇多十個工具名。
交功課站：先至諗「高度動態」
規劃交功課站係再後一步。到嗰陣我先知唔再係「改 Markdown 就見到頁」，而係要有登入、列表、上傳呢啲互動。我唔係後台「增刪查改」老手；只係同 AI 查過：交功課站聽落似呢類場景，Remix 有人會推介，話表單同列表更新概念上夾派功課、交功課。我冇用 Remix 起過任何專案，只係睇過 AI 點解釋。
Remix 同 Astro 點揀，都係同 AI 傾出嚟嘅對比：Astro 預設輸出靜態頁、互動位用少量 JavaScript；Remix 偏整頁動態切換，理論上複雜後台好啲。AI 當時歸納做兩條路：留 Astro 就係快啲做完、deploy 簡單；轉 Remix 就係為咗將來做大型 SaaS 式後台。我 5 月第一版要嘅只係「學生登入、派功課、交功課、老師睇到列表」跑通，唔係重做一個可無限擴充嘅 SaaS 後台；所以就算紙上 Remix 好似啱，我都唔會為第一版成個框架轉場。
Remix 我有認真同 AI 對比過，但冇落手轉框架。中間由 Auth.js 改揀 Better Auth 之後，就更唔會成個交功課站重寫。Blog 專案已經用緊 Astro，Better Auth 加 D1 跑得通；第一版要快啲跑通，唔使為「紙上談兵可能更好」轉場。交功課站最後用 Astro 6 加少量 React 互動位同後端接口砌出嚟；對我而家規模夠用，但呢個係做出嚟先知，唔係一開始就好熟後台資料操作。
曾經諗過 Nuxt 或 Next，但第二個 GitHub 專案已定用 Astro 加 Cloudflare。一人公司，學習成本本身都係成本。
部署：Cloudflare 一條龍，但 Pages 唔等於 Workers
我踩過一個坑：一開始用 Workers 去接 Blog，因為 Workers 後台可以直接加 domain，好似唔使喺 Pages 再開 project、再綁網址、再填 build 設定。但 Blog 基本上係靜態 Astro 輸出，唔使亦唔應該用 Workers；結果常見係 build 綠咗，yourownclub.com 開到嘅卻唔似 Blog。funnel、交功課站呢啲要 API 同動態嘅位先值得用 Workers；靜態面同動態面唔可以共用同一套「加 domain 就搞掂」嘅直覺。
Blog 用 Pages；交功課站用 Astro on Cloudflare adapter，落到 Workers，要處理 D1／R2 綁定同密鑰設定。兩條線搞亂，就會「build 成功但網址開錯站」。點解動態產品最後仍集中喺 Cloudflare 一條龍（而唔係 Blog 喺 A、交功課喺 B），Zeabur、Supabase 同 D1 點揀，見下文「資料庫」小節。DNS、SSL（HTTPS 憑證）、CDN（內容分發網絡）係 yourownclub 子域共用入口；第一次轉 DNS，好多紀錄我唔明，只係跟 Checklist 做（排查順序見 第 3 篇）。深度對照睇 Cloudflare 服務點揀 同 Pages 五個常見錯誤。
4 月中：改 SEO 同 GA4 嗰陣，DNS 越改越亂
踩坑大概喺 4 月 24 日前後。同一輪我仲喺改 GA4／Clarity、外觀、logo、捲動動畫、PageSpeed、SEO；桌面資料夾「加入各 SEO 及改唔用 worker 後連結出問題解決」就係一路改 DNS、改連結，越改越亂，唔係 code 壞咗。
我同 Cursor 講嘅唔係成段咁整齊，大意係：開住 Blog 專案嗰個對話，真網址開錯；請分清楚 Blog 應該用 Cloudflare Pages，唔好用 Workers 頂靜態站；唔好改 現有文章檔。搞掂之後我先固化：靜態面（Blog、主頁、LP）用 Pages；要 Workers 嘅（funnel、交功課站）先喺 Workers 加 domain、處理綁定設定。
資料庫：Supabase、D1，定先唔要 DB？
4 月 Blog 階段，我刻意唔要資料庫。內容就係檔案，Git 就係版本歷史，簡單到近乎無聊，但上線快。
D1 一開始其實唔係我嘅首選；我唔想所有嘢都綁死 Cloudflare。後來做播放學習器（影片逐句循環、自動暫停嗰類工具），諗住用 Supabase 頂住，以為可以唔使整登入就開工。點知開 project 幾日後，收到提醒：大約七日左右 inactive 就會 pause project，仲叫你考慮 Pro plan。功能仲係試驗階段就要付月費，我唔接。
到 5 月交功課站一定要有資料庫，我就改揀 D1：資料庫更新腳本同 GitHub 專案一齊留版本，同已經用緊嘅 Workers、R2 同一個帳戶。唔係事後諸葛亮式「Cloudflare 最好」，而係 Supabase 免費版嘅使用節奏同我當時唔夾。
Zeabur 帳戶同建立網頁差唔多同期已開；早期亦試過喺上面裝 NocoDB（連資料庫、表格睇數據嘅開源工具），想睇有冇簡單後台可用。交功課第一版最終仍用 D1，唔需要為 NocoDB 再多維一個 Zeabur 服務。
Auth：NextAuth、Lucia、Better Auth、Remix Auth 點揀？
交功課系統一定要登入。登入方案對照留咗好長對話；我逐個睇過 NextAuth（而家文件多寫 Auth.js）、Lucia Auth、Better Auth、Remix Auth，唔係一開始就鎖死 Better Auth。
NextAuth 生態最大，教學文多；我一度沿 Auth.js 方向睇，但 Astro 加 D1 要自己接適配器，Magic Link 同登入狀態點寫入用戶表要花時間對清楚，後來改揀 Better Auth。Lucia Auth 我本來幾想揀：較輕巧、概念清晰；但查落去發現已經停更新（作者轉做維護模式，唔再新功能），教學方第一版唔想用可能冇後續嘅套件，就排除。Remix Auth 同 Remix 框架一併擱置（見上文「Astro 定 Remix？」）。Better Auth 最啱我當時想解決嘅問題：內建 Google 登入同 Email Magic Link；有 D1 適配；登入狀態同用戶資料表配好；喺 Astro 後端接口運行，唔使另開登入伺服器。
真正迷惘位唔係「揀邊個登入套件」，而係 Magic Link 寄信要接郵件 API。交功課站用 Resend；本機設定檔同正式環境密鑰要成對設定；搞錯就「收唔到信，以為登入壞咗」，其實只係 mail 設定錯。
Cursor 對話情境（5 月中旬）：Auth 加 D1
（開住交功課站專案）
交功課站第一版要 Google 登入 + Email Magic Link。
資料庫已經用 Cloudflare D1，唔想用 Supabase Auth。
我已經睇過 NextAuth（Auth.js）、Lucia Auth、Better Auth、Remix Auth。
請用表格比較佢哋喺 Astro + D1 嘅接入成本同 Magic Link 支援。
我而家只要建議同最小接入步驟。Cursor 列出 Better Auth 要填嘅設定清單；我對照過其他方案：Lucia 查到停更新後排除；Remix Auth 連住 Remix 轉場一併擱置；最後揀 Better Auth 做第一版。逐項填本機設定，每填一項試一次登入。
郵件：Resend
兩個月內寄信實戰以 Resend 為主，見上文「預約系統」段旁嘅郵件小節。呢度只補一個教訓：唔好未驗 DNS 就改 template；以為「改咗 code 就收到新內容」，原來 production 未 deploy 或 DNS 未驗證完成，空等半日。
CMS：Keystatic 好靚，但我揀 Markdown
Keystatic 連 GitHub 嘅編輯模式我玩過，介面好靚。Blog 仍然用 Markdown 加 Cursor：一人出文，唔需要編輯器權限管理；Git 本身就係版本歷史；少一層 OAuth、Cloudinary 設定。唔係最潮先至最好，而係最少組件。
選擇疲勞點樣自救
資料夾標題變成「購物車系統點揀」「留言系統點揀」同時存在，我做咗三件事：寫第一版唔做清單；每個 GitHub 專案一份主線文件；同 Cursor 講清楚開邊個專案、附邊份規格文件。
同現有教學文嘅分工
呢篇係決策敘事。Cloudflare 設定睇 Cloudflare 服務點揀。Markdown 出文睇 Astro 內容工作流。
本篇小結
點揀工具唔係一次過揀「最佳組合」，而係跟問題一層層加：4 月靜態管道；4 月底～5 月上旬預約同郵件；5 月中旬交功課站先有 D1、R2、Better Auth。選擇疲勞好常見；自救靠「而家最想解決乜」、第一版唔做清單、同 Cursor 講清楚專案同文件範圍。下一篇進入 4 月 Blog 上線實戰。
下一篇預告
第三篇進入 4 月 Blog 上線同 5 月上旬主站收尾：deploy、GTM/GA4、預約郵件表單，至開交功課站之前。你會見到，上線唔靠天才，靠 Checklist 同本機預覽通咗先上載、再用瀏覽器消除快取驗收。
常見問題 FAQ
一人公司應該一次過揀齊「全套工具同服務」先開工嗎？
唔好。先問自己想解決乜問題，再揀最少組件。4 月先將 Blog、主頁、禮品頁同 LP 分開上線；5 月先做交功課站（登入、資料庫、檔案上傳）。
Cloudflare Pages 同 Workers 有咩分別？
Pages 適合靜態站同 Astro build 輸出；當你要 API、session、D1、R2 一齊跑，通常會落到 Workers 或 Astro on Cloudflare adapter。我交功課站係後者。
交功課站點解唔用 Remix？
交功課站聽落似「新增、查閱、修改、刪除」呢類後台場景；我唔係呢方面老手，只係同 AI 查過同對比 Remix，冇真正用 Remix 起過站。Auth.js 改揀 Better Auth 之後，冇再成個框架轉 Remix；Blog 專案已有進度，第一版要快啲跑通。
點解最後唔用 Supabase？
起初我唔太想加深 Cloudflare 依賴，D1 唔係第一選擇。做播放學習器嗰陣諗住用 Supabase、以為可以唔使自建登入；但 project 開咗幾日，收到約莫七日 inactive 就 pause、叫你升 Pro 嘅提醒。交功課站要資料庫嗰刻，就改定用 D1，同 Pages、Workers、R2 同一 Cloudflare 帳戶，維護路徑短啲。
About me
你好，我係阿丸。呢度以數位主權為核心，分享點樣用 AI 幫手整網頁、建立吸客贈品頁、整理內容同上線作品， 目標係幫你用更短時間把內容同網站做成可帶走、可維護嘅自有資產。
我會持續更新可跟做嘅教學、踩坑記錄同流程模板，等你唔使被平台黑盒綁死，亦唔使再由零重複試錯。
同時呢度會多寫一人公司最常遇到嘅訂閱制現實：工具加價、用量隱形成本、平台綁定風險， 同埋點樣用可執行嘅做法，將名單、主站同漏斗慢慢揸返喺自己手度。
你會見到嘅內容包括：支出檢視框架、用量上限與警報、搬遷前準備同主權策略；目標唔係一夜換晒工具， 而係先止血，再建立長期可維護嘅自有資產。
想先攞可跟做模板同檢查清單？
先由免費吸客贈品包開始，將文章做法變成你可即用嘅落地清單，再按需要對照服務範圍安排下一步。
想睇合作模式同交付範圍，可先睇服務與合作方式。