PostHog AI 可观测性实战用 LLM 评测把功能 trace 量转化为 Slack 实时用例 feed【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthogPostHog 的不少功能group session summaries、single session summaries、replay AI search、error tracking AI debug 等每周会产出成百上千条 LLM trace人工逐条阅读已不可行。本文基于仓库中的 Agent 技能文档 feature-usage-feed/SKILL.md完整讲解端到端的落地模式如何选对过滤模式、起草 LLM-judge 提示词、创建并迭代评测、配置 Slack workflow 分发以及上线后如何持续校验信号质量。读完后你可以为任意一个发$ai_generation事件的 PostHog AI 功能搭出一条「规范用例canonical use cases直播 feed」直接回答「用户在生产环境里到底在拿这个功能做什么」这类问题。适用场景与边界这个技能回答的典型问题是「人们在生产环境里实际上是如何使用 [功能 X] 的」「能否识别出 [功能 X] 的规范用例以便我们写更好的文档、排改进优先级」「我想有一条 Slack feed 持续推送代表性使用案例而不想手动浏览 trace。」「给 [功能 X] 在 #team-[area]-usage 里建一条用例 feed。」如果需求只是调试单条 trace 或调优已有评测应改走仓库中另两个技能 exploring-llm-traces 或 exploring-llm-evaluations而不是本模式。整个工作流是混合模式偏 UI 操作trace 检查与过滤器发现步骤 1–2走 MCP 工具评测创建、dry-run、启用步骤 4–5在posthog:llma-evaluation-*工具暴露给 agent 时走 MCP但实际部署中这些工具经常未暴露需要回退到 UI而步骤 6 的 Slack alert 目的地配置永远是 UI 操作。每个步骤下文都标了 UI 回退路径——即使从 chat 开始也要预期最终在 UI 里收尾。两种过滤模式先定模式再动手这个技能支持两种把评测范围圈定到「你关心的功能」的方式选择模式是第一步决策后续的提示词、过滤器和 Slack 频道命名都由它决定。模式 A —— 功能原生的 trace_id 前缀。适用于自身发出$ai_trace_id模式的功能如session-summary:group:、replay-search:、error tracking 特定流程直接按前缀过滤。模式 B —— PostHog AI agent 模式。适用于用户通过 PostHog AI 的某个特定 agent 模式交互的功能error tracking、product analytics、session replay、SQL、flags、surveys、AI observability按ai_product posthog_ai AND agent_mode mode过滤。模式 B 有一个后端前提仓库中 AgentExecutable._get_agent_mode_posthog_properties 会把agent_mode与supermode组装成遥测属性字典再经由 AgentExecutable._get_model 中以posthog_properties参数传给MaxChatAnthropic定义在 ee/hogai/llm.py 的MaxChatMixin从而把这些属性线程化到聊天 agent 循环发出的每一条$ai_generation上——这正是技能文档中提到的 enabling PR 的落点。这个线程化带来一个有用的附赠效果agent_mode IS NOT NULL是可靠的「用户可见聊天回合」过滤器——批处理任务和工具内部 LLM 调用走不同代码路径其agent_mode为 null因此被天然排除。判别规则用户问「在 ET / replay / SQL / flags / surveys 模式下用户试图在 PostHog AI 里做什么」是模式 B问「[某个独立功能] 覆盖了哪些用例」是模式 A。前置条件与验证方法要求验证方式模式 A功能发出的$ai_generation事件带有稳定的$ai_trace_id模式用posthog:execute-sql查询不同的$ai_trace_id前缀模式 B近期的$ai_generation事件上有agent_mode属性用posthog:execute-sql对近期ai_productposthog_ai事件按properties.agent_mode分组。Null 桶是正常的批处理 工具内部调用——你要关心的是各模式上的非 null 覆盖$session_id附加在$ai_generation事件上把 trace 链接到触发会话posthog:execute-sql查countIf($session_id IS NOT NULL) / count()$session_id也附加在$ai_evaluation事件上让 Slack alert 能链到会话评测跑过一次后对$ai_evaluation事件执行同样的查询用户拥有组织级 AI 数据处理审批llm_judge评测的硬性要求关键结论如果任一事件类型缺$session_id先提后端修复再继续——UI 侧无 workaround。session summary 功能的线程化模式可作为工作范例参考。MCP 工具清单注意暴露情况工具用途posthog:query-llm-traces-list找出匹配功能$ai_trace_id模式的样例 traceposthog:query-llm-trace端到端检查某条 trace 的内容posthog:execute-sql验证 trace 量、session_id 覆盖率、评测结果分布posthog:llma-evaluation-create经常未暴露— UI 回退AI observability → Evaluations → New创建 LLM-judge 评测初始禁用posthog:llma-evaluation-run经常未暴露— UI 回退评测详情页有 Run on event 按钮在提示词迭代期间对特定 generation 做 dry-runposthog:llma-evaluation-update经常未暴露— UI 回退在 AI observability → Evaluations 中编辑调提示词 / 启用posthog:llma-evaluation-report-create经常未暴露— UI 回退评测详情页的 Reports tabfeed 跑起来后在评测上调度 AI 报告持续关注信号质量posthog:workflows-list/posthog:workflows-get经常未暴露— UIData pipeline → Workflows浏览已有 workflow 配置克隆结构。只读写侧无工具步骤 6 的 Slack workflow 搭建只能走 UI仓库的 MCP 工具清单见 products/ai_observability/mcp/tools.yaml其中llma-evaluation-create、llma-evaluation-run、llma-evaluation-update、llma-evaluation-report-create等条目均声明了evaluation:writescope 与启用状态——「工具是否可用」最终取决于部署时该 MCP server 向 agent 暴露了哪一批工具因此文档要求开始前先检查当前 agent 的工具集未加载的按 UI 走查处理。步骤 1 —— 确定过滤器模式 A找出映射到目标功能的前缀。SELECT splitByChar(:, coalesce(properties.$ai_trace_id, ))[1] AS root, splitByChar(:, coalesce(properties.$ai_trace_id, ))[2] AS subtype, count() AS events FROM events WHERE timestamp now() - INTERVAL 3 DAY AND event $ai_generation AND properties.$ai_trace_id IS NOT NULL GROUP BY root, subtype ORDER BY events DESC LIMIT 25注意coalesce(..., )是承重写法——在 HogQL 里对 nullable 列直接splitByChar会报错。模式 B验证目标模式的覆盖度与量级。SELECT properties.agent_mode AS agent_mode, properties.supermode AS supermode, count() AS events, count(DISTINCT properties.$ai_trace_id) AS traces FROM events WHERE timestamp now() - INTERVAL 3 DAY AND event $ai_generation AND properties.ai_product posthog_ai GROUP BY agent_mode, supermode ORDER BY events DESC LIMIT 20agent_mode的预期取值error_tracking、product_analytics、sql、session_replay、flags、survey、llm_analytics、null。Null ≈ 批处理任务 工具内部调用非用户聊天。supermodeplan把规划回合与执行回合分开——如果 feed 专门关注 plan mode值得单独拆出来看。记录模式 大致量级低量模式100 events/天会产生很难在早期验证的涓流高量模式1k/天可能需要采样以防 Slack 被刷屏见文末 Tips。步骤 2 —— 抽取一批样例 trace这些样例用于步骤 4 的提示词迭代。模式 Aposthog:query-llm-traces-list { properties: [ { type: event, key: $ai_trace_id, operator: icontains, value: your-prefix-here } ], limit: 10, dateRange: { date_from: -2d }, randomOrder: true }模式 Bposthog:query-llm-traces-list { properties: [ { type: event, key: ai_product, operator: exact, value: posthog_ai }, { type: event, key: agent_mode, operator: exact, value: mode-here } ], limit: 10, dateRange: { date_from: -2d }, randomOrder: true }randomOrder: true很关键——按时间就近取样会产生有偏的非代表性样本。挑 5–10 条 trace 做测试集。输出体积警告query-llm-traces-list在limit: 10时常规返回 3–6MB JSON每条 generation 的完整输入/输出会撑爆上下文窗口。一旦看到 result exceeds maximum allowed tokens 错误立即把摘要工作委托给子 agent——让子 agent 逐条提取trace id、第一条用户消息截断到 ~300 字符、采样的$current_url、以及一句话说明该会话在聊什么。不要在主上下文里硬读原始文件。警惕模式 B 样本中的话题漂移。agent_mode标签反映的是回合发生时用户选择的模式但聊天状态在同一会话内会保留该模式——即使用户后来跑题例如用户选了 error tracking 模式三回合后却问了个无关的定价问题。评测提示词的分类步骤必须对 topic-drift 保持明确边界PASS 应表示「用户在做这个模式范围内可识别的事情」FAIL 应抓住跑题漂移。否则 feed 里会混进只是恰好带了这个模式标签的无关 PASS 条目。步骤 3 —— 起草 LLM-judge 提示词提示词承担两个职责(a) 把 trace 分类为相关或不相关(b) 产出可以直接贴进 Slack的推理文本无开场白、无元描述。reasoning 字段就是 Slack 消息正文。模板You are analyzing a PostHog [FEATURE NAME] trace to extract its real use case. Your reasoning text will be posted directly to a Slack channel as a notification. Write it as a short, ready-to-post message — no preamble, no meta-description. Step 1 — Classification: - PASS this trace is the [feature kind] you care about - FAIL a different LLM call or a false match - N/A ambiguous from the trace alone Step 2 — Reasoning (only matters if PASS). Write 2-3 sentences in this exact format: [OPENER] [what they targeted/filtered for]. They were trying to [understand X / debug Y / find Z]. The result surfaced [key pattern or finding]. Your output MUST start with the exact phrase [OPENER]. No other opening is allowed. Rules: - No This is a [feature]... or The input contains... preamble - No JSON, field names, system-prompt references, or meta-description - Concrete generic. users hitting error tracking for the first time beats user behavior - If you cannot infer one of the three pieces from the trace, write (unclear from trace) in that slot — do not guess选与用户实际交互方式匹配的[OPENER]。强制开场白是承重机制防止模型漂成 this trace is a... 式元描述但具体措辞必须贴合交互形态功能 / 模式OPENERSession summarygroup / singleA user ran a summary onReplay AI searchA user searched replays forPostHog AI error tracking 模式A user asked PostHog AI aboutPostHog AI session replay 模式A user asked PostHog AI aboutPostHog AI SQL 模式A user asked PostHog AI to write SQL for注意supermodeplan是叠加在agent_mode行之上的子过滤条件——它不是独立的一行。若要只看 plan mode过滤agent_modemode AND supermodeplan并选诸如A user asked PostHog AI to plan的 opener。对聊天型功能强行用 A user ran模型会产出别扭的扭曲句式A user ran a question about...在 Slack 里读起来不对劲。强制 opener 是机制具体措辞按功能定。负面清单No This is a... preamble 等无论 opener 是什么都是承重的不要删。步骤 4 —— 创建评测禁用态、测试、迭代以enabled: false创建避免立刻向所有 trace 扇出。若posthog:llma-evaluation-create已暴露使用如下 payloadposthog:llma-evaluation-create { name: [feature] use case feed, description: Extracts canonical use cases for [feature] for the #team-[area]-usage Slack feed, evaluation_type: llm_judge, evaluation_config: { prompt: full prompt from step 3 }, output_type: boolean, output_config: { allows_na: true }, model_configuration: { provider: provider, model: model }, enabled: false, conditions: [ { id: default, rollout_percentage: 100, properties: [ // Pattern A — feature-native trace_id prefix: { key: $ai_trace_id, type: event, operator: icontains, value: your-prefix } // Pattern B — PostHog AI agent mode (use these INSTEAD of the trace_id filter): // { key: ai_product, type: event, operator: exact, value: posthog_ai }, // { key: agent_mode, type: event, operator: exact, value: mode } ] } ] }模型选择留给用户——LLM-judge 成本随事件量线性增长「便宜 vs 能力强」是用户应基于自身花费容忍度和信号质量要求做的真实权衡不要替他选。UI 回退llma-evaluation-create未暴露时AI observability → Evaluations → New evaluation。类型选LLM judge输出 boolean 允许 N/A过滤器如上enabled 关。粘贴步骤 3 的提示词。然后对样例 trace 做 dry-run。若posthog:llma-evaluation-run已暴露posthog:llma-evaluation-run { evaluationId: uuid from create, target_event_id: a $ai_generation event id from step 2, timestamp: ISO timestamp of that event }UI 回退在评测详情页用 Run on event 按钮传入样例 trace 的事件 id。查看返回的$ai_evaluation_reasoning。若它带开场白、跑题或描述输入本身就改提示词llma-evaluation-update或 UI 编辑并重跑。在启用之前先迭代 3–5 条 trace。迭代期常见失败模式症状修复Reasoning 以 This is a... 开头加强强制 opener 指令补一个反例Reasoning 泛化user behavior、various patterns在提示词里加具体措辞的正例模型把所有 trace 都判 PASS收紧 FAIL 定义加一个非匹配长什么样的例子Reasoning 对 Slack 来说太长加硬性句数上限MAX 3 sentences, hard limit步骤 5 —— 启用评测当 3–5 条样例运行产出干净的 Slack-ready 输出后若posthog:llma-evaluation-update已暴露posthog:llma-evaluation-update { evaluationId: uuid, enabled: true }UI 回退AI observability → Evaluations → 打开评测 → 打开 enabled 开关。之后评测会在每一条新匹配$ai_generation事件上运行。步骤 6 —— 搭建 Workflow纯 UIWorkflow 写侧不可经 MCP 访问posthog:workflows-list/posthog:workflows-get只读以下是 UI 走查。前置开始前先把 PostHog Slack bot 邀请进目标频道在 Slack 频道里/invite PostHog。不做这步Slack 分发会在发送时而非保存时报一个不透明的权限错误——很容易漏掉。6.1 创建 workflowData pipeline → Workflows → New workflow。命名为feature use case feed与步骤 4 的评测名对齐。6.2 触发步骤事件AI evaluation (LLM)即$ai_evaluation。这是评测运行时发出的事件也是唯一携带$ai_evaluation_*属性的事件。原始$ai_generation事件不会被评测结果丰富化所以在这里按$ai_generation过滤会匹配不到任何东西。属性过滤两条都必需AI Evaluation Name (LLM)等于步骤 4 的评测名AI Evaluation Result (LLM)等于true⚠️ 承重细节$ai_evaluation_result的存储值是字符串True/False/None——而不是提示词模板内部称呼的PASS/FAIL/N/A。Workflows UI 的属性过滤器会把true归一化为True所以从下拉里选equals true能工作。但如果你在别处用原始 SQL 接这个比如 hog function就需要写字符串字面量。保存前先验证存储分布SELECT DISTINCT toString(properties.$ai_evaluation_result) AS result, count() AS n FROM events WHERE event $ai_evaluation AND properties.$ai_evaluation_name your eval name AND timestamp now() - INTERVAL 1 HOUR GROUP BY result如果只有True/False/None且True占主导UI 的equals true过滤就能命中看到别的值就相应调整。6.3 Slack 分发步骤Add step → Slack dispatch频道#your-team-usage-feed发送者 / bot 显示名取一个在频道里读起来顺口的名字如PostHog Usage FeedBlocksSlack block-kit JSON——粘贴以下模板并把project_id替换为你的实际数字项目 ID如2[ { text: { text: emoji *{event.properties.$ai_evaluation_name}* triggered by *{person.name}*, type: mrkdwn }, type: section }, { text: { text: {event.properties.$ai_evaluation_reasoning}, type: mrkdwn }, type: section }, { type: actions, elements: [ { url: https://us.posthog.com/project/project_id/ai-observability/traces/{event.properties.$ai_trace_id}?event{event.properties.$ai_target_event_id}, text: { text: View Trace, type: plain_text }, type: button }, { url: https://us.posthog.com/project/project_id/replay/{event.properties.$session_id}, text: { text: View Trigger Session, type: plain_text }, type: button }, { url: {person.url}, text: { text: View Person, type: plain_text }, type: button } ] } ]emoji按功能形态选 product analytics、 error tracking、 session replay、 search/AI search、 experiments、 flags、 surveys、 通用 AI。{event.properties.X}和{person.X}占位符是合法的 PostHog 模板语法在发送时解析。6.4 启用前先测试Workflows Test 面板有两种模式——这点很重要因为天真地按 Test 可能在集成其实没坏时看起来像坏了Synthetic event默认——Test 面板会伪造一个$ai_evaluationpayload不真正打 Slack API 跑流程。适合做 block 模板的 dry-run但{event.properties.$ai_*}占位符可能解析成nullSlack 的 block 校验器会以invalid_blocks拒绝 payload。这是测试工装test-harness伪影不是真 bug——别去追。勾选 Make real HTTPS requests——打开后 Workflows 会拉取一条符合过滤条件的近期真实$ai_evaluation事件并端到端跑完整流程包括真实发到 Slack。这才是真正告诉你「它工作了」的测试。如果还没有匹配的真实事件评测刚启用时很常见自己触发一次该功能等约 1 分钟再重试。推荐流程synthetic → 确认 block 模板能渲染 → 打开真实请求 → 确认频道里真的收到帖子 → 保存并启用 workflow。步骤 7 —— 生产环境端到端验证Workflow 启用后自己触发一次该功能。一两分钟内$ai_generation事件应出现在 AI observability评测应自动运行并发出$ai_evaluation事件Workflow 应触发Slack 帖子应落到配置好的频道点 View Trigger Session——应落在你自己使用该功能的录像上而不是 replay 首页如果 View Trigger Session 落在 replay 首页说明$ai_evaluation事件上缺$session_id它和$ai_generation是两回事——两个事件的线程化是相互独立的。需要后端修复——见前置条件一节。两个完整工作范例范例 A模式 Agroup session summary 用例。一个group_summary_use_case_feed评测流到#team-usage-feed频道。trace 前缀session-summary:group:。OpenerA user ran a group summary on。Slack 频道展示效果类似group_summary_use_case_feedtriggered bysome userA user ran a group summary on a companys onboarding sessions from the last 7 days. They were trying to understand why account activation rates are low. The summary surfaced that most users abandon at the company onboarding wizard after creating accounts. [View Trace] [View Trigger Session] [View Person]范例 B模式 BPostHog AI error tracking 模式。一个agent_mode error_tracking范围的 feed回答「用户在 error tracking 模式下和 PostHog AI 聊天时实际想做什么」。各 agent 模式之间量级可差一个数量级以上——接好之前务必按步骤 1 抽查各模式量级因为高量模式可能刷爆频道。OpenerA user asked PostHog AI about。搭建后的关键观察agent_mode标签反映的是回合时点的模式但聊天状态在用户会话中途跑题时仍保留模式选择。抽查中一条随机的agent_modeerror_tracking样本最终聊的是 session replay 定价。所以评测提示词的分类必须对 topic drift 有明确边界——只有当回合可识别地属于该模式范围内才 PASS会话已漂到完全别的话题时 FAIL。这也是范例 A 与模式 B 在提示词设计上要分别对待的原因。上线后校验信号质量Feed 跑上一两天后按规模做一次 sanity check。若posthog:llma-evaluation-report-create已暴露在评测上调度一份 AI 报告让 pass/fail 图景自动送达posthog:llma-evaluation-report-create { evaluation: uuid, frequency: scheduled, rrule: FREQWEEKLY;BYDAYMO, delivery_targets: [{ type: email, value: youexample.com }] }posthog:llma-evaluation-report-generate立即运行已配置的报告posthog:llma-evaluation-report-run-list返回历史运行内容。UI 回退在 AI observability → Evaluations 打开评测进 Reports tab。如果 FAIL 桶很大说明分类步骤过严——放松它。如果 PASS 桶里泛化的 reasoning 很多就在提示词上继续迭代以强制具体性。报告让你不逐条翻事件就能快速读出这一层。需要时抽查原始事件注意存储值不是PASS而是True——见步骤 6SELECT properties.$ai_evaluation_reasoning AS reasoning, properties.$ai_trace_id AS trace_id, timestamp FROM events WHERE event $ai_evaluation AND properties.$ai_evaluation_name your eval name AND properties.$ai_evaluation_result True AND timestamp now() - INTERVAL 1 DAY ORDER BY timestamp DESC LIMIT 25实操 TipsReasoning 字段就是Slack 消息——为这个目标设计提示词而不是「分类前的思维链」。模型能一次性产出结构化的 Slack-ready 文本。LLM judge 在重跑间是非确定性的。即使提示词和模型都固定也预期 1–5% 的噪声。若需要可复现性在model_configuration中固定确定性的 provider/seed。通过conditions上的$ai_trace_id前缀属性过滤保持评测范围紧收。否则它会扇出到项目里每一条$ai_generation事件烧掉 LLM 成本。对高量功能10k traces/周考虑采样——让评测只跑匹配事件的一个百分比。Slack 刷屏是真实存在的失败模式。View Trigger Session 按钮是告警里价值最高的链接。没有它feed 只是文本——你看不到用户当时实际在做什么。认为 feed 交付之前先按步骤 7 验证它可用。Feed 上线后持续读 PASS 运行的 reasoning调度报告或上面那段$ai_evaluation_result True的 SQL提炼主导的用例簇。这是把 feed 从「通知流」变成「真正的产品洞察」的方式。小结这套模式的价值在于把一个不可规模化的问题人工读 trace拆成四个各自可验证的环节过滤模式选择SQL 验证量级与覆盖、提示词设计用随机样例 trace dry-run 迭代到 Slack-ready、事件链路$ai_generation→ 评测 →$ai_evaluation→ Workflow、分发验证真实请求测试 端到端生产验证。其中两个最容易被跳过、代价最高的细节是$ai_evaluation_result的字符串化存储值True而非PASS以及$session_id在两种事件上各自的独立线程化——前者决定 workflow 触发能不能命中后者决定 View Trigger Session 这个最高价值链接是否可用。【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考