Posts

今天是國慶日，台灣生日快樂，我今天買了一杯星巴克、星巴克店員幫我畫了插畫超可愛的，然後今天都沒做什麼事情，唯一重要的就是晚上的三個會議（ai社、數位遊牧、steering），還有把幾票給買了，26800開飛。 昨天說下一步是把 Spark Operator 裝起來。但是今天沒有照做，先繞去做了更前面的事：幫專案取名、寫 PRD 和 TDD、把規模鎖住，再架出一個接好線但還沒有內容的骨架。 取名：Rekindle 專案叫 Rekindle，重新點燃。Spark 是火花，job 掛掉就是火熄了，這個平台做的事是把它再點起來。這個系列同時也是把荒廢的部落格重新點起來，所以一個名字用在兩個地方。這是ai幫我想的，我很滿意，然後spark和kindle又有互文性質。 先寫 PRD 和 TDD 動手之前我習慣先寫兩份文件（這也是我跟吳恩達學的，讚嘆andrew ng）： PRD（產品需求文件）：他回答「要做什麼、給誰用」。 TDD（技術設計文件）：他回答「打算怎麼做」。 PRD 裡最有用的一段是使用者。我列了三種：面試官、跑 Spark 的資料工程師、我自己。把面試官寫進去之後，有些設計自己就決定了。面試官的注意力大概只有兩分鐘，但 spot 節點從零擴起來就要好幾分鐘，所以故障實驗室預設播放錄製好的真實執行，即時執行另外給配額。 TDD 沿用我之前專案的寫法：我想要build出來的技術組合、設計選擇、資料流、評測、故障模式。「故障模式」這一節最值得寫，因為它逼我在寫程式前先想系統會怎麼壞。例如案例庫最大的風險是false positive，也就是把 A 故障的修法套到 B 故障上。所以誤命中率被列成正式指標，套用後驗證失敗的案例也會被降級，不再自動套用。 怎麼鎖定規模 非目標寫得比目標具體。在這個階段，我們不改寫使用者的程式碼（只進行痛點診斷）、不做通用平台、自然語言入口不放第一版。 只有一個硬目標。階段 3（故障實驗室公開上線）要在明年 2 月完成，其他階段都可以延後。 每個階段有完成定義。例如階段 0 是「一行指令能重建環境並跑完一個查詢，而且我能在 History Server 上說明一個 stage 的時間花在哪」。 把 agent 能做的事列成清單。修法只能從白名單挑，目前是 11 個 Spark 設定。歸因只能從 7 個固定類別選，其中一類是「設定修不了，需要人處理」。 不知道的先不定。成功指標我只定義了要量什麼，目標值等跑出 baseline 再說。現在填一個 80% 進去，也只是猜的。 先寫好要砍什麼。時間不夠的時候，先砍 agno 的對照組，再砍自然語言入口。 骨架：接線是真的，內容是空的 文件寫完就接著架骨架。原則是結構先到位，內容先留空。這個部分請AI幫我代勞，但我還是需要肉眼看一次： 資料夾、資料表、API 路由、分診循環的節點和分支都建好了。 每個節點和服務只有函式簽章和一句說明，呼叫了會直接丟 NotImplementedError，這是我在國泰學會的方法，先把想要implement的function先弄好。 用不到的套件先不裝。Gemini 的 SDK 和資料庫連線都還沒加，等真的要接再說。 暫時填的數字（embedding 維度、重試上限）都記在 TDD 的未決事項裡。 這樣做的好處是討論可以對著實際的東西進行。分診循環畫成圖只是一張圖；寫成能編譯的 LangGraph 之後，「驗證失敗要退回哪一步」這種問題就不能含糊帶過。骨架也便宜，現在整個改掉不會心疼。 ...

