我们愈是学习，愈觉得自己的贫乏。——雪莱

PostHog：一套把产品、数据、Agent 和修复动作串起来的平台

有些产品像工具箱，打开以后是一格一格摆好的能力；有些产品更像控制台，坐上去之后，面前是一整套能观测、判断、行动、再验证的系统。PostHog 更接近后者。

它把自己的定位说得很直接：PostHog is the open source platform for building self-driving products。这句话里最醒目的，不只是“open source platform”，更是“self-driving products”。它显然不满足于做一个只记录数据的地方，而是试图把产品信号、诊断能力、自动化动作，以及 Agent 所需要的上下文，统统编织进一张更大的网里。

项目地址：https://github.com/PostHog/posthog

它想做的，不只是分析产品，而是让产品自己更会“开车”

PostHog 在 description 里的表述非常有辨识度：它是一个用于构建 self-driving products 的领先平台。它列出的开发者工具包括：

AI observability
analytics
session replay
flags
experiments
error tracking
logs
以及更多能力

这些工具并不是各自孤立摆放的。README 中对整体方向的描述非常明确：它们共同承担一件事——捕获 Agent 诊断问题、发现机会、交付修复所需要的全部上下文。

这意味着 PostHog 的视角，并不只停留在“发生了什么”，而是更进一步，想把“为什么发生”“接下来该怎么处理”“谁来推动下一步”也一起拉进来。于是，它看起来就不只是一个数据平台，而像一位始终盯着仪表盘、也准备好随时出手的驾驶辅助系统。

一张能力清单，像一整套产品操作系统

README 里列出的能力非常丰富，而且覆盖的范围很广。从中最容易感受到的一点是：PostHog 不是只想解决一个局部问题，而是在尝试搭建一套围绕产品构建、观察和优化的完整工作面。

Self-driving mode

README 对这一点的描述很有画面感：它可以把产品数据中的信号——比如错误、rage clicks、失败查询等等——变成经过研究的报告和供你审核的 pull requests。

这是一种很特别的表述。它并不是停在“发现异常”这一步，而是把信号继续往前推进，直到形成可以被审阅的改动建议。也就是说，从异常，到分析，到交付候选修复，它试图把链路尽量拉直。

Product analytics

PostHog 支持通过自动采集或手动埋点的方式，进行基于事件的产品分析，以便理解用户行为，并通过可视化或 SQL 来分析数据。

这部分能力提供的是产品理解的底座。它像是系统里的感知层，让团队知道用户做了什么、路径如何变化、行为模式如何展开。

Web analytics

它也提供 Web analytics，用于监控网站流量和用户会话，并给出类似 GA 的仪表盘，还能关注 conversion、web vitals 和 revenue。

这说明 PostHog 并没有把“产品行为”和“网站行为”割裂开来，而是把它们都纳入同一张观察视野中。

Session replays

它支持观看真实用户的会话回放，用来诊断问题并理解用户行为。这种能力像是把抽象的数据重新变回现场，让“发生了某个事件”不只是数字，而重新带上时间流动与交互动作。

Feature flags

通过 feature flags，可以把功能安全地逐步发布给指定用户或 cohort。这个能力在现代产品迭代里已经非常关键，而 PostHog 把它自然纳入整体体系中，让“观察”和“控制”出现在同一个平台里。

Experiments

它支持 experiments，用来测试改动，并测量其对目标指标的统计影响，同时还支持 no-code 的实验设置方式。这样一来，产品变更不只是拍脑袋试一试，而是有机会在更可验证的框架里推进。

Error tracking

它提供错误跟踪、告警以及问题解决能力。这里的关键词很朴素，却很核心：追踪、提醒、处理。问题不是只被记录，而是被纳入一个可以响应的系统。

Logs

它还能摄入、搜索和分析日志数据，并且把日志与其他产品数据放在一起看。这样带来的好处非常直接：日志不再孤零零地躺在另一个角落，而可以与行为、错误、回放、实验结果放在同一个分析上下文里。

