既然代码总会挂，我就用 o1 模型写了一套自动重写系统。今天凌晨，一个爬虫脚本又死在 API 频率限制上了，这次我没骂娘，因为系统已经自动生成了三套绕过方案，正在用 n8n 推送到测试服务器。
这玩意儿本质上是个缝合怪。核心是 o1-preview 的推理能力，我让它分析错误日志，不是让它直接写代码，是让它拆解问题。比如“429 Too Many Requests”，它得先判断是单 IP 超限还是账号配额耗尽，然后回溯调用链，看是哪个环节的 sleep 参数设低了，还是代理池该换了。以前这种活儿我得自己 grep 日志，现在 o1 能直接给我画出个调用时序图，虽然有时候画得不对，但方向对了。
真正的难点在动作执行层。o1 分析完，给出建议“增加随机延迟，切换代理IP”。怎么执行？我最初想得太美，让它直接改原文件，结果两次就把生产环境搞崩了。后来改成沙盒模式：任何修复方案，先在一个完全隔离的 Docker 容器里跑通单元测试，测试用例也是 o1 根据错误上下文生成的。过了这关，才用 Git 打 tag，触发 CI/CD 流水线。
这套系统现在能处理 70% 的常规性挂掉，比如依赖版本冲突、第三方 API 变更、简单的内存泄漏。但面对真正的黑天鹅，比如云服务商整个区域宕机，它也只能干瞪眼，然后给我发一条最高优先级的告警。这就够了，我要的不是完美，是把我从“救火队长”的角色里解放出来。2021年那会儿，我半夜被报警电话叫醒是常态，现在至少能睡个整觉。
自愈系统的成本账得算清楚。o1 的 API 调用不便宜，尤其是深度推理模式。我做了个简单的成本控制：同类错误，三天内出现第二次，修复方案直接从未执行的“方案池”里调取，不再触发新的 o1 分析。同时，所有被采纳的修复代码都会进入一个知识库，用 embedding 做了向量化存储，下次遇到相似错误先做语义匹配。这套组合拳下来，月度 API 账单从最初的吓人，降到了可以接受的范围。
但这带来了新的焦虑：我对这套系统的依赖越来越深，深到已经有点看不懂它自动生成的某些复杂修复了。上周它处理一个 websocket 断连重试逻辑，生成的代码用了两种不同的指数退避算法，还加了心跳包校验。我看了半天，才勉强理清逻辑。这感觉很奇怪，你亲手造的“工具”，开始展现出你无法完全理解的“智能”。一方面庆幸效率提升，另一方面，那种“失控感”隐隐作痛。就像 2019 年管团队，你把权责下放，然后发现某个核心员工的想法你已经跟不上了。
自愈力才是 2024 年的生存红利。这句话不是鸡汤，是血泪教训。前几年拼的是谁更能熬夜修 bug，现在拼的是谁的代码能在你睡觉的时候自己长好。这种能力的迁移，本质上是从“体力防御”转向“系统防御”。我的爬虫、我的自动化工具、甚至我的博客发布流程，现在都挂上了这套自愈系统的钩子。它不保证 100% 不挂，但它保证挂了之后，恢复时间（MTTR）在以肉眼可见的速度缩短。
最后留个尾巴，这套系统目前最大的瓶颈，是 o1 对复杂业务逻辑的上下文理解还不够。它擅长处理技术性报错，但一旦错误根源藏在业务规则深处（比如，因为某个上游数据格式突变，导致我清洗数据的正则集体失效），它就容易给出隔靴搔痒的方案。下一步，我打算把核心业务的数据 schema 和规则文档也向量化，作为上下文喂给它，看看能不能突破这层天花板。如果成了，我可能就真的能把自己从代码里“摘”出来了。
