240+ 篇 自動發佈
內容自動化系統（Distill） →
一台 Mac 上跑的內容產線：每天從國外一線來源選題，用繁體中文重寫、事實查核，自動發佈到多個社群頻道，再沉澱成自有網站資產。3 個頻道、月觸及約 4 萬 views，日常零人工操作。
把「像真人寫、而且不出錯」當可靠性問題設計——事實查核閘門、四層發佈防線、去 AI 味規則、成效回饋。這個站本身就是它的產物。
LLM Pipeline 自動化 Threads API
童曉瑜 · John Tung
Data Lead · Principal Data Engineer。
十年在 GCP、AWS、Azure 上建資料平台，其中兩年半帶 Data Team。現在在媒體集團負責整條資料線——平台、平台上的 AI、還有人——也還親自寫 code。工具看需求挑；做得好不好，看的是非工程師有沒有真的在用。
關於我
人在台北。目前在媒體集團帶資料線，平台是從零建起來的：Facebook／Instagram／Threads／YouTube／GA4 跨平台 ingestion 進 BigQuery、dbt 建模、三個主管與編輯每天打開的上線產品，以及真的上了生產、而且有品質把關的生成式 AI。再往前，帶過 4 人的 Data Team 兩年半。
過去幾份工作，GCP、AWS、Azure 都有正式環境的經驗，工作流程編排用過 Airflow 和輕量的 scheduler，資料處理 PySpark、dbt、BigQuery 都跑過 — 累積下來的心得是：最適合的工具，是「對得上實際需求 + 團隊維護得起來」的那一個。
資料建模和基礎建設這兩塊花的時間差不多 — 後者像是讓 token 不會過期、讓 job 保持 idempotent、讓帳單一直停在很小的數字。
現在最投入的，是讓 AI 可靠到能進編輯台：只依據數據生成、品質一掉就讓任務失敗的評測、在明確規則裡工作的 agent——其實就是回到本業：中文文字探勘與輿情分析。
代表作
幾個有成效的案子。
Gemini 上生產 有品質把關
不會越線的生成式 AI
Gemini 直接在 BigQuery 裡跑（AI.GENERATE）：留言情緒與貼文主題分類、只依當期數字寫的 AI 觀點；Vertex 嵌入 + KMEANS 把負評分群、命名主題。留言 RAG 檢索每週跑一次 LLM-as-judge 評測——檢索品質一掉，任務直接失敗，不會默默變差。
編輯台 4 工具 agent 已上線：不寫 SQL、每份草稿強制自檢、成本硬上限、每週回放評測。共用快取讓 AI 成本不隨使用人數膨脹。
BigQuery AI.GENERATE RAG + LLM-as-judge Agent 守門
3 個產品 非工程師每天用
主管與編輯真的會打開的儀表板
給 C-level 的集團數位營收儀表板、給行銷主管與編輯的社群成效儀表板、把月營收表排成報紙版面 PDF 的產製工具——都在 Streamlit + Cloud Run 上、Google 登入。
三層 ACL 讓主管自己增刪成員，留稽核軌跡、埋使用分析；要權限不必再開單。
Streamlit OIDC + ACL Cloud Run
$300 → <$1 月成本
接手 pipeline 重寫
接手一條原本跑在 Composer + Apps Script 上的營收 pipeline，整套換成 BigQuery External Tables + Scheduled Queries。產出一樣、時效一樣，月支出降到原本的 1/300。
這個案子之後一直在套用的心得：多數「pipeline」其實不需要 orchestrator，需要的只是一個會照排程跑的 query。
BigQuery Scheduled Queries 成本
34 jobs 錯峰排程、有監控
會大聲失敗的跨平台 ingestion
Facebook、Instagram、Threads、YouTube、GA4 進 BigQuery——34 個 Cloud Run Jobs 錯開時間排程，dbt 建模、append-only 保留每次變動（不只最新狀態）。
dbt source freshness、帳號級守門、Cloud Monitoring 三層一起，抓最糟的那種失敗：job 成功，但什麼都沒寫。
Cloud Run Jobs dbt BigQuery
0 人 在授權流程裡
不用開單的 OAuth
Threads 雙帳號 OAuth、8 種權限，每週一支 Cloud Run Job 透過 Secret Manager 自動換 60 天 token——沒有人會因為 token 過期被叫起來。給編輯的那一端，是 Cloudflare Pages 上的純前端自助頁：自己走完授權、零後端、幾乎零維運。
OAuth 2.0 Secret Manager Cloudflare Pages
寫作
Postmortem 跟比較長的工作筆記。
- Observability · Self-hosting 2026-07-29
大聲的備份與多疑的探針：巡檢系統收官
為什麼備份是唯一被禁止沉默的 loop、為什麼每日回歸探針用確定性斷言而不用 LLM 裁判——以及「趁健康時建立基準線」的完整論證。
- Observability · Self-hosting 2026-07-26
Webhook bot 沒辦法看住自己：存活、日報、交付稽核
沉默死亡是 webhook bot 最糟的失敗模式——而 LINE 會讓它自我延長。三道巡檢 loop 回答三個不同的問題：還活著嗎、在悄悄變爛嗎、承諾兌現了嗎。
- Design · Data freshness 2026-07-23
不用假日表的到價警報：兩道閘門，不是一本黃曆
家庭 bot 怎麼盯股價又做到閒置零成本、假日零誤報——盤中閘門管成本、新鮮度閘門管正確性，外加一個上線隔天就被推翻的界線決策。
正在做
目前手上在做的事。
-
需求即資料
一個 PoC：把需求訪談變成可追溯的型別化記錄庫——每條需求都指得回使用者原話——由五組不同模型的檢查員稽核，並與原做法跑 A/B 對照。
-
做得動的資料治理
把治理盤點抓到的缺口一項項收掉——成本歸屬、最小權限、對 IT 的存取需求——每個決定都寫下來，讓團隊和 AI agent 照同一套規則做事。
聯絡
歡迎聊聊。
© 2026 John Tung. 以 Astro 建置。