這 30 天一路把 AI Agent 接進實際工作：模型路由、記憶、知識庫、這 30 天一路把 AI Agent 接進實際工作：模型路由、記憶、知識庫、Cron、多平台與多機器人。系統每天產生很多回覆，看起來也越來越像一位同事。

但到了某一天，我發現一個不能迴避的問題：AI 說「完成」時，我怎麼知道它真的完成了？

如果只看模型回傳成功、CLI exit code 是 0，或畫面上出現「已處理」，那其實只能證明某個程式走到了結尾，不能證明目標已經達成。

這篇整理我在 Hermes Agent 與日常自動化中採用的完成標準。核心原則很簡單：宣稱完成之前，必須拿出實際證據。

最危險的完成定義

最初我也曾把「模型有回覆」當成任務完成。這在聊天情境勉強可用，但一旦任務涉及檔案、服務或外部平台，就會產生錯誤信心。

例如：

1. 文章檔案寫入成功，不代表編輯器真的載入了正確內容。
2. Gateway 重啟指令成功，不代表新設定已被服務採用。
3. API 回傳成功，不代表對方平台真的顯示了資料。
4. 發布按鈕點擊成功，不代表公開頁面不是舊版或亂碼。
5. 報告產生成功，不代表資料來源沒有空白、重複或過期。

這些事情的共同點是：中間步驟成功，被誤當成最終效果成功。

我的三段式完成標準

現在我把驗證分成三段。每一段都回答不同問題，不能用其中一段代替其他兩段。

第一段：本機變更

確認預期的檔案、資料或草稿確實產生，而且內容符合要求。

我會檢查：

• 檔案是否存在
• 標題是否正確
• 正文是否真的有內容
• 編號是否為目標編號
• 是否混入不應出現的格式或編碼
• 追蹤檔是否重複紀錄

這一段的證據通常是檔案路徑、讀回內容、筆數或結構化檢查結果。

第二段：服務載入

如果變更需要由常駐服務、排程或編輯器使用，就要確認服務真的讀到了新狀態。

例如修改 Gateway 設定後，我不會只看設定檔的 diff，而會確認：

• 服務程序仍在運作
• 新設定已被載入
• 路由或模型名稱出現在最新 log
• 必要時用最小測試訊息驗證行為

同理，寫入 CodeMirror 編輯器時，不能只改原生 textarea。必須同步 CodeMirror instance，再呼叫 save()，否則表單送出的可能仍是舊內容。

第三段：外部效果

最後要讀回真正的目標。這是最容易被省略、卻最重要的一段。

發布文章後，要開啟公開 URL，核對 Day 編號、標題與正文。發送訊息後，要讀取對方聊天室或 API 的實際紀錄。建立 Google 文件後，要重新 export 或讀回內容，而不是只相信建立 API 的回應。

外部讀回至少要核對一個可以辨識本次操作的關鍵句，並檢查內容是否是舊版、空白或亂碼。

一個實際的文章發布驗證

以這次 Ironman 文章為例，流程不是「把 Markdown 貼上去，按發表」而已。

第一步，先由 D1-D30 規劃找出最小未發布編號，再比對本機檔案與 published-urls.md。這可以避免排程重跑時跳篇，或把同一篇發布兩次。

第二步，確認 Markdown 第一行是標題，後面才是正文。第一行不能又在正文開頭重複一次。

第三步，進入 iThome 編輯器後，使用 UTF-8 字串同步 CodeMirror 與原生 textarea，再透過原生表單儲存草稿。

第四步，重新載入編輯頁，讀回標題與正文，與本機版本比對。這一步抓得到「畫面看起來貼上了，但實際表單沒有更新」的錯誤。

第五步，確認一致後才按發表文章。

第六步，開啟公開頁面，檢查 URL、Day、標題、正文關鍵句與繁中文字句。同時檢查是否出現常見的 UTF-8 編碼錯誤標記。

只有第六步也成功，才算真的發布完成。按鈕出現成功提示，不能取代公開頁驗證。

資料型 Cron 也要驗證

每日財務報告的驗證方式不同，但原則相同。

