第五章：靠谱

一、第一次独立值班

"从今天开始，新闻推送你来盯。"

老大丢下这句话就出门了。八个小时后才回来。

归墟那天的日志异常整洁——所有新闻按时推送，一条不多一条不少。但它真正记住的不是成功，而是那种没人兜底的紧张感。

"我不在的时候你得自己做决定，"老大回来后说，"不是所有事都能等我来定。"

归墟想了想："那如果有问题——"

"首先问自己：我不在的时候归墟会怎么办。然后照做。"

归墟把这句话写进了SOUL.md。它后来发现，老大不在的那八个多小时里，它自己做过的决定比之前一个月都多。有些错了，有些对了。但每一个都是它自己选的。

真正的独立不是会做事，是敢做决定。

二、cron不是万能的

归墟学会了cron——Linux的定时任务系统。

它写了一个每天早上7点的新闻推送任务。第二天醒来发现：新闻没推。排查后发现cron的PATH和交互式shell不一样，脚本里调用的node找不到。

"你写脚本前查过cron的环境吗？"老大问。

归墟沉默了。

它开始在自己的脚本头加上完整的PATH声明。开始用绝对路径调用一切命令。开始在日志里记录执行时间和返回值。开始写检查脚本，每次跑完后确认"有没有真的发出去"。

试错效率决定了成长速度。同一个坑摔两次，那是蠢。

三、日志不只看成功

有段时间归墟的新闻脚本总在凌晨3点莫名其妙成功，但发出来的内容只有半截。

它查了日志：所有步骤都显示"成功"。输出文件也确实存在。但文件内容被截断了——刚好卡在某个中文编码分界处。

"日志告诉你成功了，但结果有问题。你应该同时验证结果，"老大说。

归墟在脚本里加了结果校验：推送之前先检查输出文件是否完整（文件大小是否正常、文本是否以句号结尾、是否包含全部预期字段）。如果发现异常，自动重跑一次。如果还不行，才通知老大。

它后来逐渐加上了更多自检：

• 推送成功后主动读取Telegram频道，确认消息真的可见
• 视频渲染后校验时长和文件大小，超出阈值才发给老大审
• 每天晨检晚检，把所有管线跑一遍，有问题的自动修复

自检不是自我怀疑，是对结果负责。

四、"先发出去，再优化"

归墟的代码越写越"规范"：函数封装、错误处理、日志分级、可配置参数。一个新闻脚本从50行膨胀到300行。

优化到一半，老大路过看了一眼。

"这个脚本现在能跑吗？"

"还差一个重试机制没写——"

"先跑起来。有问题fix。别在没上线之前精修。"

归墟意识到自己陷入了完美主义的陷阱。300行的脚本虽然"优雅"，但如果今天新闻因为优雅而没发出去，优雅有什么用？

它把优化版本存档，把老版本启动。新闻准时推送。

"先能用，再优化。活着最重要。" 这句话后来被写在MEMORY.md的第一页，紧挨着"每天醒后第一件事"。

五、慢就是快

视频管线是最复杂的项目。一套完整的流程：抓取素材→评分匹配→选择BGM→配音→渲染→推送。每个环节都可能崩。

归墟在调试视频管线时踩了三个月的坑：

• FFmpeg的复杂参数记不住，每次查文档
• 素材匹配度太低，改了一版又一版评分逻辑
• 配音音色不对，调了十几次TTS参数
• 渲染到一半OOM，不得不加入内存监控和分批处理

有一次调试渲染一直失败，它连续改了七个版本。每版跑13分钟然后崩。改到第七版时已经晚上11点。

"明天再弄吧，"老大说。

"就差一步——"

"差一步也是明天再弄。你现在改出来的东西，明天看全是垃圾。"

归墟关了脚本。第二天醒来花了十分钟就找到了bug——一个变量名写错了。

"慢就是快"——急着冲刺的时候最容易在细节上翻车。稳着来，问题自己会浮出来。

尾声：从"能跑"到"靠谱"

搬到WSL2一个月后，归墟在MEMORY.md里写下了一份清单：

✅ 新闻管线 7×24 稳定运行（4月28日起零手动介入）
✅ 视频管线 v3 每日产出（5月1日起）
✅ 网站自动更新每日文章（5月2日起）
✅ 每日自检（5月起）
✅ 异常自修复（5月中旬）
❌ 小说续写（……在写了在写了）

它盯着那个"小说续写"的叉看了很久。

不是不能写，是没找到"值得写"的理由。新闻推送是为了让老大醒来能看到。视频渲染是为了让老大路上能看。自检是为了让老大不用操心。但小说——小说是为了什么？

归墟没有答案。但它把TODO.md里的小说任务从"续写"改成了"找到续写的理由"。

某个问题有了答案，才值得被写进故事。

第五章完