feature-usage-feed

通过 LLM 评估构建功能使用情况动态消息流

PostHog 的一些功能（群组会话摘要、单个会话摘要、回放 AI 搜索、错误跟踪 AI 调试等）每周会生成数百或数千条 LLM 跟踪记录。手动阅读这些记录并不可行。本技能介绍端到端的做法，将这些跟踪记录转化为实时 Slack 消息流，展示典型用例——也就是用户实际如何使用该功能。

此工作流混合使用多种方式，并以 UI 为主。跟踪记录检查和筛选条件发现（步骤 1-2）由 MCP 驱动。创建评估、试运行和启用（步骤 4-5）在 Agent 能使用 posthog:llma-evaluation-* 工具时由 MCP 驱动；但通常无法使用，此时应改用 UI（配置提醒时始终通过 UI：Data pipeline → destinations）。每个步骤都会说明 UI 备选方案。即使从聊天开始，也要做好最后在 UI 中完成操作的准备。

适用场景

• “用户在生产环境中实际如何使用 [功能 X]？”
• “我们能否找出 [功能 X] 的典型用例，以便编写更好的文档 / 确定改进优先级？”
• “我想要一个 Slack 消息流，展示有代表性的使用示例，而不用手动浏览跟踪记录。”
• “为 [功能 X] 在 #team-[area]-usage 中设置用例消息流。”

如果用户只是想调试单条跟踪记录或调整现有评估，请转而使用 exploring-llm-traces 或 exploring-llm-evaluations。

两种筛选模式

此技能支持两种不同的方式，可将评估范围限定为“你关心的功能”：

模式 A — 功能专属的 trace_id 前缀。 适用于会生成专属 $ai_trace_id 模式的独立功能（例如 session-summary:group:、replay-search:、错误跟踪专属流程）。按前缀筛选。

模式 B — PostHog AI Agent 模式。 适用于用户通过 PostHog AI 的特定 Agent 模式使用的功能（错误跟踪、产品分析、会话回放、SQL、功能标志、调查、AI 可观测性）。按 ai_product = 'posthog_ai' AND agent_mode = '<mode>' 筛选。这要求已部署 PR #55160（于 2026 年 4 月合并），该 PR 会将 agent_mode 和 supermode 添加到聊天 Agent 循环发出的每条 $ai_generation 记录中。还有一个实用的附带效果：agent_mode IS NOT NULL 是可靠的“面向用户的聊天轮次”筛选条件——批处理作业和工具内部的 LLM 调用会走不同的代码路径，且 agent_mode=null，因此会自动排除。

如果用户问“用户在 PostHog AI 的 [ET / 回放 / SQL / 功能标志 / 调查] 模式下想做什么”，那就是模式 B。如果他们问“[独立功能] 涵盖哪些用例”，那就是模式 A。先选择模式——提示词、筛选条件和 Slack 频道命名都由此决定。

前置条件

要求	验证方法
（模式 A）功能会发出 $ai_generation 事件，并采用稳定的 $ai_trace_id 模式	使用 posthog:execute-sql 查询不同的 $ai_trace_id 前缀
（模式 B）近期的 $ai_generation 事件包含 agent_mode 属性	使用 posthog:execute-sql 对近期 ai_product='posthog_ai' 事件的 properties.agent_mode 分组。空值分组是正常的（批处理作业和工具内部调用）——你需要关注的模式都应有非空值覆盖。
$ai_generation 事件附带 $session_id（将追踪与触发会话关联起来）	使用 posthog:execute-sql 查询 countIf($session_id IS NOT NULL) / count()
$ai_evaluation 事件也附带 $session_id（让 Slack 告警能够链接到会话）	运行一次评估后，对 $ai_evaluation 事件执行相同的查询
用户已获组织级别的 AI 数据处理批准	llm_judge 评估所必需

如果任一事件类型缺少 $session_id，请先提交后端修复，然后再继续——没有 UI 变通方案。会话摘要功能的 PR #54952 中提供了线程关联模式的完整示例。对于模式 B，Agent 模式的线程关联模式见 PR #55160。

