GitIntel 没什么好说的，那篇插桩文章才是真东西

昨晚刷 dev.to，刷到一篇 SigNoz 黑客松的参赛文章，题目里躺着"GitHub 打分"四个字，没忍住点了进去。项目叫 GitIntel，一句话定调——一个用 Gemini 2.5 Flash 给 GitHub 仓库打分的 AI 分析器。丢一个 GitHub 用户名，选最多五个仓库，按八个工程维度评分，顺手出一份开发者画像。demo 级，跑起来挺顺，工具本身没什么好说的。

真正让我蹲下来看完的，是作者 Divya 给这个 AI 应用上了全套可观测性之后挖出来的两个反直觉结论。

起因是 token 消耗差异悬殊——有的逼近四万，有的不到四千；一次分析的耗时从 8 秒到 52 秒，明明仓库看起来差不多。这种事不插桩根本看不见，看不见就没法优化。她装了 OpenTelemetry SDK，配自托管 SigNoz，原生支持 OpenTelemetry，几分钟拉起来，插桩代码全堆在一个 telemetry.py。自动插桩只给了基础的 HTTP 和 GitHub API 追踪，值钱的是手动加的那层——Gemini 生成、文件抓取单独打 span，附带仓库名、提示字符数这些属性；token 指标也按仓库名分开记，能直接对比消耗。

结论来了。第一，GitHub API 的抓取速度根本不是瓶颈，真正的延迟大头是 Gemini 的推理耗时。第二，仓库的文件数量不能预测 token 成本，提示的构造方式和是否分批处理，影响比文件数大得多。这个我服！第二条我在别的地方真没见过有人写出来。

坑也写得老实：Render 上部署时目标环境没有 OpenTelemetry Collector，导出器死磕 localhost:4317，报错刷屏把日志全淹了；SigNoz 刚启动时 ClickHouse 还没就绪，数据落不了盘。自托管过可观测性的人应该都懂。

她自己的总结一句到底："自动插桩提供基本可见性，自定义插桩才提供深层次理解。"后面还补了句"应该一开始就插桩而不是事后补救"——多少有点事后聪明，她自己也是先跑起来才加的。不过人就是这么学乖的。

适合谁：在写 AI 应用、尤其被 token 成本和推理耗时搞到头大的，这篇值得点开看。她文末挂着演示地址和 repo，想拿 GitIntel 跑一下也行，但那不是重点。不适合谁：只是想要个现成 GitHub 评分工具的，这是演示级作品，别指望它给你写绩效报告。

候选池里本来蹲着一个同方向的评测框架，看完这篇反而犹豫了——AI 应用的可观测性这块，愿意给自己插桩的项目不多，能写清楚的更少。先记一笔，下次再看。