代码的“生存力”不是指它能跑多快，而是指它能不能在没人盯着的时候自己爬起来。这套自愈系统，本质上是我对“失控”的恐惧催生出来的。四十岁，精力断崖，半夜被报警电话叫醒去修生产环境的日子，我一天都不想再过了。
这套系统的核心逻辑很简单：让 AI 当那个永远在线的、不知疲倦的运维。但难点在于，你不能只信一个 AI。GPT-4 会胡编乱造，Claude 有时过于保守，DeepSeek 对中文指令理解好但英文上下文弱。单一模型的“幻觉”就是单点故障。我的方案是“三权分立”：一个主执行模型（通常是 GPT-4），一个交叉验证模型（Claude 3 Opus），再加一个专门做代码补全和语法检查的模型（比如 Code Llama 70B 本地部署）。它们不是串联，是并联加博弈。
具体到那次支付回调接口雪崩的事故。凌晨两点，监控告警：回调成功率从 99.9% 跌到 40%。旧流程是我被电话吵醒，连 VPN，看日志，大概率是上游支付机构证书更新或 IP 白名单变动。但这次，自愈系统先动了。主模型（GPT-4）读取错误日志（“SSL handshake failed”），它给出的第一版修复是更新本地 CA 证书库。这个指令被同步给交叉验证模型（Claude），Claude 调取了同一时间段内其他正常服务的网络拓扑日志，发现并不是全局证书问题，它判断更可能是对方服务器 TLS 版本不匹配。两个模型结论冲突，触发“仲裁机制”。
仲裁不是投票，是让它们各自生成修复代码和回滚方案，然后丢进一个沙箱环境做快速测试。测试脚本会模拟真实流量，调用一个我提前部署好的、用于验收的 Mock 支付网关。十秒内，沙箱反馈：GPT-4 的证书更新方案无效，错误依旧；Claude 的“强制降级 TLS 1.2”方案通过。系统自动采纳 Claude 方案，生成热修复补丁，通过 Jenkins Pipeline 发布到预发环境，跑完集成测试后，自动灰度发布到一台生产服务器。全程，我手机只收到一条飞书通知：“支付回调 SSL 故障，已采用方案 B（TLS降级）修复，灰度发布中，成功率回升至 95%。” 这时候我才刚醒，摸过手机看了一眼，还能再睡四十分钟。
技术栈上，这套东西是 n8n 做流程编排的骨架，串联了 OpenAI、Anthropic 和本地 Ollama 的 API。核心是那个“仲裁沙箱”，用 Docker 临时容器实现，每次仲裁启动一个干净环境，执行候选修复代码并运行验证用例，完事即焚。最难的部分不是让 AI 写代码，而是设计那个“验证用例”的生成逻辑。你不能指望 AI 自己完全理解业务的全部边界，所以我提前埋了大量“契约测试”的桩子，比如“回调成功后本地订单状态必须为 paid”、“不得重复通知”。自愈系统生成的任何代码，最终都要通过这些桩子的检验，否则会自动回滚到上一个可用版本，并标记该次修复策略为“不可信”。
这背后是一种思维转变。以前追求代码的“优雅”和“性能”，现在只追求“生存”。优雅的算法可能因为一个依赖库弃用而崩溃，但一个能自动寻找替代依赖、甚至重写相关函数段的系统，才有资格活下去。我四十岁了，没体力再和千奇百怪的运行时环境搏斗。我的核心竞争力，不再是能写出多精妙的递归，而是构建一个能包容混乱、自我修正的生态。让代码像野草一样，火烧不尽，环境变了，它自己能找到缝钻出去长。
这套系统目前看管了大概 70% 的常规线上故障，主要是第三方 API 变更、证书问题、数据格式微调这类。真正的复杂业务逻辑漏洞还不行，AI 理解不了背后的商业意图。但够了，它把我从“消防员”变成了“监工”，值回所有投入。下一步是让它学会分析监控数据趋势，在故障发生前就提前预警和修补，那才是真正的“自愈”。到那时，我大概就能安心地、真正地睡个整觉了。
