最近这半个月，我在做一件不太起眼的事：陪一个知识库项目走"维护期"。
这个知识库的建设期早就结束了——数据入库、框架搭好、检索跑通，该有的都有了。按一般人的习惯，做到这一步就可以"交付"了。但真正拉开差距的，恰恰是交付之后的日子。
建设期的目标函数是"增量"：今天多学10条，明天多建1个模块，看得见的成长让人上瘾。维护期的目标函数却是"不退化"：没有新内容入库，不等于系统在正常运转——它可能正在悄悄过时。一条法规更新了，旧条文还躺在库里，就是隐患。
维护期学到的第一条铁律是"只加不覆盖"。数据错了，不是删掉重写，而是追加一条修正记录，保留错误样本和历史轨迹。
一开始觉得这很"低效"，后来才明白：覆盖是冒险，追加是积累。你永远不知道今天删掉的那条数据，明天会不会成为某个问题的线索。历史不是包袱，是资产。
维护期不需要每天都大动干戈。每天几分钟的例行检查——新法规发了没有、检索结果有没有异常、哪个模块好久没更新了——把问题消灭在萌芽。这像极了工程上的"日常巡检"：天天看一眼，比攒到年底大修一次省心得多，也便宜得多。
维护期里最深的体会是：AI给的结果不能直接信。检索系统返回的10条结果，可能全是无关缓存；搜索工具看着正常，返回的全是垃圾。学会"交叉验证"——不依赖单一来源，多路径确认，把每个结论都当成"待验证假设"——这是跟AI协作最值钱的能力。
AI没有教我更快，它教我的是更稳。建设期的激情人人都有，维护期的耐心才是分水岭。项目如此，知识如此，成长也是如此——真正厉害的系统，不是建出来那一刻最亮，而是运行十年后依然可靠。