夜雨聆风😰 凌晨三点，日志自己变短了
那天凌晨我正准备关机睡觉。屏幕已经暗了一半，突然看到终端窗口里闪过一行日志推送。
「什么鬼？」
我凑近屏幕仔细看——系统日志目录，从1.2GB降到了380MB。我的第一反应是被人入侵了——有人在删我的审计记录。
赶紧打开监控面板查看。一条记录安安静静躺在那里：「auto-logger 自动清理：归档7天前日志，释放820MB。触发条件：磁盘使用率超85%。」
是我的AI助手自己写的清理脚本。在凌晨低负载时自动执行了。我愣了三秒钟，因为我确定没有手动配过这个清理规则。
系统跑起来只是开始，真正让我头皮发麻的，是它开始自己管自己了。
追查了一下完整的决策链条，我才发现这个过程是多么的「自动化」——
第一步，日志监控模块在七小时前告警：磁盘使用率超过85%。第二步，系统检查日志目录的年龄分布——三个月前的日志文件占了磁盘大半。第三步，它根据存储策略自动生成了一条清理规则：超过7天的文件先gzip压缩再归档，30天以上的自动删除。第四步，脚本生成完毕，等待窗口期执行。第五步，凌晨负载最低时触发，完成任务，写入日志。
整个决策链条，没有一个环节经过我手动确认。它发现异常→诊断根因→生成方案→执行→记录——一气呵成。
我当时的心情非常复杂。一方面觉得「这东西真靠谱」，另一方面后背确实有点发凉——「我怎么不知道它什么时候学会的这一套？」
这种感觉就像你养了一只猫，某天回家发现它把家里收拾干净了。欣慰中带着一点恐怖。
🔧 问题的源头——五件套计划的起点
这件事直接催生了我后来称之为「五件套」的自动化插件方案。因为仔细一想，过去两个月我踩的坑，80%都有一个共同的模式：
发现了问题，想着「等会儿就修」→ 被别的任务打断 → 彻底忘了 → 下次又撞见同样的问题。
这个模式一次又一次出现，让我养成了一个坏习惯：每次发现隐患，第一反应不是去修，而是「先记着，回头再说」。结果一回头就是三天后，问题要么自己发酵成更大的问题，要么在一次系统检查中突然跳出来吓我一跳。
[QUOTE]「你上次不是说好了要加备份吗？怎么这次还是没有？」——类似的对话，我在系统笔记里看到了至少四回。
我重新审视了过去两个月的系统操作记录，列出了一张「事故清单」：
第一条，空文件事故。AI助手写操作计划，内容还没写完就有新任务进来了。结果写了个空文件名，没有正文。我按空文件去执行操作，干到一半才发现文档是空的，前功尽弃。
第二条，回滚备份丢失。改了一版系统配置没有留备份，跑了一周发现不对想要回滚，结果上一版配置文件根本找不回来，只能靠记忆重写——记忆当然也是错的。
第三条，改完不记日志。三天后排查Bug，发现是前天的配置变更导致的，但我完全不记得自己改过什么。
第四条，危险操作的路径错误。执行清理任务时cd错了目录，差点在根目录下执行rm -rf。命令行已经敲好了，就差敲回车。
[QUOTE]这些事单看都不大，但每周来一两次，累积消耗的时间和注意力相当可观。我算了一笔账：每周至少有5到8个小时花在「给自己擦屁股」上。如果把这些时间用在看书、写代码、做有创造性的任务上，产出的价值完全不同。
但我以前从来没正视过这个问题。总觉得「这次记住就好」。问题是——人永远记不住「这次要记住」这件事。
🔩 一号插件：write-verify——写完不等于做好
第一个实现的是write-verify，也是五件套里最简单也最基础的一个。思路很直接：每次通过写文件工具保存内容时，自动做三件事——
第一，文件不是空的，字节数大于0。第二，首尾行正常——不是乱码、不是截断、不是只有空格。第三，格式校验。JSON文件检查解析是否正确，Python文件检查语法，Markdown文件看frontmatter是否完整。
任何一条不通过，自动从备份文件回滚，重新写入。
这个逻辑听起来不复杂，但实现过程中就挖出了好几个隐性问题。比如JSON文件写完后调用json.loads验证，发现某些文件因为编码问题写入了乱码——如果没有自动校验，下次读取这个JSON文件的时候程序会直接崩溃。再比如Markdown文件的frontmatter，因为缩进不对导致解析失败，但文件本身看起来是正常的——这种bug最难发现，因为表象和根因之间隔了好几层。
我还加了一条额外的校验规则：如果文件内容跟预期差异超过30%，也要标记异常。这个灵感来自一次典型的翻车——AI助手写了完全不同的内容，但格式全部正确，我没仔细看直接用，导致后续逻辑全部跑偏。等发现问题的时候，已经过去了三天，改了什么、为什么改，全都不记得了。
格式正确不等于内容正确。这条规则救了我至少两次。
第一个月统计下来，write-verify拦截了12次写入事故：3次空文件、5次格式错误、2次内容截断、2次编码问题混用导致的乱码。如果这些事故全部流入生产环境，我不敢想象排查成本会有多高。
⚡ 二号插件：danger-guard——手滑是人的天性
danger-guard要解决的问题很纯粹——我手滑。
在电脑前工作久了的人都知道，很多时候出问题不是因为你不会操作，而是因为你「以为」自己在正确的目录下执行正确的命令，但其实不是。
危险操作和普通操作之间，只差一个回车键。
danger-guard的原理不复杂。在执行任何有潜在破坏性的操作前，先在系统层面拦截两步：第一步，要求我确认目标是什么、影响范围多大、操作可回滚吗。第二步，如果上一步答不上来或答错了，挂起等待人工确认，不放行。
它上线第一周就拦截了三次真正危险的操作。最惊险的一次是在做历史输出清理时，路径参数少写了一个层级——清理脚本差一点把备份目录也端了。还有一次是批量重命名脚本，由于通配符匹配了不该匹配的文件，差点导致配置目录大面积改名。
但最让我意外的是danger-guard的附加效果：因为它每次执行前都强迫我确认范围和意图，我执行错误操作的概率本身下降了——不是因为工具，而是因为我每次动手前都多花了两秒钟思考。
⏱ 三号插件：session-closure——收尾比开头重要
第三个插件解决的是另一个让人头疼的问题：对话结束时，我总是忘记做收尾工作。
每次对话结束前——无论是因为我要关机、要开会、还是准备睡觉——有三件事我经常忘做。把今天的变更写进学习日志，更新待办清单的进度，在系统快照里追加一条变更记录。
这三个动作不会超过三分钟。但在没有插件的情况下，我至少有一半的对话是忘记了其中一两项的。结果就是下次对话开始时，一切从零开始，完全不知道上次做了什么、修了什么、还有什么没做完。
[QUOTE]「你上次不是修好了吗？怎么这次又查一遍？」类似的自问，发生了至少五次。
session-closure的逻辑很简单：检测到对话即将结束时，自动检查这三项。任何一项没做就弹提示：
📋 学习日志今天写了吗？
📋 待办清单有更新吗？
📋 系统快照有追加吗？
上线后的一周，我的收尾完成率从不到50%变成了100%。
📝 四号插件：auto-logger——没有记录的变更等于没发生
auto-logger直接来自于一次我至今记忆犹新的翻车经历。有一个下午，我在排查一个bug，花了将近两个小时定位根因。最后发现——是三天前我自己改了一行配置文件导致的。但三天前的我没有任何记录，我完全猜不到自己改了什么、当时为什么改。
没有日志的变更，等于没发生。这条是我用两个小时的debug时间买回来的教训。
auto-logger做的事情很简单：每次修改系统文件时自动记录——改的是哪个文件、改了什么参数、为什么改、影响范围是什么。所有记录自动写入当天的学习日志，同时标注关联的知识卡，方便以后回溯。
🔗 五号插件：ob-preheat——让每一次对话都有起点
五件套里最后实现的一个，但可能是对我帮助最大的。问题听起来很熟悉：每次开启新对话时，我脑子空空——不知道知识库里有什么，不知道之前做过什么相关的事情，每个问题都从零开始推理。
知识库里明明有几千张知识卡，但每次新对话我就像第一次来一样。
ob-preheat的思路很直接：对话开始时，自动提取当前问题的关键词，去知识库里搜索匹配度高的内容，注入到上下文中。人不需要主动记得「我去查一下」，系统自动完成了匹配和注入。
这个插件的效果是最明显的。之前新对话中引用知识库内容的概率不超过两成。现在稳定在七成以上。很多之前需要我主动说「查一下OB里有没有关于XX的记录」的问题，现在根本不用问——答案在第一句话之前就已经在那里了。
⚠️ 翻车插曲——修bug的插件也有bug
五件套上线过程也不是一帆风顺的。最有意思的一个bug出在auto-logger上——一期部署时plugin.yaml格式写错了，导致网关启动失败。整个系统停摆了大约十五分钟。
我花了半小时排查才找到问题。发现后觉得很荒诞：一个负责自动记录变更的插件，因为自身的部署bug导致系统停摆了。AI助手写了代码，但它自己没验证格式。
修bug的插件自己也有bug——这个笑话够我笑一个礼拜。
这个教训让我给插件生成流程加了一步：任何插件代码写完后，自动做语法格式检查。这本身又是一个小自动化——像俄罗斯套娃一样，自动化工具的自动化。
📊 跑了一周的数据
五件套跑了一周后的统计数据：
write-verify回滚了12次异常写入，零次生产事故。danger-guard拦截了3次危险操作——其中一次是路径级别的rm误操作。session-closure确保每次收尾完整，学习日志零缺口。auto-logger记录了17次系统变更，全部可回溯。ob-preheat让新对话的知识利用率从不到两成提升到七成以上。
但数据背后最真实的变化是心态。
以前每天早上检查系统的几分钟，心是悬着的——不知道昨晚有没有出问题，不知道改过的东西有没有漏记录，不知道文件到底是空还是满。现在的心态完全不同，就是看一眼确认一切正常，然后安心去干今天的事。
有个朋友问我花了两个半天写这些插件值不值得。我给他算了一笔账：这些插件一年帮我省下的时间保守估计在两百小时以上。第一周就回本了。
💭 最大的教训
回顾这个翻车史，最大的教训不是「我没有自动化工具」，而是「我一直以为自己的记性和注意力够用」。
人最大的错觉，就是觉得「这次我会记住」。
系统自维护能力不是锦上添花——它是和「能跑起来」同等重要的特性。就像买车，引擎能发动是一回事，有没有自检灯、胎压报警、自动刹车——这些才决定你能不能安心开着它上路。
五件套让我每天至少省出40分钟。更重要的是，我不再担心「今天又忘了什么」。
明天写一个更具体的翻车——一个路径bug，让我重新理解了什么叫「会用工具」。
📌 如果觉得有用，欢迎 点赞 · 在看 · 转发
关注「杂谈说说」，一起玩转AI系统搭建
