建立 AI 內容自動化的第一週：9 個讓品質穩定的系統設計

⚠️ 不合格／AI自動生成：這篇文章是 30 天 Blog 內容自動化實驗期間（2026-06-08～2026-07-01）由 AI 全自動生成，經內部審查後判定品質未達最低標準，僅保留作為歷史存檔。完整記錄與根因分析請見《30 天 Blog 內容自動化實驗完整記錄》。

大多數人在設計 AI 自動化系統時，只關注「流程能跑起來」，不關注「輸出的品質是什麼」。

6 月 8 日，Antigravity 2.0 正式上線。五個站台，Claude Opus 每天定時觸發，自動讀章節、生成文章、部署上架。第一週的執行記錄看起來完美：所有任務成功，全數推送。

但當你仔細讀那些文章，會發現三個根本問題。而這三個問題，幾乎每個建立 AI 內容系統的教練或創作者都會犯。

第一週發現的三個根本問題

問題 1：AI 會自行填補沒有設定邊界的空白

一篇文章裡出現了這句：「根據最新研究，使用 AI 工具的創作者收入提升了 340%」。

這個數字沒有來源。原始資料裡根本沒有這個百分比。系統在「這裡放數字會更有說服力」的推斷下，自行生成了一個看起來合理的數字。

大語言模型的預設行為是填補空隙。你沒有明確設定「只能使用原始資料裡的數字」，它就用「看起來合理」的數字填進去。

這不是模型能力不足的問題——是工作環境設計沒有設定清楚邊界。

問題 2：跨站身份混淆

五個站台各有對應的主理人設定。第一週，有一篇文章把 A 站主理人的名字和事蹟，混入了 B 站的文章裡。

對讀者而言，這不只是一個名字錯誤——整個「主理人公開建造，分享真實歷程」的可信度都會因此瓦解。

教練事業的核心是信任。如果你的內容系統會輸出身份不一致的文章，這個系統在建立信任上是反效果的。

問題 3：開場缺乏情緒共鳴設計

大多數第一週的文章使用了這樣的開場：

「本文將介紹如何利用 AI 工具提升創作效率，以下是三個步驟……」

這是說明書的寫法，不是讓讀者產生共鳴並繼續閱讀的寫法。讀者在開頭三段感受不到情緒連結，就不會讀完——更不會點擊行動按鈕。

根本原因：系統工作環境的設計不足

這三個問題有同一個來源：系統的 Harness（工作環境）設計得不夠精確。

Harness Engineering 是這樣定義的：設計讓 AI 穩定產出高品質結果的工作環境與規則框架。

這個概念對教練事業有直接的應用：你雇用了一個 AI 助理（或自動化系統），但沒有給它明確的工作規範——它就會用「合理推斷」代替你的判斷，在每個邊界模糊的決策點上做出你未必認可的選擇。

結果是：系統跑起來了，但輸出的品質不穩定，需要大量人工複查和修正。這恰恰抵消了自動化的效益。

9 個讓品質穩定的系統設計

問題發現後，對系統做了 9 項調整，全部寫入了 AGENTS.md（系統作戰手冊），每次執行前強制讀取。

P1：來源章節化排程

問題：系統每天自由選題，內容來源無法追溯，容易重複或失焦。 設計：建立 30 天章節序排程，每天只讀指定的章節範圍（約 5,000–12,000 字），而非全書（約 103,000 字）。

結果：Token 用量減少約 95%，更重要的是，每篇文章的來源變得可追溯——可以確認「這個論點來自原始資料的第幾行」。

P2：寫作模板庫

從認可的好文章萃取寫作技法，建成參考模板庫。系統動筆前先讀模板，套用 2–3 個技法（結論先行、具體數字、作者判斷、FAQ 結構）。

這個設計的邏輯：不讓系統從空白開始決定文章結構，而是給它已驗證有效的結構範本。

P3：開場公式框架

強制每篇文章的開頭使用以下三種公式之一：

| 公式 | 結構 | |------|------| | A型 | 描述讀者的一個具體日常行為 → 指出背後的結構性問題 → 「這不是你的問題」| | B型 | 直接點名一個讀者熟悉但說不清楚的情緒 → 比讀者更精準地解釋情緒來源 | | C型 | 提出一個讀者以為知道答案的問題 → 給出反直覺的答案 → 解釋為什麼 |

框架式說明開場（「本文將介紹……」）明確禁止。

H1：受眾語言橋接

每個站台的讀者群不同，相同的核心概念在不同站台需要翻譯成不同的表達方式。

規則：動筆前，必須先把今日核心概念翻成該站讀者的日常語言，才能開始撰寫。如果文章中出現讀者不熟悉的術語，必須搭配讀者熟悉的語言解釋，不能單獨使用。

H2：準備資訊滲漏測試

系統在準備階段會聲明「今日目標查詢：___」，這是給系統自身的 meta 資訊，不應出現在文章正文中。

設計：在 git push 前強制搜尋文章本體，確認這個字串不存在。看似細節，但真的發生過。

H3：數字真實性規則（最關鍵）

文章中的所有數字——百分比、金額、時間、人數——必須來自今日章節原始資料，或主理人的真實記錄。

沒有可查證出處的數字一律刪除，改用具體對比描述：

> 「原本需要 3 小時的工作，現在 20 分鐘完成」

這樣的表述沒有百分比，但有畫面感，而且是真實的。

H4：發布前五點驗證清單

在 git push 前，強制執行以下五點確認：

□ 文章主理人身份屬於本站台？
□ 所有數字有原始資料出處？
□ 開場使用了 A/B/C 公式之一？
□ 準備階段 meta 資訊未出現在正文中？
□ 結尾有今天可執行的具體行動？

任何一點未通過 → 修正後重新驗證，不得跳過。

H5：反例資料庫

將第一週真實出現過的失敗句子整理成反例資料庫。系統每次執行前讀取。

設計邏輯：讓系統不只知道「應該做什麼」，也明確知道「做這個等於直接失敗」。已知的失敗模式是比任何正向規則更有效的約束。

H6：主理人身份鎖定

建立站台身份對應表：每個站台的主理人只屬於該站台，不能跨站混淆。

跨站身份混淆採用零容忍機制——不是警告，是強制修正後才能繼續。

這對你的 AI 教練事業意味著什麼

如果你正在建立任何形式的 AI 輔助教學或內容系統，第一週的這些問題是幾乎可以預期的。

核心洞見只有一個：

讓 AI 系統穩定運作的核心工作，不是讓模型更聰明，而是設計讓它無法做錯的工作環境。

你設計框架，AI 執行重複工作——但框架本身的品質，決定了系統輸出的品質上限。這個邏輯和你設計課程 SOP 是一樣的：SOP 設計得越精確，學員的成果越可預期。

AI 系統的 Harness，就是你的 AI 教練事業的 SOP。

今天可以開始的一件事：

檢視你目前給 AI 的任何指令或提示詞，找出其中「沒有明確禁止就可能發生」的空白決策。

把那個空白寫成一條明確的規則，放進你的工作環境裡。

一條規則，解決一個重複發生的品質問題。這是 Harness Engineering 最小的起點。