跳到正文
Chandler Nguyen
AI閱讀時間6分鐘

AI

Migration 之後發生乜事:8 日嘅複利回報

我將個 blog migrate 到 Next.js,以為最難嘅部分已經過咗。然後複利開始——8 日內 6 篇 mega guide、一個更醒嘅 AI 助手、原生 newsletter、bot 保護同 SEO 大翻新。

八日前,我用 4 日 rebuild 咗成個 blog backend。我將 485 篇 WordPress 文章 migrate 到 Next.js,令 Sydney(我嘅 AI chatbot)復活,同 ship 咗一個 production site。

我以為呢個就係個故事。Migration done,慶祝,move on。

我錯咗。Migration 唔係終點——佢係起跑線。

以下係我個 site 喺 2 月 5 日 vs 今日嘅對比:

Feature2 月 5 日(Migration 當日)2 月 13 日(今日)
Blog posts485(由 WordPress migrate)492(6 篇新 mega guide)
Sydney AI基本 RAG,未測試過質量評估過、優化過、81% hit rate
NewsletterBeehiiv embed(第三方)原生 Supabase + Resend,按興趣分
SEO基本 sitemap + meta tagsStructured data、FAQ schema、llms.txt、AEO
安全只有 rate limitingCloudflare Turnstile + rate limiting
性能基本 Lighthouse check用 Chrome DevTools MCP 做系統性 profiling
Featured images手動整AI 生成 pipeline(Gemini + auto-optimize)

每一個改進嘅發生都係因為前一個令佢變得更容易。呢個就係我冇預期到嘅複利。


Unlock:你嘅 Blog 而家係 Code

冇人會話你知由 WordPress migrate 到 code-based stack 之後嘅一件事:migration 本身唔係重點。 重點係之後變成可能嘅嘢。

當你嘅 blog 係 Git repo 入面嘅 492 個 MDX 檔而唔係 MySQL database 入面嘅 row,一切都變咗:

  • 每篇文章係一個檔 — Claude Code 可以大規模 read、search 同 modify
  • 每個改動係一個 diff — 你可以 review 50 篇文同時改咗乜
  • 每個 feature 係 composable — 你嘅 newsletter system 可以讀同 AI chatbot 一樣嘅 post metadata
  • 每次 deploy 係一個 commandpnpm build && vercel --prod,搞掂

用 WordPress,update 12 篇 blog post 意味住 login wp-admin、逐篇 click、改嘢、update、repeat。用 MDX 檔同 Claude Code?我可以話「喺所有 12 篇現有公園指南加返國家公園 pillar post 嘅 link」然後佢就 read 每個檔、喺啱嘅 context 加啱嘅 cross-link、然後 show 我 diff。全部 12 個 update 幾分鐘搞掂。

呢個就係 unlock。唔係 migration。係之後嚟嘅 velocity


4 日寫 6 篇 Mega Guide

Migration 之後我 build 嘅第一樣嘢?Content。好多。

我想咗幾個月寫全面嘅 expat 指南——嗰種 2,000-4,000 字嘅 pillar post,真正幫到正喺搬到美國嘅混亂中嘅人。WordPress 令呢件事好痛苦。每篇文要手動 formatting、upload 圖片、設定 SEO plugin、管理 category。

而家?Pipeline 係咁嘅:

  1. Brainstorm 文章結構同大綱
  2. 成篇 MDX,SEO/AEO 優化一齊做
  3. 生成 featured image — Claude 讀篇文、寫 prompt、send 去 Gemini 生成圖
  4. Optimize — Python script 轉 WebP、壓縮 for web
  5. Upload 去 Vercel Blob
  6. Publishgit pushvercel --prodpnpm db:publish
  7. Sydney 即刻知 — 篇文 sync 到 Supabase 連 embedding

以下係嗰 4 日 ship 咗嘅嘢:

文章題目字數
Healthcare 指南HSA、FSA 同 HDHP 解釋~3,200
Credit Building由零到 720+ credit score~3,500
儲蓄同投資T-Bills vs HYSA 比較~2,800
信用卡 RewardsPoints、miles、cashback 策略~3,000
搬遷指南完整搬到美國 playbook~3,800
國家公園26 個公園、4 條 road trip~4,200

每篇文都跟同一個 AEO pattern:answer-first 開頭、comparison table、120-180 字 section、bold 定義、底部 FAQ schema。呢種結構可以獲得多 340% 嘅 AI 引用

國家公園指南係最大嘅——一篇 pillar post link 返 12 篇現有嘅公園 review。我同時 build 咗一個 PhotoGallery component,因為 scroll 過 20 張獨立圖片好恐怖。而家係一個乾淨嘅 grid 加 lightbox。簡單,但有效。


Sydney 變聰明咗

當我喺 migration 期間復活 Sydney,佢係 work 嘅——我 launch 前手動測試過。佢可以答問題、搵相關文章、cite sources。但手動測試只會話你知「呢個 seem okay」。佢唔會話你知 幾 okay,或者邊度有 gap,或者點樣改善。

我冇系統性嘅方法量度質量——冇 measurement 就冇辦法改善。

