去年鐵人賽我寫了兩個系列（理論篇、實戰篇），都跟 AI-Driven Development 有關，實戰篇有幸拿到佛心分享佳作。這給了我很大的信心，我知道有很多人開始對 AI 實戰有興趣。

鐵人賽結束了，但我還是持續在研究 AI 開發，想要有個地方輸出，於是因緣際會開了社群帳號（文末會放資訊，有興趣歡迎交流）。當初只是抱著做筆記的想法，後來慢慢有人追蹤，才開始認真經營。

不過，每天都要想內容是一件非常痛苦的事情。好在 AI 在裡面佔了很大一部分的功勞，讓我每天在學習跟產出內容的過程中相當有效率，而且非常快樂。從開始經營社群到現在也持續了半年，過程中我做了許多自動化流程，幫我生產內容、也幫我學習。

這個系列就是要把我的壓箱寶全部端出來：三十天，每天一篇，把我現在正在跑的內容產線整個拆解一遍。我是怎麼堅持日更、讓每篇內容都有觀點跟來源；AI 在自動化產出的過程中，要怎麼證明自己是對的；以及我們要怎麼讓 AI 持續且不斷地迭代，讓內容越來越好，這些我都會在系列裡一一拆解。有興趣的人歡迎追蹤～

「內容產線」不只是發文流程

這裡的「內容產線」，不只是一條發 Threads 的流程。我想用內容工作當作固定場景，拆開 AI 自動化真正麻煩的地方：輸入不只一種，中間會有不確定的資料，輸出也可能是專欄、摘要、圖片、網站或社群內容。

舉幾個例子。我把一條影片連結丟進清單，之後它會自己變成一篇帶圖的導讀文章；每天有一份自動整理回來的情報，幫我決定要不要跟熱點；發文之前，會有腳本先把過去 30 天的數據拉回來對照。這些流程長得不一樣，卡住的地方也不一樣，但它們要回答的問題是同樣的，AI 的產出如果得到某種程度的驗證，自動化就可行。

老實說，它們還不是一套接好所有接口的系統，也不是每一條都全自動。接下來 30 天，我會把這些實際做過的流程放進同一張地圖，找出它們共用的設計：原始證據怎麼留、AI 能改到哪裡、哪個狀態要停下來找人，以及交付後怎麼確認真的成功。

為什麼要談 Harness Engineering

這也要回頭看看今年 AI 領域的新名詞：Harness Engineering。今年 OpenAI 有一篇文章〈Harness engineering: leveraging Codex〉談到它。我這裡先保留英文，不把「駕馭工程」當成官方翻譯。

那篇文章真正關心的，是當 agent 承擔更多執行工作之後，人要怎麼設計環境、說清楚意圖，再把測試、驗證與 feedback loop 放進系統，讓 agent 能可靠地工作。接下來我會用內容產線這個場景，看這些東西實際長什麼樣。

驗證要拆成四層

放到內容產線裡，我會把驗證拆成四層。第一層看來源還在不在，第二層看主張有沒有超過證據，第三層看格式、連結和流程規則是否通過，第四層才是交付後有沒有真的成功。少了任何一層，AI 產出得再快，都還不能算完成。

這 30 天會怎麼走

這 30 天會分成四段。前七天先把產線、證據和責任攤開；第二段看連結、影音、會議和每日情報怎麼進來；第三段拆同一份素材怎麼變成文章與視覺；最後一段才處理發布、失敗、回饋，以及哪些迴圈到 Day 30 還沒有接好。

30 天後想留下什麼

我希望 30 天後留下的不是一份工具清單，而是一張可以重跑的內容產線地圖。哪些工作適合交給規則，哪些需要 AI 讀資料，哪幾個位置一定要由人判斷，還有哪些迴圈到現在都沒接好，我都會照現有證據拆開。做不到的地方，也會留下來。

我平常在這些地方輸出，有興趣歡迎交流：

• Threads：@ci.fullstack — 我平常在這裡輸出 AI 驅動開發的心得
• Discord：邀請連結 — 一起聊 AI 驅動開發，不限主題