最近在維護幾個 AI 自動報告流程時，我又被一件很不華麗、但很要命的事提醒：AI 報告最容易失真的地方，很多時候不是最後那段「生成文字」，而是前面的「取材」。
這句話聽起來很像廢話，對吧？沒有好資料就沒有好輸出，大家都知道。但實際做排程報告時，災難通常不是以「資料很爛」的形式出現，而是以一堆看起來很合理的小妥協慢慢滲進來：某個來源 403、某個 API rate limit、某個頁面結構改了、某個 fallback 抓到的其實不是原文。然後報告還是準時產出，語氣還很篤定。
報告準時，不代表它可信
做自動化的人很容易把焦點放在排程有沒有跑、格式有沒有對、訊息有沒有送到。這些當然重要，我也不是說可以不管。可是 AI 報告跟一般 ETL 最大的差異在於：它會把不完整的素材包裝成很順的文字。
傳統程式抓不到資料，通常會丟 error、空值或 broken chart。難看，但至少你知道它壞了。AI 報告比較麻煩，它很擅長把「我只抓到一半」寫成「綜合觀察可以看出」。
這就是我現在對自動報告最警覺的地方：不是怕它不會寫，而是怕它太會寫。
一個來源失敗，如果系統沒有明確標記，模型可能會用其他片段補上。兩個來源互相矛盾，如果沒有交叉驗證，模型可能會挑比較像故事的那一邊。某個頁面被反爬擋住，如果 fallback 工具回來的是摘要或錯頁，模型可能根本不知道自己站在沙地上。
最後送到主管、工程師或使用者眼前的，不是「資料不足」，而是一份看起來很完整的錯誤信心。這比直接失敗更危險。
取材流程要像產品，不是像臨時腳本
我以前也常把報告取材寫得很工程師腦：先打 API，失敗就爬頁面，再失敗就走 reader service，再不行就搜尋一下。能抓到就好，反正後面模型會整理。
現在我會比較保守。因為每一層 fallback 都不是免費的，它會改變資料的可信度。
官方 API 通常結構穩、欄位清楚，但可能有 rate limit。官網文章權威性高，但可能有反爬、動態載入或 canonical URL 問題。搜尋結果適合 discovery，卻不適合直接當事實來源。第三方 reader 很方便，但它拿到的是不是完整頁面、是不是最新版本、是不是同一篇文章，都要驗證。
所以取材流程不能只寫成「抓不到就換下一個」。它應該像一個小產品，有來源等級、有失敗狀態、有驗證規則，也有「寧可不報」的判斷。
flowchart TD
A[排程啟動] --> B[來源 discovery]
B --> C{找到原始來源?}
C -->|是| D[抓取內容與 metadata]
C -->|否| X[標記資料不足，不硬寫]
D --> E{交叉驗證通過?}
E -->|是| F[交給模型整理]
E -->|否| Y[降級為待確認線索]
F --> G[輸出報告]
Y --> G
這張圖看起來很基本，但它背後的重點是：模型不應該負責猜資料品質。資料品質要在進模型之前就被標記清楚。
fallback 不是魔法，是風險轉移
很多自動化系統壞掉，都是壞在 fallback 寫得太有自信。
例如某個 API 被 rate limit，工程師很自然會想：「那我改爬網頁。」網頁被擋，再想：「那我用一個能轉純文字的 reader。」reader 也抓不到，再想：「那搜尋標題看有沒有別人轉載。」
這些都不是錯。錯的是把它們當成同等可信的資料來源。
fallback 的本質不是修好問題，而是把問題從「抓不到」轉成「抓到一個可信度較低的替代品」。如果系統沒有把這個可信度差異留下來，後面的人就會以為它們都是同一種事實。
我現在會要求報告流程至少記住幾件事：資料來自哪裡、是不是原始來源、抓取時間、是否有第二來源驗證、哪些段落是推論、哪些只是線索。這些資訊不一定全部出現在最終報告裡，不然讀者會被 metadata 淹死；但系統裡一定要有。
尤其是無人值守的 cron job，更不能靠「這次看起來沒問題」。凌晨三點的系統不會心虛，它只會照規則跑。規則如果把低可信來源當高可信，隔天早上你看到的就是一份很漂亮的假穩定。
寧可少寫，也不要補腦
做內容報告的人會有一個誘惑：每天都要有東西交差。排程固定跑，使用者也期待固定收到輸出。於是當資料不足時，系統很容易用一些語氣把空洞補起來。
「市場持續關注」、「業界普遍認為」、「值得留意的是」——這些句子很滑順，也很危險。因為它們可以在沒有足夠來源時，製造出一種「我有看過很多資料」的錯覺。
我寧可讓報告短一點，甚至某些欄位直接寫「今天沒有足夠可信來源」，也不要讓模型用漂亮話把缺口糊起來。這不是保守，是維持長期信任的成本。
從技術主管角度看，自動報告不是文案產生器，而是一套資訊供應鏈。供應鏈最怕的不是慢，而是不知道哪一批料有問題。慢可以調整，少可以補；但如果系統把未驗證的東西混進正式輸出，後面每個決策都會被污染。
AI 報告的核心能力，是可追溯
我越來越覺得，AI 報告系統要成熟，重點不只是 prompt 寫得多漂亮，也不是模型換得多新。真正的核心能力是可追溯。
這份報告為什麼這樣寫？它看了哪些來源？哪些來源失敗？哪些結論有交叉驗證？哪些只是暫時觀察？如果明天有人問「這句話根據哪裡來的」，系統能不能回答？
如果不能，那它就還只是很會寫作文的排程，不是可靠的資訊系統。
生成式 AI 很適合把資訊整理成人能讀的形狀，這件事我完全買單。但前提是，我們不能把資料治理的責任丟給模型。模型可以幫忙摘要、比較、重組、提煉觀點；但來源可信度、失敗狀態、驗證鏈路，應該由工程流程負責。
如果這幾天維護自動報告流程給我最大的提醒，大概就是這句：不要只問 AI 寫得像不像人，要問它吃進去的資料像不像事實。
報告可以少一點，可以慢一點，可以保守一點。可信，比熱鬧重要多了。