所以我 build 咗一個 RAG evaluation framework。32 個測試 query 涵蓋 12 個 category,每個都有我 hand-curate 嘅 expected result。好似「Expat 應該攞咩信用卡?」應該 return credit building 指南。「同我講 Yosemite」應該 return Yosemite 遊記。

然後我測試咗 30 個唔同嘅設定組合——6 個 similarity threshold × 5 個 result count——量度 hit rate、precision 同 temporal diversity。

結果令人大開眼界:

指標之前(Default)之後(Optimized)
Hit rate~30%81.2%
Zero-hit queries30 個入面 6 個30 個入面 0 個
Temporal spread1.2 年6.7 年

最大嘅 fix 係尷尬嘅:OpenAI SDK 喺 Next.js 下面靜靜 drop 咗 dimensions parameter。Sydney 生成緊 1536-dimension embedding 但 search 一個 384-dimension index。難怪結果差。轉用直接 fetch() call 一晚之間就 fix 咗。

我同時擴展咗 Sydney 嘅 system prompt 涵蓋所有 490+ 篇 blog 嘅題目——佢而家識講國家公園、信用卡、healthcare 同完整嘅 expat 內容庫。唔再只係 AI 同 marketing。

兩個 command 自己試:

pnpm eval:rag        # 用 local Supabase 測試
pnpm eval:rag:prod   # 用 production 測試

而家我可以真正量度 Sydney 幾時變聰明。呢種 infrastructure 你喺 WordPress 永遠唔會 build。


大規模做 SEO 同 AEO

2026 年嘅 SEO 唔再只係 Google。佢係關於當有人問你嘅內容可以答嘅問題時,被 ChatGPT、Perplexity 同 Claude 引用。

我喺一個 weekend 做咗完整嘅 SEO/AEO stack:

傳統 search:

  • 動態 sitemap(639 頁 indexed)
  • Structured data — Person、WebSite、Article、BreadcrumbList、FAQPage schemas
  • RSS feed for syndication
  • Google Search Console verified

AI 引擎(AEO/GEO):

  • llms.txt — 俾 AI crawler 嘅 priority content guide(GPTBot、Claude-Web、PerplexityBot 全部喺 robots.txt 俾入)
  • 每個 section 開頭嘅 answer-first pattern(頭 150 字嘅 bold key statement)
  • 問題格式嘅 H2 配合人問 AI 助手嘅方式
  • FAQ section 自動偵測並 render 成 FAQPage schema

性能: 我用 Chrome DevTools MCP profile 唔同嘅頁面類型——homepage、blog listing、個別 post、/ask 頁面——同搵出 bottleneck。可以喺同一個 Claude Code session run performance trace、分析結果、fix 問題係⋯⋯不合理地高效。

結果?我寫嘅每篇新文自動有 structured data、FAQ schema(如果有 FAQ section)、同 format for AI extraction。冇 plugin。冇手動設定。呢個就係 site 而家嘅運作方式。


Beehiiv Out,原生 Newsletter In

呢個令我意外。我有一個喺 Beehiiv 運作嘅 newsletter。佢收 email。佢 send 更新。點解要換?

三個原因:

  1. 控制 — 我想要按興趣嘅 subscription。「AI 同科技」嘅訂戶唔應該收到國家公園內容。Beehiiv 免費 tier 唔 support。
  2. 整合 — 我嘅訂戶數據而家同 Sydney 嘅 search index 住喺同一個 Supabase database。One source of truth。
  3. 成本 — Supabase(free tier)+ Resend(free tier for low volume)= $0/月。

我 build 嘅系統:

  • Double opt-in — subscribe → verification email → confirmed → welcome email 連個人化推薦
  • 5 個興趣 group — AI、Expat Life、Leadership、Marketing、Travel & National Parks
  • Smart matching — post category 自動 map 到訂戶興趣。當我 publish 信用卡指南,只有「Expat Life」訂戶收到通知。
  • Daily cron — Vercel 喺 PST 11 AM run job,搵過去 48 小時嘅文章,send targeted 通知
  • Deduplicationnotification_log table 防止重複 email,永遠

最正嘅部分?每篇 blog post 底部嘅 subscribe form 根據文章嘅 category 自動 pre-select 相關興趣。睇緊 AI 文章?當你 scroll 到底 subscribe 嗰陣「AI 同科技」pill 已經 pre-selected。

由零開始 build 呢個聽落好多工。大約一個晚上嘅 focused effort。Supabase migration、API routes、email templates 同 cron job — Claude Code handle scaffolding 而我 focus logic 同 copy。


安全:隱形直到你需要

有一個 public-facing AI chatbot 同 newsletter signup,我有兩個 bot 最鍾意 abuse 嘅 endpoint。Rate limiting 已經有(Upstash Redis,每分鐘 5 個 request),但我想要第二層。

Cloudflare Turnstile 登場——一個隱形 CAPTCHA,只係喺懷疑可疑活動先 show challenge。99% 嘅真實訪客完全隱形。對 bot?一道牆。