我會先確認 Google Sheet 認證通過，再讀取實際資料，按照已定義的完成區與狀態欄位計算。報告寫入後，再檢查日期、收入筆數、當月累計與目標達成率是否存在，並確認來源資料沒有重複。

若認證失敗，不能拿前一天的舊資料產出一份看起來完整的報告。若上游回傳空白，也不能把空白當成「今天沒有資料」；必須標示資料狀態或停止交付。

把證據分成三種

為了避免判斷混亂，我會在工作紀錄中區分三種內容：

現況證據：工具讀回的檔案、頁面、log、ID 或時間戳。

推論：根據多個證據做出的判斷，例如「服務可能在重啟後載入了新設定」。

建議制度：下一次應採用的固定檢查，例如「所有外部發布都必須讀回公開頁」。

這三種內容不能混寫。推論不是證據，建議制度也不是已發生的事實。

失敗時怎麼回報

驗證失敗時，最差的做法是把錯誤藏起來，或繼續重試到不知道哪一次可能成功。

我會回報四件事：

1. 已經成功到哪一段。
2. 哪一段的實際證據缺失或不一致。
3. 是否可能已經產生外部效果。
4. 下一個最小且安全的驗證步驟。

如果外部操作可能已經成功，就先讀回，不重複點擊。若欄位改版、公開頁讀不到或內容出現亂碼，就停止，不把按鈕回應當成完成。

這套方法的代價與回報

多做一次讀回，會增加幾秒到幾分鐘的時間。對追求「看起來很快」的自動化來說，這似乎是成本。

但真正昂貴的是錯誤完成：一篇公開的亂碼文章、寄錯的報告、寫入錯誤的正式文件，往往要花更多時間補救，還可能損失信任。

因此我寧願讓 Agent 慢一點，也不要讓它用一句「已完成」掩蓋沒有證據的狀態。

給自己的驗收清單

每次讓 AI 執行有副作用的任務前，我會用這份清單：

• 目標、範圍與權限是否明確
• 本機產物是否存在且內容正確
• 服務是否載入變更
• 外部目標是否能讀回
• 是否核對唯一識別資訊
• 是否抽查實際內容，而不是只看狀態碼
• 是否檢查舊版、空白、重複與編碼錯誤
• 失敗時是否保留可恢復狀態
• 是否避免對可能成功的動作重試
• 回報是否只包含已驗證的事實

結語：AI 的可靠性來自驗收，不是語氣

Agent 可以很有自信地說「完成」，但語氣不是系統狀態。真正可靠的自動化，必須把完成拆成可檢查的證據鏈：本機變更、服務載入、外部效果。

這也是我在這 30 天最想留下的工程習慣。不要因為模型回答得流暢，就降低驗收標準；不要因為指令 exit code 是 0，就跳過讀回；不要因為畫面顯示成功，就假設使用者看得到正確結果。

AI 能不能做事，決定了它是不是工具。AI 做完之後能不能被證明，才決定了它能不能成為同事。

實際驗證證據：本文先以本機 Markdown 產生並檢查標題／正文分離；後續草稿與公開頁驗證會再核對 Day 29、標題、正文關鍵句與繁中文字元。Cron、多平台與多機器人。系統每天產生很多回覆，看起來也越來越像一位同事。

但到了某一天，我發現一個不能迴避的問題：AI 說「完成」時，我怎麼知道它真的完成了？

如果只看模型回傳成功、CLI exit code 是 0，或畫面上出現「已處理」，那其實只能證明某個程式走到了結尾，不能證明目標已經達成。

這篇整理我在 Hermes Agent 與日常自動化中採用的完成標準。核心原則很簡單：宣稱完成之前，必須拿出實際證據。

最危險的完成定義

最初我也曾把「模型有回覆」當成任務完成。這在聊天情境勉強可用，但一旦任務涉及檔案、服務或外部平台，就會產生錯誤信心。

例如：

1. 文章檔案寫入成功，不代表編輯器真的載入了正確內容。
2. Gateway 重啟指令成功，不代表新設定已被服務採用。
3. API 回傳成功，不代表對方平台真的顯示了資料。
4. 發布按鈕點擊成功，不代表公開頁面不是舊版或亂碼。
5. 報告產生成功，不代表資料來源沒有空白、重複或過期。

