前面幾篇其實一直在處理同一個循環：產品先留下資料，再由工程師找出值得處理的問題、做修改，最後確認結果有沒有改善。Error Tracking 用來找到程式錯誤，Product Analytics、Session Replay 與 Survey 幫助我們理解使用者在哪裡失敗，Feature Flag 與 Experiment 用來控制與驗證改動，AI 功能則另外需要 Trace 與 Eval。

工具各自處理不同問題，但流程中常有一段需要持續投入人力：有人要定期打開這些資料，判斷哪些異常值得處理，整理 Evidence，再把它變成一件可以執行的工作。

Coding Agent 已經可以幫忙完成部分程式修改。如果前面的「發現問題與整理脈絡」也能部分自動化，這個循環就可以再往前推一步。PostHog 目前的 Self-driving 就是在處理這件事。

Self-driving 的工作流程

PostHog Self-driving 目前仍在 Open beta。它會從產品資料中建立 Signal，把相關 Signal 整理成 Report，再由 Agent 調查問題。當 Report 足夠具體而且可以直接處理時，Agent 會在 Sandbox 中準備修改並建立 Pull Request；如果還缺少商業脈絡或需要在人類的多個合理方向中做選擇，Report 會留在 Inbox 等待輸入。

整個流程可以整理成幾個階段：

1. Signal sources 與 Scouts 從產品資料中找到值得注意的現象。
2. 這些現象被整理成帶有 Evidence 的 Signal。
3. 相關 Signal 會被合併成一個 Report，減少同一個問題產生多筆通知。
4. Agent 進一步查看 Product Data 與 Codebase，判斷問題是否可以形成具體修改。
5. 可以直接處理的 Report 會產生 Pull Request；需要產品判斷的則標記為 Needs input。
6. 人類 Review / Merge 後，PostHog 再檢查這次修改針對的 Metric 是否有變化。

設定可以直接透過 Wizard 開始：

npx @posthog/wizard self-driving

Wizard 會檢查 PostHog 是否已經接好，協助啟用 Signal sources、Scouts，並連到 Self-driving Inbox。Self-driving 也需要 Organization 開啟 AI data processing，Wizard 會在設定過程中檢查。若要讓 Agent 建立 Pull Request，還需要連接對應的 GitHub Repository。

Signal sources 與 Scouts

Self-driving 的輸入單位是 Signal。官方文件將它定義成一個結構化 Finding，包含發生了什麼、支持這個判斷的 Evidence，以及可以採取的 Action。

Signal 主要有兩種來源。Signal source 會持續監看一個明確的資料流，例如 Error Tracking、Session Replay，或 Jira、Linear 等外部來源。這類來源的重點是 Coverage：符合條件的資料會持續被處理，不需要 Agent 每次重新判斷要不要看。

Scout 則是排程執行的 Agent。它可以跨不同資料探索，再依照事先描述的標準判斷哪些現象值得回報。相比 Signal source，Scout 不追求把每一筆資料都列出來，而是用 Judgment 篩出值得注意的部分。

這兩種方式處理的問題不同。已經有明確 detector 的 Error，適合由 Signal source 持續收集；如果想觀察「Checkout 最近有沒有出現值得調查的異常」，就更接近 Scout 的用途，因為不是每一次 Conversion 波動都值得建立工作。

一個產品問題也可能同時留下多種 Signal。例如 Checkout 發生錯誤時，Error Tracking 看到 Exception，Session Replay 看到使用者卡在付款流程，客服系統可能也開始收到相關問題。Self-driving 會把指向同一個問題的 Signal 整理到同一個 Report，讓後續處理的是一個產品問題，而不是多筆彼此獨立的通知。

從 Report 到可以執行的修改

Report 形成後，Agent 會進一步查看 Product Data 與 Codebase，確認問題的影響與可能原因，再判斷是否能形成具體修改。PostHog 對 Report 的說明中會把結果分成 Actionable 與 Needs input。

Actionable 代表目前已有足夠資訊提出修改，Agent 可以建立 Pull Request；Needs input 則代表還需要產品或商業脈絡，例如兩個方向都合理、需要決定產品行為，或目前的 Evidence 不足以支持直接修改。

這也界定了 Self-driving 目前比較適合的範圍。官方文件將它主要放在 Maintenance：Bug Fix、Broken Flow、Instrumentation Gap，以及持續性的 Optimization。新產品方向、功能優先順序，或兩個合理方案之間的取捨仍然需要團隊自己決定。

Review 與修改後的衡量

目前 Self-driving 不會自行把修改送進 Production。官方文件明確保留 Human Review：Agent 建立 Pull Request 後，團隊仍然要 Review、要求修改，最後決定 Merge 或 Decline。

Human Review 負責確認程式修改本身，而修改完成後還有另一個問題：產品結果有沒有改善。前面談 Experiment 時已經看到，成功發布一個改動不等於產品真的變好。Self-driving 在修改送出後還會繼續檢查它針對的 Metric 是否產生變化，再把結果帶回後續的 Signal。

例如 Agent 修正 Checkout 的 Exception，Error Rate 下降是一個正面 Signal；如果同時 Checkout Completion 也下降，就不能只因為 Exception 消失而判斷修改成功。同樣地，把流程從五步縮成四步，也還是要確認使用者是否真的更容易完成原本的 Job。

這裡的 Measure 也不會取代前面介紹的 Product Analytics 與 Experiment。Metric 發生變化可以告訴我們結果是否朝預期方向移動；如果問題需要確認因果關係，仍然需要 Experiment 或其他更適合的驗證方式。Self-driving 可以自動化觀察與執行的一部分，但 Success Metric 和驗證方法仍然要先定義清楚。

產品工程師仍然要定義成功

Self-driving 可以降低從「看到資料」到「提出修改」之間需要投入的人力，但這個流程能不能產生有價值的結果，仍然取決於產品本身有沒有把成功定義清楚。

Scout 需要知道什麼現象值得回報；Signal 需要可以支持判斷的 Evidence；Agent 需要知道哪些操作允許自動執行；修改完成後，也需要一個合理的 Metric 判斷結果。如果這些條件本身沒有定義好，把更多步驟交給 Agent 只會更快地執行一個不明確的方向。

因此，產品工程師需要處理的問題並沒有因為 Agent 出現而消失。使用者到底想完成什麼？目前最大的阻礙在哪裡？哪些 Signal 能代表他正在接近成功？什麼程度的改善值得投入？哪些修改可以安全地交給 Agent，哪些決策一旦判斷錯誤就應該先由人確認？這些仍然是產品與工程之間需要一起回答的問題。

回頭看這個系列，Error Tracking、Product Analytics、Session Replay、Survey、Feature Flag、Experiment、Workflow、AI Observability、Eval、MCP 到 Self-driving，看起來是很多不同工具與功能，實際上處理的是同一條線：讓產品發生的事情可以被觀察，讓問題可以被理解，讓修改可以被驗證，再把重複的部分逐步自動化。

PostHog 的功能會繼續改變，AI 能做到的事情也會繼續增加。工具本身並不是這個系列最後想留下的重點。無論是準備開發一個功能、看到一個異常，或讓 Agent 自動提出下一個修改，最後仍然要回到同一件事：確認這次改動是否真的讓使用者更容易完成他原本想做的事。

如果你願意花 30 秒留下回饋，我會用這些意見來調整後續文章：分享你的意見