$10 的小產品也想要「會自己修 bug」的飛輪？關鍵是把 log 寫給 AI 讀，不是給人看

緣起：我想知道我們的工具有沒有「行為記錄」

我們在做一個社群影片下載工具，貼上 IG／FB／YouTube 的連結就會自動抓下來。我開始想產品化的事，於是問了 Claude 一個看似很技術的問題。

我的提問：貼什麼都能進來，但抓不到的時候，它會留記錄嗎？

我那時是這樣說的：

貼什麼東西都可以進來，但我們的工具會去判斷它能不能下載到資料。假設下載不到，它會不會留下工作記錄？我想要一個很簡單的 worklog——幾點幾分、從哪個 IP 或哪個 user ID、貼上了什麼東西。

為什麼要這個？因為未來產品化，如果每個人的帳號都是獨立的世界，可溯源就變得很重要。當出現錯誤的時候，用戶通常是無法做錯誤回報的，可是我們可以用很簡單的 log 就知道他卡在哪。而且不只「貼上連結」這一步，後面工作流的每個環節也都該像 Cloudflare Pages 部署那樣——步驟一、步驟二、步驟三打勾。斷在哪、錯在哪，一看就懂。

Claude 的回答：你其實已經有 log 了，只是記得不夠細

Claude 先去查了後台，然後告訴我一件我沒意識到的事：記錄其實已經有了。我貼進去的每個網址，都有留下「時間＋網址＋狀態（成功／失敗）＋失敗原因」。連我故意丟進去的兩個沒有影片的網址（一篇純文章、一個廣告課程報名頁），都清清楚楚記成 failed，原因是 Unsupported URL。

所以問題不是「沒記錄」，而是三個缺口：

只有最終狀態，沒有環節 checklist——只有「成功／失敗」，中間工具做了哪些環節（連上頁面、找到影片源、下載、轉檔、存縮圖、寫入庫）沒有逐關記錄。斷在第幾關看不出來，正是我說的「步驟打勾」缺的部分。
沒有「誰、從哪」——沒記 user ID / IP。我一個人用不需要，但產品化多人時必要。
前端沒把失敗告訴使用者——記了，但藏得太安靜。

然後 Claude 問我：環節要記「粗顆粒」還是「細顆粒」？

我又追問：我不是在選粗還是細，我要的是產品「活著」

這時候我發現，我得把真正的動機講清楚：

我真實想要的，是希望你多跳推理動機，去上網查 2026 年頂尖的 SaaS，如果定價是美金 10 元以下（月費或一次性都可以），這個價位的產品，它的 log 服務機制應該符合什麼條件？

我的核心思考點是：怎麼讓這個產品真正活起來。活起來的意思是——AI 看得懂、AI 知道問題在哪。當用戶有任何問題回報的時候，AI 已經超前部署、有了最基礎的資料，可以判斷問題卡在哪個環節。然後自動去做議題發佈、修正、測試、驗測，乃至更新發佈、在正式環境驗證通過，甚至主動回報給客戶「我們修正了什麼、如何做到、為什麼」。這樣才是一個完整的產品飛輪。

所以「粗還是細」關乎的是我在意什麼——我在意的是，用最輕巧、最簡單的方式，就能實現這個產品自動成長機制，讓產品真的活著。

Claude 的回答一：2026 的分水嶺，正好就是「飛輪 vs 資料墳場」

Claude 去查了 2026 年的可觀測性（observability）趨勢，找到一句話直接命中我的直覺（出自 Braintrust 與 Rootly 的產業整理）：

會把追蹤資料自動餵回下一個修復循環的平台，形成可靠性飛輪；只把資料存起來的平台，只是一座資料墳場。

這就是我講的「活著 vs 死的」的專業版。而 2026 的頂尖玩法，已經不是「記 log 給人看」，而是讓 AI 跑完整閉環——像 Metoro 的 AI 自己做「偵測→調查→根因→部署驗證→開修復 PR」，Latitude 用 MCP 把偵測到的失敗直接推給 coding agent 變成 PR。跟我要的飛輪一模一樣。

Claude 的回答二：$10 買不起現成的飛輪，但 AI 讓你自己做得起

這裡有個殘酷的現實：現成的 AI 自動診斷／修復都遠超 $10。Sentry 的 Seer autofix 是 $40／人／月（Sentry 定價），Datadog 更貴。

