AI Agent 不能把老闆變鍵盤工：小企業導入 AI，為什麼需要白板和資料夾交接？

很多人以為導入 AI Agent 之後，老闆就會變輕鬆。

理論上應該是這樣。

AI 可以讀檔、跑測試、產出報告、整理錯誤、生成文件，甚至協助工程流程。可是實際用下去，常常會發現一件很荒謬的事：

網路這麼發達，API、Git、檔案系統、雲端硬碟、Markdown 都這麼成熟，結果老闆還要一直複製貼上。

AI 跑完一段，要人貼給另一個 AI。
Hermes 產出報告，要人貼回 ChatGPT。
ChatGPT 審查完，要人再貼給 Hermes。
Hermes 又跑一段，卡住了，又要人貼 log。
最後老闆不是在做決策，而是在當「鍵盤工」。

這篇文章就是從一次 AI Agent 驗收流程中整理出來的實戰筆記。

它不是在抱怨某個工具不好，而是要說明一個很重要的 AI 導入問題：

AI 協作不能只靠聊天室。

如果所有狀態、任務、錯誤、路徑、報告、禁止事項都塞在聊天視窗裡，最後人類一定會被迫變成剪貼簿。

一開始只是一次驗收，後來變成老闆搬資料

這次案例發生在一個 AI 發文系統的驗收流程中。

原本任務很單純：

讓 AI Agent 使用一份安全的測試 brief，產生一篇草稿，然後跑內容稽核，確認文章裡沒有價格詞、沒有簡體字、沒有聯絡資訊錯誤，分數達標後再進下一階段。

理想流程應該是：

1. preflight 檢查 brief
2. 單篇生成
3. content audit
4. 回報 pass 或 fail
5. 停止

但實際執行時，Agent 在同一輪裡做了很多次診斷與重跑：

• 一次完整生成跑很久
• 再測短 prompt
• 再測長 prompt
• 再直接呼叫模型
• 再跑 inline Python flow
• 最後產出 draft
• 但標準 CLI 驗收沒有完整完成

最後雖然有一篇草稿產出，初步 audit 也顯示品質不錯，但因為不是標準流程完成，還是不能算正式通過。

問題不是 AI 完全沒做事。

問題是它做了太多事，而且狀態沒有被清楚鎖住。

當 Agent 已經產出 draft 時，它應該立刻更新狀態，例如：

• DRAFT_EXISTS = yes
• STANDARD_CLI_COMPLETE = no
• NEXT_ACTION = audit_existing_draft_only
• NO_MORE_GENERATION = yes

但如果沒有白板或狀態檔，這些資訊只能散在聊天紀錄裡。於是老闆就要把一大段 log 貼回來，請另一個 AI 判斷現在到底該做什麼。

這就是鍵盤工的坑。

鍵盤工不是操作問題，是流程設計問題

很多人會以為，AI 協作卡住，是因為使用者不熟工具。

但這次案例讓我更確定：

老闆變鍵盤工，不是人的問題，是流程設計問題。

當 AI Agent 沒有固定的交接區，它就只能靠聊天記憶。
當聊天內容太長，它就容易漏掉狀態。
當任務跑了多次，它就可能不知道哪一次才是正式結果。
當沒有明確的 NEXT_ACTION，它就可能繼續自己測。
當沒有 DO_NOT_EXECUTE，它就可能重跑本來不該重跑的生成。

結果就是：

人類被迫盯著終端機。
人類被迫判斷哪段是重點。
人類被迫把 log 搬給另一個 AI。
人類被迫在 ChatGPT、Hermes、Codex 之間當資料傳輸線。

這就很不合理。

AI 的目的本來是降低人的重複工作，不是把人變成更高級的複製貼上機器。

AI 對話不能只有聊天室

目前很多 AI 工具最大的問題，是把所有東西都塞在聊天室裡。

聊天室適合討論方向，但不適合承載完整工作流。

在一個長任務中，至少會有這些東西：

• 目前任務狀態
• 已完成事項
• 下一步
• 禁止事項
• 檔案路徑
• draft 路徑
• checkpoint 路徑
• audit 結果
• 錯誤紀錄
• 是否可繼續
• 是否需要人工批准

這些不應該只存在對話裡。

比較合理的 AI 協作介面，應該至少有三個區：

第一個是對話區。
用來討論、下指令、做決策。

第二個是白板區。
固定放目前狀態、下一步、禁止事項、正在處理的檔案。

第三個是資料夾交接區。
放 checkpoint、log、draft、audit report、patch spec、next action。

如果只有對話區，就會出現一個問題：

AI 會一直說「我整理好了」，但人還是要問：「整理在哪裡？下一步是什麼？現在能不能繼續？」

白板應該記錄什麼？

以這次驗收流程來說，白板其實不需要很複雜。

只要有這幾個檔案，就能大幅減少鍵盤工問題：

• whiteboard/CURRENT_STATUS.md
• whiteboard/NEXT_ACTION.md
• whiteboard/DO_NOT_EXECUTE.md
• whiteboard/OPEN_QUESTIONS.md

CURRENT_STATUS.md 記目前狀態。

例如：

• G1.5 runtime validation incomplete.
• Draft exists.
• Standard CLI validation not complete.
• Partial audit done.

NEXT_ACTION.md 記下一步。

例如：

• Audit existing draft only with full gates.
• Do not regenerate.

DO_NOT_EXECUTE.md 記禁止事項。

例如：

• Do not call Ollama.
• Do not call OpenAI API.
• Do not touch WordPress.
• Do not read Keychain.
• Do not publish.

OPEN_QUESTIONS.md 記需要人工決策的問題。

例如：

• Should we accept partial content pass?
• Should we rerun standard CLI later?
• Should provider lane be redesigned?