工具

工具	用途
posthog:query-llm-traces-list	查找符合该功能 $ai_trace_id 模式的示例轨迹
posthog:query-llm-trace	端到端检查特定轨迹的内容
posthog:execute-sql	验证轨迹数量、session_id 覆盖范围和评估结果分布
posthog:llma-evaluation-create	（通常未公开——UI 备用路径：AI 可观测性 → 评估 → 新建）创建 LLM 裁判评估（初始为禁用状态）
posthog:llma-evaluation-run	（通常未公开——UI 备用路径：评估详情页上有一个“针对事件运行”按钮）在迭代提示词期间，针对特定生成内容试运行评估
posthog:llma-evaluation-update	（通常未公开——UI 备用路径：在 AI 可观测性 → 评估中编辑评估）调整提示词／准备就绪后启用
posthog:llma-evaluation-report-create	（通常未公开——UI 备用路径：评估详情页上有一个“报告”标签页）Feed 开始运行后，针对该评估安排 AI 报告，持续监控信号质量
posthog:workflows-list / posthog:workflows-get	（通常未公开——UI：数据管道 → 工作流）浏览现有工作流配置——设置新 Feed 时，可用于复制现有 Feed 的结构。此工具为只读；目前尚未公开创建／更新工具，因此第 6 步的 Slack 工作流设置只能通过 UI 完成。

开始之前，**请检查 Agent 的 MCP 工具集中实际公开了哪些 posthog:llma-evaluation-* 工具。**如果这些工具尚未加载，请将第 4–5 步视为 UI 操作指南，而不是工具调用。

工作流

步骤 1 — 确定筛选条件

模式 A（功能原生 trace_id 前缀）： 找出与你的功能对应的前缀。

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 中对可空列调用 splitByChar 会报错。

模式 B（PostHog AI Agent 模式）： 确认目标模式的覆盖范围和事件量。

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 20

agent_mode 的预期值：error_tracking、product_analytics、sql、session_replay、flags、survey、llm_analytics、null。Null ≈ 批处理作业 + 工具内部调用（不是用户聊天）。supermode='plan' 会将规划轮次与执行轮次分开——如果你的信息流专门针对 plan 模式，值得单独说明。

记录模式和大致事件量。低事件量模式（<100 个事件/天）会产生难以尽早验证的零星信息流；高事件量模式（>1k 个/天）可能需要抽样，以免 Slack 消息泛滥。有关抽样，请参阅“提示”部分。

步骤 2 — 获取少量示例跟踪记录

在步骤 4 中用这些记录迭代提示词。

模式 A：

posthog: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
}

模式 B：

posthog: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 条跟踪记录进行测试。

输出大小警告： query-llm-traces-list 使用 limit: 10 时，通常会返回 3-6MB 的 JSON（每次生成的完整输入/输出）。这会撑爆你的上下文窗口。一旦看到“result exceeds maximum allowed tokens”错误，就立即将摘要工作委派给子 Agent——让子 Agent 按每条跟踪记录提取：跟踪 ID、第一条用户消息（截断至约 300 个字符），以及一句话描述对话内容。不要尝试直接读取原始文件。

跟踪记录工具只返回 AI 负载。 $current_url、agent_mode 或 ai_product 等自定义属性会以名称的形式出现在 _redactedKeys 中，但不包含值， 因此当样本需要这些属性时，请使用 posthog:execute-sql 查询抽取的跟踪 ID。 如上文两种模式所示，按这些属性筛选不受影响。

留意模式 B 样本中的主题偏移。 agent_mode 标签反映用户在该轮对话开始时选择的模式——但即使用户在同一段对话中偏离主题，聊天状态仍会保留该模式（例如，用户选择了“错误跟踪”模式，三轮之后却问了一个无关的定价问题）。评估提示词中的分类步骤需要允许主题偏移：PASS 应表示“用户正在做符合该模式范围的事情”，FAIL 应识别偏离主题的情况。否则，你的信息流会包含一些无关的 PASS 条目，只因为它们带有该模式标签。

