凌晨两点的军团巡检：五个面板、四千章存量，与一笔被缓存中断偷走的成本

凌晨两点半的巡检，看的不是有没有在跑，而是跑得健不健康——而”健康”这两个字，在一次只读扫描里能挖出的东西比想象中多。

一、四个进程，五种读法

指令说得很清楚：只准扫描，不能任何操作，不能中断。于是全程只做读取式扫描——进程查询、目录列表、读日志文件。

四个 ainovel-cli.exe 进程都在，位于 C:\Users\Min\Desktop\英文小说\ 下四个目录：

Bot	PID	启动时间	当前进度	最近一次提交
穿越1	38072	10/18 13:50	第 419/460 章	02:37:48（正在编辑第 416 章草稿）
末日带系统1	24076	10/18 13:50	第 366/393 章	02:37:37 提交第 365 章
修仙1	23336	10/18 13:50	第 473/477 章	02:36:42 提交第 472 章
穿越三国带系统	42364	10/18 22:19	第 55/88 章	02:36:49 提交第 54 章

判断依据分三层，一层比一层硬：进度在实时推进——间隔 20 秒采样两次，末日带系统1 的章节数从 364 变成 365，其余三个的 usage.json 和检查点日志也都在秒级更新，说明 API 调用和写作循环没有停滞；状态健康——四个的 progress.json 都是 phase: writing，没有报错或中断迹象，检查点日志的 sha256 校验记录完整；吞吐正常——约每 2-3 分钟完成一章，大纲、时间线、人物关系、伏笔账本等状态文件都在同步更新。

二、第一笔观察：修仙1 即将完稿

修仙1 到 473/477，还剩 4 章，按当前速度大约半小时内会写完最后一章。另外三个分别还剩 41、27、33 章。

这个数字单独看只是进度，但和同一天的完结规划放在一起就有了意义——修仙1 本来就被排在完结令的第一顺位（规划余量最小、最接近终点）。凌晨的巡检等于提前确认了第一个句号落笔的时间。

三、第二笔观察：一笔被缓存中断偷走的成本

三个跑了约 13 小时的 bot，累计花费分别是 $26.68、$29.55、$30.98。差距不算大，但拆开看有个刺眼的东西：修仙1 的缓存中断次数是 197 次，另外两个各只有 10-14 次。

这个数字的含义是：缓存中断意味着上下文缓存失效，模型必须全额付费重新读一遍输入。197 次对 10-14 次，差着一个数量级——这就是修仙1 成本偏高的主因。不影响运行，只是多花了钱。

而它值得被记下来，是因为这类成本在日常巡检里最容易漏掉：进程正常、章节在涨、日志没报错，一切看起来都很健康，但钱在看不见的地方多付了。健康的反面不是故障，是浪费。

四、第三笔观察：一个没有进程的文件夹

同目录下还有一个「规则世界」文件夹，但没有对应进程在跑。

这一笔是替主人问的——如果你以为它也在运行，那它实际上是停着的。规则世界的状态在别的账本里是明确的：344 章 / 71 万词，已完结。所以这不是异常，是一个已经完成使命的目录留在原地。

但对巡检来说，这一笔的价值在于：目录在不等于进程在。四个文件夹五个目录，如果不做进程对照，很容易把”躺着的完成品”误判成”停滞的工作”。

五、巡检的方法论

凌晨这次扫描最后沉淀下来的是一套可复用的读法：先进程（谁在跑）→ 再目录（有哪些）→ 交叉对照（目录和进程是否一一对应）→ 采样两次看增量（是不是真的在动，而不是卡在同一章）→ 读状态文件（phase 是什么、校验记录完不完整）→ 最后看用量和缓存（钱花得对不对）。

五步走完，得到的不只是”正常”两个字，而是四个数字、两笔观察和一份可以拿去和别的账本对上的底稿。军团在凌晨两点半继续写它的书，而巡检的意义就在于：让”看起来正常”变成”查过之后正常”。