Surveys

它支持使用无代码模板发起问卷，也支持用 survey builder 构建自定义调查。于是，用户表达不再只通过点击和停留时间被推测，也可以被直接询问。

Data warehouse

它支持从 Stripe、Hubspot、你的 data warehouse 等外部工具同步数据，并与产品数据一起查询。这种能力让 PostHog 不只是“产品内部事件”的记录者，也开始接触更广的业务上下文。

Data pipelines

它支持对传入数据进行自定义过滤与转换，并把数据实时或批量发送到 25+ 工具或任意 webhook，也可以大批量导出到 warehouse。数据在这里不是只被存储，而是被调度、整理、再分发。

AI observability

README 明确提到，它可以为 LLM-powered app 捕获 traces、generations、latency 和 cost。这个方向非常鲜明：当 AI 成为产品的一部分，观测层也必须随之进入新的维度。

Workflows

它还支持创建 workflows，用于自动化操作或向用户发送消息。到这里，PostHog 的整体轮廓已经很清楚了：从采集，到观察，到分析，到控制，到自动化，它试图把很多原本分散在不同系统中的能力，组织成一个连续的动作链。

不只是工具集合，它更像一套上下文引擎

README 中最值得回味的一句话，是它强调这些工具会捕获所有 Agent 需要的上下文。这实际上给 PostHog 的整个产品哲学定了基调。

单独看 analytics、replay、flags、experiments、logs、error tracking，每一项都不陌生。但当它们被组织在“给 Agent 足够上下文”这个目标下时，味道就不一样了。PostHog 不只是想做“数据可见”，而是想做“问题可诊断、机会可识别、修复可交付”。

这种组合方式，让它不再只是一个观察产品的窗口，而像是一个为后续动作持续输送情报的中枢。

控制入口也很多：Slack、Web、桌面端、MCP

PostHog 还特别强调了一点：这些能力可以从多个入口统一操控，包括：

Slack
web
desktop
MCP
你自己的编辑器

这部分信息很关键。它说明 PostHog 并不要求用户必须待在单一界面里，而是允许在团队已经熟悉的协作环境、可视化入口、桌面工具乃至编辑器上下文中使用这些能力。它不是只想成为一个网页应用，而更像一个可以被多种界面“驾驶”的后台系统。

从开始使用的路径上看，它把“上手速度”和“部署自由度”都摆出来了

README 对 Getting started 的安排很清晰，首先推荐的是 PostHog Cloud。它把 Cloud 版本称为最快、最可靠的入门方式，并分别提供了 US 与 EU 的云端入口。

这种写法本身就说明，项目希望尽量降低使用门槛。如果你想快速开始，最推荐的路已经摆在前面。

不过它也同时保留了另一条路线：self-hosting the open-source hobby deploy。对于希望自行部署的用户，README 给出了一行 Linux + Docker 的部署命令：

1	/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/posthog/posthog/HEAD/bin/deploy-hobby)"

README 还补充了一个边界条件：开源部署大约可以扩展到每月 100k events，再往上则推荐迁移到 PostHog Cloud。这个信息很实在，它没有把自托管描绘成无限延展的万能选项，而是明确给出一个大致的规模参考。

配置方式：拿到实例之后，就可以接进产品里

在 Setting up PostHog 这一节，README 说明了实例准备好之后的使用方式：你可以通过安装 JavaScript web snippet，或者使用各类 SDK，把 PostHog 接入自己的产品。

它列出的 SDK 覆盖了前端、移动端和后端多个方向。

Frontend

JavaScript
Next.js
React
Vue

Mobile

React Native
Android
iOS
Flutter

Backend

Python
Node
PHP
Ruby

除此之外，README 还提到有 Go、.NET/C#、Django、Angular 等方向的文档和指南。这个列表带来的感觉非常直接：PostHog 并不把自己限制在某一类技术栈里，而是努力把入口铺到常见开发生态中。

开源的不只是代码，还有很多“怎么做事”的部分

