Posts

在建立這個個人網站的過程中，我一直有一個兩難：我希望能用自己最熟悉、最有溫度的母語（繁體中文）來記錄與創作，但同時，我也渴望與世界接軌，讓更多英文母語者或是對我的技術文章感興趣的國際讀者，有機會看到這些內容的潛力。 此外，從技術部落格的經營角度來看，雙語內容對於搜尋引擎優化（SEO）也有著顯著的幫助，能夠為網站帶來更廣泛的自然流量。 為了解決這個問題，我沒有選擇花費大量時間手動翻譯，也沒有強迫自己改變寫作語言，而是決定利用 AI 的力量來自動化這個流程。 專注於創作，把翻譯交給 AI 我最近在網站上實作了一套基於 GitHub Actions 與 Gemini API 的自動化翻譯工作流： 維持原本的寫作習慣：我只需要專注於用中文撰寫 Markdown 文章。 自動觸發翻譯：每當我把新文章 push 到 GitHub 上，GitHub Action 就會在背景自動執行 Python 腳本。 Gemini 接手處理：腳本會掃描尚未有英文版本的文章，呼叫 gemini-2.5-flash 模型，自動將內文精準翻譯成流暢的英文。 自動更新網站：翻譯完成後，腳本會自動把內容包裝成中英文切換的 HTML 區塊，並將修改直接 commit 回 repository。 現在，你在這篇文章（以及網站上的其他文章）上方，應該能看到一個「🌐 切換為英文 (Switch to English)」的按鈕。這一切都是自動發生的，我完全不需要介入。 這樣一來，我不僅保留了寫作的純粹與樂趣，也同時賦予了這個網站觸及全球讀者的能力。 未來的計畫：走向更現代化的架構 雖然目前的做法已經能很好地滿足「專注創作＋自動翻譯」的需求，但我知道這個網站還有進步的空間。 為了提供更好的閱讀體驗與效能，我之後會繼續嘗試將網站架構遷移到更輕量化、載入速度更快的 Astro.js，並結合 Astro 原生的地區適應（i18n / Localization）功能，讓雙語切換不僅僅是內文的隱藏與顯示，而是從網址結構、Metadata 到介面語系都能完美適配的現代化架構。 世界很大，語言不該是我們分享知識的障礙。接下來，就讓 AI 繼續幫我把這些文字，翻譯給更多需要的人吧！

如果剛才有在關注這個網站的讀者，可能會發現網站在幾個小時內經歷了一次劇烈的「陣痛期」——也就是切換語言時畫面直接一片空白死機。 但經過一番搶修與大改版，我很高興地宣布：這個網站已經正式升級為「原生雙語架構 (Bilingual Native)」了！ 拋棄 Hacky 的 CSS 隱藏法 在上一篇文章中，我提到使用 AI 來自動翻譯文章。當時的做法其實非常「Hack」：我讓 Python 腳本把翻譯出來的英文，跟原本的中文一起塞在同一個 Markdown 檔案裡，然後利用自訂的按鈕和 CSS 的 display: none 來強制隱藏或顯示對應的語言區塊。 這種做法雖然快速，但遇到了不少致命缺點： 排版容易崩潰：如果文章裡面有複雜的 HTML 標籤（比如置中圖片的 <div>），腳本的 Regular Expression 一個不小心就會把文章直接從中間「截斷」，導致整個網頁 HTML 結構壞死（這也是剛才網站全白死機的元兇）。 對 SEO 極度不友善：搜尋引擎爬蟲一次會把中英文全都爬進去，它根本不知道這個網頁到底是什麼語言。 遷移困難：未來如果我要把網站搬家到效能更好的 Astro.js，這種充滿自訂標籤的單一檔案絕對是一場災難。 擁抱 Hugo 原生多語系 (i18n) 痛定思痛後，我決定花點時間，把架構徹底重構成最標準、最正規的做法——使用 Hugo 內建的 i18n (Internationalization) 機制。 1. 檔案物理分離，保持純淨 現在，我依然只需要專心寫純中文的 Markdown 文章（例如 article.md）。 當我把文章 Push 到 GitHub 時，背景運行的 GitHub Actions 與 Gemini API 會自動偵測這篇新文章，並把它的標題、摘要、內文全部翻譯成流暢的英文。 最關鍵的差異在於，腳本不再把英文塞回原本的檔案，而是自動產生一個獨立的 article.en.md 檔案。這讓我的中文原始檔保持絕對的乾淨，沒有任何多餘的程式碼干擾閱讀或後續編輯。 2. 全站雙語化與 SEO 提升 受惠於原生架構，現在不只是「單篇文章」有英文版，而是**「整個網站」都有了專屬的英文空間**！ ...