Claude 的推論是：$10 以下的產品，買不起現成的飛輪，只能自己做輕量版。而這正是 AI 時代的翻轉——過去自己做要養一個 SRE 團隊，現在你的 SRE 就是 Claude Code。你不是要買 Sentry，你是要讓 log「長成 AI 讀得懂的樣子」，然後 AI 就是那個免費的、24 小時的診斷＋修復引擎。

讀到這裡我覺得很有意思：原來便宜產品的護城河，不是省下工具錢，而是把「昂貴的人力環節」換成「AI 讀得懂的資料結構」。

Claude 的回答三：這個價位的 log，該符合的 6 個條件

Claude 從研究反推出六條（綜合 Sentry 的 agent 監控指南等來源）：

AI-first，不是 dashboard-first：格式給 AI 讀，不是給人看的圖表（圖表你一個人看不完）。
零額外成本／自架：用本來就有的儲存自己記，不付第三方。
每個環節記「意圖＋結果＋原因」：記「為什麼做這動作」才叫可解釋，AI 才能重建因果。
可歸因到單一用戶：每筆綁 user ID＋任務 ID，產品化後「每人獨立世界」＋客服溯源。
隱私內建：記網址、環節、錯誤碼，不記個資／密碼，$10 產品也要符合 GDPR。
閉環能被 coding agent 消費：log 要有一個「AI 讀取口」，AI 才能讀了就診斷。

Claude 的回答四：粗還是細的真答案——環節級＋ reason code

最關鍵的來了。Claude 說這根本不是粗細二選一，而是「剛好夠 AI 重建斷點因果」的最輕顆粒：

太粗（只有成功／失敗）→ AI 看不出斷在哪。
太細（每個輸入輸出都記）→ 資料墳場，$10 養不起。
正解：以「環節」為單位，每環節記一筆，失敗的那筆帶一個「機器可讀的原因碼」（reason code）。

而 reason code 就是整個飛輪的心臟。重點不是存自由文字的 ERROR: Unsupported URL（AI 每次都要重猜），而是把它映射成有限的分類碼：

NO_VIDEO_FOUND / GEO_BLOCKED / LOGIN_REQUIRED /
FORMAT_UNAVAILABLE / RATE_LIMITED …

這一個小設計，讓兩件事同時成立：

超前部署：用戶說「壞了」→ AI 查他最近的失敗事件 → 看 reason code → 立刻知道類別＋對應的修復策略，不用問他。
自動優化產品：reason code 可以統計——哪個碼暴增，就是產品最該修的洞。這就是資料驅動的路線圖。

我丟進去那兩個網址，在這個設計下就會是 received ✓ → resolve ✗ NO_VIDEO_FOUND。一看就懂，而且會被統計進「有多少人貼了沒影片的頁」。

飛輪最後怎麼轉起來

Claude 把整條閉環畫給我看，對上了我原本的願景：

用戶貼網址
  → 每環節記一筆事件（環節、狀態、reason code、user、時間）
  → 失敗：reason code 翻成人話給用戶
     （不是 Unsupported URL，而是「這個連結裡沒有可下載的影片」）
  → 用戶回報「壞了」，甚至根本不回報
  → AI 讀事件：看是個案，還是某個 reason code 系統性暴增
  → 系統性 → AI 開議題 → 修（加一種偵測）→ 自動驗測（重跑那批失敗網址）
  → 通過 → 發佈 → 正式環境重驗 → 主動回報「我們修了 X 類連結，現在支援了」

log 不再是死資料，是餵養 AI 自我改進的血液。

我學到的

我學到最重要的一件事，是我一開始問錯了問題。我糾結「log 該記多細」，但真正決定產品能不能「活著」的，不是記得多細，而是記的格式能不能被 AI 讀懂、能不能驅動閉環。

reason code 這個看起來很小的東西，其實是槓桿：它讓一個 $10 的小產品，也能擁有過去只有大公司養得起 SRE 團隊才有的「自我診斷、自我修復」能力。因為讀 log、判斷斷點、開議題、修、驗、發的那個角色，現在可以是 AI。

輕巧不是把功能砍掉，而是找到那個「剛好夠 AI 接手」的最小結構。

這篇是我和 Claude 實際對話的學習紀錄。文中所有 2026 年 SaaS 可觀測性的趨勢、工具與定價，都是 Claude 透過網路查證後整理的，來源連結已附在各段落中，並非我個人的研究成果。