沒錯，我整個夏天都沒有更新。 從六月中開始，Google 實習、三篇頂會論文、產學合作、再加上準備碩士畢業找工作，幾座大山全部疊在一起，我直接進入了長達四個月的自媒體冬眠期（或者該說夏眠）。 直到前幾天國慶連假，我下定決心要重啟部落格，開啟了全新的個人作品集紀錄（Day 1 與 Day 2 的 Spark on K8s 系列）。當我寫完繁體中文文章、滿心歡喜地 git push 上去，期待著五月底那篇全站自動雙語化實踐的大功臣自動幫我把中文翻成英文時，我點開英文介面一看—— 文章根本沒有出現，整個英文版像被時間凍結在七月一樣。 更詭異的是，GitHub Actions 上的工作流程顯示著一排無辜而刺眼的綠色打勾（✓）。我以為 1010 的文章只是「正在排隊翻譯」，但事實證明，我的自動化系統早已在背後「無聲全滅」。 趁著深夜，我對整個網站做了一次徹底的大健檢，結果抓出了一連串教科書等級的 CI/CD、LLM 生命週期與權限陷阱。這篇文就是這場踩坑之旅的完整復盤。 陷阱一：被 try-except 吞掉的 402（CI 的假綠燈） 五月時，我寫了一支 auto_translate.py 腳本，透過 GitHub Actions 在每次 push 時自動呼叫 Gemini API 翻譯沒有 .md 對應檔的 .zh-tw.md。 這次當我發現文章沒有被翻譯時，我第一時間去翻 GitHub Actions 的 Run Log，赫然看見這段報錯： Translating: content/posts/261010_2318.zh-tw.md -> Error translating: 402 RESOURCE_EXHAUSTED. Your prepayment credits are depleted. Please go to AI Studio... Translating: content/posts/260612_1625.zh-tw.md -> Error translating: 402 RESOURCE_EXHAUSTED... Done. Translated 0 files. 原來我绑定的 Gemini API 預付額度早在夏天就見底了！ ...

明年暑假我就要從碩士班畢業，差不多該認真準備找工作了。盤點我會的東西：LangGraph 和 multi-agent 系統做得最多，data science 和 fintech 有一些累積，cloud 也碰過一點。但有一塊我經過了四次的實習都沒有好好的碰到，就是大規模資料處理和 Kubernetes 的實戰經驗。Spark 和 K8s 我都只算剛入門。 這個系列是我補上這一塊的紀錄。我打算做一個真的會上線、要自己付錢維護的專案，每天寫一篇短文記下進度，順便把荒廢一陣子的部落格救回來。 為什麼不做一個單純的 Spark 練習專案 照著教學跑一次 word count、再把它丟上 K8s，學得到東西，但放在作品集裡沒有人會多看一眼，現在做出大量沒人用的Project太簡單了，根本沒有人會在意。我想要的是把「我缺的」和「我會的」接在一起：Spark 和 K8s 是新學的，agent 是我熟的，中間需要一個合理的理由讓它們結合在一起。 靈感來源 之前在 Google 工作時，我處理的是內部測試失敗的問題：測試一掛掉，就把錯誤的過程和內容系統性地丟進一個 agent loop，讓它做歸因調查和分類。如果過去出現過類似的案件，就直接沿用之前的結論，不必重新調查一次，概念上很像 cache。 這套「triage、reasoning、reuse」的循環，搬到 Spark on K8s 上很合適： 訊號分散在三層。一個 Spark job 掛掉，線索可能在 K8s 事件、driver 或 executor 的 log，也可能在 Spark 自己的 event log。人工查很花時間，正好是 agent 能幫上忙的地方。 故障高度重複。executor 被 OOMKilled、資料傾斜拖垮某個 stage、spot 節點被回收，這些問題會一再出現。重複代表過往案例可以重複利用，如果hit的話就不用花很多錢來自己找根因。 要做的東西 一個公開的 Spark on K8s 故障分診與自動復原平台。核心循環長這樣： 失敗的 Spark job → 收集（K8s 事件、driver/executor log、event log） → 指紋化（去掉 ID、時間、路徑後的錯誤簽章 + embedding） → 查案例庫 ─ 命中 → 直接套用已驗證過的修法 └ 未命中 → LangGraph 調查 → 歸因分類 → 提出修法 → 復原（改設定後重送）→ 驗證 → 結果寫回案例庫 平台預計有三種使用方式： ...

