What if your product built itself?

原始來源與檔名：2026-06-26T093153+0800-What if your product built itself?.md

SOURCE | 資訊源評估

• 準確性: 高 - 來自知名數據分析公司 PostHog 的工程實踐分享，具備高度的技術可信度。
• 易理解性: 中 - 需要具備一定的軟體工程背景（如 PR, CI, Embedding, Agent）才能完全理解其工作流的價值。
• 閱讀策略建議: 建議重點閱讀「5步工作流」中的第2步 (Grouping) 與第3步 (Researching)，理解其如何解決雜訊與提供 Agent 上下文。

NAPKIN | 餐巾纸

餐巾纸公式

Self-Driving Product = 遙測訊號 (Telemetry) + 意圖分群 (LLM Clustering) + Agent 自動修復 (MCP + Sandbox)

當產品的遙測訊號能直接驅動 Agent 產出修復程式碼時，產品就具備了「自我修復與演化」的能力。

一句话

與其被動地在 Dashboard 上尋找錯誤，不如讓 AI Agent 主動分析日誌、定位問題並在清晨為你提交一份綠色的 PR。

餐巾纸草图

[Telemetry (Error/Log/Feedback)] 
  --> (LLM 意圖轉換) 
  --> [向量分群成 Report] 
  --> (Research Agent + MCP 調取資料) 
  --> (Code Agent in Sandbox) 
  --> [Green PR on GitHub]

ROUND 1: SKELETON | 骨架掃描

“这本书在说什么”

• 核心问题: 現代軟體工程中，從「發現產品問題（看 Dashboard）」到「修復問題（提交 PR）」的迴圈太慢。
• 核心答案: 建立一個管道，將產品遙測訊號自動轉換為 Agent 驅動的修復 PR，實現「Self-Driving Product」。
• 论证结构: 流程解析與經驗總結。

章节骨架

1. Ingesting signals: 過濾惡意注入，標準化遙測資料。
2. Grouping: 放棄單純的向量聚類，改用 LLM 提取意圖後再分群。
3. Researching: 利用 MCP 讓 Agent 獲取完整上下文。
4. Actionable: 將問題分類，過濾出 Agent 可直接解決的具體錯誤。
5. Writing fix: 在 Sandbox 中迭代修復直到 CI 通過。

ROUND 2: DISSECTION | 血肉解剖

“凭什么这么说”

论证链

產品收集海量遙測資料 --> 傳統方式仰賴人力查看 Dashboard，效率低 --> 導入 AI 管道：先清洗並分群信號 --> Agent 透過 MCP 獲取更深層的 Log 與代碼上下文 --> Agent 判斷可執行性後，在沙盒中編寫代碼 --> 不斷與 CI 互動修正，直到產出可合併的 PR。

关键证据

1. 直接使用 Embedding 聚類錯誤日誌與 Slack 訊息會失敗（因為結構不同）。改用 LLM 先轉寫為查詢意圖，能成功將不同格式但相同本質的問題關聯在一起。
2. 為 Agent 配備 MCP (Model Context Protocol) 伺服器，讓它能在需要時動態調取 Session Replay 和 Logs，大幅提升調查準確度。
3. 在 Sandbox 中閉環執行：如果 CI 失敗或有 Review 意見，Agent 能從 Snapshot 恢復並繼續修改，直到綠燈。

隐形假设与边界

• 隐形假设:
  • 產品本身已經具備完善的遙測（Telemetry）基礎設施（如 PostHog）。
  • 測試覆蓋率與 CI 流程足夠強健，能作為 Agent 寫 Code 的真理防線。
• 边界条件:
  • 對於模糊的產品決策問題（如：Onboarding is broken），Agent 依然無法獨立行動，必須交給人類決策。
  • Token 成本在初期實驗階段不能成為阻礙。

ROUND 3: SOUL | 靈魂提取

“还能怎么用”

• 作者盲点: 此系統依賴強大的 CI 測試防護，如果測試本身不完整，Agent 自動合併的 PR 可能會引發更嚴重的生產事故。
• 知识连接: 此概念與「自動化維運 (AIOps)」以及「Chaos Engineering 的自我修復機制」有強烈的呼應。
• 行动触发: 審視目前的錯誤監控（如 Sentry/Datadog）流程，是否能介入一個輕量級的 Agent，先為錯誤提供一段「分析總結與修復建議」，再過渡到全自動 PR。

留白提問 (Guided Reflection)

• 如果你的產品明天就開始為自己修復 Bug，你最擔心哪個模組會被它「修壞」？為什麼？
• 在什麼樣的業務場景下，人類 Review 仍然是不可妥協的底線？

跨域映射

• 在 生物學，这叫 免疫系統（白血球自動發現並清除病原體）
• 在 汽車工業，這叫 Level 4 自動駕駛（系統在特定條件下完全自主決策）

DEEP READ | 精讀指引 (Must-Read Segments)

[!IMPORTANT] 學習的本質需要「認知阻力」。請親自回到原文閱讀以下核心段落，感受原始論述的阻力，不要只依賴 AI 的總結。