從 Geoguessr 的「找膠帶」玄學，看深度學習的捷徑學習（Shortcut Learning）迷思，我們如果太依賴某特徵會發生什麼事情？ 1. 那些被丟在荒郊野外的日子：Vibe Guessing 的浪漫 自從結束交換學生的日子後，我意外迷上了 Geoguessr 這款遊戲。它的魅力在於不用下載任何 App，打開瀏覽器就能隨時隨地被「隨機空投」到世界某個角落。在玩這款遊戲時，我不僅能複習曾經走過的街景，還發現自己漸漸長出了一種超能力——「Vibe guessing（直覺流）」。 多虧了在歐洲遊走的經驗，我開始能用直覺去感受一個地方的「氣味」：不依賴那些主流的meta側面破解技巧，而是靠著建築的冷暖色調、路邊植物的生長姿態，甚至是一種難以言喻的「破敗感」或「秩序感」來定位。雖然這種黑盒子演算法偶爾會讓我大落漆（把南美洲猜成東歐之類的），但這種真正用雙眼去感受地理的過程，才是遊戲靈魂。 2. Meta 玩家的玄學：現實世界沒有長著涉水管的 Google 車 但與此同時，我對 Geoguessr 圈內極度推崇的「Meta 策略」抱持著高度懷疑。 什麼是 Meta？高階玩家被丟到荒郊野外時，他們第一時間不是看風景，而是低頭看 Google 街景車。他們透過記憶 Google 街景車在各國的收錄瑕疵來上分： 「車頂有黑膠帶？這絕對是迦納。」 「車頭右邊有一根涉水管？不用看了，肯亞。」 「天空有明顯的第三代鏡頭接縫光暈？定位塞內加爾。」 這確實很聰明，也是遊戲規則內的完美必勝法。他們繞過了真正需要龐大知識量的地理分析，直接破解了題庫。但荒謬的是，如果今天把這些 Meta 玩家丟到真實世界的肯亞，他們會迷路—— 因為現實中的肯亞街頭，並沒有那台長著涉水管的 Google 街景車跟著他們。 3. 演算法也是個功利的玩家：什麼是 Shortcut Learning？ 把場景換到 AI 領域，深度學習模型其實就是個死命想上分的 Geoguessr 玩家。 不管是在電腦視覺還是對抗性攻擊與防禦（Adversarial Attack/Defense，我最近跟者羅紹元老師的腳步在研究）中，模型唯一的目標就是把 Loss 降到最低。它才不管什麼大局觀，只要能最快達到目的，它就會毫不猶豫地走捷徑。 這在機器學習裡被稱為 捷徑學習（Shortcut Learning） 。 模型並沒有學會我們期望它學會的「真正特徵」，而是學到了「資料集裡的統計相關性（或是瑕疵）」。只要這個帶有強烈訊號的捷徑特徵一消失，模型的預測能力就會瞬間崩盤，毫無泛化性（Generalization）可言。 4. 殺傷力極強的隱形炸彈：相關性不等於因果關係 Shortcut Learning 在機器學習各個領域都是個災難，而且它比我們常說的Overfitting更難被發現、殺傷力更高。 Overfitting 是模型死背了訓練集，但在驗證集就會露餡。但 Shortcut Learning 可怕的地方在於，如果你的驗證集也包含了同樣的瑕疵，模型的表現會堪稱完美。 這就像經濟學和統計學裡常被拿出來鞭的鐵則：「相關性不代表因果」。模型只看到了高度相關，卻搞錯了因果。 套用回 Geoguessr 的比喻：如果哪天 Google 官方來個大更新，用 AI 把所有街景車的特徵、天線、膠帶全部 P 掉，那些高度依賴 Meta 的玩家積分絕對會迎來史詩級的雪崩。 ...

