用WorkBuddy整理模型调用日志：把失败原因归成五类
起因
调用日志攒了几千行，出问题只能靠翻。想做点统计，一开始就卡在“失败原因”五花八门：超时、格式不对、没带引用、答非所问、限流……写啥的都有，根本没法归类。
后来先做了一件事：把原因收敛成五类，再让工具批量打标。
五类怎么定
| 类别 | 判定依据 |
|---|---|
| 输入问题 | 材料缺失、超长、被截断、字段没填 |
| 格式问题 | 解析失败、字段缺失、类型不对、多了围栏 |
| 依据问题 | 无引用、引用不可用、结论超出材料 |
| 服务问题 | 超时、限流、连接中断 |
| 内容问题 | 答非所问、漏项、前后矛盾 |
分类的关键不是完备，而是互斥且能机械判定。前四类都能从日志字段直接判断，只有第五类需要人看一眼——正好把人力集中在最需要的地方。
WorkBuddy 承担什么
- 按五类给日志打标，只依据结构化字段，不让它“理解语义”；
- 统计各类占比与按时间的变化，标出突然升高的类别；
- 把“内容问题”的条目单独导出成一张复核表，附原始输入输出。
第 2 步最有用：格式问题占比突然升高，通常意味着上游或提示词刚改过，不用逐条查就能定位到时间点。把这套统计固定成每日流程，可参考 WorkBuddy 官方文档 的任务编排说明。
字段设计上，BackendWiki 把参数与取值列成表的方式 值得照搬：每一类对应哪些字段值，写死在规则里，统计结果才可复现。
一个意外收获
跑了一周发现，“输入问题”里超过一半其实是同一份材料反复超长。于是改了上游的分段规则，这一类直接掉下去。原本以为是模型不稳，结果是数据没准备好。
小结
日志不缺，缺的是能把问题分开的类别。五类、机械判定、只把最难的那一类留给人，统计才有意义。分类本身不产生答案，但它能告诉你该去改哪一层。