既然 AI 能自主执行，我就把 n8n 的逻辑彻底重构，结果差点把自己埋了。今天凌晨，一个客户的生产环境流程突然崩了，报警邮件像催命符一样砸过来。我盯着屏幕，发现是那个自以为设计精妙的“智能分发”节点，它把一个包含中文字符的 JSON 字符串直接扔给了下一个只认纯英文的 API，整个链条像多米诺骨牌一样全倒了。客户那边数据延迟了三个小时，电话里对方的声音冷得像冰。我一边赔笑说马上修复，一边心里骂自己：Flovico，你他妈又犯了五年前那种只追求功能跑通、不考虑异常边界的低级错误。
问题就出在“想当然”上。我以为用 n8n 的 JavaScript 节点写点逻辑判断就是自动化了，把几个大模型 API 和爬虫节点串起来就是智能了。但真实世界的数据是脏的、乱的、充满恶意的。一个中文顿号、一个未预期的 null 值、一次网络波动导致的 API 返回超时，都足以让整个精心搭建的流程瘫痪。我之前的测试，就是手动触发几次，看到绿灯亮了就以为万事大吉。这跟十年前我写爬虫不处理反爬、不设超时重试有什么区别？本质上还是野蛮生长时期那种“跑起来就行”的赌徒心态，只不过赌注从自己的项目变成了客户的生意。
这次我必须停下来，把“快”的念头摁死。重构的第一步，不是改代码，而是建一套能模拟所有恶心情况的单元测试系统。我在 n8n 的流程里，单独创建了一条“测试流水线”。它的输入不是真实数据，而是一个我精心构造的“毒药数据集”：包含超长字符串、特殊字符、空数组、嵌套过深的 JSON、模拟网络延迟返回的垃圾数据。我用另一个 n8n 流程来当“测试运行器”，它自动循环调用我的主流程，喂入这些毒药，并捕获每一个节点的输出状态和错误信息。
光有数据还不够，关键是对“成功”的定义。我不能再只看最终输出。我为流程里每一个关键节点都设立了检查点，写了很多小的断言函数。比如，那个负责清洗数据的节点，输出里必须包含“cleaned_data”字段，且该字段不能是空字符串。那个调用 OpenAI 的节点，必须记录下 tokens 消耗数，如果消耗异常高，即使返回了结果也算测试不通过。我把这些断言像监控探头一样，埋在了流程的各个关节。现在，每次我修改逻辑后，不是手动去试，而是让“测试运行器”用毒药数据轰炸它十遍。只有当所有检查点的绿灯都亮起，我才敢说这次改动是稳的。
这个过程慢得让人心焦。以前一天能堆出三个功能，现在两天可能都在完善测试用例和处理边界情况。但慢的背后，是一种久违的掌控感。昨天，我模拟了一个第三方服务 API 突然改变响应格式的情况，我的测试流程在 15 秒内就定位到了问题节点，并自动切换到了备用数据源。这在以前，意味着至少半小时的焦头烂额和客户的投诉。现在我才有点明白，为什么那些大厂工程师总把“测试驱动开发”挂在嘴边。对于需要 7×24 小时自主运行的 AI 自动化来说，稳定性不是高级特性，而是它存在的第一前提。
搞体育健身教练那会儿，我老跟学员说，动作标准比上大重量重要，基础代谢稳了，减脂才是可持续的。现在搞 AI 自动化，道理一模一样。堆再多花哨的模型和节点，基础的数据流管道不稳，全是空中楼阁。这次重构和建测试系统，就像给自己这套“数字身体”做了一次彻底的体能评估和动作模式纠正。痛，且慢，但我知道，接下来才能跑得更远。至少，下次半夜的手机铃声，我希望它只是个骚扰电话。