最近在盤點 datafox.tw 的後台數據時，我發現了一個非常殘酷的現實：我花了大把時間寫的某些硬核技術文章，在搜尋引擎和 AI 爬蟲的眼裡，幾乎是隱形的。在 2026 這個 AI SEO 與 GEO（Generative Engine Optimization，生成式引擎最佳化）主導注意力的時代，我忘記以EEAT為核心，這是一個非常致命的戰略失誤。 🔍 根本問題：我正在嘗試跟全世界最強的巨頭搶同一個關鍵字 我之前寫過一篇探討 flash vs thinking kv cache test time compute 的文章。我以為這篇技術含量很高，應該能獲得不錯的自然流量。結果呢？數據一片死寂。 原因很簡單：這是一個純粹的「主題型」關鍵字。當使用者或 AI 去搜尋這個詞時，我這個剛建立不久的 datafox.tw 新網域，要面對的競爭對手是誰？是 arXiv 上的頂級論文、是 Pure Storage 的官方技術部落格、是 Substack 上累積了大量反向連結的資深 AI 研究者。在這些權重極高的巨頭面前，我的文章就算寫得再好，也只會被淹沒。 對比之下，那些帶有我個人標籤的搜尋，例如 datafox llm 或 datafox ntu，我卻能穩穩佔據第一。這揭示了一個殘酷的事實：如果文章沒有綁定「你是誰」，那它就只是一篇隨時可以被取代的普通科普文。 🦊 資訊是可取代的，但「實體」不行 AI 時代，知識的獲取成本已經趨近於零。如果我只寫一篇「如何用 GitHub Actions 自動化更新網站」，這件事 AI 隨便都能幫你生成出十幾種完美版本。 但什麼東西是 AI 暴力破解也學不來的？是脈絡性與個人經驗。 同樣是自動化更新，如果我寫的是：「這隻叫 Datafox 的狐狸，他是怎麼一邊在台大讀資料科學，一邊在 Google 實習，並用這套自動化系統搞定他的周報？」 這種帶著真實血肉的經驗，AI 搬不走。 在未來的 AI 知識圖譜裡，我不需要成為全網最懂 GitHub Actions 的人，但我可以精準搶奪到「自動化 + 資料科學碩士」這組獨一無二的標籤交集。 ...

在深入研究 LLM 應用與 Agent 系統的過程中，我實在對業界那種「AI 馬屁精」式的玄學行銷感到反胃。現在廠商動不動就愛吹自家的新模型「會思考」、「有邏輯」，彷彿加了一個 “Pro” 或 “Thinking” 的後綴，神經網路就突然長出了人類的大腦。我們如果不採取懷疑與質問的態度，很容易就會被這些漂亮話牽著鼻子走。今天我們就冷酷地從底層運作機制與物理限制出發，拆解 Flash 模型與 Thinking 模型真正的差異，以及那些所謂的「思考過程」到底是什麼。 1. 根本不是「想久一點」：訓練目標與機率分佈的差異 很多人以為 Thinking 模型只是 Flash 模型跑得比較久，或者我們透過 Prompt 叫它「你想仔細一點喔」。這完全是個誤解。 Flash 模型的訓練目標是追求極致的推理速度與低延遲，它依賴強大的壓縮記憶和直覺式的 Pattern Matching。而標榜推理的 Thinking 模型，是在訓練階段引入了大量的RL，被「刻意訓練」成在給出最終答案前，必須先產生一長串的內部推理軌跡（Chain of Thought）。 無論是哪一種，它們本質上依然是在做 Next-Token Prediction。我們來看自迴歸生成最核心的機率公式：P(Y | X) = 根據過往生成的X個token 預測目前要接龍的下一個token Y的sampling長什麼樣子。 給定輸入 X，模型每一步都是在計算下一個 Token y_t 的最大條件機率。Thinking 模型並沒有跳脫這個框架，它只是被訓練成在生成最終答案的 y 之前，先利用這個公式接龍出一大堆中間步驟。 2. KV Cache 的暴力美學：破除「重新計算」的直觀迷思 既然是接龍出思考過程，這就帶出了第二個嚴重的迷思。很多人直觀地以為，Thinking 模型的運作方式是： 原始問題 -> 產出思考步驟 1。 接著把「原始問題＋思考步驟 1」整包重新餵給 Transformer -> 產出思考步驟 2… 就這樣像俄羅斯娃娃一樣越疊越大。 如果真的是這樣運作，GPU 的算力早就原地爆炸了。真正的底層魔法，在於 KV Cache（Key-Value Cache）。 ...

