苦勞德報內容流水線
苦勞德報是我發在這個 blog 上的一份 AI 社群日報，大概兩三天出一篇。它不是手寫的：我跑一個 /kudlaodebao skill，它就照著圖 1 的五個階段走完，從 Reddit 上的討論一路變成一篇排版好、已經上線的文章。
說是「流水線」，一開始可沒想那麼多。最初我只是想把 Reddit 上的討論抓回來，整理成給自己看的重點摘要，很單純的一件事。後來越做越有意思，這裡可以加一道選題、那裡可以讓它自己審稿，想到什麼就加什麼，加著加著就成了現在這五個階段。
這條線是幾個 skill 拼起來的
圖 1 看起來是一條線，背後其實是四個 skill 在分工：
kudlaodebao是這份日報專用的寫稿機，管圖 1 的 1 到 4：Reddit 抓取、選題、寫稿、AI 審稿都在它手上。blog-publish負責 5：搬檔、加藏鏡人標記、commit、push、打 tag。它不綁苦勞德報，是通用的發佈 skill。blog-review是blog-publish在部署前叫來的 local 驗證：跑 generator、validate.py、playwright 截圖與連結檢查，一樣通用。blog-draft不在這條線上，它是給手寫長文整理草稿用的；但成品最後一樣交給blog-publish跟blog-review。
以發佈流程來說，個人 blog 跟苦勞德報其實沒差別 — 都走同一支 blog-publish：搬檔、commit、push、打 tag。但兩種內容的 theme 跟 layout 不太一樣（苦勞德報要疊一層藏鏡人標記、走報紙風的版面；手寫 blog 不需要），這層差異就由這個關口自動依 path 分流：檔案落在 contents/kudlaodebao/ 就走日報那條路，落在 contents/posts/ 就走一般 blog。kudlaodebao 自己只專心做內容的編輯與校正，流程的職責是外層的事；部署細節（tag 格式、Cloudflare Pages 怎麼觸發）只活在一個地方，改一次全部更新；要再加新的內容型態，也只要在 blog-publish 多接一條路徑分流。所以以開發者的角度來理解，這只是某種程度上運用實作技巧，讓同一個步驟在不同情境有不同產出。
流水線
抓取貼文 1 是起點。我固定從 ClaudeAI、ClaudeCode、OpenAI 這三個 subreddit 抓當下熱門的貼文。會挑這三個，是因為它們是 Claude 跟 OpenAI 使用者體感最直接的地方：新功能、踩到的雷、別人摸出來的好用法，通常都先在這裡冒出來。抓這個動作本身是靠一個叫 tl-util-reddit 的小 skill，用 Reddit 的 JSON API 把貼文跟留言撈下來。
抓回來的內容需要由「總編輯」選題 2，並且剔除近期已報導的部分。由於目前是由我本人作為總編輯，至少這一步是由我 human in the loop 放行的。其中「剔除近期已報導」這道工，一開始其實沒有，是日報出了一陣子才補上的：文章一篇接一篇，慢慢會撞到「這個前幾天好像講過了」，讀者讀起來就膩了。所以這步拿新抓到的題目跟前幾天發過的比對，把重複的、熱度退了的濾掉，再挑出剩下值得寫的幾則。← 藏鏡人批：總編輯員工數 0，AI sub-agent 不算自己人。
選定之後進到並行寫稿 3。每一則新聞各丟給一個 sub-agent 同時寫。並行的好處不只是快，每個 sub-agent 只專心處理自己那一則，context 是乾淨的，不會把 A 新聞的細節混到 B 那篇去。
寫完先過一輪 AI 審稿 4。這層針對二類問題。一類是格式上的：有陣子 AI 三不五時吐出亂碼，尤其是那種變成問號的字元，一看就不是人讀得懂的東西，得直接濾掉。另一類比較需要 LLM 的智慧：素材直接來自 Reddit 貼文，對 AI 如果沒特別的約束或給予期望的說明，很容易把整篇寫成使用者的對話錄，誰回了誰、又引述了誰，讀起來像在偷看別人的聊天紀錄，而不是新聞。所以審稿要把語氣拉回新聞記者的視角：用客觀事實，集結成一段陳述性的說明。
最後是發佈上線 5，交給 blog-publish 處理：搬檔、加上「藏鏡人」批改標記，再叫 blog-review 做 local 驗證。這步不是讓 LLM 用眼睛掃一遍就算數，大半其實是自動化的：起一個本機 web server，validator 逐一檢查每一頁 URL 回不回 200、文章內部 anchor 點下去有沒有捲到大致對的位置，還有 og:image 跟 metadata 是不是都產對。全是 pass/fail 的硬檢查，過了才 commit、push、打一個 publish tag 觸發部署。圖 1 把這一步畫成暖金，因為它才是整條線真正的產出：一篇上線的日報。← 藏鏡人批：LLM 哪來的眼睛，這擬人法挺浪漫。
不過這條線其實沒那麼一氣呵成。審稿和發佈中間有個停頓：寫稿、審稿做完，文章會先落在草稿區，不是直接發。苦勞德報現在大多會自己接著跑發佈、直接上線；日報還沒穩定的那陣子，我則會讓它停在草稿，等我親自看過才放行。至於手寫的部落格長文，根本就停在草稿不動，那種文章我要自己大幅改寫，改完才手動送進發佈。
報紙邊上的藏鏡人
苦勞德報每篇上線前，還會被一個叫「藏鏡人」的角色批過一遍。它是我設定出來的匿名資深讀者，站在「這對我到底有什麼用」的角度讀文章，語氣簡短犀利、偶爾毒舌。它不動原文，只在文章上疊標記：螢光筆圈出關鍵數據、紅筆在段落末尾寫一兩句旁批，像在報紙空白處隨手寫的筆記。技術上它沒什麼玄機，就是發佈那步順手讓 AI 換上一副讀者的眼鏡，把剛寫好的稿再讀一次。但讀起來多一點互動感 —「原來有人會這麼想」、「這個吐槽的角度太有趣了」，我滿喜歡的。這個角色只有苦勞德報才有，手寫的長文不會被它批。← 藏鏡人批：標題都掛我名字了，是要我怎麼藏。
PS. 只有本篇是「法外開恩」特別請藏鏡人動動金口。
反覆執行的小事都值得成為 skill
苦勞德報對我來說，與其說是一份日報，不如說是一個練習：把會一再重複的小事，一件件做成 skill。
讓我想到 Learning Perl 這本書的副標題 ——「Making Easy Things Easy and Hard Things Possible」，讓簡單的事變得簡單、讓困難的事變得可能。skill 對我來說大概也是這樣：把流程做成 skill 後，可以在日復一日的使用中慢慢改善它，原本想像中困難的事，做著做著就被做出來了；做出來了，又變得能解釋、能拆開講；能解釋之後，下一輪又能再進化一層。
工作流水線一旦形成，我每次要做的就只剩跑一次那個 skill，然後看圖 1 最右邊那個暖金節點亮起來。← 藏鏡人批：「手會痛」，多久沒寫 code 了。
對了，本篇的圖例是另一個新做的 skill 畫的，它會照這個 blog 的視覺風格生出 SVG，目前還在摸索中。本來這篇是為了試用它寫的，但回頭看最近也沒什麼新心得要整理，就變成主要在回顧苦勞德報的內容了。連畫流程圖也是一件值得做成 skill 的小事。