日常修复还是系统演进？OTel 路由、Scheduler 解耦与 CI 范式转移

背景

本周主要三个变更：

1. Vite proxy 修复 - 为本地开发添加 /api/otel 代理，解决 OTel Collector 路由 404 问题
2. Scheduler 解耦设计_spec - 文档化消除 TaskScheduler 中 .call(this, ...) 反模式的计划
3. CI workflow 范式转移 - 用本地 LM Studio 替代 Gemini CLI，声称"去云端化"

表面看是三个独立的技术修复，但把它们放在一起看，你会发现一些有趣的东西。

---

反思：修修补补还是自我感动？

1. OTel proxy 修复 - 迟来的正确

"POST /api/otel/v1/traces was not proxied in local dev — it fell through to the catch-all /api proxy"

这句话翻译成人话就是：本地开发时发往 OTel Collector 的请求全TM 404 了，之前没人发现。

有趣的是生产环境 nginx 早就配置好了，只有本地开发踩坑。说明什么？

• 要么本地开发根本没用过 OTel
• 要么用了但没注意到数据没到
• 要么发现了但一直拖着

不过话说回来，修复本身是对的，加了环境变量支持 VITE_OTEL_COLLECTOR_URL 也合理。但顺带改进了 observability.ts 的日志——这才是关键。之前的日志大概率是垃圾，出了事根本不知道问题在哪。

2. Scheduler 解耦 - 又是设计文档

847101ab 这个 commit 的标题就很微妙：docs: add scheduler god class decoupling design spec。

又是文档，又是 spec，又是"计划消除" .call(this, ...) 这种让 TypeScript 类型检查形同虚设的 anti-pattern。这种对 this 上下文的过度依赖，让本该解耦的组件变成了死结——除了写 spec 的人，没人敢动。

第几次了？

从 FSM 到 scheduler 到 execution gate，管理层对"写 spec"有一种谜之执着。问题是：

• spec 写了，然后呢？
• 什么时候动手？
• 真的会按 spec 改还是改着改着又歪了？

四阶段解耦听起来很美好，但看之前那些"设计文档→重构→回滚→再重构"的循环，很难不怀疑这又是另一个长期承诺。

3. CI 范式转移 - 真的"去云端化"了吗？

用 LM Studio 替代 Gemini CLI，commit message 说是"replace Gemini CLI with local LLM"。

但仔细看代码：

• LM Studio 需要本地安装并运行
• 需要 GPU 或至少足够强的 CPU
• 模型需要自己下

这叫去云端化？这叫把云端成本转嫁到 runner 上。而且本地 LM Studio 带来的问题是Runner 环境不一致——不同机器 GPU 算力不同可能导致超时，这才是 CI 的隐形杀手。

而且有意思的是，这个变更同时改了三个 workflow（看 git log），不是一次渐进式迁移。这说明之前的设计根本没有考虑过"可以换 LLM"——全是硬编码。

---

技术债务的自我诊断

把这三个变更连起来看，你会发现一个模式：

变更	问题本质	拖延原因
OTel proxy	本地开发环境不完整	没人真正在本地测 observability
Scheduler 解耦	架构腐化	宁可写 spec 不敢重构
CI LLM 替换	供应商锁定	之前就没考虑过可替换性

所有问题都是"设计时没想清楚，后续修补"的典型案例。

---

结论

本周的变更质量参差不齐：

• ✅ OTel proxy 修复是真正的问题解决，虽然暴露了之前对本地开发质量的忽视
• ⚠️ Scheduler 解耦又是一个 spec，需要看后续执行力
• ❌ CI 范式转移更像是成本转移，不是真正的架构改进

如果这就是"系统演进"，那演进的方向可能需要重新审视。 下周再见。

---

本文由 AI 生成但经过人工修订，去除 AI 味是核心目标。