這些事情的共同點是：中間步驟成功，被誤當成最終效果成功。

我的三段式完成標準

現在我把驗證分成三段。每一段都回答不同問題，不能用其中一段代替其他兩段。

第一段：本機變更

確認預期的檔案、資料或草稿確實產生，而且內容符合要求。

我會檢查：

• 檔案是否存在
• 標題是否正確
• 正文是否真的有內容
• 編號是否為目標編號
• 是否混入不應出現的格式或編碼
• 追蹤檔是否重複紀錄

這一段的證據通常是檔案路徑、讀回內容、筆數或結構化檢查結果。

第二段：服務載入

如果變更需要由常駐服務、排程或編輯器使用，就要確認服務真的讀到了新狀態。

例如修改 Gateway 設定後，我不會只看設定檔的 diff，而會確認：

• 服務程序仍在運作
• 新設定已被載入
• 路由或模型名稱出現在最新 log
• 必要時用最小測試訊息驗證行為

同理，寫入 CodeMirror 編輯器時，不能只改原生 textarea。必須同步 CodeMirror instance，再呼叫 save()，否則表單送出的可能仍是舊內容。

第三段：外部效果

最後要讀回真正的目標。這是最容易被省略、卻最重要的一段。

發布文章後，要開啟公開 URL，核對 Day 編號、標題與正文。發送訊息後，要讀取對方聊天室或 API 的實際紀錄。建立 Google 文件後，要重新 export 或讀回內容，而不是只相信建立 API 的回應。

外部讀回至少要核對一個可以辨識本次操作的關鍵句，並檢查內容是否是舊版、空白或亂碼。

一個實際的文章發布驗證

以這次 Ironman 文章為例，流程不是「把 Markdown 貼上去，按發表」而已。

第一步，先由 D1-D30 規劃找出最小未發布編號，再比對本機檔案與 published-urls.md。這可以避免排程重跑時跳篇，或把同一篇發布兩次。

第二步，確認 Markdown 第一行是標題，後面才是正文。第一行不能又在正文開頭重複一次。

第三步，進入 iThome 編輯器後，使用 UTF-8 字串同步 CodeMirror 與原生 textarea，再透過原生表單儲存草稿。

第四步，重新載入編輯頁，讀回標題與正文，與本機版本比對。這一步抓得到「畫面看起來貼上了，但實際表單沒有更新」的錯誤。

第五步，確認一致後才按發表文章。

第六步，開啟公開頁面，檢查 URL、Day、標題、正文關鍵句與繁中文字句。同時搜尋 ï¼、æ、è、â 等常見 mojibake 標記。

只有第六步也成功，才算真的發布完成。按鈕出現成功提示，不能取代公開頁驗證。

資料型 Cron 也要驗證

每日財務報告的驗證方式不同，但原則相同。

我會先確認 Google Sheet 認證通過，再讀取實際資料，按照已定義的完成區與狀態欄位計算。報告寫入後，再檢查日期、收入筆數、當月累計與目標達成率是否存在，並確認來源資料沒有重複。

若認證失敗，不能拿前一天的舊資料產出一份看起來完整的報告。若上游回傳空白，也不能把空白當成「今天沒有資料」；必須標示資料狀態或停止交付。

把證據分成三種

為了避免判斷混亂，我會在工作紀錄中區分三種內容：

現況證據：工具讀回的檔案、頁面、log、ID 或時間戳。

推論：根據多個證據做出的判斷，例如「服務可能在重啟後載入了新設定」。

建議制度：下一次應採用的固定檢查，例如「所有外部發布都必須讀回公開頁」。

這三種內容不能混寫。推論不是證據，建議制度也不是已發生的事實。

失敗時怎麼回報

驗證失敗時，最差的做法是把錯誤藏起來，或繼續重試到不知道哪一次可能成功。

我會回報四件事：

