PostHog AI 可观测性工具：2026 实用指南

# PostHog AI 可观测性工具：2026 实用指南 AI 应用正在从简单的提示词实验，发展为结合语言模型、检索、工具、代理、数据库和用户界面的生产系统。这带来了新的监控问题。传统应用指标，例如请求延迟或 HTTP 错误率，当然有价值，但它们无法解释回答是否有依据、工具调用是否返回了正确数据、提示词变更是否损害了质量，或者使用量增长是否让系统变得不经济。 PostHog 通常被视为产品分析平台，但它的事件模型也可以支持 AI 可观测性。通过合理设计事件，团队可以把模型调用与用户、会话、产品结果、实验和成本连接起来。这样得到的不只是模型请求日志，而是一种理解 AI 行为如何影响产品的方法。 本文介绍 PostHog AI 可观测性工具在实践中的含义、如何设计埋点策略、哪些指标重要、如何调查故障，以及专业 AI 工具在工作流中的位置。文章也会说明，为什么不应把产品分析平台当作唯一的可观测性系统。功能、集成和价格可能发生变化，实施前请查看 PostHog 官方文档和产品页面的当前信息。 ## 什么是 AI 可观测性？ AI 可观测性是收集和解释必要信号的实践，用来理解 AI 系统在生产环境中的表现。这些信号通常覆盖四个维度： | 维度 | 应回答的问题 | 示例信号 | |---|---|---| | 可靠性 | 系统是否可用且技术状态健康？ | 错误率、超时率、重试次数、供应商故障 | | 性能 | 体验是否足够快？ | 首 token 时间、总延迟、排队时间、工具耗时 | | 质量 | 输出是否有用、安全且适合任务？ | 用户反馈、评估分数、引用检查、拒答模式 | | 经济性 | 系统是否具备可持续的成本？ | 输入 token、输出 token、模型成本、每次结果成本 | AI 产品的可观测性还必须跟踪完整执行路径。一次用户请求可能会经过路由、文档检索、模型调用、一个或多个工具调用、答案修订，最后再以流式方式返回给用户。只监控最终 HTTP 请求，会隐藏最可能发生故障的部分。 因此，一个有用的 trace 应记录父级操作及其子操作。父级可以是一段助手对话，子操作则可以包括检索、提示词构建、模型生成、审核和工具执行。PostHog 可以把这些操作表示为带结构化属性的事件。具体实现取决于应用架构和所使用的 PostHog SDK 或数据写入方式。 ## PostHog 在 AI 可观测性技术栈中的位置 当技术 AI 信号需要与产品行为连接时，PostHog 最有价值。它可以帮助回答以下问题： - 哪个模型版本与任务成功完成相关？ - 用户是否会在首次响应较慢后放弃对话？ - 哪个提示词变体带来了更多有用反馈？ - 昂贵的工具调用是否集中在某类工作流？ - 哪些客户群体遇到了检索故障？ - 一次发布是否提升了质量，同时增加了延迟或成本？ PostHog 不适合单独承担高容量原始提示词和回答存储、深度分布式追踪、基础设施性能分析或完整事故管理。成熟的技术栈可以把低层日志和 trace 发送到专业可观测性后端，同时把经过筛选的产品事件和评估结果发送到 PostHog。 ### PostHog 与相邻 AI 工具的比较 当前目录中的工具并不是 PostHog 可观测性的替代品。它们可以支持文档、原型、内容生产或 AI 系统周边的应用开发。以下比较区分了这些角色。 | 工具 | AI 工作流中的最佳角色 | 可观测性角色 | 价格层级 | |---|---|---|---| | PostHog | 产品分析、功能开关、实验和事件分析 | 正确埋点后，作为面向产品的主要分析层 | 请查看官网当前价格 | | [Notion](/zh/tools/notion-ai) | 文档、运行手册、评估记录和提示词治理 | 保存人类可读的运营知识，而不是运行时 telemetry | Freemium；请查看官网当前价格 | | [Gemini](/zh/tools/gemini) | 通用研究、写作和分析 | 可以辅助检查抽样 trace，但不是 telemetry 存储系统 | Freemium；请查看官网当前价格 | | [Replicate](/zh/tools/replicate) | 运行和集成模型工作负载 | 可以作为模型供应商或推理步骤进行埋点 | Freemium；请查看官网当前价格 | | [Loom](/zh/tools/loom) | 录制产品演示和事故说明 | 适合团队定性沟通，不适合自动监控 | Freemium；请查看官网当前价格 | | [Gamma](/zh/tools/gamma) | 创建关于系统发现的内部演示 | 在分析之后帮助传达趋势 | Freemium；请查看官网当前价格 | 实际结论很简单：使用 PostHog 保存结构化行为证据，使用文档工具保存政策和决策，使用模型或应用平台负责执行。不要因为某个内容或开发工具能够处理 AI 生成的文本，就把它称为可观测性平台。 ## 数据模型：事件、trace 和属性 可靠的实现从稳定的事件分类开始。事件名称应描述有意义的操作，而不是每个迭代都会变化的实现细节。例如，`ai_generation_completed` 通常比 `openai_sdk_wrapper_v3_finished` 更持久。 一个实用的最小模型包含以下事件族： | 事件族 | 用途 | 推荐属性 | |---|---|---| | `ai_request_started` | 标记用户可见 AI 操作开始 | Trace ID、会话 ID、功能、模型、提示词版本、时间戳 | | `ai_retrieval_completed` | 记录搜索或检索行为 | 查询类型、文档数量、延迟、检索版本、空结果标记 | | `ai_tool_call_completed` | 记录外部操作或函数调用 | 工具名称、成功标记、耗时、验证结果、重试次数 | | `ai_generation_completed` | 记录模型输出和性能 | 模型、供应商、延迟、token、结束原因、安全结果 | | `ai_feedback_submitted` | 捕获用户明确判断 | 评分、反馈类别、trace ID、界面、用户分群 | | `ai_outcome_recorded` | 把 AI 行为与业务或产品结果连接 | 结果名称、成功标记、结果耗时、功能、实验变体 | 使用共同的 `trace_id` 连接一次用户请求中的所有子操作。需要区分模型、检索或工具步骤时，可以使用 `span_id` 或操作 ID。`session_id` 连接相关的多轮交互，用户或账户标识则支持队列分析。请确保这些标识跨浏览器、服务器、worker 和队列边界保持一致。 ### 值得重点关注的属性 #### 模型和版本 记录供应商、模型系列、可用时的模型版本、路由决定以及是否发生回退。`production` 这样的标签不足以复现事故。模型别名可能指向不断变化的实现，因此在可行时应保存供应商返回的标识。 #### 提示词和检索版本 不要只保存提示词正文。保存提示词模板版本、系统政策版本、检索配置版本和解析器版本。版本标识能够进行比较，也可以避免在每个事件中暴露敏感正文。 #### 时间 记录每个 span 的开始和结束时间。对于流式应用，分开记录首 token 时间和总完成时间。检索延迟也应与重新排序和上下文组装时间分开。 #### 用量和成本 在可用时保存输入和输出 token 数。如果 API 不返回供应商价格，应在应用中使用版本化价格表计算估算成本。要明确标记这是估算值，不要把它描述为供应商最终账单。 #### 结果 技术上的完成并不等于成功。模型可能返回 HTTP 200，但仍然无法完成用户任务。记录导出完成、答案接受、工作流提交或需要人工修正等后续结果。 ## 隐私与数据治理 AI telemetry 可能包含用户提示词、文档、姓名、标识符和模型输出。应把可观测性数据视为生产数据。在发送到 PostHog 之前，定义哪些信息对诊断必要，哪些内容应留在受控存储中。 实用政策通常包括以下内容： 1. 默认发送元数据：ID、版本、耗时、状态、数量和分数。 2. 只有在有明确调试需求且经过批准的保留政策允许时，才发送原始提示词或回答。 3. 在写入之前删除密钥、访问 token、支付数据、健康信息和不必要的个人信息。 4. 分析人员不需要原始值时，对标识符进行哈希或假名化。 5. 对原始 trace 的访问限制应比对聚合面板的访问更严格。 6. 为原始内容、衍生指标和评估结果定义保留期限。 7. 明确客户数据是否可以用于调试、评估或模型改进流程。 不要假设隐藏用户名就足够。提示词上下文可能暴露身份，检索文档也可能包含机密信息。脱敏层应在数据离开处理这些信息的服务之前运行。 ## 重要的 AI 指标 ### 可靠性指标 按供应商、模型、功能和版本跟踪请求成功与失败。包括超时、限流、格式错误响应、结构化响应验证失败、工具错误和检索错误。单一成功率可能隐藏某个小但重要工作流中的严重问题，因此要按操作分组。 有用的可靠性视图包括： - 生成完成率。 - 结构化输出验证率。 - 工具执行成功率。 - 空检索结果率。 - 回退频率。 - 重试频率及重试成功率。 - 安全或政策拦截率。 - 缺少子 span 的 trace 比例。 ### 延迟指标 AI 延迟与普通 API 延迟的感知方式不同。流式回答即使总完成时间较长，只要首 token 很快到达，也可能让用户觉得响应及时。因此应同时测量这两个指标。 建议跟踪： - 处理前排队时间。 - 检索耗时。 - 首 token 时间。 - 流式分块之间的时间。 - 总生成耗时。 - 工具调用耗时。 - 用户可见的端到端耗时。 - 尾部延迟，而不只是平均值。 按模型、提示词版本、上下文大小、工具路径和回退路径拆分延迟。较大的上下文可能改善质量，但也会造成更慢、更贵的请求；面板应让这种权衡可见。 ### 质量指标 质量需要结合明确、隐式和自动化信号。没有单一指标足够可靠。 明确信号包括赞或踩、评分、纠错按钮或用户选择的原因。隐式信号包括用户是否复制回答、接受生成草稿、完成下一步工作流，或立即重新生成。隐式信号有帮助但存在歧义。复制动作可能代表回答有用，也可能代表用户复制了错误内容准备稍后修改。 自动化信号可以包括引用是否存在、schema 是否有效、groundedness 检查、禁止内容检查或基于评分标准的评估器。把自动化分数视为带有误差的测量，而不是事实真相。保存评估器版本和评分标准版本，使分数在评估器变化后仍然可解释。 ### 成本指标 成本是产品问题，而不只是基础设施问题。记录每次请求、每个成功结果、每个活跃账户和每个功能的估算模型成本。区分输入和输出用量，因为检索上下文很大的提示词，即使最终回答短，也可能很贵。 应关注以下问题： - 哪个功能消耗最多模型预算？ - 哪些 trace 很贵，却没有带来成功结果？ - 简单请求是否可以由更便宜的模型完成？ - 解析失败造成的重试是否增加了总成本？ - 提示词或检索变更是否增加了上下文大小？ 不要只把成本作为质量目标。低成本但经常失败的系统会制造支持工作并损害信任。 ## 分步教程：埋点一个基础 AI 请求 以下流程与供应商无关。请根据后端使用的 PostHog SDK 调整事件调用。模型和工具操作应尽可能在服务器端记录。 ### 第一步：定义 trace 边界 选择一个应作为整体调查的用户可见操作。对于支持助手，它可以是一次提交的问题和回答。在请求开始时生成 trace ID，并把它传给所有下游函数。 ### 第二步：捕获请求元数据 记录功能名称、应用版本、环境、用户或账户标识、会话 ID、提示词版本和模型路由决定。在完成隐私审查前，避免记录完整提示词。 ### 第三步：创建子 span 分别包装检索、审核、工具调用和生成。每个 span 都应包含开始时间、结束时间、状态和错误分类。即使子操作失败，也应发出 span，因为故障位置对诊断至关重要。 ### 第四步：记录用量和输出状态 供应商返回响应后，记录 token 数、结束原因、schema 验证、安全结果和回退状态。如果供应商没有返回用量数据，应保存 null，而不是制造虚假的精确度。 ### 第五步：稍后记录产品结果 用户结果可能在模型响应之后才发生。当用户接受、提交、导出或修改结果时，发送单独的结果事件，并使用 trace ID 关联它。 ### 第六步：测试失败路径 在非生产环境中强制触发供应商超时、无效结构化输出、空检索结果、工具调用失败和用户取消。确认事件保留相同 trace ID，并能区分每种失败。 简化后的事件序列如下： ```text ai_request_started ai_retrieval_completed ai_tool_call_completed ai_generation_completed ai_feedback_submitted ai_outcome_recorded ``` 这只是示意，不是强制性的 PostHog schema。重要的是标识符一致、状态字段清晰，以及技术执行与产品结果之间存在连接。 ## 分步教程：构建 PostHog AI 可观测性面板 ### 第一步：从少量问题开始 分别为可靠性、性能、质量和经济性创建视图。不要一开始就使用所有属性。能够回答几个运营问题的面板，比堆满图表且无人维护的面板更有价值。 ### 第二步：加入量级和失败趋势 绘制请求量和失败率随时间的变化。按操作、供应商、模型、应用版本和环境拆分失败。解读突然变化前，要确认时区和事件延迟。 ### 第三步：加入延迟分解 使用事件属性或 span 时长比较检索、工具、生成和总延迟。加入功能与模型筛选。注意只影响尾部延迟的变化；平均延迟稳定时，一部分用户仍可能等待更久。 ### 第四步：加入质量信号 展示反馈率、正负反馈、修正率、评估器分数和下游完成率。按提示词版本和检索版本分组。保留样本量显示，因为少量评估得到的高分不应压过更广泛的信号。 ### 第五步：加入成本和结果视图 绘制每次请求和每个成功结果的估算成本。比较不同模型路径和工作流类型。某个模型单次调用更贵，但如果它减少重试并带来更多完成任务，整体可能更高效。 ### 第六步：添加发布和实验注释 标记部署、提示词变更、模型变更、检索变更和功能开关变更。没有注释，分析人员可能看到指标变化，却找不到引发变化的运营事件。 ### 第七步：谨慎定义告警 对可行动的条件告警，例如持续供应商失败、schema 验证率崩溃、工具错误异常升高、telemetry 缺失或明显延迟回归。不要对主观质量分数的每个小波动都告警。告警应包含受影响功能、版本和调查所需的 trace 链接。 ## AI 事故排查 当用户报告助手回答质量下降时，应从用户可见症状开始，沿 trace 向下检查。实用的调查顺序是： 1. 确认受影响工作流和时间范围。 2. 将请求量、失败率、延迟、质量信号和成本与健康时期比较。 3. 按部署、提示词版本、模型路径、检索版本和账户分群筛选。 4. 检查代表性 trace，包括成功和失败样本。 5. 判断问题开始于检索、工具执行、提示词构建、模型生成、解析还是展示层。 6. 检查 telemetry 是否不完整。缺失 span 可能让健康组件看起来像责任方。 7. 使用脱敏输入和相同版本复现问题。 8. 记录根因、缓解措施和后续评估。 ### 常见故障模式 | 症状 | 可能的调查路径 | 有用证据 | |---|---|---| | 回答相关性下降 | 检索、上下文组装、提示词版本、模型路径 | 检索版本、空结果率、评估器分数 | | 响应变慢 | 队列、检索、工具、上下文大小、供应商延迟 | span 时长、首 token 时间、回退率 | | 结构化输出失败 | schema、解析器、提示词变化、模型能力 | 验证状态、原始错误类别、提示词版本 | | 成本突然增加 | 路由、重试、上下文增长、输出长度 | token 数、重试次数、模型路径、成本估算 | | 用户不再完成任务 | 质量、界面、延迟、工作流错误 | 结果事件、反馈、放弃、发布注释 | | 只有部分账户失败 | 数据权限、租户检索、账户配置 | 账户分群、检索状态、工具响应状态 | 不要根据一条戏剧性的 trace 进行判断。一个例子可以揭示故障模式，但不能说明故障发生的普遍程度。应把 trace 检查与分组后的聚合数据结合起来。 ## 评估工作流 可观测性告诉你发生了什么，评估则帮助判断结果是否良好。建立能够在稳定测试集和抽样生产 trace 上运行的评估流程。 ### 创建评估数据集 使用具有代表性的、经过隐私审查的示例，覆盖常见请求、困难请求、空知识库情况、模糊指令、工具失败和政策敏感场景。保存稳定的案例 ID 和预期行为，不要让原始客户内容被广泛访问。 ### 定义评分标准 评分标准可以包括事实依据、任务完成、遵循指令、格式有效性、语气和安全性。每项标准都要具体。例如，groundedness 标准应说明什么算无依据内容，以及部分证据如何处理。 ### 对所有内容进行版本化 对测试集、评分标准、评估器、提示词、检索配置和模型路径进行版本化。如果无法识别生成分数的系统，分数就没有足够的意义。 ### 比较变更前后 修改提示词或模型时，在相同案例上比较旧配置和新配置。随后观察发布后的生产结果。离线指标提升，并不保证用户体验更好，因为延迟、成本或集成故障可能上升。 ### 有策略地使用人工评审 人工评审成本较高，但对模糊或高影响案例很有价值。可以优先抽样不确定性高、评估器意见不一致、有负面用户反馈或分数变化很大的案例。重要决策还应记录评审者一致性和评审说明。 ## 可观测性使用场景比较 | 使用场景 | 关键事件 | 重要维度 | PostHog 适配度 | |---|---|---|---| | 聊天助手 | 请求、生成、反馈、结果 | 模型、提示词、会话、账户 | 适合产品行为和队列分析 | | 检索增强生成 | 检索、生成、引用检查 | 语料库、检索版本、文档数量 | 正确埋点后适配度高 | | AI 代理工作流 | 规划、工具调用、审批、结果 | 工具、步骤、重试、人工介入 | 适合漏斗分析，需要谨慎设计 trace | | AI 内容生成 | 请求、草稿、编辑、发布 | 内容类型、模型、编辑操作 | 适合采用率和完成指标 | | 客服自动化 | 分类、响应、升级 | 队列、类别、解决、人工交接 | 适合工作流结果和分群 | | 批量推理 | 任务、项目、模型结果、错误 | 批次 ID、项目状态、耗时、成本 | 适合任务级报告，应配合任务日志 | | 安全监控 | 政策检查、拦截、申诉、评审 | 政策、类别、评审决定 | 适合趋势分析，但需严格控制敏感数据 | ## 如何选择目录中的配套工具 当角色定义清楚时，目录中的工具可以补充可观测性计划。 [Notion](/zh/tools/notion-ai) 可以保存 AI 系统运行手册、事件字典、提示词变更记录、评估评分标准和事故复盘笔记。让文档链接到面板名称和版本标识，分析人员便可以从决策直接找到证据。 [Gemini](/zh/tools/gemini) 可以帮助团队总结经过抽样和脱敏的 trace，或起草评估标准。但它不应被视为自动事实来源。评审人员仍需根据底层事件验证结论。 当应用调用托管模型或试验不同推理工作负载时，[Replicate](/zh/tools/replicate) 可能有用。应使用模型、版本、延迟、用量、错误和结果属性记录供应商调用。供应商可用并不代表应用不需要监控。 对于应用原型，[Lovable](/zh/tools/lovable) 和 [Bolt.new](/zh/tools/boltnew) 可以帮助创建界面或工作流原型。在原型接触真实用户前，仍需添加明确的服务器端 telemetry、隐私控制、错误处理和测试覆盖。不要假设生成的应用代码已经具备生产级可观测性。 对于视觉和媒体工作流，[Runway](/zh/tools/runway)、[Luma AI](/zh/tools/luma-ai)、[Ideogram](/zh/tools/ideogram) 和 [Canva](/zh/tools/canva) 可能成为内容管线的一部分。应把素材生成请求、审批、修改、导出和发布记录为产品事件。媒体工具能生成素材，并不能说明素材是否有用或工作流是否盈利。 ## 应避免的反模式 ### 永久记录所有内容 原始提示词和回答昂贵、敏感且难以治理。只保存有明确调试或评估目的所需的最少内容，并使用保留控制。 ### 把 HTTP 成功当作 AI 成功 成功响应可能包含错误回答、无效 schema、无关检索结果或失败的业务操作。应把技术状态和下游结果关联起来。 ### 使用单一分数代表质量 赞率、评估器分数或完成率可能因与回答质量无关的原因变化。使用多个信号并检查分群。 ### 混用提示词版本 如果提示词没有版本化，变更前后的比较就只能靠猜测。模板、政策、解析器、检索设置和模型路径都应版本化。 ### 忽略缺失 telemetry 面板可能因为失败请求从未发出完成事件而看起来健康。发送开始和失败事件，监控事件完整性，并把中断 trace 纳入分析。 ### 使用隐藏假设计算成本 成本估算取决于 token 化、供应商价格、缓存、重试和路由。保存价格表版本，并清楚标记估算值。 ### 只发送客户端事件记录服务器操作 浏览器事件可能遗漏供应商失败、工具错误和服务器重试。权威运营事件应从服务器发送，客户端事件则用于记录用户交互。 ### 不惜代价优化延迟 减少上下文或缩小模型可能降低延迟，却损害回答质量。应综合评估质量、成本和完成结果之间的权衡。 ## 实用实施清单 ### 埋点前 - 定义用户可见的 AI 工作流。 - 明确数据负责人和隐私要求。 - 选择 trace、会话、用户和账户标识。 - 定义事件名称和必需属性。 - 决定哪些原始内容可以保留。 - 为重要工作流定义结果。 ### 实施期间 - 发送开始、成功和失败状态。 - 为检索、工具、审核和生成创建子 span。 - 记录模型、提示词、检索、解析器和应用版本。 - 为流式响应捕获首 token 和总延迟。 - 记录用量数据并标记估算值。 - 测试供应商故障、格式错误响应和用户取消。 ### 上线前 - 使用真实示例验证脱敏。 - 检查标识符是否跨服务一致。 - 将面板数量与应用日志进行核对。 - 确认失败无法静默消失。 - 添加发布注释和负责人信息。 - 定义告警阈值和升级路径。 ### 上线后 - 定期检查代表性 trace。 - 跟踪质量和产品结果，而不只是可靠性。 - 抽样分析负面反馈。 - 重新审查保留和访问策略。 - 在模型或工作流变化时审核事件 schema。 - 记录事故，并在修复后更新评估。 ## 常见问题 ### PostHog 是 AI 可观测性平台吗？ 当 AI 操作被建模为结构化事件，并与用户、会话、版本、结果和实验连接时，PostHog 可以支持 AI 可观测性。它最适合把 AI 行为与产品分析连接起来。但不应自动把它视为专业追踪、日志管理、基础设施监控或模型评估系统的替代品。 ### LLM 请求应该记录什么？ 至少记录 trace ID、操作名称、模型和供应商、提示词版本、应用版本、开始和完成状态、延迟、可用时的 token 用量、错误类别和下游结果。使用检索或工具的应用还应记录对应 span。只有在获得批准的隐私和保留政策允许时，才保存原始提示词与回答。 ### 应该把提示词和模型输出发送到 PostHog 吗？ 只有在存在明确理由并且具备适当控制时才应这样做。元数据通常更安全，也足以支持聚合分析。如果调试确实需要原始内容，应删除密钥和个人数据、限制访问并设置有限的保留期限。即使可见提示词不敏感，上下文和检索文档也可能包含敏感信息。 ### 如何衡量 AI 质量？ 结合明确反馈、隐式行为、自动检查、人工评审和下游任务结果。对评分标准和评估器进行版本化。按功能、模型、提示词版本、检索配置和用户分群分析质量，而不是只依赖总分。 ### 如何准确衡量 AI 成本？ 在可用时捕获供应商用量数据，并使用版本化价格表计算估算值。需要时纳入重试、回退、工具调用、检索处理和批量工作。同时报告每次请求成本与每个成功结果成本，并把估算值与供应商最终账单区分开。 ### PostHog 能监控 AI 代理吗？ 如果每个重要步骤都使用共同 trace ID，并使用独立操作或 span 标识，PostHog 可以帮助分析代理工作流。应记录规划、工具调用、重试、审批、失败和最终结果。代理 trace 可能具有高基数且成本较高，因此应谨慎选择事件细节和保留期限。 ### 应该把哪些相邻工具与 PostHog 搭配？ 使用 [Notion](/zh/tools/notion-ai) 保存运行手册和治理文档，使用 [Replicate](/zh/tools/replicate) 支持相关推理工作流，使用 [Lovable](/zh/tools/lovable) 或 [Bolt.new](/zh/tools/boltnew) 创建原型，但在投入生产前仍需正确添加 telemetry。每个工具都应按照真实职责使用，不要把它当作可观测性替代品。 ### 第一个应该构建什么面板？ 从一个工作流开始，展示请求量、失败率、首 token 时间、总延迟、反馈、下游完成率、估算成本、模型路径和提示词版本，并为代表性失败添加 trace 链接。只有当第一个面板能帮助团队做出明确的运营或产品决策后，再继续扩展。 ## 结语 PostHog AI 可观测性工具更适合被理解为一种建立在 PostHog 事件模型之上的埋点和分析方法，而不是某个神奇的单一功能。它的价值来自把模型执行与周围的用户和业务上下文连接起来。 从稳定的 trace 标识、精简的事件分类、严格的隐私控制和明确的产品结果开始。随后根据工作流需要加入检索、工具、生成、评估、延迟和成本细节。再把面板与抽样 trace 结合起来：聚合数据揭示模式，trace 解释原因。 在 2026 年，可靠的 AI 产品之间的区别，不只是能否调用模型，而是团队能否理解、评估和改进调用之后发生的事情。设计良好的 PostHog 实现可以为产品和工程团队提供共同视角，但前提是同时具备严格的版本管理、测试、治理和合适的配套系统。