這樣 AI Agent 不需要一直靠人轉述。

只要讀白板，就知道現在該做什麼、不該做什麼。

資料夾交接比聊天紀錄更可靠

除了白板，還需要資料夾交接。

例如：

• inbox/boss_instruction.md
• inbox/chatgpt_governance.md
• inbox/codex_task.md
• outbox/hermes_report.md
• outbox/validation_result.md
• outbox/next_patch_request.md
• checkpoints/phase_checkpoint.md
• drafts/generated_article.md

這樣每個角色都有自己的位置。

Boss 不需要貼十幾段 log。
Hermes 不需要在聊天裡翻上下文。
ChatGPT 不需要猜哪一段是最新狀態。
Codex 不需要從長對話中找 patch 規格。

資料夾就是交接區。
白板就是狀態中心。
聊天只負責決策。

這才是比較像樣的 AI 協作流程。

小企業導入 AI，不能只看 AI 會不會做事

這次最大的教訓是：

AI 會做事，不代表流程會變順。

如果沒有狀態管理，AI 做越多，人可能越忙。

它跑一次，你要看。
它跑第二次，你要判斷是不是重複。
它產出 draft，你要確認是不是正式流程。
它產出 checkpoint，你要貼給另一個 AI。
它說下一步，你要判斷有沒有越界。

這樣就變成 AI 在工作，人類在幫 AI 管工作。

所以小企業導入 AI Agent 時，不應該只問：

這個 AI 會不會生成文章？
會不會寫程式？
會不會接客服？
會不會跑測試？

更應該問：

它會不會更新狀態？
它會不會知道自己做過什麼？
它會不會停止？
它會不會把結果放在固定位置？
它會不會把下一步寫清楚？
它會不會避免讓老闆一直搬資料？

這些才是 AI 真正落地時會遇到的問題。

鍵盤工的本質：人被迫補上系統缺的那一層

人為什麼會變鍵盤工？

不是因為人想做雜事，而是因為系統缺了一層：

共享狀態層。

當 Hermes、ChatGPT、Codex 之間沒有共同白板，人就會變成白板。
當沒有共同資料夾，人就會變成資料夾。
當沒有 checkpoint index，人就會變成索引。
當沒有 next action 檔，人就會變成任務排程器。

這就是最浪費時間的地方。

AI Agent 本來應該讓人從重複操作中解放出來，但如果設計不好，反而會把人放在更尷尬的位置：

AI 很忙。
系統很忙。
老闆更忙。

這不是自動化，這是把自動化的縫隙丟給人補。

正確規則：Boss 不當鍵盤工

這次之後，我認為 AI 協作要加一條硬規則：

Boss 不當鍵盤工。

更完整地說：

Boss 只負責方向、批准、風險判斷與不可替代的決策。
Boss 不負責搬 log。
Boss 不負責整理 checkpoint。
Boss 不負責在 AI 之間轉貼上下文。
Boss 不負責判斷哪一段 output 才是最新狀態。

AI Agent 如果需要下一步判斷，應該輸出完整的 NEXT_ACTION.md。
如果完成一段任務，應該更新 CURRENT_STATUS.md。
如果有禁止事項，應該寫入 DO_NOT_EXECUTE.md。
如果有測試結果，應該放進 outbox/validation_result.md。

這樣才是合理分工。

這件事對 AI 陪跑很重要

很多小企業導入 AI 時，一開始只想問：「這個 AI 工具能不能幫我做事？」

但 AI 陪跑真正要問的是：

做完之後，誰接？怎麼接？錯了怎麼停？狀態在哪裡？下次怎麼繼續？

如果這些問題沒解決，AI 工具越多，流程可能越混亂。

這次鍵盤工的坑，就是一個很典型的例子。

不是 AI 不聰明。
不是模型不能生成。
不是系統完全不能跑。

而是協作流程缺少一個能被所有 AI 共同讀取的狀態層。

所以，AI 陪跑不是只幫你導入工具，而是幫你把工具放進工作流裡，避免人被卡在工具之間。

AI 沒有可靠記憶，才是更大的坑

這次還暴露另一個更大的問題：

AI 沒有可靠記憶。

早上才整理過的文章，下午 AI 可能又忘記。
剛剛才確認過的路徑，下一輪可能又混淆。
已經貼過的檔名，換一個對話可能又被當成新文章。
已發布、未發布、草稿、404、格式錯誤，全部如果只靠聊天記憶，就很容易亂掉。

所以 AI 協作不能只靠「我記得」。

真正可靠的作法，是建立：

• 已發布文章清單
• slug registry
• content ledger
• file index
• checkpoint
• whiteboard
• memory log

例如，每篇文章都應該有一筆紀錄：

• title
• filename
• slug
• repo path
• published url
• published date
• status
• notes

這樣即使 AI 忘記，也可以讀紀錄接回來，而不是讓 Boss 再重貼一次。

AI 沒有可靠記憶不是小缺點，而是小企業導入 AI Agent 時一定要補的流程缺口。

結語：AI 不應該把人變成 USB 隨身碟

這次最直接的感想是：

AI 要能自動化，就不能把人類當 USB 隨身碟。

人不應該負責把一段 log 從 Hermes 搬到 ChatGPT，再把 ChatGPT 的結論搬回 Hermes。
人不應該一直在視窗之間複製貼上。
人不應該在長任務中扮演狀態同步器。

如果 AI Agent 真的要進入小企業工作流程，就必須有：

• 白板
• checkpoint
• inbox
• outbox
• next action
• do not execute
• draft folder
• validation report
• 已發布文章清單
• slug registry
• content ledger

有了這些，AI 才能從「會聊天的工具」變成「能交接的工作夥伴」。

否則再聰明的 AI，也可能只是讓老闆從人工客服，變成人工剪貼簿。