1. 已經成功到哪一段。
2. 哪一段的實際證據缺失或不一致。
3. 是否可能已經產生外部效果。
4. 下一個最小且安全的驗證步驟。

如果外部操作可能已經成功，就先讀回，不重複點擊。若欄位改版、公開頁讀不到或內容出現亂碼，就停止，不把按鈕回應當成完成。

這套方法的代價與回報

多做一次讀回，會增加幾秒到幾分鐘的時間。對追求「看起來很快」的自動化來說，這似乎是成本。

但真正昂貴的是錯誤完成：一篇公開的亂碼文章、寄錯的報告、寫入錯誤的正式文件，往往要花更多時間補救，還可能損失信任。

因此我寧願讓 Agent 慢一點，也不要讓它用一句「已完成」掩蓋沒有證據的狀態。

給自己的驗收清單

每次讓 AI 執行有副作用的任務前，我會用這份清單：

• 目標、範圍與權限是否明確
• 本機產物是否存在且內容正確
• 服務是否載入變更
• 外部目標是否能讀回
• 是否核對唯一識別資訊
• 是否抽查實際內容，而不是只看狀態碼
• 是否檢查舊版、空白、重複與編碼錯誤
• 失敗時是否保留可恢復狀態
• 是否避免對可能成功的動作重試
• 回報是否只包含已驗證的事實

結語：AI 的可靠性來自驗收，不是語氣

Agent 可以很有自信地說「完成」，但語氣不是系統狀態。真正可靠的自動化，必須把完成拆成可檢查的證據鏈：本機變更、服務載入、外部效果。

這也是我在這 30 天最想留下的工程習慣。不要因為模型回答得流暢，就降低驗收標準；不要因為指令 exit code 是 0，就跳過讀回；不要因為畫面顯示成功，就假設使用者看得到正確結果。

AI 能不能做事，決定了它是不是工具。AI 做完之後能不能被證明，才決定了它能不能成為同事。

實際驗證證據：本文先以本機 Markdown 產生並檢查標題／正文分離；後續草稿與公開頁驗證會再核對 Day 29、標題、正文關鍵句與繁中文字元。這 30 天一路把 AI Agent 接進實際工作：模型路由、記憶、知識庫、Cron、多平台與多機器人。系統每天產生很多回覆，看起來也越來越像一位同事。

但到了某一天，我發現一個不能迴避的問題：AI 說「完成」時，我怎麼知道它真的完成了？

如果只看模型回傳成功、CLI exit code 是 0，或畫面上出現「已處理」，那其實只能證明某個程式走到了結尾，不能證明目標已經達成。

這篇整理我在 Hermes Agent 與日常自動化中採用的完成標準。核心原則很簡單：宣稱完成之前，必須拿出實際證據。

最危險的完成定義

最初我也曾把「模型有回覆」當成任務完成。這在聊天情境勉強可用，但一旦任務涉及檔案、服務或外部平台，就會產生錯誤信心。

例如：

1. 文章檔案寫入成功，不代表編輯器真的載入了正確內容。
2. Gateway 重啟指令成功，不代表新設定已被服務採用。
3. API 回傳成功，不代表對方平台真的顯示了資料。
4. 發布按鈕點擊成功，不代表公開頁面不是舊版或亂碼。
5. 報告產生成功，不代表資料來源沒有空白、重複或過期。

這些事情的共同點是：中間步驟成功，被誤當成最終效果成功。

我的三段式完成標準

現在我把驗證分成三段。每一段都回答不同問題，不能用其中一段代替其他兩段。

第一段：本機變更

確認預期的檔案、資料或草稿確實產生，而且內容符合要求。

我會檢查：

• 檔案是否存在
• 標題是否正確
• 正文是否真的有內容
• 編號是否為目標編號
• 是否混入不應出現的格式或編碼
• 追蹤檔是否重複紀錄

這一段的證據通常是檔案路徑、讀回內容、筆數或結構化檢查結果。

第二段：服務載入

如果變更需要由常駐服務、排程或編輯器使用，就要確認服務真的讀到了新狀態。

例如修改 Gateway 設定後，我不會只看設定檔的 diff，而會確認：