當時的我會覺得，Decoder 說穿了根本只是看著輸入做「文字接龍」，沒辦法預先知道整體要生成什麼。但現在回頭看，如果我們不跟著那些 AI 馬屁精瞎起鬨、講一些「因為 GPT 比較有靈性」的漂亮話，而是冷酷地從Information Theory與工程現實的底層來拆解，你會發現 Decoder-only 的勝出，根本是一場數學與物理限制下的必然。 1. 統一架構的暴力美學：交叉熵與自作聰明的代價 Seq2Seq 雖然邏輯清晰，但它把「理解」與「生成」拆成兩個模組，其實在數學目標函數上「自我閹割」了資訊壓縮的純粹性。 我們回到機率與資訊理論最純粹的定義——熵的鏈律（Chain Rule for Entropy）： $$H(X_1, X_2, \dots, X_n) = \sum_{i=1}^{n} H(X_i | X_{i-1}, \dots, X_1)$$ 這條公式告訴我們，要量化一段人類語言的總體不確定性，最完美、最無損的拆解方式，就是去計算「在給定所有歷史資訊的情況下，下一個字的條件熵」並全部加總。 而 LLM 每天在跑的 Next-Token Prediction，其損失函數本質上就是最小化真實世界人類語言分佈 $p$ 與模型預測分佈 $q$ 之間的交叉熵（Cross-Entropy）： $$H(p, q) = H(p) + D_{\text{KL}}(p \parallel q)$$ 這裡面的物理意義非常優雅：$H(p)$ 是「上帝的熵」，人類語言本身自帶的終極亂度；而 KL 散度 $D_{\text{KL}}(p \parallel q)$ 則是模型因為不夠聰明，導致我們在進行接龍時，平均每一步要多付出的資訊代價（雜訊）。優化模型的終極目標，就是要把這個代價逼近到 0。反觀 Seq2Seq，它偏要把這個統一的優化任務拆開，用雙向 Attention 去搞 Span Corruption（挖空填空），再用 Cross-Attention 去撈 Embedding。這打碎了能量化一切的條件熵鏈律，讓參數空間的優化目標變得極度不純粹。 2. 質問：我們真的希望 KL 散度歸零嗎？ 好，這時候如果有人舉手質問：「照你這樣說，我們希望 $D_{\text{KL}}$ 越低越好，那終極目標不就是讓它等於 0？如果模型分佈跟人類真實資料採樣完全一模一樣，那它不就只是個死記硬背的隨機鸚鵡？你們天天掛在嘴邊的『湧現能力』到底從哪裡蹦出來的？」這個質問，就是解開 Decoder-only 勝出謎題的終極鑰匙。 ...