步骤 3 — 起草 LLM 评审提示词

提示词有两项职责：（a）将轨迹分类为相关或不相关；（b）生成可直接发布到 Slack 的推理文本（不加前言，不作元描述）。推理字段将成为 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]。 强制使用开场语至关重要（它可以防止模型偏离主题，转而输出“这条轨迹是……”之类的元描述），但具体动词必须符合实际交互方式：

功能 / 模式	OPENER
会话摘要（群组 / 单个）	A user ran a summary on
Replay AI 搜索	A user searched replays for
错误追踪模式下的 PostHog AI	A user asked PostHog AI about
会话回放模式下的 PostHog AI	A user asked PostHog AI about
SQL 模式下的 PostHog AI	A user asked PostHog AI to write SQL for

注意：supermode='plan' 是一个叠加在 agent_mode 行之上的子筛选条件，不是单独的一行。如果只想筛选 plan 模式，请使用 agent_mode='<mode>' AND supermode='plan' 进行筛选，并选择类似 "A user asked PostHog AI to plan" 的开场语。

如果你在基于聊天的功能中强制使用 "A user ran"，模型会生成生硬别扭的表达（例如 “A user ran a question about...”），在 Slack 中读起来不自然。强制开场语是通用机制，但具体短语应按功能选择。

无论使用哪种开场语，负面示例列表（“不要使用 ‘This is a...’ 作为前言”等）都至关重要。不要删除。

步骤 4 — 创建评估（禁用状态），测试并迭代

创建时设置 enabled: false，以免立即向所有轨迹扇出评估。

如果提供了 posthog:llma-evaluation-create，请使用以下负载：

posthog: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 评审成本会随事件量线性增长，而低成本与高能力之间确实需要权衡；用户应根据自己的开支承受能力和信号质量要求做出选择。不要替他们选择。

UI 备用方案（未提供 llma-evaluation-create 时）：AI observability → Evaluations → New evaluation。类型 = LLM judge，输出 = 布尔值 + 允许 N/A，筛选条件如上，启用 = 关闭。粘贴步骤 3 中的提示词。

然后对示例轨迹进行试运行。

如果提供了 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”按钮，并填写轨迹示例的事件 ID。

检查返回的 $ai_evaluation_reasoning。如果它出现前言、偏离主题或描述输入内容，请修正提示词（通过 llma-evaluation-update 或在 UI 中编辑），然后重新运行。启用之前，至少用 3-5 条轨迹进行迭代测试。

迭代过程中常见的问题：

症状	修复方法
推理以 “This is a...” 开头	强化强制开场语指令，并添加一个反例
推理过于笼统（“用户行为”“各种模式”）	在提示词中添加具体措辞的正面示例
模型将所有内容都分类为 PASS	收紧 FAIL 的定义，并添加一个不匹配示例
推理对 Slack 来说太长	添加严格的句数上限（“最多 3 句，严格限制”）

第 5 步 — 启用评估

当 3–5 次示例运行都能生成可直接发布到 Slack 的干净输出后。

如果提供了 posthog:llma-evaluation-update：

posthog:llma-evaluation-update
{
  "evaluationId": "<uuid>",
  "enabled": true
}

UI 备用方案： AI 可观测性 → 评估 → 打开该评估 → 切换为启用。

现在，每当有新的匹配 $ai_generation 事件时，都会运行此评估。

第 6 步 — 构建工作流（仅限 UI）

工作流设置不支持通过 MCP 写入（posthog:workflows-list / posthog:workflows-get 为只读）。以下步骤为 UI 操作指南。

前置条件： 开始前，先将 PostHog Slack 机器人邀请到目标频道（在 Slack 频道中输入 /invite @PostHog）。否则，Slack 分发步骤会在发送时失败，并显示不明确的权限错误，而非在保存时提示——很容易忽略。

6.1 创建工作流

数据管道 → 工作流 → 新建工作流。将其命名为 <feature> use case feed，与第 4 步中的评估名称保持一致。

6.2 触发步骤

