LLM错误分析生命周期

前提认知：不要一上来就写测试。Evals 本质是对 LLM 应用做数据分析，测试必须从真实数据里长出来（这一点与传统软件工程不同——LLM 是随机系统、表面积大，你无法预知它会怎么错）。

1. 看 traces（完整交互日志）：在任意 observability 工具（Braintrust / Phoenix Arize / LangSmith 均可，无工具偏好）里逐条查看系统提示词、用户消息、工具调用、AI 回复的完整序列。
2. Open coding（开放式笔记）：由人——通常是产品经理/域专家——对每条 trace 写一条自由笔记，只记录看到的第一个最上游错误，不追求找全该条里的所有问题，写完就走。笔记要具体（"未与用户确认就转接人工"），不要只写 "janky" 这种模糊词，否则后续人和 LLM 都无法归类。此步骤不能交给 LLM：LLM 缺产品上下文，会把坏 trace 判成 "looks good"（例：产品根本没有虚拟看房功能，AI 却向客户承诺了虚拟看房，ChatGPT 看不出这是幻觉）。
3. 数量与停止标准：建议先做 100 条——这个数字是为了心理解锁，不是魔法数。真正的停止标准叫 theoretical saturation（理论饱和）：连续看新 trace 不再发现新类型问题就停，很多人 15-60 条即饱和。
4. Axial coding（轴向归类）：把所有 open codes 丢给 LLM（ChatGPT / Claude 项目 / Julius 均可），用 "open codes / axial codes" 这两个社科术语提示它，让它归纳失败模式类别。人必须审改这些类别，使其具体、可行动（"tour 改期问题" 好于 "能力局限" 这种不可行动的大词）。技巧：加一个 "none of the above" 选项，若 LLM 频繁选中，说明你的类别不完备，需要回头补。
5. 计数与排优先级：用最笨的 pivot table 统计每个失败模式的出现次数，从混沌变成 "我最大的问题是 X"。计数不是唯一标准——低频但危害大的问题也可优先。
6. 分流处理：一眼能修的工程性错误（如 prompt 里忘了写格式要求）直接去修，不必为它建 eval；只有主观、反复出现、不知如何修的顽固失败模式，才值得建自动评估器——能用代码断言（格式、长度、包含关键词）就用代码（便宜），否则用 LLM-as-judge。
7. 持续循环：初次重投入后每周约 30 分钟做一轮。为降低看数据的摩擦，可用 AI 花几小时给自己造一个内部标注小工具（隐藏系统提示词、快捷键翻页、自动计数等 quality-of-life 改进）。