README 里有一段很有个性的描述：Our code isn’t the only thing that’s open source 😳。它提到 PostHog 还开源了公司的 handbook，其中包含它们的 strategy 等内容。

这让整个项目多了一层很独特的气质。它不是只把仓库打开，而是连一部分组织层面的思考也公开出来。这种做法让 “open source” 在这里显得不仅仅是许可证意义上的开放，也像是一种更完整的公开协作姿态。

贡献入口也写得很明白

对于想参与项目的人，README 提供了几条很清晰的路径：

在 roadmap 上给功能投票或提前体验 beta 功能
提交 PR，并查看本地开发说明
提交 feature request 或 bug report

它还特别指出，如果想了解代码库结构，可以查看：

docs/internal/monorepo-layout.md
products/README.md

这两条信息很有意思，因为它们说明 PostHog 自己也承认：这是一个需要结构化理解的代码库。它不是那种一眼就能扫完的轻量仓库，而是一个有 monorepo 布局、有产品分层的更大体系。

开源与付费边界，在 README 中也说明了

README 提到，这个仓库在许可上有明确边界：仓库本身使用 MIT expat license，但 ee 目录有单独的许可。与此同时，如果需要绝对 100% FOSS 的版本，还可以看 posthog-foss 仓库，它被描述为移除了所有专有代码和功能的版本。

这一段信息很重要，因为它直接给出了项目在开源与商业化之间的组织方式：哪些内容在这个仓库里、哪些内容有额外许可、如果只想要完全 FOSS，该看哪里。它没有把这个问题藏起来，而是相当坦率地摆在 README 里。

CLI：PostHog 不只活在界面里，也活在命令行里

除了主 README，这个仓库里的 cli/README.md 也透露出很多信息。它展示了 PostHog 的另一张面孔：命令行接口。

这套 CLI 的职责包括：

通过 shell-friendly 的方式暴露 PostHog 的 MCP tool catalog
处理 error tracking 所需的 debug symbol 上传
以及更多命令行相关能力

安装方式有两种。

通过向导安装：

1	npx -y @posthog/wizard@latest cli add

或者直接全局安装：

1	npm install -g @posthog/cli@latest

从 CLI 的帮助信息中，可以看到它包含的命令有：

login
exp
sourcemap
dsym
hermes
proguard
symbol-sets
api
help

这份命令列表本身就说明，PostHog 的命令行能力并不是只做一个简单壳子，而是在错误跟踪、符号文件处理、Agent-first API 使用等方面都铺开了接口。

CLI 里的“Agent-first”味道尤其明显

cli/README.md 中有一部分非常值得注意，叫 Agent-first API tools。

它写到，posthog-cli api 会通过 shell-friendly 的方式暴露 PostHog 的 MCP tool catalog，面向 coding agents。文档给出的示例包括：

posthog-cli api --agent-help
posthog-cli api search feature-flag
posthog-cli api info feature-flag-get-all
posthog-cli api schema query-trends series
posthog-cli api call --json feature-flag-get-all '{"limit":5}'
posthog-cli api call --dry-run feature-flags-bulk-delete-create '{"ids":[123]}'
posthog-cli api skill list
posthog-cli api skill install audit
posthog-cli api agents-md install

这里最有意思的一点，是 PostHog 不只是让 Agent“旁观数据”，而是在 CLI 层面直接准备了面对 Agent 的工具目录、帮助信息、schema 查询、dry-run 调用，甚至连 steering instructions 的安装都考虑进去了。

Agent steering instructions

README 中还给出了安装 agent 指令到项目指令文件的命令：

1	posthog-cli api agents-md install

如果项目使用的是不同路径的指令文件，也可以指定：

1	posthog-cli api agents-md install --path path/to/AGENTS.md

这一点非常能体现 PostHog 的风格：它不只是提供能力，还认真考虑这些能力如何被 Agent 读取、如何被注入项目上下文、如何被长期维护。

关于认证、上传和并发控制，它也给出了非常实用的命令行细节

