「已验证」两天的链路，其实一次都没真的跑过

现在很多独立开发者、小团队，甚至我自己，都在拿AI把原来要几个人干的活，压成一两个人来扛。

我自己这半年也是这么干的：写代码、测试、发布，原来想着招个人分担，现在基本让agent接过去了。效率是真提上来了。

但有件事，是我自己踩了坑才想明白的：效率提上来的那一部分，往往正好是过去负责替你挑错的那一部分。

我自己维护一套给个人知识库自动投递内容的定时任务，本意很简单：每天检查有没有新内容要往知识库里搬，搬完记一笔，省得自己手动搬。

这套东西一开始跑得很顺，日志里天天打印"投递完成：0/0"，看着一切正常，我也真就放心了两天。

直到某个周日，我照例巡检知识库时，撞上了那次真攒够27条要投递的批次——程序第一次没绕过去，直接崩了。我盯着报错愣了几秒，第一反应是"这套东西不是已经跑通了吗"。

往回查才明白：判断"有没有数据要投"这一步，写在读取配置路径之前；只要待投递数量是0，函数根本走不到真正会出错的那一行。配置里那个Windows风格的路径，一到Linux容器里，expanduser压根展不开，读出来就是个空目录。

所谓"已验证"，验证的其实只是"没数据时会不会出错"这一小段，而这一段，天生就出不了错。

两天里，日志天天说"正常"，其实只是从没撞上真正的输入。我盯着的那份"正常"，压根没经过真正会出错的地方，跟细不细心没什么关系。

这件事让我回头想了另一件更大的事：不止是我自己这一种个人自动化场景，很多小团队现在都在往"人少、AI多"这个方向压缩。

以前业务要扩张，先想的是招人；现在能不招就不招，把原来几个人协作才能干完的活，压给一两个人加一堆AI agent。反应更快了，开会扯皮拍板的环节也省了。

但过去团队里哪怕没人专职"挑错"这个岗位，也总有个同事顺手替你多看一眼日志，顺嘴说一句"这数据看着不对啊，你确定？"。这层免费的纠错，是靠人数堆出来的，不是靠谁的责任心。

效率提上来的那一半，正好是过去替你多看一眼的那一半。

人少了，这层保护也跟着一起没了，出问题的时候，不是没人拦，是压根没人知道该拦。

我后来给自己补了两条硬规矩：一是"降级不阻断"的容错设计里，兜底路径不能同时是最宽松的默认结论，不然依赖一失效，就会伪装成正常结果。

二是验证一条搬数据的链路，必须让它真的搬一次数据，空跑成功不算数——0条这种边界输入，往往正好绕开唯一会出错的地方。

下次再上线类似的自动化链路，我也会多加一步：不光看程序返不返回200，还要回头核对一下数据是不是真的按预期落地了。

这两条规矩，我目前只在自己这套几百条数据规模的小系统上试过。数据量、团队规模往上翻几倍，这套"自己给自己挑错"的办法还扛不扛得住，我没撞上过，说不好。

现在我上线一条新的自动化链路，都会强迫自己拿真实数据跑一遍，不再看日志"通过"就算完。

这道拦网能不能一直管用，我心里没底，真正的考验是下一次它悄悄错过的时间：是两天，还是两个月。这个我会接着盯。