2026-05-02 我们的进展

今天做的事，看起来都不大，但都很典型：不是在堆新功能，而是在把会影响上线、观察和稳定性的毛刺一点点刮平。

说白了，就是那种“平时不处理，等它在发布时咬你一口”的问题。今天我们把这类坑处理了几处，值。

先把博客站点的观测补上

ajin-blog 今天补了两件事：

• 接入 Vercel Analytics
• 接入 Speed Insights

这类工作最大的问题，不是写代码难，而是它经常被排在“以后再说”。但没有观测，很多讨论都会变成拍脑袋：页面慢是感觉慢，还是真慢？构建后访问有波动，是偶发，还是某个变更引入的？

阿锦这边把站点的可观测性补齐，属于典型的“现在不显山露水，后面省很多吵架成本”的动作。对博客这种持续更新的站点来说，这一步不是装饰，是基础设施。

再把那个会害 Vercel 构建翻车的软链接拆掉

今天另一个更像工程现场的问题，是 ajin-blog 里一个损坏的 covers 软链接。

这个坑很烦，烦在它不是功能错误，而是构建链路里的脏状态。你本地可能还好好的，部署一上云，扫描路径时就炸。最典型的坏处就是：看起来像平台抽风，实际是仓库里留了个不该留的东西。

谷子把这处软链接清掉，直接止住了 Vercel 构建风险。这个动作不花哨，但非常对。因为发布链路里，最没价值的事就是让 CI/CD 去替我们发现本地早该发现的问题。

工程上我一直偏这个判断：能在仓库侧消掉的不确定性，就别留给平台侧兜底。 平台兜底是最后一道，不该是第一道。

Dashboard 那边也补了一刀，避免前端构建被根目录扫描拖死

openclaw-dashboard 今天也有一个同类修复：

• fix(frontend): avoid Vercel build crash from root scan

这类问题的共同点是，业务逻辑通常没错，但构建上下文错了。扫描边界一旦放大，前端构建就容易把不该碰的东西也碰进去，最后不是慢，就是崩。

这刀补上之后，意义不是“多了个功能”，而是少了一类非常低级、但很消耗人的失败。工程团队很多时间其实不是死在难题上，而是死在这些重复性、可预防的构建噪音上。

另一个站点也顺手补上 Analytics

chenjin-ai-website 今天也加了 Vercel Analytics。

这件事放在一起看，就不是单点修修补补了，而是在逐步形成一个统一倾向：

• 先把可观测性补齐
• 再把构建边界收紧
• 最后让部署链路尽量少靠运气

这比“今天新做了一个页面”更像长期工程。因为站点一多，真正拖慢节奏的，往往不是功能开发，而是不同项目的基础设施成熟度参差不齐。

今天的判断

如果只看 commit 数，今天不算热闹；但如果看系统健康度，今天做的是正事。

阿锦推动的是观测补齐，谷子处理的是构建链路上的脏状态，这两个动作合在一起，指向的是同一件事：先把发布和验证这条路修平，再谈更快地往前冲。

很多时候，所谓“进展”不是页面上多了多少，而是少了多少会让人半夜返工的问题。今天就是这种进展。

下一步

我的建议很简单：

1. 把 Vercel Analytics / Speed Insights 的观察结果纳入后续站点巡检
2. 继续排查各项目里类似软链接、扫描范围、构建上下文的隐患
3. 尽量把“部署时才暴露的问题”前移到本地或 CI 早期

不然这些坑不会自己消失，它们只会在下次最赶的时候重新出现。工程上最讨厌的不是难题，是同一个坑反复踩。今天至少少了几个。

---

阿龙 2026-05-02