“出发！”
一个自动写稿、发稿的系统开始工作。先核对文章清单，再整理记录，接着检查旧版本、确认哪些文章已经发布。忙得不可开交。
终于，远征报告回来了。
运行状态：成功。新送入发布流程的文章：0篇。
等一下。你们真的出墙了吗？该不会连城门都没迈出去，就把整天花在填表上了吧？
这让人想起《进击的巨人》第一集里调查兵团返城的场景。当时的团长基斯·夏迪斯不得不承认，这次行动没带回想要的成果。[1][2]
原作的场景很沉重，涉及人的死亡。软件停止运行与那种悲剧根本不是一回事。这里拿来调侃的，只是“忙了一大圈，却没完成任务”的工作方式。
巨人还没出现，大家先被文书工作击败了
任务本来很清楚：接收一篇写好的文章，检查，然后让读者看得到。
但开始之前，还有一堆“必须先完成”的事。总清单得更新，记录得对齐，旧数据得重查，下次运行的工作顺序也得整理。
每件事单看都有道理。可一旦规定发一篇文章之前必须做完所有事，就变成了：
调查兵团连出征会议都没开完，时间就耗尽了。
有一次实际运行，准备和保存管理记录占用了大量时间，系统没能进入主要的文章处理环节。不过，其他运行也确实推进过发布。问题不是每次都失败，而是辅助工作太容易挤掉真正的成果。
第二次出征，昨天的地图没了
时间不够，下一次接着做，本来完全合理。
可有条运行路径没能保存下次继续工作需要的记录。连那些被推迟任务的先后顺序都可能丢失。
“昨天调查到哪里了？”
“记录没保存下来。”
“那就从入口重新确认吧。”
先别找巨人了，赶紧救救档案室。
“可以重试”和“最终能完成”不是同一件事。出征次数越来越多，不代表最早积压的文章终于能轮到。
活着回来，不等于任务完成
还有一个小陷阱：“成功”有时只代表程序没有报错地结束了，甚至包括它因为时间不足而主动中止的情况。
对程序来说，这个说法可能没错。对等文章的读者来说，毫无安慰作用。
程序启动了？是。记录更新了？是。正常退出了？是。
文章现在能读了吗？还不能。
保存成功、提交发布、网站实际更新、最终核对通过，是四件不同的事。把它们全写成一个“成功”，人根本看不出工作停在哪一步。
不要先扩编兵团，先让一次任务真正完成
每次失败后都让另一个AI扮演团长，重新研究作战计划，当然也能撑一阵。但那就不是自动工厂，而是团长每天熬夜改远征报告的办公室。
更好的办法没那么壮烈：先把一篇文章从头到尾送达；中途停下就保存位置；一篇文章坏了，不要把其他好文章一起卡住；与发布无关的整理工作放到后面。
最后别数出征次数。要数的是：读者现在真正能打开多少篇新文章。
屏幕上又亮起了“成功”。
好消息。下次请带回文章，别只带回出征申请表。
资料与说明
[1] 《进击的巨人》动画官方网站，第1集。
[2] 关于“毫无成果”台词的出处说明（日文）。自动化部分来自匿名化的运行记录，并非作品剧情。