我先加喺 /ask endpoint(Sydney chat),然後用完全一樣嘅 pattern 加喺 /api/subscribe。同一個 verification library、同一個 graceful degradation:

  • 冇設定環境變數 → bypass(local dev 唔需要)
  • Cloudflare API down → fail-open(rate limiter 做 fallback)
  • Token missing 但 secret key 有設 → reject(捉到 bypass frontend 嘅 bot)

呢個 reuse 就係點解係 compounding 嘅故事。Newsletter 嘅 Turnstile integration 用咗幾分鐘而唔係幾個鐘,因為 infrastructure 由 Sydney 嗰度已經有。


複利效應

以下係我冇 plan 但自然發生嘅嘢:

Migration 到 Next.js(2 月 1-5 日)
  └─→ MDX 檔令 Claude Code 可以大規模 read/modify 內容
       └─→ 6 篇 mega guide 寫好連 SEO/AEO 優化(2 月 6-11 日)
            └─→ 新內容暴露 Sydney 嘅搜索質量問題
                 └─→ RAG eval framework build 好,Sydney 優化(2 月 11 日)
                      └─→ 更多內容需要 newsletter(唔係 Beehiiv)
                           └─→ 原生 newsletter build 喺 Supabase 上(2 月 12 日)
                                └─→ Public endpoint 需要 bot 保護
                                     └─→ Turnstile 加到 Sydney + subscribe(2 月 12-13 日)

冇一個係作為 sequence plan 嘅。每一個 reveal 下一個需要。Migration 令內容創作快。快嘅內容創作暴露搜索質量 gap。Fix 搜索令我想要更好嘅 distribution。更好嘅 distribution 需要保護。

呢個就係複利。 每個改進唔止係加 value——佢 multiply 之前所有嘢嘅 value。 :)

而條 common thread 穿過所有嘢?我 site 嘅每一部分而家都係 code,可以被 programmatically read、test 同 modify。呢個就係真正嘅 unlock。


數字

因為我知你想知:

指標數值
Migration 以來嘅日數8
新 blog post7(包括呢篇)
新 feature shipped6(newsletter、Turnstile ×2、RAG eval、SEO stack、PhotoGallery)
Blog post updated12+(cross-linking、broken link fix)
新增 code 行數~5,600
新增 database table2(subscribers、notification_log)
新增 API endpoint4(subscribe、verify、unsubscribe、cron)
成本增加$0/月(全部 free tier)

What's Next

我仲未完。Compounding 仲未停:

  • 更多 expat 指南 — 稅務策略、簽證時間線、銀行比較。呢個系列有腿。
  • Sydney 繼續變聰明 — 而家我可以量度質量,我想將 hit rate 推過 90%。
  • 更多用 AI build 嘅 deep dive — 啲工具每個星期都喺進化。我邊做邊記錄。(最新:喺唔識 Swift 嘅情況下 build 原生 iOS app,同發現 AI 帶你去到 60%——最後嘅 40% 先係 product 真正所在。)

但老實講?我主要只係興奮可以繼續寫。17 年 blogging 以來第一次,publish 新文真正係好玩——唔再係 45 分鐘嘅 WordPress 苦差。 :D

你有冇試過 migration 或大嘅技術決定之後呢種 compounding?我好奇——你第一個意料之外嘅 unlock 係乜?

祝好,

Chandler


常見問題

網站開發入面嘅複利效應係乜?

複利效應係當你 site 嘅每一個改進令下一個改進變得更快更容易。 例如,migrate 到 code-based stack 令 AI 輔助嘅內容創作成為可能,呢個暴露咗搜索質量問題,呢個帶到 build evaluation framework。每一步都 build on 前一步。

點樣優化 blog post for AI 搜索引擎?

AI 搜索引擎偏好結構化、answer-first 嘅內容配清晰嘅 heading 同精簡嘅 section。 關鍵技巧包括:頭 150 字嘅 bold definitional statement、問題格式嘅 H2 heading、comparison table、120-180 字嘅 section 同 FAQ schema。呢啲 pattern 可以獲得多達 340% 嘅 AI 引用。

RAG evaluation framework 係乜?

RAG evaluation framework 測試你嘅 AI 助手搵到同 return 相關內容嘅能力。 佢用預定義嘅 query 配 expected result(ground truth)同量度 hit rate、precision 同 temporal diversity 等指標。呢個令你可以系統性優化搜索設定而唔係靠猜。

點解用自定 newsletter system 取代 Beehiiv?

自定 newsletter system 俾你完全控制訂戶數據、按興趣 targeting 同同你現有 database 嘅整合。 用 Supabase + Resend build,我得到按興趣嘅 subscription、自動通知同 $0/月 hosting——全部同 Sydney 嘅 search index 整合。

Cloudflare Turnstile 同傳統 CAPTCHA 有咩分別?

Cloudflare Turnstile 係一個隱形嘅 bot 偵測系統,只對可疑訪客 show challenge。 唔似傳統 CAPTCHA 要每個用戶解 puzzle,Turnstile 對合法用戶靜靜運行。佢用 browser signal 偵測 bot 而唔打斷用戶體驗。


仲喺 code、仲喺學、仲喺睇住 compound interest 增長。