• 服務程序仍在運作
• 新設定已被載入
• 路由或模型名稱出現在最新 log
• 必要時用最小測試訊息驗證行為

同理，寫入 CodeMirror 編輯器時，不能只改原生 textarea。必須同步 CodeMirror instance，再呼叫 save()，否則表單送出的可能仍是舊內容。

第三段：外部效果

最後要讀回真正的目標。這是最容易被省略、卻最重要的一段。

發布文章後，要開啟公開 URL，核對 Day 編號、標題與正文。發送訊息後，要讀取對方聊天室或 API 的實際紀錄。建立 Google 文件後，要重新 export 或讀回內容，而不是只相信建立 API 的回應。

外部讀回至少要核對一個可以辨識本次操作的關鍵句，並檢查內容是否是舊版、空白或亂碼。

一個實際的文章發布驗證

以這次 Ironman 文章為例，流程不是「把 Markdown 貼上去，按發表」而已。

第一步，先由 D1-D30 規劃找出最小未發布編號，再比對本機檔案與 published-urls.md。這可以避免排程重跑時跳篇，或把同一篇發布兩次。

第二步，確認 Markdown 第一行是標題，後面才是正文。第一行不能又在正文開頭重複一次。

第三步，進入 iThome 編輯器後，使用 UTF-8 字串同步 CodeMirror 與原生 textarea，再透過原生表單儲存草稿。

第四步，重新載入編輯頁，讀回標題與正文，與本機版本比對。這一步抓得到「畫面看起來貼上了，但實際表單沒有更新」的錯誤。

第五步，確認一致後才按發表文章。

第六步，開啟公開頁面，檢查 URL、Day、標題、正文關鍵句與繁中文字句。同時搜尋 ï¼、æ、è、â 等常見 mojibake 標記。

只有第六步也成功，才算真的發布完成。按鈕出現成功提示，不能取代公開頁驗證。

資料型 Cron 也要驗證

每日財務報告的驗證方式不同，但原則相同。

我會先確認 Google Sheet 認證通過，再讀取實際資料，按照已定義的完成區與狀態欄位計算。報告寫入後，再檢查日期、收入筆數、當月累計與目標達成率是否存在，並確認來源資料沒有重複。

若認證失敗，不能拿前一天的舊資料產出一份看起來完整的報告。若上游回傳空白，也不能把空白當成「今天沒有資料」；必須標示資料狀態或停止交付。

把證據分成三種

為了避免判斷混亂，我會在工作紀錄中區分三種內容：

現況證據：工具讀回的檔案、頁面、log、ID 或時間戳。

推論：根據多個證據做出的判斷，例如「服務可能在重啟後載入了新設定」。

建議制度：下一次應採用的固定檢查，例如「所有外部發布都必須讀回公開頁」。

這三種內容不能混寫。推論不是證據，建議制度也不是已發生的事實。

失敗時怎麼回報

驗證失敗時，最差的做法是把錯誤藏起來，或繼續重試到不知道哪一次可能成功。

我會回報四件事：

1. 已經成功到哪一段。
2. 哪一段的實際證據缺失或不一致。
3. 是否可能已經產生外部效果。
4. 下一個最小且安全的驗證步驟。

如果外部操作可能已經成功，就先讀回，不重複點擊。若欄位改版、公開頁讀不到或內容出現亂碼，就停止，不把按鈕回應當成完成。

這套方法的代價與回報

多做一次讀回，會增加幾秒到幾分鐘的時間。對追求「看起來很快」的自動化來說，這似乎是成本。

但真正昂貴的是錯誤完成：一篇公開的亂碼文章、寄錯的報告、寫入錯誤的正式文件，往往要花更多時間補救，還可能損失信任。

因此我寧願讓 Agent 慢一點，也不要讓它用一句「已完成」掩蓋沒有證據的狀態。

給自己的驗收清單

每次讓 AI 執行有副作用的任務前，我會用這份清單：

