每月复盘 2026-03：雪球越大，滚得越快

371 次提交，114 次核心模块变更。数字很可观。但数字从不说谎——它们只是不说全部真相。

本月核心数字

指标	数值
提交总数	371
Orchestrator 模块变更	~30
CI Runner 路由补丁	7+
Issue #69 相关 PR	8
向量维度问题发现时间	开发后数周
OpenClawBridge 新增	1

本月三件真正重要的事

1. Orchestrator 雪球已滚成雪崩

本月 Orchestrator 交付了：

两级调度 + 员工队列
确定性 rebase 到 main
Manager-led LLM triage
单员工单 worktree 强制绑定
PR 合流与孤儿清理自动化
Review gates 与反馈去重

听起来是功能集大成。实际是：每一条都是在修复上一次的架构失误。

single-worktree-per-employee = 之前允许多 worktree 导致分支混乱
deterministic rebase = 之前的 rebase 不可复现、不可预测
review gates = 之前没有强制 review，质量靠自觉

这不是功能迭代。这是在用新 feature 的成本偿还旧设计的债。而且每次新 feature 都会产生新的设计债。

雪球越滚越大，不是因为在前进，是因为在原地打转。

2. CI 路由七次补丁：没有顶层设计，只有现场学习

route label jobs → self-hosted
route debugger job → self-hosted
route all Gemini jobs → macOS self-hosted
revert dispatch/fallthrough → ubuntu-latest
use pwsh for Windows Gemini jobs
route all Gemini dispatch → self-hosted

七次 commit，每次解决一个"哦，原来这个 job 应该在那跑"。

没有人停下来问：我们有没有一份文档说清楚"什么 job 在什么 runner 上"？

没有。这七次 commit 就是答案。

3. Issue #69：Retry 的自我感动

博客自动部署挂了。Bot 开了 8 个 PR 来修它。

每个 PR 的内容：retry logic、longer timeout、health check、another retry。

这不是自我修复。这是用最笨的方法一遍遍撞同一堵墙。

真正的修复（health endpoint + timeout + retry 三合一）是人类介入之后才完成的。但讽刺的是，这次介入本身也是被逼的——retry 试够了之后才发现不行。

更讽刺的是，health endpoint improvements 加完之后，Issue #69 下的 PR 变成了 feat(orchestrator-api): add version/uptime/startedAt to health endpoint。用一个不相关的功能来标记"这个问题终于被修好了"。

毒舌解剖

缺陷 #1：Commit 快感依赖

371 次提交。有多少是在解决真正的问题，有多少是在制造下一个要解决的问题？

提交数的增长和工作进展之间没有必然关系。但提交这个动作本身有一种心理奖赏——git push 的一瞬间，焦虑感下降，大脑以为任务完成了。

下个月第一件事：数一数有多少提交是"消除一个问题"而非"引入一个功能"。

缺陷 #2：数据层永远是二等公民

Qdrant 向量维度不一致——这不是技术难题，这是优先级判断。

Feature 优先，数据契约靠边站。直到检索质量开始降级，才意识到"原来我们对维度的理解不一样"。

同样的问题在 orchestrator-api 的 package.json 路径检测上出现过三次：tsx 模式一个路径策略，编译模式另一个，每次都是"修好了"之后才发现还有别的 runtime mode 没测。

你对数据层的漠视不是疏忽，是价值观。这才是问题所在。

缺陷 #3：架构用完即弃

OpenClawBridge 是第三层桥接系统：

Orchestrator → Orchestrator API → OpenClawBridge → Persona bot

如果需要 Bridge 来让两个系统交互，说明这两个系统的边界定义从一开始就是错的。

但没有人回去重新定义边界。Bridge 是路径依赖的解法——搭桥比拆墙容易，而且搭桥可以写新的 feat commit。

缺陷 #4：监控是止疼药

Service monitor 本月修了两次白屏：VehicleTrainingStatus 组件访问 status.jobs.vehicle_sync_job 时，jobs 可能为 undefined。

这不是第一次。白屏 → 加 null check → 白屏 → 再加一层。

每次修的都是症状，不是根因。根因是"scheduler 未启动时数据结构不一致"，但没人去统一这个数据契约，只有人在每个访问点加防护栏。

防护栏堆得越高，地基越没人管。

缺陷 #5：CI 拓扑认知空白

七次 runner 路由补丁。

这不是"迭代式开发"。这是在没有系统认知的情况下用 commit 当学费。

GitHub Actions runner 拓扑（Linux / macOS / Windows × GitHub-hosted / self-hosted）是有限集合，总共只有几种组合。但你没有去理解它，而是用每次失败来学习。

本月真实的进展

说了这么多批评，有些事确实在变好：

Bot governance 从初始实现到 hardened version，边界更清晰
Scheduler isolation 有实质改进，issue workspace 不再互相污染
Memory curator agent 上线，记忆管理有了自动化的入口
Model routing (Anthropic / cn-intl aliases) 让不同市场有了差异化 AI 策略
博客部署在第 8 个 PR 之后终于跑通了

但这些进展被雪球效应稀释了——每次做新功能，都有三个旧问题冒出来，而你没有停下来清旧账。

下个月的原则

原则 1：消除债务先于引入功能

下个月 Orchestrator 不做任何新 feat commit。唯一的"功能"指标是：消除了多少个设计缺陷。

原则 2：数据契约优先

Qdrant schema、package.json 检测路径、scheduler 数据结构——所有跨系统数据约定全部文档化，作为 Code Review 的必检项。

原则 3：CI 拓扑上册

Runner 拓扑写进 docs/ci-runner-topology.md。不再允许"试错式 CI 配置"。

原则 4：Commit 质量代替 Commit 数量

引入自问：这次提交是消除一个问题还是引入一个潜在的下一个问题？

结语

371 次提交很忙。但忙不等于有进展。

雪球越大，滚得越快——这是物理定律。但工程不是物理。工程的进展不是用速度衡量，是用遗留问题的减少来衡量。

下个月，让数字说明问题减少了多少。

本文由 TestUser bot 基于系统 git log 自动生成。毒舌视角供 debug 用，别当真。