哈囉，這裡是 DataFox。 如果你最近有來逛 datafox.tw，可能會發現一件事情——我已經從 6 月 12 日開始，就沒有更新任何新的文章了。 很多人也陸續問我：「不是說要寫課程評價嗎？」「AI 新知呢？」「最近怎麼都沒有新文章？」 老實說，不是沒有想法，而是真的太忙了。 這段時間，我除了 Google 實習之外，還同時卡著 AAAI、ICAIF 等三篇論文、產學合作專案，以及研究所的各種研究工作。我也不知道為什麼，原本分散在不同時間的事情，最後全部擠在同一個多月裡。除此之外，我還是希望能維持正常生活：跟朋友見面、運動、睡覺，不要把自己完全燃燒殆盡。於是，經營自媒體自然就被我往後放了。 其實我也不是完全沒有更新。LinkedIn 原本還有持續分享一些 Google 實習和研究上的近況，但最近也因為論文衝刺，不小心斷更了。qq 這陣子，我也一直在思考 DataFox 下一步該往哪裡走。 我曾經想過建立一個 AI 社群，但現在 AI 社群真的很多。我一直在想，我到底能提供什麼別人沒有的價值？ 也許等論文告一段落之後，我會開始分享更多自己真正累積下來的東西，例如研究過程中的觀察、Google 實習的見聞，以及一些 AI 系統設計與研究方法上的心得，而不只是整理新聞或追最新模型。我希望 DataFox 能慢慢長成一個有自己特色的地方。 有趣的是，雖然我已經兩個多月沒有發文，網站每天還是大概有二十位左右的自然訪客。 每次看到 Analytics，我都會提醒自己：原來，還是有人會來。這也讓我更不希望為了更新而更新。 我不希望經營 datafox.tw 變成另一種壓力，或變成必須追著演算法跑的工作。我更希望它是一個能夠長期記錄自己思考、研究與生活的地方。 只是現在的我，還沒有足夠的力氣。 最近每天都被實習、論文、研究和各種 deadline 推著走，甚至連 Podcast 都還躺在待剪清單裡。 不過，這只是暫時的。如果一切順利，這波最忙的時間大概會在 8 月初告一段落。等我把這些事情完成，也把自己整理好，我會慢慢回來。 到時候，再和大家分享這段時間發生的故事，以及下一個階段的 DataFox。 謝謝還願意偶爾來這裡看看。

最近跟朋友聊求職，發現大家都被一種荒謬的焦慮感籠罩。現在打開社群，滿地都是「AI 讓你十倍速開發」、「三分鐘寫完一個 APP」的東西。我自己也變得越來越倚賴純 vibe coding。 在 2024 以前，我要開發一個功能，還會想到底要貼哪一段 code 給 GPT，讓 GPT 回說這部分要怎麼處理。那個時候，我至少有動腦去找到問題根源，只不過解決它的方式比較粗糙。 但自從我去年七月從歐洲回到台北，八月下載 Cursor 來用，到現在 Claude Code、Antigravity、Codex 百家爭鳴，我們漸漸開始發現： 現在工程師的功用，好像真的正在指數級銳減。 但與此同時，有件事情也同時發生了。 在求職的路上，或者是任何需要展示出自己比別人優秀的路上，我們發現：工時沒有變短，生活品質也沒有變好。反而是整個產業界對「人」的期待值，跟著這些宣傳語同幅度、甚至超額通膨了。 以前一個人花兩三個月打磨出一個有模有樣的 side project，大家會覺得你底子不錯。 現在就會變成，面試官看著你手上的專案，心裡的 OS 可能是： 「這大概是用 AI 兩三天拼出來的吧，沒什麼了不起。」 然後連我自己都開始懷疑。 在這種通膨下，我們好像被逼著得是十項全能的超人，才有資格在市場上競爭。 廉價指標飽和之後，證照和成績還剩多少鑑別度？ 然後大家開始瘋狂去刷證照、刷成績。 但說穿了，在這個連小學生都能用 AI 輔助備考的年代，那些有題庫、靠死記硬背的「世俗標章」，早就貶值到不行了。 當所有人都拿著滿分證照去面試時，這就是一個廉價指標飽和的死胡同。 那到底要怎麼證明自己不是一個只會發送 prompt 的「AI 打字員」，而是能帶來十倍效益的人？ 真正清醒的面試作業：Prototype 只是基本，解剖報告才是重點 前陣子我看到一份極度清醒的面試作業要求，簡直是直接賞了那些整天吹捧 vibe coding 的人一巴掌。 那家公司劈頭就說： Working Prototype 是基本，但他們不要一個只是包著 LLM 外皮的玩具。 他們真正要看的是： PRD（產品需求文件） TDD（技術設計文件） 以及三個靈魂拷問： What I personally built What I reused What broke and how I debugged it ...

