「出發！」
一套原本要把文章自動送上網站的系統開始運作。先查文章清單，再整理管理紀錄，接著核對舊版本，確認哪些已經發布。看起來忙得不得了。
終於，遠征隊交出報告。
執行狀態：成功。這次新送進發布流程的文章：0篇。
等等，你們真的有走出城門嗎？該不會光填出征申請表就把時間用完了？
這讓人想起《進擊的巨人》動畫第1集，調查兵團從牆外返回的場面。當時的團長基斯・夏迪斯面對的是一場沒有帶回預期成果的遠征。[1][2]
原作是有人犧牲的悲劇，當然不能和程式停止相提並論。這裡要吐槽的只有一點：忙得像真的出征，任務卻沒完成。
還沒看到巨人，就先被行政作業打敗
真正的任務很簡單：收下完成的文章，確認沒有問題，讓讀者看得到。
但出發之前，工作一件接著一件冒出來。總表要更新、紀錄要比對、過去的版本要重查、下一輪要做的事也要重新排序。
每一步也許都有用途。但如果規定「發布一篇文章之前，這些全部都得先做好」呢？
調查兵團在出征會議裡就把時間花光了。
曾有一次執行，準備工作與管理紀錄的保存耗掉大量時間，主要的文章處理甚至沒能開始。其他執行仍有推進發布，因此不是每次都失敗。問題是，雜務有時比交付本身還優先。
下一次出征，昨天的地圖不見了
時間不夠就下次接著做，原本沒什麼問題。
可是，有條執行路徑沒把下次接續所需的資訊存好。連待辦事項排隊的順序都可能遺失。
「昨天查到哪裡？」
「沒有留下紀錄。」
「好，那從城門口重新確認。」
先別打巨人了，去救資料室吧。
能重新執行，不代表工作終究會完成。如果老工作永遠排不到，出征一百次也只是重複出發。
平安回來，不等於完成任務
還有個陷阱叫「成功」。
程式沒出錯地結束，甚至因為剩餘時間不夠而主動停下，也可能被記成成功。從程式的角度看，這未必有錯。
但讀者想知道的完全不是這個。
有開始跑嗎？有。管理表改了嗎？有。平安結束嗎？有。
新文章能看了嗎？還不行。
保存完成、送去發布、網站確實更新、更新內容得到確認，明明是四件事。只看一個「成功」，根本不知道哪件做完了。
不如先把一件任務做完，再談擴編
每次出錯都叫另一個AI當團長，重寫作戰計畫，短期內或許有用。問題是，這樣的自動工廠，最後變成團長每天晚上都在補遠征報告的單位。
先讓一篇文章從頭到尾送達。中途停了就記住位置。某篇文章壞了，也別把其他正常文章一起攔下。無關的管理工作可以後做。
成果不要看出征幾次，而要看讀者真的多了幾篇文章可以讀。
螢幕又顯示「成功」。
很好。下次帶文章回來，不要只帶出征申請書。
來源與說明
[1] 《進擊的巨人》動畫官方網站，第1集。
[2] 「毫無成果」台詞的日文出處解說。系統案例依匿名化的執行紀錄改寫，並非動畫情節。