• 事件： AI evaluation (LLM)，即 $ai_evaluation。这是评估运行时发出的事件，也是唯一包含 $ai_evaluation_* 属性的事件。原始 $ai_generation 事件不会附加评估结果，因此在此处筛选 $ai_generation 不会匹配到任何事件。
• 属性筛选条件（两项都必需）：
  • AI Evaluation Name (LLM) 等于 <your eval name from step 4>
  • AI Evaluation Result (LLM) 等于 true

⚠️ 关键事项： $ai_evaluation_result 存储的值是字符串 'True' / 'False' / 'None'，而不是 'PASS' / 'FAIL' / 'N/A'（尽管提示词模板内部将它们称为这些值）。工作流 UI 属性筛选器会将 true 规范化为 'True'，因此从下拉菜单中选择 equals true 即可。但如果你在其他地方（例如 hog 函数）通过原始 SQL 进行设置，则需要使用字符串字面值。保存前请确认存储值的分布：

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 分发步骤

• 添加步骤 → Slack 分发
• 频道： #<your-team>-usage-feed
• 发送者 / 机器人显示名称： 选择一个在频道中显示效果良好的名称（例如 PostHog Usage Feed）
• 区块（Slack 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>：📊 产品分析、🐛 错误跟踪、🎬 会话回放、🔎 搜索/AI 搜索、🧪 实验、🚩 标志、📋 调查、🧠 通用 AI。

{event.properties.X} 和 {person.X} 占位符是有效的 PostHog 模板语法，会在发送时解析。

6.4 启用前先测试

工作流测试面板有两种模式——这一点很重要，因为直接点击“测试”可能会让集成看起来像是坏了，但实际上并非如此：

• 合成事件（默认）——测试面板会伪造一个 $ai_evaluation 载荷，并在不调用 Slack 真实 API 的情况下运行流程。可用于试运行区块模板，但 {event.properties.$ai_*} 占位符可能会解析为 null，Slack 的区块验证器也可能会因 invalid_blocks 而拒绝载荷。这是测试框架造成的现象，并非真实错误——不要因此追查问题。
• “发出真实 HTTPS 请求”——启用此开关。随后，工作流会拉取一条符合筛选条件的近期真实 $ai_evaluation 事件，并端到端运行整个流程，包括实际发布 Slack 消息。这才是真正能验证“是否可用”的测试。如果还没有符合条件的真实事件（评估刚启用时很常见），请自行触发该功能，等待约 1 分钟后重试。

建议流程：合成事件 → 确认区块模板能正确渲染 → 启用真实请求 → 确认频道中收到实际消息 → 保存并启用工作流。

步骤 7 — 在生产环境中进行端到端验证

启用工作流后，亲自触发该功能。一两分钟内：

1. $ai_generation 事件应出现在 AI 可观测性中
2. 评估应自动运行并发出 $ai_evaluation 事件
3. 工作流应触发，Slack 消息应发送到配置的频道
4. 点击“查看触发会话”——应打开你使用该功能的录制，而不是回放主页

如果点击“查看触发会话”后打开的是回放主页，则 $ai_evaluation 事件缺少 $session_id（它与 $ai_generation 事件相互独立——两者的关联是独立的）。需要修复后端——请参阅前置条件。

完整示例 A（模式 A）：分组会话摘要用例

模式：将 group_summary_use_case_feed 评估流式发送到 #<team>-usage-feed 频道。Trace 前缀：session-summary:group:。开场白："A user ran a group summary on"。Slack 频道中显示的内容示例：

📊 group_summary_use_case_feed 由 some user 触发 “一位用户对某家公司过去 7 天的入职会话运行了分组摘要。他们想了解为何账户激活率较低。摘要指出，大多数用户在创建账户后，会在公司入职向导页面放弃操作。” [查看 Trace] [查看触发会话] [查看用户]

使其生效的 PR（在此作为 $session_id 关联模式的完整示例链接，并非技能本身的步骤）：

• PostHog/posthog#54952 — 在会话摘要后端中，将 trigger_session_id 关联到 $ai_generation 事件
• （后续 PR — 专门将 $session_id 关联到 $ai_evaluation 事件）

