PostHog Data Warehouse 数据源文档规范化指南模板、共享 Snippet 与 docsUrl/slug 防 404 规则【免费下载链接】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 仓库中 documenting-warehouse-sources 技能文档 为核心系统讲解如何为 PostHog Data warehouse 导入源编写或更新用户可见文档。你将掌握标准文档模板与 frontmatter 规范、SourceParameters //SourceTables /组件的自动渲染机制、共享 Snippet 的复用方法以及让文件名、docsUrl、slug 三者对齐以避免 404 的审计命令与实操流程并了解修复代码而非文档的单一事实来源原则。文档放在哪里posthog.com 仓库而非本仓库首先需要明确一个关键边界面向用户的 Data warehouse source 文档存放在 posthog.com 仓库中不在当前 posthog 仓库固定路径为contents/docs/cdp/sources/slug.md该文件会同时发布到两个 URL 路径下/docs/cdp/sources/slug与/docs/data-warehouse/sources/slug。这一约定使旧版 Data warehouse 文档路径与新版 CDP 路径共享同一份内容避免双份维护。技能文档要求假设本地存在一个并行的 posthog.com checkout例如../posthog.com。撰写过程中应将其与.agents/skills/implementing-warehouse-sources/技能配合使用——前者负责写文档后者负责实现 source二者是一套完整工作流的两半documenting-warehouse-sources/SKILL.md决定每份 source 文档必须遵循的唯一形态implementing-warehouse-sources/新增 source 时从代码侧实现含lists_tables_without_credentials等代码约定。由于目标文档位于 posthog.com checkout 而非本仓库本文在描述这些文档及 Snippet 时给出的是 posthog.com 仓库内的相对路径而代码侧的单一事实来源均可在当前仓库中直接定位到精确文件。网站替你渲染的两件事SourceParameters 与 SourceTables你不需要手写连接字段或表清单——这两者都来自public_source_configsAPI该 API 在站点构建时被拉取并通过两个 MDX 组件镜像进文档SourceParameters /渲染连接/配置表单字段数据源自get_source_config.fieldsSourceTables /渲染Supported tables支持的表参考区块表名、描述、同步方式、增量字段、主键数据源自该 source 的get_documented_tables()。SourceTables /何时有数据lists_tables_without_credentialsSourceTables /只有在 source 类上显式开启lists_tables_without_credentials True时才渲染真实表清单。该选项仅当get_schemas遍历的是静态的 endpoint 目录、不产生任何 I/O时才是合法的详细代码约定见 implementing-warehouse-sources 技能。否则组件会渲染一段通用的将从你的账户中发现表的说明文字。修复文档中的表格问题的正确姿势如果渲染出来的表清单为空或描述过于单薄且该 source 是固定 schema 类型那么应当修复 source 代码settings.py中的 endpoints 与canonical_descriptions.py而不是改文档——文档只是渲染 API 的返回结果因此代码始终是单一事实来源single source of truth。从当前仓库的目录布局可以印证这套约定。每个 provider 以独立包的形式位于 sources 目录下典型包含settings.pyendpoint 目录配置、canonical_descriptions.py表与字段的标准描述、source.pysource 类实现以及tests/。以 ActiveCampaign 为例settings.py 用ActiveCampaignEndpointConfig数据类描述每个 endpoint 的 API 路径、响应体顶层data_selector、分区键partition_key与额外查询参数dataclass class ActiveCampaignEndpointConfig: name: str # Path under /api/3 (e.g. /contacts). path: str # Top-level key the list of records lives under in the response body data_selector: str # Stable created-date field to partition by, or None to skip partitioning. partition_key: Optional[str] None # Extra query params merged into every request for this endpoint. extra_params: dict[str, str] field(default_factorydict)文档中支持的表即来源于这些settings.py的 endpoints 定义与canonical_descriptions.py中的描述文本这正是要改表清单就改代码的落点。这些 source 是如何被发现的public_source_configs背后是源码侧的注册机制。当前仓库 sources/init.py 中的load_all_sources()会逐个导入每个 source 模块使各模块内的SourceRegistry.register装饰器完成注册为保证健壮性若整体批量导入因某个 source 模块异常而中断还会退化为逐个模块单独导入避免一个坏模块拖垮整个 source UI。SourceRegistry本体定义在 sources/common/registry.py而ExternalDataSourceType枚举位于 backend/types.py。这也解释了为何文档的sourceId必须是真实的ExternalDataSourceType值——它是连接文档与 API 配置图标、字段、表的关键键。Frontmatter 规范sourceId 是文档与代码的锚点每份 source 文档开头都必须带如下 frontmatter--- title: Linking Source as a source sidebar: Docs showTitle: true availability: { free: full, selfServe: full, enterprise: full } sourceId: EnumValue # MUST equal the ExternalDataSourceType value, e.g. ActiveCampaign, Stripe beta: true # optional — only for beta sources ---字段说明字段必填说明title是页面标题规范格式为Linking Source as a sourcesidebar是固定为DocsshowTitle是固定为trueavailability是各套餐可用性如{ free: full, selfServe: full, enterprise: full }sourceId是必须与ExternalDataSourceType枚举值完全一致PascalCase例如ActiveCampaign而非Active Campaignbeta否仅 beta source 需要设为true并配合 beta 状态片段sourceId是文档与其 API 配置图标、字段、表之间的链接键。一旦写错文档渲染出来将没有任何SourceParameters //SourceTables /数据——因此它必须是一个真实的ExternalDataSourceType值PascalCase例如ActiveCampaign不能写成Active Campaign。该枚举在 backend/types.py 中定义审计命令见下文正是用它对每份文档的 frontmatter 做校验。标准模板Canonical Template每份 source 文档都应遵循下列统一骨架--- title: Linking Source as a source sidebar: Docs showTitle: true availability: { free: full, selfServe: full, enterprise: full } sourceId: EnumValue --- import SourceSetupIntro from ../_snippets/source-setup-intro.mdx import SyncModes from ../_snippets/sync-modes.mdx import TroubleshootingLink from ../_snippets/dw-troubleshooting-link.mdx !-- Alpha/beta only: import AlphaRelease from ../_snippets/alpha-release.mdx and render AlphaRelease / here -- One or two sentences: what this connector syncs and the typical use case. ## Prerequisites Account tier / admin rights / API access the user needs before they can connect. ## Adding a data source SourceSetupIntro / List the specific credentials this source needs and exactly where to get them (link to the providers dashboard). For sources with more than one auth method, use ### subsections (mirror Stripes Option 1 / Option 2). ## Sync modes SyncModes / Add any source-specific recommendation here (e.g. use webhooks for Stripe). ## Configuration SourceParameters / ## Supported tables SourceTables / ## Troubleshooting Source-specific errors and fixes (optional but encouraged), then: TroubleshootingLink /每个 source 的必备章节Essential sections必须按顺序出现的章节为状态横幅仅 alpha/beta→ 简介intro→ Prerequisites前置条件→ Adding a data source添加数据源→ Sync modes同步模式→ Configuration配置→ Supported tables支持的表→ Troubleshooting故障排查各部分职责Intro一至两句话说明该连接器同步什么数据、典型使用场景是什么Prerequisites用户连接前所需的账户层级/管理员权限/API 访问权Adding a data source渲染SourceSetupIntro /随后列出该 source 需要的具体凭据以及在哪里获取指向服务商控制台。若一个 source 有不止一种认证方式用###子章节区分参考 Stripe 的 Option 1 / Option 2 写法Sync modes渲染SyncModes /可追加 source 专属建议例如Stripe 建议使用 webhooksConfiguration渲染SourceParameters /Supported tables渲染SourceTables /Troubleshooting先列 source 专属的错误与修复方案可选但鼓励最后渲染TroubleshootingLink /作为收尾。可选章节Optional sections仅当实际适用时才添加不要为不需要的 source 发明章节Webhooks实时同步CDC数据库类 sourceColumn selection列选择Row filters行过滤Inbound IP addresses用InboundIpAddresses /渲染 IP 白名单表data-type handling数据类型处理Known limitations已知限制ERD/relationships实体关系图文档指出仓库中已有可参照的实现范例StripeSaaS webhooks、Postgres数据库 CDC、ClickHouse数据库。这些 source 包均位于 sources 目录下是撰写各类 source 文档时最直接的对照样本。共享 Snippet避免重复手写大段文案所有 source 文档应优先复用共享片段位于 posthog.com 仓库的contents/docs/cdp/_snippets/下而不是各自重新撰写相同文字Snippet用途source-setup-intro.mdx标准的 Adding a data source 步骤sync-modes.mdx同步模式摘要并链接到权威解释页alpha-release.mdx/beta-release.mdx状态横幅同时需在 frontmatter 中设置beta: truedw-troubleshooting-link.mdx故障排查/支持页脚inbound-ip-addresses.mdx数据库类 source 的 IP 允许清单表格feedback-questions.mdx反馈/FAQ 页脚关于文件扩展名与全局组件.md后缀的 source 文档同样支持 MDXimport语法例如convex.md、mongodb.md因此无需把文件改名为.mdx也能使用 Snippet——当然保留.mdx扩展名也完全可行。而CalloutBox、ProductScreenshot、SourceParameters、SourceTables是全局组件无需 import 即可直接使用。docsUrl / slug 一致性规则防 404 的关键网站会从 source 的docsUrl其最后一个/docs/cdp/sources/slug路径段推导出文档 slug因此以下三者必须一致文档文件名slug.mdget_source_config中的docsUrlhttps://posthog.com/docs/cdp/sources/slug隐式列表链接现已改为从docsUrl推导因此会自动跟随。多词 slug 必须使用kebab-case如active-campaign而不是activecampaign。与之对照的是当前仓库源码目录使用的是 snake_case如active_campaign文档发布态与代码命名约定不同撰写时注意不要混淆。运行审计命令写完或重命名文档后在当前posthog仓库运行审计命令对并行的 posthog.com checkout 执行校验python manage.py audit_source_docs --docs-dir ../posthog.com/contents/docs/cdp/sources该命令的实现位于 audit_source_docs.py其逻辑可以印证 SKILL.md 中描述的两条硬性校验docsUrl 必须能解析到已提交的文档文件audit_source_docs.py#L44-L54命令用正则DOCS_URL_SLUG re.compile(r/docs/cdp/sources/([^/?#]))提取每个已注册 source 的docsUrl中的 slug再与--docs-dir下所有.md/.mdx文件主名求交集——若某 source 的docsUrl指向不存在的文件即报错每份文档的sourceId必须是真实 sourceaudit_source_docs.py#L56-L64命令解析每份文档的 frontmatter校验sourceId是否落在{str(member.value) for member in ExternalDataSourceType}来自 backend/types.py集合内否则报错。命令的任何不匹配都会以非零状态退出raise CommandError(...)因此可以作为 CI gate 卡住docs/source 实现相关的工作流全部通过时则输出OK: N source docs consistent with the registry。此外若重命名一份已发布的文档还需要在posthog.com/vercel.json中同时为/docs/cdp/sources/*与/docs/data-warehouse/sources/*两条路径配置 301 重定向确保旧书签与外部链接不失效。交付前 Checklist技能文档给出了每次交付前应逐项确认的清单可直接作为 PR 前的自查项Frontmatter 的sourceId与ExternalDataSourceType值完全一致已包含必备章节Intro、Prerequisites、Adding a data source、Sync modes、Configuration、Supported tables、Troubleshooting若为 alpha/beta 状态已引入状态 Snippet 并设置beta: true使用共享 Snippet 而非自行撰写大段重复文案已放置SourceParameters /与SourceTables /不要手写字段或表清单若渲染出的表清单为空/过薄且该 source 为固定 schema应充实其代码lists_tables_without_credentials、settings.py、canonical_descriptions.py参考 implementing-warehouse-sources 技能文件名、docsUrl、slug 三者一致kebab-caseaudit_source_docs校验通过小结PostHog Data warehouse source 文档的本质是代码即事实、文档即渲染文档只是public_source_configsAPI 返回内容的 MDX 视图模板与 Snippet 保证每份 source 文档结构一致而sourceIddocsUrl/slug 三对齐规则 audit_source_docs审计命令则确保文档与代码注册表永不脱节。遵循本指南与 SKILL.md 中的模板配合 implementing-warehouse-sources 技能实现代码即可稳定交付结构统一、信息准确、不会出现 404 的 source 文档。【免费下载链接】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），仅供参考
PostHog Data Warehouse 数据源文档规范化指南：模板、共享 Snippet 与 docsUrl/slug 防 404 规则
PostHog Data Warehouse 数据源文档规范化指南模板、共享 Snippet 与 docsUrl/slug 防 404 规则【免费下载链接】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 仓库中 documenting-warehouse-sources 技能文档 为核心系统讲解如何为 PostHog Data warehouse 导入源编写或更新用户可见文档。你将掌握标准文档模板与 frontmatter 规范、SourceParameters //SourceTables /组件的自动渲染机制、共享 Snippet 的复用方法以及让文件名、docsUrl、slug 三者对齐以避免 404 的审计命令与实操流程并了解修复代码而非文档的单一事实来源原则。文档放在哪里posthog.com 仓库而非本仓库首先需要明确一个关键边界面向用户的 Data warehouse source 文档存放在 posthog.com 仓库中不在当前 posthog 仓库固定路径为contents/docs/cdp/sources/slug.md该文件会同时发布到两个 URL 路径下/docs/cdp/sources/slug与/docs/data-warehouse/sources/slug。这一约定使旧版 Data warehouse 文档路径与新版 CDP 路径共享同一份内容避免双份维护。技能文档要求假设本地存在一个并行的 posthog.com checkout例如../posthog.com。撰写过程中应将其与.agents/skills/implementing-warehouse-sources/技能配合使用——前者负责写文档后者负责实现 source二者是一套完整工作流的两半documenting-warehouse-sources/SKILL.md决定每份 source 文档必须遵循的唯一形态implementing-warehouse-sources/新增 source 时从代码侧实现含lists_tables_without_credentials等代码约定。由于目标文档位于 posthog.com checkout 而非本仓库本文在描述这些文档及 Snippet 时给出的是 posthog.com 仓库内的相对路径而代码侧的单一事实来源均可在当前仓库中直接定位到精确文件。网站替你渲染的两件事SourceParameters 与 SourceTables你不需要手写连接字段或表清单——这两者都来自public_source_configsAPI该 API 在站点构建时被拉取并通过两个 MDX 组件镜像进文档SourceParameters /渲染连接/配置表单字段数据源自get_source_config.fieldsSourceTables /渲染Supported tables支持的表参考区块表名、描述、同步方式、增量字段、主键数据源自该 source 的get_documented_tables()。SourceTables /何时有数据lists_tables_without_credentialsSourceTables /只有在 source 类上显式开启lists_tables_without_credentials True时才渲染真实表清单。该选项仅当get_schemas遍历的是静态的 endpoint 目录、不产生任何 I/O时才是合法的详细代码约定见 implementing-warehouse-sources 技能。否则组件会渲染一段通用的将从你的账户中发现表的说明文字。修复文档中的表格问题的正确姿势如果渲染出来的表清单为空或描述过于单薄且该 source 是固定 schema 类型那么应当修复 source 代码settings.py中的 endpoints 与canonical_descriptions.py而不是改文档——文档只是渲染 API 的返回结果因此代码始终是单一事实来源single source of truth。从当前仓库的目录布局可以印证这套约定。每个 provider 以独立包的形式位于 sources 目录下典型包含settings.pyendpoint 目录配置、canonical_descriptions.py表与字段的标准描述、source.pysource 类实现以及tests/。以 ActiveCampaign 为例settings.py 用ActiveCampaignEndpointConfig数据类描述每个 endpoint 的 API 路径、响应体顶层data_selector、分区键partition_key与额外查询参数dataclass class ActiveCampaignEndpointConfig: name: str # Path under /api/3 (e.g. /contacts). path: str # Top-level key the list of records lives under in the response body data_selector: str # Stable created-date field to partition by, or None to skip partitioning. partition_key: Optional[str] None # Extra query params merged into every request for this endpoint. extra_params: dict[str, str] field(default_factorydict)文档中支持的表即来源于这些settings.py的 endpoints 定义与canonical_descriptions.py中的描述文本这正是要改表清单就改代码的落点。这些 source 是如何被发现的public_source_configs背后是源码侧的注册机制。当前仓库 sources/init.py 中的load_all_sources()会逐个导入每个 source 模块使各模块内的SourceRegistry.register装饰器完成注册为保证健壮性若整体批量导入因某个 source 模块异常而中断还会退化为逐个模块单独导入避免一个坏模块拖垮整个 source UI。SourceRegistry本体定义在 sources/common/registry.py而ExternalDataSourceType枚举位于 backend/types.py。这也解释了为何文档的sourceId必须是真实的ExternalDataSourceType值——它是连接文档与 API 配置图标、字段、表的关键键。Frontmatter 规范sourceId 是文档与代码的锚点每份 source 文档开头都必须带如下 frontmatter--- title: Linking Source as a source sidebar: Docs showTitle: true availability: { free: full, selfServe: full, enterprise: full } sourceId: EnumValue # MUST equal the ExternalDataSourceType value, e.g. ActiveCampaign, Stripe beta: true # optional — only for beta sources ---字段说明字段必填说明title是页面标题规范格式为Linking Source as a sourcesidebar是固定为DocsshowTitle是固定为trueavailability是各套餐可用性如{ free: full, selfServe: full, enterprise: full }sourceId是必须与ExternalDataSourceType枚举值完全一致PascalCase例如ActiveCampaign而非Active Campaignbeta否仅 beta source 需要设为true并配合 beta 状态片段sourceId是文档与其 API 配置图标、字段、表之间的链接键。一旦写错文档渲染出来将没有任何SourceParameters //SourceTables /数据——因此它必须是一个真实的ExternalDataSourceType值PascalCase例如ActiveCampaign不能写成Active Campaign。该枚举在 backend/types.py 中定义审计命令见下文正是用它对每份文档的 frontmatter 做校验。标准模板Canonical Template每份 source 文档都应遵循下列统一骨架--- title: Linking Source as a source sidebar: Docs showTitle: true availability: { free: full, selfServe: full, enterprise: full } sourceId: EnumValue --- import SourceSetupIntro from ../_snippets/source-setup-intro.mdx import SyncModes from ../_snippets/sync-modes.mdx import TroubleshootingLink from ../_snippets/dw-troubleshooting-link.mdx !-- Alpha/beta only: import AlphaRelease from ../_snippets/alpha-release.mdx and render AlphaRelease / here -- One or two sentences: what this connector syncs and the typical use case. ## Prerequisites Account tier / admin rights / API access the user needs before they can connect. ## Adding a data source SourceSetupIntro / List the specific credentials this source needs and exactly where to get them (link to the providers dashboard). For sources with more than one auth method, use ### subsections (mirror Stripes Option 1 / Option 2). ## Sync modes SyncModes / Add any source-specific recommendation here (e.g. use webhooks for Stripe). ## Configuration SourceParameters / ## Supported tables SourceTables / ## Troubleshooting Source-specific errors and fixes (optional but encouraged), then: TroubleshootingLink /每个 source 的必备章节Essential sections必须按顺序出现的章节为状态横幅仅 alpha/beta→ 简介intro→ Prerequisites前置条件→ Adding a data source添加数据源→ Sync modes同步模式→ Configuration配置→ Supported tables支持的表→ Troubleshooting故障排查各部分职责Intro一至两句话说明该连接器同步什么数据、典型使用场景是什么Prerequisites用户连接前所需的账户层级/管理员权限/API 访问权Adding a data source渲染SourceSetupIntro /随后列出该 source 需要的具体凭据以及在哪里获取指向服务商控制台。若一个 source 有不止一种认证方式用###子章节区分参考 Stripe 的 Option 1 / Option 2 写法Sync modes渲染SyncModes /可追加 source 专属建议例如Stripe 建议使用 webhooksConfiguration渲染SourceParameters /Supported tables渲染SourceTables /Troubleshooting先列 source 专属的错误与修复方案可选但鼓励最后渲染TroubleshootingLink /作为收尾。可选章节Optional sections仅当实际适用时才添加不要为不需要的 source 发明章节Webhooks实时同步CDC数据库类 sourceColumn selection列选择Row filters行过滤Inbound IP addresses用InboundIpAddresses /渲染 IP 白名单表data-type handling数据类型处理Known limitations已知限制ERD/relationships实体关系图文档指出仓库中已有可参照的实现范例StripeSaaS webhooks、Postgres数据库 CDC、ClickHouse数据库。这些 source 包均位于 sources 目录下是撰写各类 source 文档时最直接的对照样本。共享 Snippet避免重复手写大段文案所有 source 文档应优先复用共享片段位于 posthog.com 仓库的contents/docs/cdp/_snippets/下而不是各自重新撰写相同文字Snippet用途source-setup-intro.mdx标准的 Adding a data source 步骤sync-modes.mdx同步模式摘要并链接到权威解释页alpha-release.mdx/beta-release.mdx状态横幅同时需在 frontmatter 中设置beta: truedw-troubleshooting-link.mdx故障排查/支持页脚inbound-ip-addresses.mdx数据库类 source 的 IP 允许清单表格feedback-questions.mdx反馈/FAQ 页脚关于文件扩展名与全局组件.md后缀的 source 文档同样支持 MDXimport语法例如convex.md、mongodb.md因此无需把文件改名为.mdx也能使用 Snippet——当然保留.mdx扩展名也完全可行。而CalloutBox、ProductScreenshot、SourceParameters、SourceTables是全局组件无需 import 即可直接使用。docsUrl / slug 一致性规则防 404 的关键网站会从 source 的docsUrl其最后一个/docs/cdp/sources/slug路径段推导出文档 slug因此以下三者必须一致文档文件名slug.mdget_source_config中的docsUrlhttps://posthog.com/docs/cdp/sources/slug隐式列表链接现已改为从docsUrl推导因此会自动跟随。多词 slug 必须使用kebab-case如active-campaign而不是activecampaign。与之对照的是当前仓库源码目录使用的是 snake_case如active_campaign文档发布态与代码命名约定不同撰写时注意不要混淆。运行审计命令写完或重命名文档后在当前posthog仓库运行审计命令对并行的 posthog.com checkout 执行校验python manage.py audit_source_docs --docs-dir ../posthog.com/contents/docs/cdp/sources该命令的实现位于 audit_source_docs.py其逻辑可以印证 SKILL.md 中描述的两条硬性校验docsUrl 必须能解析到已提交的文档文件audit_source_docs.py#L44-L54命令用正则DOCS_URL_SLUG re.compile(r/docs/cdp/sources/([^/?#]))提取每个已注册 source 的docsUrl中的 slug再与--docs-dir下所有.md/.mdx文件主名求交集——若某 source 的docsUrl指向不存在的文件即报错每份文档的sourceId必须是真实 sourceaudit_source_docs.py#L56-L64命令解析每份文档的 frontmatter校验sourceId是否落在{str(member.value) for member in ExternalDataSourceType}来自 backend/types.py集合内否则报错。命令的任何不匹配都会以非零状态退出raise CommandError(...)因此可以作为 CI gate 卡住docs/source 实现相关的工作流全部通过时则输出OK: N source docs consistent with the registry。此外若重命名一份已发布的文档还需要在posthog.com/vercel.json中同时为/docs/cdp/sources/*与/docs/data-warehouse/sources/*两条路径配置 301 重定向确保旧书签与外部链接不失效。交付前 Checklist技能文档给出了每次交付前应逐项确认的清单可直接作为 PR 前的自查项Frontmatter 的sourceId与ExternalDataSourceType值完全一致已包含必备章节Intro、Prerequisites、Adding a data source、Sync modes、Configuration、Supported tables、Troubleshooting若为 alpha/beta 状态已引入状态 Snippet 并设置beta: true使用共享 Snippet 而非自行撰写大段重复文案已放置SourceParameters /与SourceTables /不要手写字段或表清单若渲染出的表清单为空/过薄且该 source 为固定 schema应充实其代码lists_tables_without_credentials、settings.py、canonical_descriptions.py参考 implementing-warehouse-sources 技能文件名、docsUrl、slug 三者一致kebab-caseaudit_source_docs校验通过小结PostHog Data warehouse source 文档的本质是代码即事实、文档即渲染文档只是public_source_configsAPI 返回内容的 MDX 视图模板与 Snippet 保证每份 source 文档结构一致而sourceIddocsUrl/slug 三对齐规则 audit_source_docs审计命令则确保文档与代码注册表永不脱节。遵循本指南与 SKILL.md 中的模板配合 implementing-warehouse-sources 技能实现代码即可稳定交付结构统一、信息准确、不会出现 404 的 source 文档。【免费下载链接】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），仅供参考