尧图网页设计 
数据分析后端前端数据可视化大数据【免费下载链接】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点击查看免费下载本文基于 PostHog 仓库中 suggesting-path-cleaning-rules 技能文档 展开结合 service.py、定时健康检查、管理命令、REST API 与前端实现完整剖析 PostHog 如何每周主动为 Web 分析团队建议路径清理规则。读完本文你将掌握这套系统的架构分层、团队门控gating逻辑、re2 校验机制、管理命令与 API 的完整用法以及如何阅读、应用甚至扩展一条 AI 建议的清理规则。背景为什么需要主动建议路径清理规则PostHog Web 分析的$pathname属性记录每个页面的真实 URL。未配置路径清理时像/users/123/profile、/users/456/profile这样的动态 URL 会被当作完全不同的行参与统计导致 Web 分析瓦片tiles与 Paths 洞察的细分结果被碎片化成成千上万条几乎相同的 URL。系统提示词prompts.py对这一问题的描述是动态段数字 ID、UUID、slug、日期、locale会把一个细分结果撕裂成数千条近似重复的 URL。多数团队从不主动配置路径清理。于是 PostHog 推出了这个建议功能面向 web-analytics precompute 队列每周为每个团队采样真实路径调用 LLM 生成{regex, alias}规则用团队自己的真实路径校验后存储供人类审阅。该功能遵循一个极其重要的设计原则它只建议suggests从不自动应用auto-apply。原因在技能文档与命令 docstringsuggest_path_cleaning_rules.py中写得很清楚应用规则会改写所有已清理图表中的历史数字这必须保留为人的决策。手工编写或直接应用规则请使用managing-path-cleaning-rules技能本技能只负责建议这条链路。架构总览一条从采样到建议的流水线技能文档给出了清晰的五层架构结合仓库源码可进一步对应到具体文件层职责仓库位置Core采样、LLM 调用、校验、合并service.pyStorage以HealthIssueseverityinfo形式存储建议posthog/models/health_issue.py通用模型Schedule每周一次的定时健康检查path_cleaning_suggestions.pyCohort参与团队白名单web.pySurfacing设置页 Banner、Onboarding 步骤、健康页、MCP 工具frontend/src/scenes/settings/environment/、tools.yamlCore 层service.py 的四个关键函数products/web_analytics/backend/path_cleaning_suggestions/service.py是整套流水线的核心包含四个关键函数1.sample_pathnames/count_distinct_pathnames—— 通过 HogQL 取 Top$pathnamesample_pathnames执行一条 HogQL 查询按页面浏览量倒序取前 N 个$pathnameservice.pySELECT properties.$pathname AS path, count() AS views FROM events WHERE event $pageview AND timestamp now() - toIntervalDay({days}) AND properties.$pathname IS NOT NULL AND properties.$pathname ! GROUP BY path ORDER BY views DESC LIMIT {limit}count_distinct_pathnames则用count(DISTINCT properties.$pathname)统计窗口内去重后的路径数用于后续的低基数门控。两条查询都通过execute_hogql_query执行并打上web_path_cleaning_*的 query_type 标签。2.call_llm_for_rules—— 经 LLM 网关的一次性调用通过get_llm_client(productweb_analytics, team_idteam.id)走 LLM 网关service.py模型默认是WEB_ANALYTICS_PATH_CLEANING_SUGGESTIONS_MODEL缺省值为claude-haiku-4-5service.py。请求由 SYSTEM_PROMPT 与build_user_prompt(paths)拼接的路径样本组成temperature0.2保证输出稳定userfteam-{team.id}用于网关侧审计。返回内容先经_extract_json剥离可能的json代码围栏后解析为SuggestedRulesResponse。3.validate_and_annotate_rules—— 用 re2 校验并测试应用技能文档中的test before saving步骤这是整个设计的精髓所在。每条建议规则都用re2ClickHousereplaceRegexpAll使用的同一正则引擎编译并实际应用到采样路径上service.py正则无法编译re2.error或 alias 包含无法满足的反向引用如\1但正则中没有捕获组触发IndexError的规则被直接丢弃测试应用后没有匹配到任何路径的规则同样被丢弃存活的规则获得稠密dense的order编号按模型给出的最具体在前顺序重新编号、match_count该规则实际改写了多少条采样路径以及仅存于内存的 before/afterexamples每条规则最多 3 个示例MAX_EXAMPLES_PER_RULE 3。4.generate_suggestions_for_team/apply_suggestions_to_team—— 编排与合并generate_suggestions_for_team串起以上步骤并施加门控见下节它只负责生成、不落库返回带status的TeamSuggestionResult。所有 ClickHouse 查询都在tags_context(productWEB_ANALYTICS, featureHEALTH_CHECK, ...)中执行以保证无论调用方是管理命令、API 还是定时检查查询标签一致。单个团队的异常被try/except捕获并转换为该团队的error状态绝不会中断整轮队列扫描。apply_suggestions_to_team则把规则**合并merge**进团队的path_cleaning_filters绝不整体覆盖按 regex 去重、在现有最大 order 之后续接编号service.py。合并过程使用transaction.atomic()select_for_update()锁行防止并发的 apply 或设置页保存读到同一个旧列表而互相覆盖。返回实际新增的规则数量。Storage 层建议即健康问题建议不建独立模型而是以HealthIssue健康问题的形式存储severity 为info。关键设计每个团队最多一个活跃建议hash_keys[]payload携带rules、model、sampled_path_count、distinct_path_count字段统一由 build_suggestion_payload 产出保证定时检查、按需 API、前端 Banner 三方字段一致出于隐私考虑真实路径的 before/after 示例与可能引用真实路径的模型reason字段从不入库——健康问题 payload 仅需health_issue:read权限即可读取不能泄漏团队的原始事件数据应用或手工配置规则后下一次检查运行时该团队因已有规则而判为健康问题自动 resolve用户也可通过健康问题的dismissed标志手动忽略。Schedule 层每周一次的健康检查PathCleaningSuggestionsCheckpath_cleaning_suggestions.py挂在共享健康检查框架上schedule 23 6 * * 1每周一 06:23 UTC执行策略HealthExecutionPolicy(batch_size5000, max_concurrent1)批次必须够大因为框架在批处理前会枚举所有活跃团队批次太小会导致云环境出现数千个串行、最终又过滤成零候选的空转 activity而每个候选团队一次 LLM 调用的昂贵部分被限制在detect()内部按候选即 cohort 交集严格串行处理一个大批次只产生一个 activity而非一次 LLM 调用风暴去重优化已有活跃建议的团队直接重新发射已存储的 payloadexisting_by_team不产生新的 LLM 往返同时保留其dismissed标志并在团队配置规则后由框架自动 resolve检查是机会而非缺陷severity 保持 INFO问题 payload 中携带经过校验的建议规则供设置页 Banner 与健康页提供一键应用render_alert生成人机可读的提示内容remediation分别面向人类打开设置 → Product analytics → Path cleaning rules 审阅后应用与 Agent读取 payload、调用 apply 端点或先调用 generate 重新生成。Cohort 层参与团队的来源与配置队列由WEB_ANALYTICS_PATH_CLEANING_SUGGESTIONS_TEAM_IDS定义默认值即 precompute 入组列表WEB_ANALYTICS_LAZY_PRECOMPUTE_TEAM_IDSweb.py。两处配置均支持环境变量覆盖逗号分隔的 team id 列表默认在非测试的云部署EU/US/DEV/E2E中为2。同时WEB_ANALYTICS_PATH_CLEANING_SUGGESTIONS_MODEL可通过环境变量更换模型前提是该模型必须在 LLM 网关的web_analytics产品白名单内llm-gateway 产品配置。门控Gating一个团队为什么被跳过generate_suggestions_for_team返回带状态的TeamSuggestionResultservice.py六种状态对应六种门控结果状态含义触发条件绕过方式skipped_inactive团队不活跃窗口内visited_within_days默认 30 天无$pageview。has_recent_pageviews用LIMIT 1让 ClickHouse 提前终止而非统计全窗口service.py--ignore-visit-gateskipped_configured团队已配置规则已有path_cleaning_filters且未传include_configured--include-configuredskipped_low_cardinality路径基数过低去重路径数 min_distinct_paths默认 50清理无价值不值得花 token调低--min-distinct-pathsskipped_no_paths窗口内无 pageview 样本采样结果为空—generated成功产出规则生成成功规则列表可能为空——路径本来就干净空生成永不存储避免遮蔽一条真正可操作的建议—error采样/LLM 失败单团队捕获异常错误信息含类型: 信息绝不中止整轮队列扫描—注意门控顺序的实现细节活动性门控的 ClickHouse 查询被放在与其余步骤相同的防护内部因此一次瞬时查询失败会作为该团队的error状态浮现而不是从整轮队列扫描中抛出。如何运行管理命令suggest_path_cleaning_rules技能文档给出了三类核心用法suggest_path_cleaning_rules.py# 默认 cohort打印建议存储为健康问题 python manage.py suggest_path_cleaning_rules # 指定团队干跑不落任何存储 python manage.py suggest_path_cleaning_rules --teams 2,19279 --no-store # 为已审阅的团队生成并应用合并绝不覆盖 python manage.py suggest_path_cleaning_rules --teams 2 --apply全部命令行参数参数默认值说明--teams配置的 cohort逗号分隔的团队 id与--teams-file互斥--teams-file—从文件读取逗号或换行分隔的团队 id--days30回看窗口天数--limit300采样的 Top-N 路径数--min-distinct-paths50去重路径数低于此值的团队跳过低基数无价值--include-configuredFalse也处理已配置规则的团队默认跳过--no-storeFalse不持久化为健康问题仅打印--visited-within-days30仅处理最近多少天内打开过 Web 分析的团队--ignore-visit-gateFalse即使团队近期未打开 Web 分析也处理--applyFalse将生成的规则合并进path_cleaning_filters绝不覆盖必须显式开启命令行为细节未给--teams/--teams-file且配置的 cohort 为空时命令直接抛CommandError提示传参未知团队 id 会打印skipping N unknown team ids提示并跳过打印输出按团队分组状态为generated时输出规则数、采样/去重路径数、模型名并逐条打印[order] regex - alias (matches N paths)及每条规则前 2 个真实路径的 before/after 示例——这些示例只在命令输出中出现永不落库--apply与存储可以共存应用成功后会 resolve 对应活跃健康问题并输出applied N new rule(s) to team {id}命令结尾输出summary:汇总各状态计数与applied_rules总数。该健康检查也和其他健康检查一样可通过健康问题的refresh端点或管理后台 UI 按团队手动触发。用户如何看到并应用建议设置页 BannerPathCleaningSuggestionsBanner挂在/settings/project#path_cleaning即 PathCleaningSuggestionsBanner.tsx显示最新一条suggested规则为regex → alias预览并附匹配数groups N of your top M pathsApply all 仅限项目管理员前端通过useRestrictedArea镜像后端的管理员门槛关闭按钮执行 dismiss。Preview on your paths 打开模态框展示最近 30 天最常访问路径、按顺序应用全部建议规则的 before/after 与浏览量。驱动这一切的是 pathCleaningSuggestionsLogic.ts该 kea logic 通过健康问题 APIkindpath_cleaning_suggestionsstatusactivedismissedfalse拉取建议并做乐观隐藏apply/dismiss 即刻隐藏、失败回滚、应用中的按钮禁用、以及切换项目时重置状态防止用旧 issue id 操作新项目。Onboarding 步骤OnboardingWebAnalyticsPathCleaningStepstepKeypath_cleaningOnboardingWebAnalyticsPathCleaningStep.tsx在 Web 分析引导流程中呈现同样的 Banner。REST API专用端点位于 web_analytics_path_cleaning_suggestions.py列表与忽略则走通用健康问题 APIPOST /api/projects/:id/web_analytics_path_cleaning_suggestions/generate/ GET /api/projects/:id/web_analytics_path_cleaning_suggestions/{issue_id}/preview/ POST /api/projects/:id/web_analytics_path_cleaning_suggestions/{issue_id}/apply/ GET /api/projects/:id/health_issues/?kindpath_cleaning_suggestionsstatusactivedismissedfalse PATCH /api/projects/:id/health_issues/{id}/ # body: {dismissed: true}generate按需采样、调 LLM、校验并存储为全新建议替换之前的活跃建议即使团队已有规则也会执行include_configuredTrue需要web_analytics:write作用域且受特性开关web-analytics-path-cleaning-suggestions门控——这是三个动词中唯一会花钱ClickHouse 采样 LLM 调用的因此额外加了 dogfooding 开关与AIBurstRateThrottle/AISustainedRateThrottle限流preview 每次请求也会重新采样 ClickHouse同样限流preview把建议规则按 order 顺序前一条输出喂给下一条与 ClickHouse 应用已配置规则的语义完全一致见 preview_rules_on_team应用到最新采样路径返回最多 20 条发生变化的 before/after 对及changed_path_count只读作用域、按需计算、永不存储——这是 Banner Preview on your paths 模态框的数据来源apply合并规则并 resolve 底层健康问题同一事务内完成避免 resolve 失败导致 Banner 再次出现Apply all重复应用已合并的规则仅限项目管理员——与团队 API 对path_cleaning_filters的写入门槛一致防止借该端点绕过。健康页与 PostHog AIMax检查渲染在/web/health与其它 web-analytics 检查并列附带人类与 Agent 的修复指引generate/apply 已作为 MCP 工具暴露在 tools.yamlweb-analytics-path-cleaning-suggestions-generate/-applypreview 默认enabled: false用户可直接对话式地让 Max 建议并应用清理规则。apply 被标记为destructive会改变历史图表数字因此触发 MCP 确认门槛generate 则要求requires_ai_consent: true并同样挂在特性开关下。审阅建议数据形态与隐私边界读取某团队当前活跃建议SKILL.md 给出的示例HealthIssue.objects.filter(team_idteam_id, kindpath_cleaning_suggestions, statusactive).first()payload[rules]中的每条规则携带四个字段见 API 序列化器与build_suggestion_payload字段含义regexre2 模式匹配动态路径段alias替换串使用id、uuid、slug、date、locale等尖括号占位符保持可读order应用顺序规则串行执行、前一条输出喂给下一条最具体的在前、最通用的兜底在后match_count改写了多少条真实采样路径——这是规则曾在真实流量上验证过的证据这四字段就是呈现给人类决策者判断是否应用的内容。真实路径上的 before/after 示例只在管理命令生成时打印刻意排除在存储 payload 之外——原因如前所述健康问题 payload 只需health_issue:read即可读取不能泄漏团队事件数据。提示工程如何让 LLM 产出高质量规则prompts.py 中的 SYSTEM_PROMPT 是规则质量的源头其约束本身就值得作为路径清理规则编写规范复用每条规则是regexGoogle re2 语法不要转义/alias替换串推荐尖括号占位符id、uuid、slug、date、locale捕获组反向引用\1虽被查询层支持但求值更慢不要使用仅在段必须位于路径开头时用^锚定用$或(/|$)收尾防止\d这类通用规则把路径中间的任意数字串也吞掉顺序即语义规则顺序应用、输出喂给下一条因此最具体在前、最通用catch-all在后通用规则永远不能吞掉应由具体规则处理的路径只针对样本中真实存在的模式提规则宁要 3–10 条强规则不要一堆猜测性规则路径本来就干净时返回空列表输出严格限定为单一 JSON 对象无任何散文形状为{rules: [{regex: ..., alias: ..., reason: ...}]}。扩展与定制新增一个展示渠道站内通知、设置 Banner、引导步骤读取团队活跃的path_cleaning_suggestions健康问题并渲染其payload[rules]保持 apply 为手动操作即可。更换模型必须先在 llm-gateway 产品配置 中把模型加入web_analytics产品白名单再通过WEB_ANALYTICS_PATH_CLEANING_SUGGESTIONS_MODEL环境变量切换。Agent 化替代方案设计笔记中勾勒了一个signals-scout-web-analytics-path-cleaningscout 的代理方案但针对 precompute cohort 应优先使用本专用任务因为它精确命中该 cohort并产出结构化、经过校验的行而非 Signals 收件箱式的结果。小结PostHog 的路径清理规则建议系统是一个典型的AI 生成 确定性校验 人类确认闭环HogQL 采样真实路径 → LLM 一次性生成候选规则 → re2 编译并在真实路径上测试应用 → 只把通过校验的规则含 order、match_count以健康问题形式存储 → 通过设置页 Banner、Onboarding、健康页与 MCP 工具呈现给用户由管理员决定是否一键应用。其核心工程取舍——空生成不落库、示例与 reason 不入 payload、select_for_update合并、空转批次控制——都值得在同类AI 建议型功能中借鉴。赞分享数据分析后端前端数据可视化大数据【免费下载链接】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点击查看免费下载相关推荐PostHog 路径清洗规则Path Cleaning Rules实战指南用 re2 正则与 MCP 工具驯服海量 URL 路径PostHog 路径清洗规则Path Cleaning Rules实战指南用 re2 正则与 MCP 工具驯服海量 URL 路径 路径清洗规则Path数据分析后端前端数据可视化大数据PostHog MCP Tools 实现指南从 YAML 定义到代码生成的完整流水线PostHog MCP Tools 实现指南从 YAML 定义到代码生成的完整流水线 MCP tools 是 PostHog 中面向 AI Agent 的原子数据分析后端前端数据可视化大数据最完整贝塞尔曲线实战指南从路径规划到无人机轨迹生成最完整贝塞尔曲线实战指南从路径规划到无人机轨迹生成 你还在为路径规划算法生成的轨迹不平滑而烦恼吗 在自动驾驶Autonomous Driving和移动机示例工程上一篇Ollama构建缓存优化CMake与Go编译加速终极指南下一篇Obsidian终极美化指南20个免费CSS片段让你的知识库焕然一新创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PostHog 路径清理规则智能建议（Path-Cleaning Suggestions）实现指南：从 AI 生成到人工确认的完整流水线
数据分析后端前端数据可视化大数据【免费下载链接】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点击查看免费下载本文基于 PostHog 仓库中 suggesting-path-cleaning-rules 技能文档 展开结合 service.py、定时健康检查、管理命令、REST API 与前端实现完整剖析 PostHog 如何每周主动为 Web 分析团队建议路径清理规则。读完本文你将掌握这套系统的架构分层、团队门控gating逻辑、re2 校验机制、管理命令与 API 的完整用法以及如何阅读、应用甚至扩展一条 AI 建议的清理规则。背景为什么需要主动建议路径清理规则PostHog Web 分析的$pathname属性记录每个页面的真实 URL。未配置路径清理时像/users/123/profile、/users/456/profile这样的动态 URL 会被当作完全不同的行参与统计导致 Web 分析瓦片tiles与 Paths 洞察的细分结果被碎片化成成千上万条几乎相同的 URL。系统提示词prompts.py对这一问题的描述是动态段数字 ID、UUID、slug、日期、locale会把一个细分结果撕裂成数千条近似重复的 URL。多数团队从不主动配置路径清理。于是 PostHog 推出了这个建议功能面向 web-analytics precompute 队列每周为每个团队采样真实路径调用 LLM 生成{regex, alias}规则用团队自己的真实路径校验后存储供人类审阅。该功能遵循一个极其重要的设计原则它只建议suggests从不自动应用auto-apply。原因在技能文档与命令 docstringsuggest_path_cleaning_rules.py中写得很清楚应用规则会改写所有已清理图表中的历史数字这必须保留为人的决策。手工编写或直接应用规则请使用managing-path-cleaning-rules技能本技能只负责建议这条链路。架构总览一条从采样到建议的流水线技能文档给出了清晰的五层架构结合仓库源码可进一步对应到具体文件层职责仓库位置Core采样、LLM 调用、校验、合并service.pyStorage以HealthIssueseverityinfo形式存储建议posthog/models/health_issue.py通用模型Schedule每周一次的定时健康检查path_cleaning_suggestions.pyCohort参与团队白名单web.pySurfacing设置页 Banner、Onboarding 步骤、健康页、MCP 工具frontend/src/scenes/settings/environment/、tools.yamlCore 层service.py 的四个关键函数products/web_analytics/backend/path_cleaning_suggestions/service.py是整套流水线的核心包含四个关键函数1.sample_pathnames/count_distinct_pathnames—— 通过 HogQL 取 Top$pathnamesample_pathnames执行一条 HogQL 查询按页面浏览量倒序取前 N 个$pathnameservice.pySELECT properties.$pathname AS path, count() AS views FROM events WHERE event $pageview AND timestamp now() - toIntervalDay({days}) AND properties.$pathname IS NOT NULL AND properties.$pathname ! GROUP BY path ORDER BY views DESC LIMIT {limit}count_distinct_pathnames则用count(DISTINCT properties.$pathname)统计窗口内去重后的路径数用于后续的低基数门控。两条查询都通过execute_hogql_query执行并打上web_path_cleaning_*的 query_type 标签。2.call_llm_for_rules—— 经 LLM 网关的一次性调用通过get_llm_client(productweb_analytics, team_idteam.id)走 LLM 网关service.py模型默认是WEB_ANALYTICS_PATH_CLEANING_SUGGESTIONS_MODEL缺省值为claude-haiku-4-5service.py。请求由 SYSTEM_PROMPT 与build_user_prompt(paths)拼接的路径样本组成temperature0.2保证输出稳定userfteam-{team.id}用于网关侧审计。返回内容先经_extract_json剥离可能的json代码围栏后解析为SuggestedRulesResponse。3.validate_and_annotate_rules—— 用 re2 校验并测试应用技能文档中的test before saving步骤这是整个设计的精髓所在。每条建议规则都用re2ClickHousereplaceRegexpAll使用的同一正则引擎编译并实际应用到采样路径上service.py正则无法编译re2.error或 alias 包含无法满足的反向引用如\1但正则中没有捕获组触发IndexError的规则被直接丢弃测试应用后没有匹配到任何路径的规则同样被丢弃存活的规则获得稠密dense的order编号按模型给出的最具体在前顺序重新编号、match_count该规则实际改写了多少条采样路径以及仅存于内存的 before/afterexamples每条规则最多 3 个示例MAX_EXAMPLES_PER_RULE 3。4.generate_suggestions_for_team/apply_suggestions_to_team—— 编排与合并generate_suggestions_for_team串起以上步骤并施加门控见下节它只负责生成、不落库返回带status的TeamSuggestionResult。所有 ClickHouse 查询都在tags_context(productWEB_ANALYTICS, featureHEALTH_CHECK, ...)中执行以保证无论调用方是管理命令、API 还是定时检查查询标签一致。单个团队的异常被try/except捕获并转换为该团队的error状态绝不会中断整轮队列扫描。apply_suggestions_to_team则把规则**合并merge**进团队的path_cleaning_filters绝不整体覆盖按 regex 去重、在现有最大 order 之后续接编号service.py。合并过程使用transaction.atomic()select_for_update()锁行防止并发的 apply 或设置页保存读到同一个旧列表而互相覆盖。返回实际新增的规则数量。Storage 层建议即健康问题建议不建独立模型而是以HealthIssue健康问题的形式存储severity 为info。关键设计每个团队最多一个活跃建议hash_keys[]payload携带rules、model、sampled_path_count、distinct_path_count字段统一由 build_suggestion_payload 产出保证定时检查、按需 API、前端 Banner 三方字段一致出于隐私考虑真实路径的 before/after 示例与可能引用真实路径的模型reason字段从不入库——健康问题 payload 仅需health_issue:read权限即可读取不能泄漏团队的原始事件数据应用或手工配置规则后下一次检查运行时该团队因已有规则而判为健康问题自动 resolve用户也可通过健康问题的dismissed标志手动忽略。Schedule 层每周一次的健康检查PathCleaningSuggestionsCheckpath_cleaning_suggestions.py挂在共享健康检查框架上schedule 23 6 * * 1每周一 06:23 UTC执行策略HealthExecutionPolicy(batch_size5000, max_concurrent1)批次必须够大因为框架在批处理前会枚举所有活跃团队批次太小会导致云环境出现数千个串行、最终又过滤成零候选的空转 activity而每个候选团队一次 LLM 调用的昂贵部分被限制在detect()内部按候选即 cohort 交集严格串行处理一个大批次只产生一个 activity而非一次 LLM 调用风暴去重优化已有活跃建议的团队直接重新发射已存储的 payloadexisting_by_team不产生新的 LLM 往返同时保留其dismissed标志并在团队配置规则后由框架自动 resolve检查是机会而非缺陷severity 保持 INFO问题 payload 中携带经过校验的建议规则供设置页 Banner 与健康页提供一键应用render_alert生成人机可读的提示内容remediation分别面向人类打开设置 → Product analytics → Path cleaning rules 审阅后应用与 Agent读取 payload、调用 apply 端点或先调用 generate 重新生成。Cohort 层参与团队的来源与配置队列由WEB_ANALYTICS_PATH_CLEANING_SUGGESTIONS_TEAM_IDS定义默认值即 precompute 入组列表WEB_ANALYTICS_LAZY_PRECOMPUTE_TEAM_IDSweb.py。两处配置均支持环境变量覆盖逗号分隔的 team id 列表默认在非测试的云部署EU/US/DEV/E2E中为2。同时WEB_ANALYTICS_PATH_CLEANING_SUGGESTIONS_MODEL可通过环境变量更换模型前提是该模型必须在 LLM 网关的web_analytics产品白名单内llm-gateway 产品配置。门控Gating一个团队为什么被跳过generate_suggestions_for_team返回带状态的TeamSuggestionResultservice.py六种状态对应六种门控结果状态含义触发条件绕过方式skipped_inactive团队不活跃窗口内visited_within_days默认 30 天无$pageview。has_recent_pageviews用LIMIT 1让 ClickHouse 提前终止而非统计全窗口service.py--ignore-visit-gateskipped_configured团队已配置规则已有path_cleaning_filters且未传include_configured--include-configuredskipped_low_cardinality路径基数过低去重路径数 min_distinct_paths默认 50清理无价值不值得花 token调低--min-distinct-pathsskipped_no_paths窗口内无 pageview 样本采样结果为空—generated成功产出规则生成成功规则列表可能为空——路径本来就干净空生成永不存储避免遮蔽一条真正可操作的建议—error采样/LLM 失败单团队捕获异常错误信息含类型: 信息绝不中止整轮队列扫描—注意门控顺序的实现细节活动性门控的 ClickHouse 查询被放在与其余步骤相同的防护内部因此一次瞬时查询失败会作为该团队的error状态浮现而不是从整轮队列扫描中抛出。如何运行管理命令suggest_path_cleaning_rules技能文档给出了三类核心用法suggest_path_cleaning_rules.py# 默认 cohort打印建议存储为健康问题 python manage.py suggest_path_cleaning_rules # 指定团队干跑不落任何存储 python manage.py suggest_path_cleaning_rules --teams 2,19279 --no-store # 为已审阅的团队生成并应用合并绝不覆盖 python manage.py suggest_path_cleaning_rules --teams 2 --apply全部命令行参数参数默认值说明--teams配置的 cohort逗号分隔的团队 id与--teams-file互斥--teams-file—从文件读取逗号或换行分隔的团队 id--days30回看窗口天数--limit300采样的 Top-N 路径数--min-distinct-paths50去重路径数低于此值的团队跳过低基数无价值--include-configuredFalse也处理已配置规则的团队默认跳过--no-storeFalse不持久化为健康问题仅打印--visited-within-days30仅处理最近多少天内打开过 Web 分析的团队--ignore-visit-gateFalse即使团队近期未打开 Web 分析也处理--applyFalse将生成的规则合并进path_cleaning_filters绝不覆盖必须显式开启命令行为细节未给--teams/--teams-file且配置的 cohort 为空时命令直接抛CommandError提示传参未知团队 id 会打印skipping N unknown team ids提示并跳过打印输出按团队分组状态为generated时输出规则数、采样/去重路径数、模型名并逐条打印[order] regex - alias (matches N paths)及每条规则前 2 个真实路径的 before/after 示例——这些示例只在命令输出中出现永不落库--apply与存储可以共存应用成功后会 resolve 对应活跃健康问题并输出applied N new rule(s) to team {id}命令结尾输出summary:汇总各状态计数与applied_rules总数。该健康检查也和其他健康检查一样可通过健康问题的refresh端点或管理后台 UI 按团队手动触发。用户如何看到并应用建议设置页 BannerPathCleaningSuggestionsBanner挂在/settings/project#path_cleaning即 PathCleaningSuggestionsBanner.tsx显示最新一条suggested规则为regex → alias预览并附匹配数groups N of your top M pathsApply all 仅限项目管理员前端通过useRestrictedArea镜像后端的管理员门槛关闭按钮执行 dismiss。Preview on your paths 打开模态框展示最近 30 天最常访问路径、按顺序应用全部建议规则的 before/after 与浏览量。驱动这一切的是 pathCleaningSuggestionsLogic.ts该 kea logic 通过健康问题 APIkindpath_cleaning_suggestionsstatusactivedismissedfalse拉取建议并做乐观隐藏apply/dismiss 即刻隐藏、失败回滚、应用中的按钮禁用、以及切换项目时重置状态防止用旧 issue id 操作新项目。Onboarding 步骤OnboardingWebAnalyticsPathCleaningStepstepKeypath_cleaningOnboardingWebAnalyticsPathCleaningStep.tsx在 Web 分析引导流程中呈现同样的 Banner。REST API专用端点位于 web_analytics_path_cleaning_suggestions.py列表与忽略则走通用健康问题 APIPOST /api/projects/:id/web_analytics_path_cleaning_suggestions/generate/ GET /api/projects/:id/web_analytics_path_cleaning_suggestions/{issue_id}/preview/ POST /api/projects/:id/web_analytics_path_cleaning_suggestions/{issue_id}/apply/ GET /api/projects/:id/health_issues/?kindpath_cleaning_suggestionsstatusactivedismissedfalse PATCH /api/projects/:id/health_issues/{id}/ # body: {dismissed: true}generate按需采样、调 LLM、校验并存储为全新建议替换之前的活跃建议即使团队已有规则也会执行include_configuredTrue需要web_analytics:write作用域且受特性开关web-analytics-path-cleaning-suggestions门控——这是三个动词中唯一会花钱ClickHouse 采样 LLM 调用的因此额外加了 dogfooding 开关与AIBurstRateThrottle/AISustainedRateThrottle限流preview 每次请求也会重新采样 ClickHouse同样限流preview把建议规则按 order 顺序前一条输出喂给下一条与 ClickHouse 应用已配置规则的语义完全一致见 preview_rules_on_team应用到最新采样路径返回最多 20 条发生变化的 before/after 对及changed_path_count只读作用域、按需计算、永不存储——这是 Banner Preview on your paths 模态框的数据来源apply合并规则并 resolve 底层健康问题同一事务内完成避免 resolve 失败导致 Banner 再次出现Apply all重复应用已合并的规则仅限项目管理员——与团队 API 对path_cleaning_filters的写入门槛一致防止借该端点绕过。健康页与 PostHog AIMax检查渲染在/web/health与其它 web-analytics 检查并列附带人类与 Agent 的修复指引generate/apply 已作为 MCP 工具暴露在 tools.yamlweb-analytics-path-cleaning-suggestions-generate/-applypreview 默认enabled: false用户可直接对话式地让 Max 建议并应用清理规则。apply 被标记为destructive会改变历史图表数字因此触发 MCP 确认门槛generate 则要求requires_ai_consent: true并同样挂在特性开关下。审阅建议数据形态与隐私边界读取某团队当前活跃建议SKILL.md 给出的示例HealthIssue.objects.filter(team_idteam_id, kindpath_cleaning_suggestions, statusactive).first()payload[rules]中的每条规则携带四个字段见 API 序列化器与build_suggestion_payload字段含义regexre2 模式匹配动态路径段alias替换串使用id、uuid、slug、date、locale等尖括号占位符保持可读order应用顺序规则串行执行、前一条输出喂给下一条最具体的在前、最通用的兜底在后match_count改写了多少条真实采样路径——这是规则曾在真实流量上验证过的证据这四字段就是呈现给人类决策者判断是否应用的内容。真实路径上的 before/after 示例只在管理命令生成时打印刻意排除在存储 payload 之外——原因如前所述健康问题 payload 只需health_issue:read即可读取不能泄漏团队事件数据。提示工程如何让 LLM 产出高质量规则prompts.py 中的 SYSTEM_PROMPT 是规则质量的源头其约束本身就值得作为路径清理规则编写规范复用每条规则是regexGoogle re2 语法不要转义/alias替换串推荐尖括号占位符id、uuid、slug、date、locale捕获组反向引用\1虽被查询层支持但求值更慢不要使用仅在段必须位于路径开头时用^锚定用$或(/|$)收尾防止\d这类通用规则把路径中间的任意数字串也吞掉顺序即语义规则顺序应用、输出喂给下一条因此最具体在前、最通用catch-all在后通用规则永远不能吞掉应由具体规则处理的路径只针对样本中真实存在的模式提规则宁要 3–10 条强规则不要一堆猜测性规则路径本来就干净时返回空列表输出严格限定为单一 JSON 对象无任何散文形状为{rules: [{regex: ..., alias: ..., reason: ...}]}。扩展与定制新增一个展示渠道站内通知、设置 Banner、引导步骤读取团队活跃的path_cleaning_suggestions健康问题并渲染其payload[rules]保持 apply 为手动操作即可。更换模型必须先在 llm-gateway 产品配置 中把模型加入web_analytics产品白名单再通过WEB_ANALYTICS_PATH_CLEANING_SUGGESTIONS_MODEL环境变量切换。Agent 化替代方案设计笔记中勾勒了一个signals-scout-web-analytics-path-cleaningscout 的代理方案但针对 precompute cohort 应优先使用本专用任务因为它精确命中该 cohort并产出结构化、经过校验的行而非 Signals 收件箱式的结果。小结PostHog 的路径清理规则建议系统是一个典型的AI 生成 确定性校验 人类确认闭环HogQL 采样真实路径 → LLM 一次性生成候选规则 → re2 编译并在真实路径上测试应用 → 只把通过校验的规则含 order、match_count以健康问题形式存储 → 通过设置页 Banner、Onboarding、健康页与 MCP 工具呈现给用户由管理员决定是否一键应用。其核心工程取舍——空生成不落库、示例与 reason 不入 payload、select_for_update合并、空转批次控制——都值得在同类AI 建议型功能中借鉴。赞分享数据分析后端前端数据可视化大数据【免费下载链接】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点击查看免费下载相关推荐PostHog 路径清洗规则Path Cleaning Rules实战指南用 re2 正则与 MCP 工具驯服海量 URL 路径PostHog 路径清洗规则Path Cleaning Rules实战指南用 re2 正则与 MCP 工具驯服海量 URL 路径 路径清洗规则Path数据分析后端前端数据可视化大数据PostHog MCP Tools 实现指南从 YAML 定义到代码生成的完整流水线PostHog MCP Tools 实现指南从 YAML 定义到代码生成的完整流水线 MCP tools 是 PostHog 中面向 AI Agent 的原子数据分析后端前端数据可视化大数据最完整贝塞尔曲线实战指南从路径规划到无人机轨迹生成最完整贝塞尔曲线实战指南从路径规划到无人机轨迹生成 你还在为路径规划算法生成的轨迹不平滑而烦恼吗 在自动驾驶Autonomous Driving和移动机示例工程上一篇Ollama构建缓存优化CMake与Go编译加速终极指南下一篇Obsidian终极美化指南20个免费CSS片段让你的知识库焕然一新创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考