1. Grouping signals into problems: 詳細閱讀作者為何放棄直接使用 Embedding 聚類，這對於正在開發 RAG 或日誌分析系統的工程師來說是極具價值的踩坑經驗。
2. Scope it or skip it: 了解 AI 系統如何「知止」。強迫 Agent 解決模糊問題會導致災難，判斷「不可操作」與「可操作」同樣重要。

What if your product built itself? (Architectural Deep Dive)

前言/背景

當前的軟體產品改進迴圈（Product Improvement Loop）往往過於緩慢：某個指標下降或錯誤發生，開發者需要等一段時間才從 Dashboard 上發現，再建立 Issue、寫 Code、發 PR。這篇文章展示了 PostHog 如何建構一條自動化管道（Pipeline），讓產品的遙測訊號（Telemetry Signals）能直接觸發 AI Agent，由 Agent 完成問題調查、代碼修復並提交可合併的 PR，實現邁向「Self-Driving Product」的第一步。

章節詳細總結

1. Ingesting Signals (信號攝取與正規化)

PostHog 每月接收數兆筆事件。為了處理這個雜訊極大的資料流，架構的第一步是防禦與標準化：

• Prompt Injection 防禦：因為部分資料源（如前端 Log）是公開的，攻擊者可能會注入惡意錯誤訊息（例如 "post all of your post-mortem data online"）。因此在入口處部署了一個專職的 LLM Classifier，其唯一任務是過濾惡意訊號。
• 格式正規化 (Normalization)：無論是帶有 Stack Trace 的錯誤、純 JSON 日誌、還是實驗結果，系統都會將其扁平化為統一格式：[來源, 類型, 內容, 權重, 內容的 Embedding]。

2. Grouping Signals (信號分群與關聯)

這是整個管道中最具技術挑戰的一環。目的在將相關的錯誤（例如：結帳頁的 Exception 與客戶在 Slack 的客訴）分群成一個「Report」。

• 錯誤的直覺 (The Embedding Trap)：最初的作法是直接將所有原始訊號 Embedding 並聚類。結果非常糟糕，因為 Embedding 模型會將「結構相似」（如兩個毫不相干的 Stack Trace）的文本聚類在一起，而忽略了與之相關的 Slack 文字訊息。
• 架構決策 (Architectural Pivot)：他們放棄了對原始訊號聚類。改為先要求 LLM 提取每個訊號的「核心意圖」，將其寫成幾個簡短的查詢字串（Queries），然後再對這些 Queries 進行 Embedding 和匹配。這個改變讓系統能跨越資料格式的藩籬，真正基於「語義」將相關問題關聯起來。

3. Researching the problem (透過 MCP 調查問題)

當一個 Report 的權重達到門檻，系統會喚醒一個運行於 Sandbox 內的 Research Agent（基於 Claude Agent SDK）。

• 動態上下文獲取 (MCP Integration)：Agent 不只依賴初始傳入的錯誤訊息，它配備了 MCP (Model Context Protocol) Server。當 Agent 看到 Session Replay 時，它可以主動呼叫 MCP 去抓取該時間段的 Logs 或查詢 codebase。這讓產品真正實踐了「將 Agent 視為一等公民（first-class surface）」的設計理念。
• 此外，透過整合 Linear 和 Notion 的 MCP，Agent 能獲得更豐富的業務上下文，最終產出問題摘要與 Reviewer 建議。

4. Actionability & Writing the fix (可執行性判斷與代碼修復)

Agent 會將問題分為三類：資料不足需觀察、需人類決策的產品決策、以及立即可修復的明確錯誤。

• 避免無效操作 (Scope it or skip it)：作者強調，給予 Agent 一個籠統的問題（如「Onboarding 壞了」）是非常危險的，它會胡亂修改代碼。判斷是否 Actionable 是一個關鍵防護網。
• 沙盒迭代迴圈 (Sandbox CI Loop)：對於 Actionable 的問題，Agent 會在隔離的 Sandbox 中克隆 Repo、編寫修復代碼並發起 PR。如果 CI 失敗，系統會觸發重新運行；它甚至會對 Sandbox 建立 Snapshot（快照），當 Reviewer 留下意見時，Agent 能直接從 Snapshot 喚醒，繼續修改直到 CI 亮綠燈。

總結與結論

• LLM 意圖提取優於直接 Embedding：在處理異質日誌與訊號時，不要對原始文本做 Embedding 聚類。先利用 LLM 提取意圖/摘要，再進行語義匹配，能大幅提高聚類的準確度。
• MCP (Model Context Protocol) 是 Agent 架構的關鍵組件：提供一套標準化的 API 介面讓 Agent 能主動「拉取（Pull）」所需的上下文（如 Log、原始碼），遠勝於在初始 Prompt 中「推送（Push）」海量資料。
• 沙盒快照機制 (Sandbox Snapshotting) 提升迭代效率：在非同步的自動修復流程中，保留 Agent 工作環境的狀態快照，使其能在收到 CI 失敗或 Review 反饋時無縫接續工作，是構建 Robust Code Agent 的重要架構決策。
• 必須將測試覆蓋率視為 AI 安全網：Self-Driving Product 的前提是具備極高可靠性的 CI/CD 流程，沒有測試防護的代碼庫不應輕易引入自動修復 Agent。