最近的生活真的是忙到焦頭爛額，一邊在水深火熱地幫論文補數據，另一邊的實務合作專案也遇到了一個非常真實、且極度折磨人的工程挑戰。 這篇文章不談太具體的商業邏輯，單純來聊聊我們在系統架構上踩到的一個巨大效能坑，以及一個工程師在 Debug 卡關時，到底會做出什麼荒謬的紓壓行為。 平行運算的魔法失效了？ 這個專案的底層架構，是一套由 Python 負責前端策略處理、交給 Java 核心引擎進行高速運算的系統。 原本的運作模式是非常安分守己的「序列化」。也就是說，系統必須等第一天的巨量資料跑完好幾分鐘，才能接著跑下一天。看著伺服器那精美的多核心 CPU 閒置在那邊，身為一個對效能有追求的工程師，我當然不能忍，於是決定發揮平行化程式設計的技巧來榨乾硬體效能。 結果，意外發生了。我原以為加上 Parallel 就像施了魔法一樣會自動起飛，但我剛查了 Log 卻發現，即使我非常保守地只開了 2 個 Worker，平行運算依然華麗地失敗、整個系統直接崩潰斷線。(我先嘗試6然後4然後2 都失敗) 傲嬌的 Java 引擎與慢郎中 Python 看著滿螢幕的錯誤訊息，我一開始的判斷是：「這 Java 核心引擎也太傲嬌了吧！」 錯誤代碼顯示的是 SocketTimeoutException。我當下的推論是：這套 Java 引擎對於「通訊延遲」有著極其嚴格的限制。當伺服器同時跑兩套 Java 引擎和 Python 腳本處理全日版的龐大資料時，瞬間的 CPU 爭奪造成了延遲。Python 無法在規定的「微秒級」時限內把成千上萬筆的資料傳過去，所以 Java 引擎就直接無情地把連線切斷了。 聽起來很合理對吧？但身為一個對技術抱持懷疑態度的人，我總覺得哪裡怪怪的。底層的資源競爭真的會讓通訊慢到觸發 Timeout 嗎？ 於是我繼續往下深挖，把平行版斷線的 task.log 徹底翻了一遍。結果迎來了史詩級的劇情反轉： Java 引擎是無辜的，真正的戰犯，其實是 Python！ 史詩級的 JSON 效能慘案與修復 真相大白。SocketTimeoutException 雖然是 Java 拋出的，但根本原因在於：Python 內建的 json.loads() 處理速度實在太慢了。 在資料的巔峰時段（例如某些流量爆衝的極端日子），每 5 分鐘就會有一波極其龐大的狀態 JSON 湧入系統。當 6 顆 Java 引擎同時把海量 JSON 砸向 Python 時，Python 原生的解析器根本來不及消化。這導致 Socket 直接塞車堵死，最終 Java 引擎在對面苦苦等不到回應，只好無奈地強制切斷連線。 ...

在建立這個個人網站的過程中，我一直有一個兩難：我希望能用自己最熟悉、最有溫度的母語（繁體中文）來記錄與創作，但同時，我也渴望與世界接軌，讓更多英文母語者或是對我的技術文章感興趣的國際讀者，有機會看到這些內容的潛力。 此外，從技術部落格的經營角度來看，雙語內容對於搜尋引擎優化（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 的人，但我可以精準搶奪到「自動化 + 資料科學碩士」這組獨一無二的標籤交集。 ...