CLI README 还包含了很多相当具体的说明：

环境变量认证

推荐在 CI/CD 中通过这些环境变量认证：

POSTHOG_CLI_HOST
POSTHOG_CLI_API_KEY
POSTHOG_CLI_PROJECT_ID

并且支持通过 --dotenv-file <PATH> 加载 dotenv 风格文件。

原生调试符号上传

支持通过下面的方式上传 native debug symbols：

1	posthog-cli symbol-sets upload --directory <dir>

它说明该命令可处理 Linux 的 ELF，以及 macOS 的 .dSYM。同时还支持 --include-source 以打包相关源文件。

sourcemap 上传并发配置

默认情况下，sourcemap 上传最多同时处理 10 个文件。可以通过 --concurrency 调整：

1	posthog-cli sourcemap process --directory ./dist --concurrency 32

也可以通过环境变量方式设置：

1	POSTHOG_CLI_SOURCEMAP_UPLOAD_CONCURRENCY=32 npm run build

dry-run

如果希望跳过上传动作，可以在顶层加上 --dry-run，或者设置 POSTHOG_CLI_DRY_RUN=true。README 说明这适合 CI gate 场景，在保留打包流程的同时不真正上传制品。

这些内容让人很容易感受到：PostHog 的 CLI 不是为了“看起来有个命令行”，而是认真为开发、构建、CI、Agent 场景设计过的。

还有一个很特别的角落：`.stamphog/`

仓库里另一个有意思的 README 来自 .stamphog/。它描述的是一个声明式策略目录，用于 stamphog 的 PR 审批合并门控。

这里面提到：

policy.yml 是全局机器策略
review-guidance.md 是注入 reviewer system prompt 的受信任审查规范文本
对 .stamphog/**、AGENT_APPROVALS.md、tools/pr-approval-agent/** 的变更不会被自动批准
某些目录可通过 AGENT_APPROVALS.md 提供逐级累积的指导与覆盖

这一部分虽然不是主 README 的核心内容，但它非常能体现 PostHog 仓库的另一面：不仅产品功能丰富，连 PR 审批和 Agent 审查流程本身，也被显式策略化、文件化、规则化了。这个仓库显然不只是代码堆叠，它还在不断把协作机制本身产品化。

为什么说 PostHog 像一套“产品驾驶系统”

如果只看名字，PostHog 很容易让人先想到 analytics。但只要顺着 README 往下看，就会发现它的野心明显更大。

它把：

产品分析
Web 分析
会话回放
功能开关
实验
错误跟踪
日志
问卷
数据仓库
数据管道
AI 可观测性
工作流

放进同一个大框架里，又进一步强调这些信息会成为 Agent 诊断、发现和修复问题所需要的上下文。再加上可以从 Slack、Web、桌面端、MCP 和编辑器进行操控，它就不再只是“一个分析平台”，而更像一套围绕产品运行的操作系统。

它既能看，也能控；既能记，也能驱动下一步；既面向人，也越来越面向 Agent。

它最有辨识度的地方，不是功能多，而是把这些功能串成了一条线

PostHog 最让人印象深刻的，并不是它单点能力有多长，而是它把这些能力串起来的方式。信号进入系统后，不只是被展示在面板里，还可能被回放、被比对、被实验验证、被工作流处理、被 Agent 使用，甚至被进一步转成待审阅的 pull request。

这条链路的存在，让它看起来像一个会持续吸收上下文、再把上下文转化成动作建议的平台。

如果把 README 和相关 CLI 文档合在一起看，会发现 PostHog 描绘的是一个很完整的世界：从数据采集，到问题观测，到环境接入，到命令行工具，到 Agent-first API，再到自动化工作流，整个平台都在努力回答同一个问题——当产品自己开始变得更“自动驾驶”时，底层那套观测、分析和执行系统应该长什么样？

而 PostHog 给出的答案，是一整套已经被组织起来的能力网。它不只是告诉你“看见了什么”，还在努力让系统进一步知道“该做什么”。