「如果要通往圖靈機的路上，Seq2Seq 本身比 Decoder 還要合理。」這是我在 2022 年的筆記裡寫下的一句話。 當時我試玩了早期的 GPT-2，心裡總覺得：這到底是個什麼東西？相比之下，基於 Seq2Seq 概念的 BART 或是 T5 看起來合理太多了。沒想到幾年後的現在，在這場 AI 軍備競賽中，竟然是 Decoder-only 架構拿下了 MVP。 當時的我會覺得，Decoder 說穿了根本只是看著輸入做「文字接龍」。它沒辦法預先知道自己整體要生成什麼，只能不斷在 Sample Space (樣本空間) 中選擇「現在這個情況下，下一個字機率最大的是誰」。 相較之下，Seq2Seq 才是完整使用 Transformer 架構的「好學生」： Encoder 負責看懂整個句子架構，並生成富含語意細節的 Embedding。 Decoder 應用 Encoder 給的全局上下文 (Context) 來輸出序列。 這樣的分工聽起來超合理，對吧？但為什麼現在的發展卻完全偏向了 Decoder-only？以下是我後來自己的反思，以及結合近期與 AI 討論後整理出的幾個關鍵原因。 1. 統一架構的暴力美學：Scaling Law 與目標函數 Seq2Seq 雖然邏輯清晰，但它把「理解」與「生成」拆成了兩個模組。Encoder 負責理解並產生針對細部觀念的 Embedding。這其實帶來了一個隱形的代價：訓練目標的不一致。 Seq2Seq 常常使用 Span Corruption（例如把一段話挖空，讓 AI 填空，類似 BERT/T5 的作法）來預訓練；而 GPT 則是貫徹到底的 Next Token Prediction (預測下一個詞)。 後來的事實證明，當模型參數規模放大到百億、千億等級時，遵守 Scaling Law (規模法則) 的 Next Token Prediction 是最能榨取資料價值的「目標函數」。當我們要壓低 Loss Function，讓 Decoder-only 的模型表現越來越好時，因為要預測下一個字足夠準確，模型被迫要在內部「模擬」出整個世界的邏輯、常識甚至物理規律。 ...

在〈datafox 竣工後記〉裡，我很自豪地介紹了我怎麼用 JSON-LD 做 AI-SEO、怎麼把 Person Schema 埋進 extend_head.html 裡讓 Perplexity 認識我、怎麼讓 AI 搜尋引擎理解我的技術邊界。我當時覺得我在做很厲害的事情。 在大概兩個月後我打開 Google Analytics，發現一個問題。 我的流量，幾乎全部來自我自己推。每次發文 → 丟 LinkedIn → 丟群組 → 流量來一下 → 消失。 自然搜尋？幾乎零。幹我超難過的，之前在medium發文都可以吸引到自然流量，但是我這裡幾乎沒有，可憐。 一、我到底漏掉了什麼？ 這件事讓我有點汗顏，因為我之前寫過的那篇 SEO 文章，某種程度上也在教別人怎麼做 SEO。但是我忽略了一個超大的問題，也就是，我做了「AI 時代的進階 SEO」，但跳過了最基本的那幾件事。 譬如說，我的文章 URL 長這樣： https://datafox.tw/posts/260303_2222/ 這串數字對 Google 來說毫無意義。Google 不知道這篇文章在講什麼，所以也沒辦法在有人搜尋相關關鍵字時把它推出來。Medium 之所以能搜尋到，原因之一就是 Medium 的 URL 長這樣： https://datafox-tw.medium.com/datafox-竣工後記-2026-個人網站實戰指南-從-想要一個網站-到真正上線-3ae9d5a615b7 一眼就知道在講什麼。 然後是文章的 description。我翻了一下，25 篇文章裡有 17 篇是空白的。 description: "" 這代表 Google 抓到我的文章時，不知道要在搜尋結果裡顯示什麼摘要。只能自己猜。猜出來的東西通常不太好看，點擊率自然也不高。 再來是，我根本沒有主動告訴 Google 我的網站存在。robots.txt 有、sitemap 有，但我從來沒去 Google Search Console 提交過。我之前都只知道ga4，但是我沒有去gsc，讓我的自然流量門可羅雀，尤其這件事情根本只要三分鐘就搞定了 二、今天做的四件事 2.1 讓 URL 說人話 在每篇文章的 front matter 加上 slug，讓新的 canonical URL 帶有關鍵字： ...