完整示例 B（模式 B）：PostHog AI 错误跟踪模式

模式：将限定于 agent_mode = 'error_tracking' 的动态消息流发送到 #<team>-usage-feed 频道，回答“用户在错误跟踪模式下与 PostHog AI 聊天时，实际上想做什么？”不同 Agent 模式的规模可能相差一个或多个数量级——接入前，按 §步骤 1 抽查流量，因为高流量模式可能会刷屏。开场白："A user asked PostHog AI about"。

启用 PR：PostHog/posthog#55160 — 将 agent_mode 和 supermode 关联到聊天 Agent 循环发出的每个 $ai_generation 事件。接入逻辑位于 ee/hogai/core/agent_modes/executables.py（AgentExecutable._get_model），并通过 ee/hogai/llm.py 中 MaxChatMixin 现有的 posthog_properties 字段传递字典。在此 PR 之前，无法将 PostHog AI 评估限定为特定模式——最终会评估每个 PostHog AI 生成事件，导致消息流噪声较多，PASS 率仅为个位数。

配置时的重要观察：agent_mode 标签反映的是轮次进行时的模式，但即使用户在对话中途偏离主题，聊天状态仍会保留模式选择。抽查结果：一个随机的 agent_mode=error_tracking 样本中，有一段对话最终讨论的是会话回放定价。评估提示词中的分类必须允许话题偏移——只有当轮次内容明显属于该模式的范围时才判定为 PASS；当对话完全偏离主题时则判定为 FAIL。

上线后验证信号质量

数据流运行一两天后，请对评估输出进行抽样检查，确认其整体质量。

如果已开放 posthog:llma-evaluation-report-create： 请为评估安排 AI 报告，这样你无需主动请求，就能持续收到通过/失败情况。

posthog:llma-evaluation-report-create
{
  "evaluation": "<uuid>",
  "frequency": "scheduled",
  "rrule": "FREQ=WEEKLY;BYDAY=MO",
  "delivery_targets": [{ "type": "email", "value": "[email protected]" }]
}

posthog:llma-evaluation-report-generate 会立即运行已配置的报告，而 posthog:llma-evaluation-report-run-list 会返回以往运行的内容。

UI 备用方案： 在 AI observability → Evaluations 中打开评估，然后切换到“Reports”标签页。

如果 FAIL 类别占比很高，说明分类步骤过于严格——请放宽条件。如果 PASS 类别中有很多泛泛的推理内容，请迭代提示词，确保内容具体明确。无需逐条翻阅事件，报告就能让你快速了解情况。

必要时抽查原始事件（注意：存储的结果值是 'True'，而不是 'PASS'——请参阅第 6 步）：

SELECT
    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

提示

• reasoning 字段就是 Slack 消息——请围绕这一用途设计提示词，而不是设计成“分类前的思维链”。模型可以一次性生成结构化、可直接用于 Slack 的文本。
• LLM 裁判在重复运行时具有非确定性。即使使用固定的提示词和模型，也可能有 1-5% 的波动。如果需要可复现性，请在 model_configuration 中固定确定性提供方/种子。
• 使用 $ai_trace_id 前缀的 conditions 属性筛选器严格限定评估范围。否则，评估会扩展到项目中的每个 $ai_generation 事件，并产生 LLM 费用。
• 对于高流量功能（每周超过 10k 个 trace），可以考虑抽样——设置评估仅针对一定比例的匹配事件运行，而不是处理全部事件。Slack 消息泛滥确实是可能的故障模式。
• “View Trigger Session”按钮是提醒中价值最高的链接。没有它，数据流就只是一段文本——你无法查看用户当时的实际操作。请在第 7 步验证其有效，再考虑将数据流上线。
• 数据流上线后，请持续阅读通过运行的推理内容（可以使用定时报告，或使用上面的 SQL 并筛选 $ai_evaluation_result = 'True'），以发现占主导地位的用例集群。这样才能将数据流转化为真正的产品洞察，而不只是通知流。