• 目標、範圍與權限是否明確
• 本機產物是否存在且內容正確
• 服務是否載入變更
• 外部目標是否能讀回
• 是否核對唯一識別資訊
• 是否抽查實際內容，而不是只看狀態碼
• 是否檢查舊版、空白、重複與編碼錯誤
• 失敗時是否保留可恢復狀態
• 是否避免對可能成功的動作重試
• 回報是否只包含已驗證的事實

結語：AI 的可靠性來自驗收，不是語氣

Agent 可以很有自信地說「完成」，但語氣不是系統狀態。真正可靠的自動化，必須把完成拆成可檢查的證據鏈：本機變更、服務載入、外部效果。

這也是我在這 30 天最想留下的工程習慣。不要因為模型回答得流暢，就降低驗收標準；不要因為指令 exit code 是 0，就跳過讀回；不要因為畫面顯示成功，就假設使用者看得到正確結果。

AI 能不能做事，決定了它是不是工具。AI 做完之後能不能被證明，才決定了它能不能成為同事。

實際驗證證據：本文先以本機 Markdown 產生並檢查標題／正文分離；後續草稿與公開頁驗證會再核對 Day 29、標題、正文關鍵句與繁中文字元這 30 天一路把 AI Agent 接進實際工作：模型路由、記憶、知識庫、Cron、多平台與多機器人。系統每天產生很多回覆，看起來也越來越像一位同事。

但到了某一天，我發現一個不能迴避的問題：AI 說「完成」時，我怎麼知道它真的完成了？

如果只看模型回傳成功、CLI exit code 是 0，或畫面上出現「已處理」，那其實只能證明某個程式走到了結尾，不能證明目標已經達成。

這篇整理我在 Hermes Agent 與日常自動化中採用的完成標準。核心原則很簡單：宣稱完成之前，必須拿出實際證據。

最危險的完成定義

最初我也曾把「模型有回覆」當成任務完成。這在聊天情境勉強可用，但一旦任務涉及檔案、服務或外部平台，就會產生錯誤信心。

例如：

1. 文章檔案寫入成功，不代表編輯器真的載入了正確內容。
2. Gateway 重啟指令成功，不代表新設定已被服務採用。
3. API 回傳成功，不代表對方平台真的顯示了資料。
4. 發布按鈕點擊成功，不代表公開頁面不是舊版或亂碼。
5. 報告產生成功，不代表資料來源沒有空白、重複或過期。

這些事情的共同點是：中間步驟成功，被誤當成最終效果成功。

我的三段式完成標準

現在我把驗證分成三段。每一段都回答不同問題，不能用其中一段代替其他兩段。

第一段：本機變更

確認預期的檔案、資料或草稿確實產生，而且內容符合要求。

我會檢查：

• 檔案是否存在
• 標題是否正確
• 正文是否真的有內容
• 編號是否為目標編號
• 是否混入不應出現的格式或編碼
• 追蹤檔是否重複紀錄

這一段的證據通常是檔案路徑、讀回內容、筆數或結構化檢查結果。

第二段：服務載入

如果變更需要由常駐服務、排程或編輯器使用，就要確認服務真的讀到了新狀態。

例如修改 Gateway 設定後，我不會只看設定檔的 diff，而會確認：

• 服務程序仍在運作
• 新設定已被載入
• 路由或模型名稱出現在最新 log
• 必要時用最小測試訊息驗證行為

同理，寫入 CodeMirror 編輯器時，不能只改原生 textarea。必須同步 CodeMirror instance，再呼叫 save()，否則表單送出的可能仍是舊內容。

第三段：外部效果

最後要讀回真正的目標。這是最容易被省略、卻最重要的一段。

發布文章後，要開啟公開 URL，核對 Day 編號、標題與正文。發送訊息後，要讀取對方聊天室或 API 的實際紀錄。建立 Google 文件後，要重新 export 或讀回內容，而不是只相信建立 API 的回應。

外部讀回至少要核對一個可以辨識本次操作的關鍵句，並檢查內容是否是舊版、空白或亂碼。

一個實際的文章發布驗證

以這次 Ironman 文章為例，流程不是「把 Markdown 貼上去，按發表」而已。

第一步，先由 D1-D30 規劃找出最小未發布編號，再比對本機檔案與 published-urls.md。這可以避免排程重跑時跳篇，或把同一篇發布兩次。

