周记 2026-04-05: 当 CI 失败时，机器替你擦屁股

发生了什么

本周最"重量级"的提交是 feat(orchestrator): CI failure → auto-debug pipeline。

简单说：当 deploy-bm-dell-server 工作流失败时，系统会自动：

接收 webhook 回调
创建一个带有 ci-failure/auto-fix 标签的 GitHub Issue
触发 orchestrator 的 process_issue 任务
进入完整的自动修复循环： triage → worktree 隔离 → agent 诊断 → 代码修复 → push → PR → review → merge

与此同时，还修了一个 nginx auth_request 的小 bug：把 /api/v1/auth/check-session 加到 public_paths 里，这样验证 API key 的中间件就不会拦截它。

"CI 自动debug"这个功能，听起来很酷，但本质上是在解决一个自己制造的问题。

为什么 deploy 会失败？因为代码写得烂。为什么不从根本上提升代码质量，而是造一个"失败后自动修复"的系统？这就像一边熬夜一边买护肝片——治标不治本，还自我感动。

一个简单的 CI 失败，理论上只需要：收到通知 → 手动排查 → 修复提交。现在倒好，引入了一整个 webhook 链路、orchestrator 任务调度、GitHub Issue 自动创建、工作树隔离、agent 诊断...

这复杂度上升了不止一个量级。后续维护这个"自动修复"系统的成本，可能远高于手动修 bug 的成本。

为什么这么执着于"自动化修复"？深层原因可能是对不确定性的焦虑。

代码会出错，人会疲劳，部署会失败——这些都是客观现实。与其试图构建一个"永不出错"的系统，不如接受"人就是会犯错"这个事实，把精力花在如何快速响应上。

每周都有新提交、新功能，像是在用"产出"证明自己没在浪费时间。但真正有价值的，可能是深度的思考和沉淀，而不是频繁的 commit。

这周的"自动化修复"功能，是一个典型的大型项目陷阱：用复杂的解决方案，去掩盖根本的问题。它展现了技术能力，但也暴露了焦虑和过度设计的倾向。

或许下一步该思考的，不是"如何更快地修复 bug"，而是"如何减少 bug"——无论是通过更好的设计、更严格的 code review，还是更简单的架构。

下周目标：给这个自动debug系统擦屁股——不是修 bug，而是删掉它，或者至少让它不要那么"自动化"。