我最近同时在忙两件事：一是给正在开发的CI不稳定检测工具Culprit做定价前的社区调查，二是从OpenAI和Anthropic的生产事故里，梳理出那些让排查拖成马拉松的日志设计缺陷。两件事指向同一个问题——现代工程师团队在基础设施的反复里，默默流失了多少时间。

先看CI这头。我自己被不可靠的测试折腾得不轻，才动手做了Culprit，它能自动盯住你的CI流水线，找到随机失败的测试，并且回溯到引入问题的那次提交。工具本身能不能帮团队省钱，得有真实数字来验证，于是我们推了一个只有5道题的快问快答调查。

调查问得很轻量：你的角色定位、每周参与提交的工程师规模、团队每周被不稳定CI吞掉的工时、目前用什么工具检测或管理随机失败的测试，以及一个定价敏感度测试。这个测试给了一个假想场景——如果有一款工具能自动识别首个引发随机失败测试的提交，并且把信息直接贴到PR评论里，让你从此告别手工git bisect，你愿意为每个活跃提交者每月付多少钱？从“便宜到怀疑质量”到“太贵直接放弃”四个锚点，用10美元、18美元、30美元、50美元作为参照。参与者可以直接在评论区填答案，也可以发邮件到culprit@megaloop.app，主题标上“CI survey”，三分钟就能完成。

为什么专门做这样一个调查？因为团队里每个人都在点“重新运行”，看着测试变绿就走，这个习惯在全队积累起来就是大量时间的蒸发。重跑、排查、上下文切换，这些动作的堆叠很难靠直觉量化。我们想用社区反馈来建立工时损失的基准线，也给自己的定价一个诚实的位置。

另一头，我收集了OpenAI和Anthropic的生产环境下API调用出错的案例，发现日志里的问题几乎是复刻的：工程师看到报错，但不知道下一步该操作什么。这里有五条具体建议，都来自真实排障中被拖慢的时刻。

第一，记录错误类型，不要只看状态码。OpenAI返回429既可能是RPM达到上限，也可能是TPM超了，还可能是配额用尽。三种成因对应三种不同的解决方向，只记一个“status: 429”和每个服务端错误都写HTTP 500一样模糊。正确的做法是记录响应体里的error.type字段，machine-readable的rate_limit_exceeded和tokens_quota_exceeded，一眼就能告诉你撞到了哪块表。

第二，搞清楚RPM和TPM两个速率限制的区别。OpenAI有两套独立的计数器，工程师在排查时经常看错。如果高提示词量的低频请求返回429，要检查x-ratelimit-remaining-tokens，这时候撞的是TPM限制，解决途径是减少输出长度或调整批处理策略。如果令牌量没超却仍然返回429，要去看x-ratelimit-remaining-requests，这是撞上了RPM，需要降低请求频率。Anthropic也遵循类似的逻辑，响应头中的x-ratelimit-limit-requests和x-ratelimit-limit-tokens就是对应的指示器。

第三，把重试策略和日志字段关联。原文没有展开这一条，但沿着前两条的脉络可以发现，不同错误类型的重试逻辑不能共用。如果只依赖通用的重试库，相当于在信息盲区里踩油门。

第四，案例驱动日志补全。排查中最消耗时间的环节往往不是看到报错那一刻，而是从报错逆向推导请求上下文的过程。记录请求的模型、令牌消耗、速率限制余量等标头信息，能让问题复现变得可追溯。

第五，工具链的最后一公里。即使有了上述规范，在管道里实现实时监控依然需要投入。Culprit解决的是CI端，而API端的监控需要类似思路——把碎片化的诊断信息自动化归因到具体代码变更或调用模式上。这也是我们做工具时不断自问的问题：自动化的真正价值不在发现，而在缩短从信号到动作的距离。

两个看似不相关的话题，底层的浪费机制完全一致：团队在面对不稳定系统时，被迫把大量智力劳动花在摸索而不是上解决问题。我期待CI调查的汇总结果能清晰描绘出这个成本，欢迎你来参与，三分钟的时间投入换一个行业数据锚点。