Self Driving Products: Product Signals to Pull Requests — Joshua Snyder, PostHog

PostHog 的觀測資料自動修復管道解決了傳統開發流程的根本低效性。當前的工作流是：產品中發生一個信號（如錯誤激增或用戶會話失敗）→ 幾小時或幾天後開發者注意到儀表板的變化 → 診斷問題 → 提交線性工單 → 幾天後編寫拉取請求 → 代碼審查 → 部署。整個過程從數小時到數天不等，且這類工作佔據開發者的大量時間。PostHog 的目標是徹底反轉這個流程：訊號發生的瞬間，後台 agent 立即開始分析並自動提交拉取請求，開發者只需查看準備好的拉取請求清單。

管道的前兩個階段處理訊號吸收與標準化。PostHog 每月吸收數兆個事件，來自五個主要來源：錯誤追蹤、會話錄影、Slack 整合、日誌與實驗結果。由於某些來源是公開的（例如網站錯誤），攻擊者可能注入惡意訊號來探測產品或洩露資料。因此，管道的第一道防線是一個 LLM 分類器，負責掃除安全威脅。通過安全檢查後，系統將每條訊號正規化成統一結構：來源標籤、訊號類型、內容、重要性權重與語義嵌入向量。

第三階段是訊號分組，也是整個管道最具挑戰性的部分。系統需要識別「同一個問題的多個表現」——例如 Sentry 中的 null pointer 例外、會話錄影中的用戶挫折、以及 Slack 中客戶的投訴「結帳功能壞了」可能都源自同一個 bug。起初團隊使用現成的嵌入模型直接聚類訊號，但結果慘淡：模型傾向按資料結構相似性而非語義相似性分組，導致所有錯誤聚在一起、所有 Slack 訊息聚在一起，跨來源的關聯完全被忽視。解決方案是改變嵌入的對象：先用 LLM 從每條訊號生成若干查詢語句（問「這個訊號是關於什麼產品問題」），然後在嵌入空間中匹配查詢而非訊號本身。這樣嵌入模型就能基於語義內容而非資料格式進行聚類。訊號進入分組流程後持續累積權重，當單個報告的權重超過閾值時，系統將其晉升為「待研究報告」。

第四到六階段構成整個修復的核心迴圈。系統啟動一個運行在 Modal 沙箱中的研究 agent（使用 Claude agent SDK），該 agent 能存取三層資訊：PostHog 的 MCP 伺服器（用於拉取額外的日誌、會話錄影、實驗結果等補充資料）、完整的使用者程式碼庫上下文、以及外部整合如 Linear（工單系統）和 Notion（文檔）。研究 agent 的目標是理解問題的根本原因、定位相關的程式碼庫、評估優先級，並使用 Git blame 確定最合適的代碼審查者。隨後進入可行性評估階段，系統根據問題的具體程度和資料充分性做三個決定：（a）若資料不足，將報告放回池中繼續收集；（b）若涉及產品決策（如「該改進哪個功能」），轉送到人工審查收件箱；（c）若充分具體（通常來自 Sentry 等結構化來源），執行修復。在執行階段，系統克隆使用者程式庫到隔離沙箱，再次啟動 Claude agent 寫修復代碼，推送拉取請求。當 CI 報告失敗或審查 agent 留下評論時，系統會重新啟動沙箱快照並繼續迭代，直到拉取請求通過所有測試。

在建設過程中，PostHog 團隊學到了四個深刻的經驗。首先，評估測試必須在代表性生產資料上進行。本地的「感覺檢查」無法適應不同客戶的多樣化資料，盲目試驗等同於「在黑暗中摸索」。其次，嵌入模型的結構偏見是隱形的陷阱——現成模型預設按資料格式聚類，若不刻意設計應對，會導致完全的聚類失敗。第三，agent 過度應用會產生垃圾拉取請求。若將「onboarding 壞了」這樣的模糊問題丟給 agent，它會被迫猜測並生成無意義的修復，必須在上游的可行性評估中篩選掉。最後，初期的「節省代幣成本」戰略是大錯誤。團隊起初試圖延遲 agent 使用以降低成本，結果管道變得不可行。改為積極實驗後，反而發現了驚人的收獲：通過運行 agent 100 次處理同類問題，可以觀察到 agent 行為的模式，進而將昂貴的 agent 調用轉化為廉價的一次性 LLM 呼叫或訓練出輕量級模型。這樣最終的成本反而遠低於初期預估。