工程复盘：为什么“能跑”的自动化脚本并不等于可靠系统
在 虚空终端 (VoidTerm) 的开发历程中，我编写过无数自动化脚本：从基于 OCR 的屏幕信息抓取，到复杂的批处理逻辑控制。早期我常因脚本“成功跑通一次”而沾沾自喜，但在实际部署中吃过多次亏后，我才深刻意识到：“跑通”仅完成了功能的 20%，剩下的 80% 决定了系统是否具备工程级的可靠性。
一、 实验室错觉：被忽略的“正常流程”陷阱
初学自动化时，我们的测试输入往往是极其“干净”的：数据格式完美、环境无干扰、逻辑按顺序触发。在这种真空环境下，脚本表现得无懈可击。
然而，现实世界是一个充满了“脏数据”的混沌系统。识别误差、网络跳变、甚至是一个微小的延迟，都可能让原本完美的脚本瞬间崩溃。真正的系统设计，必须从“假设一切都会出错”开始。
二、 现实中的三大“系统杀手”
1. 识别偏差：误差的级联效应
在涉及 OCR 或传感器解析的任务中，误差是不可避免的。例如，系统可能会将数值 0.11 误读为 11。如果没有预设的逻辑过滤或合理性检查（Sanity Check），这种十倍级别的误差会直接传递给执行模块，引发灾难性的动作反馈。
2. 采样抖动：数值的不连续性
在自动化采集流中，数据往往存在重复、跳变或延迟。自动化系统不能盲目信任每一次读数。我们需要引入防抖逻辑 (Debouncing)：只有当数值在 $T$ 时间内保持稳定，或者符合特定的变化曲线时，才认为该输入有效。否则，系统将陷入无休止的误触发中。
3. 冷却缺失：系统的自我攻击
当判定条件在短时间内持续成立时，如果没有冷却机制 (Cooldown)，系统会以毫秒级的频率重复下达指令。这不仅会造成资源的无效空转，甚至会导致物理设备的逻辑死锁或自我攻击。一个成熟的系统，必须学会“克制”。
三、 进阶：从“脚本”到“系统”的三根支柱
要实现从简陋脚本到可靠系统的质变，我认为必须构建以下三层防御：
- 状态机设计 (State Management)： 系统必须清楚自己处于哪个阶段。决策不应仅依赖当前的瞬时输入，还应结合历史状态。状态机的存在，让系统有了“上下文”意识。
- 容错与降级 (Fault Tolerance)： 面对坏数据，系统应具备忽略、平滑处理或进入安全等待模式的能力。崩溃应当是最后的手段，而非第一选择。
- 人工介入点 (Human-in-the-loop)： 完美的自动化是不存在的。必须设计紧急停机位或人工接管接口，确保在不可控异常发生时，人类能第一时间修正航向。
四、 日志：系统的“黑匣子”与第二大脑
我后来越发重视结构化日志的建设。日志不应只是调试时的临时打印，而应是系统不可或缺的组成部分。通过记录带有时间戳、输入值、状态位和错误分类的结构化数据，我不再需要“祈祷”系统运行正常。即便发生故障，我也能通过日志回溯现场，将“玄学问题”转化为可复现的工程逻辑。
五、 结语：可靠性源于边界的清晰
构建可靠系统，核心不在于代码的复杂堆砌，而在于对边界条件的严苛定义。通过对异常、状态、接管和日志的深耕，自动化系统才能从“偶然成功”走向“长期可用”。在 VoidTerm 的未来迭代中，这种工程敬畏心将是我始终坚持的底色。