因為ai社課的原因，我想要用v0這個vercel開發的ai coding平台，來建立一個可以部署上vercel的服務。如果我可以成功，學生也一定能成功，我原本是這樣想的。沒想到，因為我前幾個版本，因為我的prompt寫得不夠好，加上v0本身的智商限制（例如他常常漏東漏西或者是根本沒看懂我給他的spec導致出現幻覺亂作一通），所以一直都沒有辦法在v0給的5美金quota裡面搞定。 最後，靠我的好夥伴 Chuan-Chi Hsu 花了重本，探索v0的邊界，最後才寫出一個可以一步（喔不，最後還是靠了4步但至少做出來了）到位的prompt，讓v0 ai可以在quota限制內寫出一個想要的rag 平台，給學生參考練習。 很多人說現在是 Vibe Coding 的時代，只要有手、有 AI，什麼都能蓋出來。但作為一個正在裡面掙扎的開發者，我的 Hot Take 可能會讓你冷靜一點： 你對資料工程（Data Engineering）越一無所知，你就要花越多錢。 AI 可以幫你寫 Code，但它沒辦法幫你補齊底層邏輯的空缺。如果你不懂 Data Pipeline、不懂向量檢索的原理，你只會在錯誤的邏輯裡反覆消耗 Token。 你的需求 Spec 寫得越不清楚，你就要花越多時間 Debug。 「幫我做一個 RAG 平台」這句話在 v0 面前價值趨近於零。模糊的指令只會換來模糊的實作。最後你會發現，花在精煉 Prompt 的時間，其實就是以前在寫 Spec 的時間。 v0 是個還不錯的工具，但務必要寫非常清楚的 Prompt。 它確實能讓你無痛接上 Vercel 快速部署，這點非常強大。但如果你沒辦法給出極度精確的約束條件，你不是在開發，你是在跟你的信用卡過不去（或者像我一樣，在跟 Gmail 帳號的數量過不去）。 🛠️ 實作成果： 在嘗試到第六個免費帳號後，我終於在額度內成功搭建了這個 RAG 平台的 Demo App。這是一個從慘痛經驗中萃取出來的產物。 因為這個平台問問題還是會花我的錢，所以如果大家想要玩玩看的，只能夠到下週的AI社社課（5/4, 19:00-21:00, 博雅505） 來試用！ ⚠️ 重要提醒： 由於這是使用免費帳號搭建的 Demo，你上傳的資料其他人都會看到！ 請當作測試場域就好，千萬、絕對、務必不要上傳任何敏感或機密資料！

為什麼想做這件事 靜態網頁有一個很常見的誤解，就是「靜態」代表死的、不能動的。但其實搭配 CI/CD 之後，它可以做到很多人沒想到的事情。 我想做一件事：讓這個網站的某個欄位，每個禮拜自動更新，不需要我手動寫任何東西。我的動機有兩個： 第一個是純粹想測試 GitHub Pages 這類靜態部署在自動化上能走多遠。從爬資料、呼叫 LLM、到最後 commit 進 repo 觸發部署，整條鏈可以完全在 GitHub Actions 裡完成，不需要任何後端伺服器。這件事本身就很有趣。 第二個是實用性：GitHub Trending 是我覺得目前還沒有被充分利用的資訊源。每週跑一次 top 15，用關鍵字篩掉不相關的，剩下的讓 LLM 幫我整理摘要，然後自動發布到網站上。這樣我不用每週主動去追，資訊會自己跑到我的網站來。 技術細節 起點是找到一個乾淨的 RSS 來源。GitHub 官方沒有提供 Trending 的 RSS，但有人做了：mshibanami/GitHubTrendingRSS，每天自動更新，週報的 URL 格式長這樣： h t t p s : / / m s h i b a n a m i . g i t h u b . i o / G i t H u b T r e n d i n g R S S / w e e k l y / a l l . x m l 有了 RSS 之後，pipeline 的結構就很清楚了： ...