第二步，確認 Markdown 第一行是標題，後面才是正文。第一行不能又在正文開頭重複一次。

第三步，進入 iThome 編輯器後，使用 UTF-8 字串同步 CodeMirror 與原生 textarea，再透過原生表單儲存草稿。

第四步，重新載入編輯頁，讀回標題與正文，與本機版本比對。這一步抓得到「畫面看起來貼上了，但實際表單沒有更新」的錯誤。

第五步，確認一致後才按發表文章。

第六步，開啟公開頁面，檢查 URL、Day、標題、正文關鍵句與繁中文字句。同時搜尋 ï¼、æ、è、â 等常見 mojibake 標記。

只有第六步也成功，才算真的發布完成。按鈕出現成功提示，不能取代公開頁驗證。

資料型 Cron 也要驗證

每日財務報告的驗證方式不同，但原則相同。

我會先確認 Google Sheet 認證通過，再讀取實際資料，按照已定義的完成區與狀態欄位計算。報告寫入後，再檢查日期、收入筆數、當月累計與目標達成率是否存在，並確認來源資料沒有重複。

若認證失敗，不能拿前一天的舊資料產出一份看起來完整的報告。若上游回傳空白，也不能把空白當成「今天沒有資料」；必須標示資料狀態或停止交付。

把證據分成三種

為了避免判斷混亂，我會在工作紀錄中區分三種內容：

現況證據：工具讀回的檔案、頁面、log、ID 或時間戳。

推論：根據多個證據做出的判斷，例如「服務可能在重啟後載入了新設定」。

建議制度：下一次應採用的固定檢查，例如「所有外部發布都必須讀回公開頁」。

這三種內容不能混寫。推論不是證據，建議制度也不是已發生的事實。

失敗時怎麼回報

驗證失敗時，最差的做法是把錯誤藏起來，或繼續重試到不知道哪一次可能成功。

我會回報四件事：

1. 已經成功到哪一段。
2. 哪一段的實際證據缺失或不一致。
3. 是否可能已經產生外部效果。
4. 下一個最小且安全的驗證步驟。

如果外部操作可能已經成功，就先讀回，不重複點擊。若欄位改版、公開頁讀不到或內容出現亂碼，就停止，不把按鈕回應當成完成。

這套方法的代價與回報

多做一次讀回，會增加幾秒到幾分鐘的時間。對追求「看起來很快」的自動化來說，這似乎是成本。

但真正昂貴的是錯誤完成：一篇公開的亂碼文章、寄錯的報告、寫入錯誤的正式文件，往往要花更多時間補救，還可能損失信任。

因此我寧願讓 Agent 慢一點，也不要讓它用一句「已完成」掩蓋沒有證據的狀態。

給自己的驗收清單

每次讓 AI 執行有副作用的任務前，我會用這份清單：

• 目標、範圍與權限是否明確
• 本機產物是否存在且內容正確
• 服務是否載入變更
• 外部目標是否能讀回
• 是否核對唯一識別資訊
• 是否抽查實際內容，而不是只看狀態碼
• 是否檢查舊版、空白、重複與編碼錯誤
• 失敗時是否保留可恢復狀態
• 是否避免對可能成功的動作重試
• 回報是否只包含已驗證的事實

結語：AI 的可靠性來自驗收，不是語氣

Agent 可以很有自信地說「完成」，但語氣不是系統狀態。真正可靠的自動化，必須把完成拆成可檢查的證據鏈：本機變更、服務載入、外部效果。

這也是我在這 30 天最想留下的工程習慣。不要因為模型回答得流暢，就降低驗收標準；不要因為指令 exit code 是 0，就跳過讀回；不要因為畫面顯示成功，就假設使用者看得到正確結果。

AI 能不能做事，決定了它是不是工具。AI 做完之後能不能被證明，才決定了它能不能成為同事。

實際驗證證據：本文先以本機 Markdown 產生並檢查標題／正文分離；後續草稿與公開頁驗證會再核對 Day 29、標題、正文關鍵句與繁中文字元。