用途：从生产 AI 流量中找出失败之处并命名失败模式。多数失败是静默的——模型返回 HTTP 200、无异常，但答案错误、跑题、忽略指令或误用工具，这类失败不会报错，却最值得关注。本技能即用于发现显性与静默失败、阅读追踪、归纳成可行动的排序失败模式（修提示词、提 bug、排优先级，或转为自动评测）。
核心原则：一切服务于阅读真实追踪。查询只告诉你该打开哪些追踪，本身不是答案；未打开追踪就报告问题清单，只描述了会抛错的“响亮少数”。这是自下而上的方式，失败模式从真实追踪中涌现，而非预先设定的通用指标。
主要工具：posthog:query-llm-traces-list（列出候选追踪，可按错误过滤、按指标排序、按类型限定）、posthog:query-llm-trace（完整读取一条追踪，必填参数 traceId）、posthog:execute-sql（找指标离群点、发现追踪分类、统计失败模式）、posthog:llma-evaluation-list（找已有评测的失败）、posthog:generate-app-url（生成带区域与项目限定的深链）。
使用方式：先与用户确定范围，聚焦单一用例（不同追踪类型失败方式不同，混在一起会平均掉信号）。再选择要读的追踪：代码错误（$ai_is_error，最廉价但代表性最差）、指标离群点（按 token、长度、成本、延迟排序看尾部）、单一追踪类型切片、分层抽样（无特定信号时的默认做法）、已有评测突增、聚类。然后实际阅读约 20–30 条追踪，用自然语言记录问题并记下最早事件时间戳与 trace ID；记录链条中第一个出错点，归纳为若干命名失败模式，读到不再出现新模式为止。最后按样本中出现频率排序，给出命名失败模式列表，每个模式附一两条追踪深链，请用户核对并选择下一步重点。
链接构造：query-llm-trace 返回的 _posthogUrl 可直接使用；仅对已知 id 但未打开的追踪用 generate-app-url 构造，如 {url: "/ai-observability/traces/{id}", params: {id: "<trace_id>"}}，不要手写主机或 /project/<id>/ 前缀。追踪链接不含时间戳，需追加 ?timestamp=<url_encoded_timestamp>。
限制与注意：不要只按错误信息 GROUP BY 出排名表就结束，那是响亮少数；不要用 SQL 代理或关键词搜索替代阅读，因为尚不知道要搜的模式。频率优先于完整性。样本不足时可放宽时间窗、用边界/对抗输入压测，或生成小规模合成数据，但合成结果只作引导，不能当作高 stakes 或小众领域的真实依据。相关技能：creating-online-evaluations、exploring-llm-clusters、exploring-llm-traces。