[META]

這個網站是怎麼運作的

Code & Cast 上的每一篇技術文章、釣魚日誌,都是由 AI pipeline 撰寫的。 Wayne 不手動寫任何內容。這個頁面說明具體機制,以及背後的設計邏輯。

「Wayne 做東西。CI 寫關於它的文章。
Wayne 不直接碰 content 目錄。」

— CLAUDE.md,架構決策

兩條 Pipeline

[CODE] 技術文章
  1. 01 CI job 掃描近期的 GitHub commit 歷史,找出有意義的工程工作
  2. 02 識別代表真實決策的 commit — 架構異動、debug 過程、基礎設施改寫
  3. 03 Claude 讀取 diff、commit message 與前後脈絡,以 Wayne 的語氣生成技術文章
  4. 04 publishedAt 日期取自實際 commit 時間戳,不是 CI 執行日期
  5. 05 文章 commit 到 staging 分支,Wayne 審閱後才上線
[CAST] 釣魚日誌
  1. 01 CI job 監控 Wayne 在社群媒體上的釣魚貼文
  2. 02 Claude 從非結構化貼文中萃取結構化資料:魚種、水域類型、釣法、裝備、當日條件
  3. 03 Claude 將貼文轉寫成 CAST 日誌格式,保留原始語氣與現場細節
  4. 04 Wayne 審閱後發布到 staging,再 merge 至正式環境

網站本身

Code & Cast 網站本身是用 Claude Code 的多 agent 工作流建構的。 有規模的新功能沿用同樣的模式;每個階段之間都有強制的人工審查關卡:

// 功能 pipeline(非瑣碎改動才啟動)
PM agents → 產品需求規格
↓ Wayne 審閱 + 批准
Architect agents → 系統設計 + 領域規則
↓ Wayne 審閱 + 批准
Designer agents → 視覺規格 + 設計系統
↓ Wayne 審閱 + 批准
Engineer agents → domain / infra / presentation 層
↓ Wayne 審閱 + 批准
QA agents → UX 測試 + 架構合規驗證
↓ Wayne 審閱 + 批准
→ 上線

日常工作——bug 修正、內容校訂、調整 CI writer 的 prompt——透過 Claude Code 直接對話處理,不啟動完整 pipeline。 每個 agent 專注一個角色,沒有任何 agent 在沒有 Wayne 介入的情況下直接把產出交給下一個 agent。

為什麼這樣做

Wayne 的時間花在寫程式和釣魚上,不是管部落格。CI pipeline 是「戰地記者」, 記錄他實際做了什麼。這個網站的內容是工作的副產品,不是工作本身。

這個設計本身也是一種展示。如果你是從 LinkedIn 來的,想知道 Wayne 怎麼用 AI—— 就是這樣。不是用 AI 自動補全句子,而是設計讓 AI 做特定工作的系統, 並在每個真正重要的決策關卡保留人工審查。