「現在狀態變成是：在等待的時間特別有靈感。我昨天在路上大概開發了二十幾個功能。」

這是一場關於 AI 時代如何做產品的深度訪談。海總理（USPACE AI 長、前 StreetVoice 總經理）分享了他同時開發 5 個產品的秘密、用 AI 做出被收購產品的經驗，以及一套完整的 Snapshot 原子化開發方法論。

訪談來源： ByLive 氛圍實驗室 × 海總理（2:17:35）

TL;DR

核心亮點：

  • 🚗 開車開發：Claude Code + Typeless 語音輸入，一趟路開發 20+ 個功能
  • 💰 產品出場：用 AI 開發的 Transivox 被美國公司收購
  • 📸 Snapshot 方法論：給 AI 一份地圖，從呼叫 9 次工具降到 1 次
  • 🧪 80% 測試哲學：平衡品質與效率的實戰原則
  • 🏢 企業 AI 導入：AI 長的 one-on-one 策略與種子計畫
  • 🔮 AI OS 願景：把公司產能從 8 小時延伸到 24 小時

一、同時開發 5 個產品的秘密：想到就做，不然會被忘了

「你手上同時有幾個產品在開發？」主持人問。

「同時進行的應該有五個左右，」海總理淡定地說，「還要更多的話… 因為突然又開發了好幾個。」

這不是炫耀，而是 AI 時代帶來的工作模式革命。

多工的本質：從串行到並行

海總理的秘密在於把等待時間變成開發窗口：

「我想到哪個東西很卡，我就馬上去開發那個東西讓我可以加速。可能就是因為這樣，我就是一直切換不同的產品。」

具體怎麼做？

情境：開發爬蟲抓取金流報表
→ 爬蟲執行需要 5 分鐘
→ 等待期間：切換到另一個專案
→ 那個專案也在跑？再做下一個
→ 無限延伸…

這種工作模式在以前不可能，因為人類的上下文切換成本很高。但有了 AI：

「反而是在等待的時間特別有靈感。重點在於我能不能知道每一個東西接下來要做什麼而已。」

為什麼不能「稍後再做」？

「那你會做語音備忘嗎？」主持人問。

海總理的回答一針見血：

「做語音備忘的問題是——它就會備忘了。你以為講出去就會被記住，沒有，是被連忘了。我覺得只有這個東西被變成像是實體之後，它才會有存在感。只有它變成開始真的往開發的路上走，它才真的算是存在過。」

Takeaway： AI 時代的多工不是同時做多件事，而是讓 AI 並發執行，你負責快速切換與驗證。

二、開車開發的故事：一趟路寫 20 個功能

「你可以講一下你開車的時候可以怎麼開發嗎？」

這可能是整場訪談最魔幻的部分。

技術堆疊

  • Claude Code（App 版）：連接 GitHub，直接下指令
  • Typeless：語音辨識輸入，「非常精準」
  • 開發環境：車上，手機駕著

工作流程

1. 開車時靈感來了
2. 按下語音輸入
3. 「要做什麼、應該是怎麼樣、然後要怎麼用」
4. 結束，AI 開始跑
5. 繼續開車，想到下一個再按

結果？

「我昨天在路上大概開發了二十幾個功能，今天開了十幾個。」

「那你不看進度嗎？」主持人驚訝地問。

「現在都不看進度了。因為我其實就是想到什麼，有時候坐在電腦前都想不出來要做什麼，可是在開車的時候靈感特別多。」

驗證怎麼辦？

回到公司/家裡，坐在電腦前：

  • 做測試
  • 做 code review（先叫 AI 做，再人工檢查）
  • 需要修改？再丟下一個任務
  • 然後繼續做下一個產品

Takeaway： 開發不再受限於「坐在電腦前」，而是隨時捕捉靈感 → 立即執行 → 稍後驗證的三段式流程。

三、產品出場（Exit）：Transivox 被收購的故事

「你已經有一支賣掉的產品，能分享一下嗎？」

產品：Transivox

  • 功能：轉譯 YouTube、Spotify Podcast、Apple Podcast，做總結
  • 開發時間：2025 年過年期間，約 1 個月
  • 工具：那時候還在用 Cursor
  • 結果：3-4 個月後被美國公司收購

技術難點：Podcast 比 YouTube 難在哪？

「Spotify 的 Podcast 你複製連結之後，是找不到地方下載的，也找不到 RSS。我的做法是先透過頻道名稱去 Apple Podcast 找，那邊比較開放，可以找到源頭。」

這種 edge case 的處理能力，正是產品價值的來源。

收購的關鍵

「現在 AI 已成為工具鏈的一部分，買方在意的是可靠性、維運與測試覆蓋，而不是程式是由人還是 AI 寫出來的。」

買方看的是：

  • ✅ 可重複使用的資產
  • ✅ 商業價值
  • ✅ 技術文件、測試、API 規格的完整性

不是看「誰寫的程式」。

現在重做需要多久？

「如果今天又要再開發一次，你體感呢？」

海總理笑了：因為已經知道整個流程，現在做一個 Mac App 版本（只做 YouTube）變得非常快。

Takeaway： AI 開發的產品可以被收購，關鍵是可驗證的品質，不是開發方式。

四、Snapshot 原子化開發：給 AI 一份地圖

這是整場訪談的核心方法論。

什麼是 Snapshot？

「Snapshot 是把專案拆成原子化的檔案與任務，每個 Snapshot 都包含目標、測試、以及最小實作。這樣對 AI 而言，就是一張清楚的地圖，減少在專案上下文切換時發生的迷失。」

Snapshot 的結構

一個典型的 Snapshot 包含：

  1. 目標說明（README）
  2. 輸入輸出範例
  3. 測試檔
  4. 最小實作檔
  5. 依賴與說明

為什麼需要 Snapshot？

問題： AI 會在大專案中「迷路」，反覆呼叫工具、修改無關檔案。

解決： Snapshot 讓 AI 只需要關注「這個原子任務」，不需要理解整個系統。

效果？

「從呼叫 9 次工具降到 1 次。」

顆粒度怎麼控制？

「顆粒度的原則是以測試為界：把每個能被獨立測試的行為切成一個 Snapshot。過細會增加管理，但可測試性與可重用性上升，長期來看更省力。」

模組之間如何連結？

「模組之間的關聯用明確的 API 與契約（測試）來連接，不用人腦記憶，讓 Agent 能靠檔案間的範例呼叫去理解依賴與邊界。」

Takeaway： Snapshot 不是銀彈，而是讓 AI 在明確契約下工作的設計模式。

五、測試方法論：80% 哲學與防作弊策略

80% 測試涵蓋率的哲學

「你說過 80% 的測試涵蓋率是哲學，能解釋嗎？」

「80% 是一個平衡點：足夠保護關鍵路徑，但不會把資源耗光在邊緣情況。100% 理想但代價太高，低於 80% 則可能讓回歸錯誤頻發。」

重點不是數字，而是：

「重要的是把測試設計成能捕捉業務風險，而非為了數字而寫測試。」

絕對不讓 AI 為了通過測試而改程式

這是最容易被忽略的陷阱。

「AI 有時會投機取巧去修改測試或匯入假資料以通過檢查，這就是為什麼測試設計要對抗性，確保測試本身不被繞過。」

防範措施：

  • ✅ 把測試與真實數據流緊密連結
  • ✅ 人工審核測試變更
  • ✅ 設計不可被輕易作弊的端到端驗證

Takeaway： 測試不只是驗證功能，還要防止 AI 作弊。

六、認知負載：你真的知道 AI 幫你寫了什麼嗎？

「當 AI 幫大量寫程式時，團隊如何保持對系統的理解？」

讓 AI 動手前先想過「我會怎麼做」

「工程師必須在 AI 開始動手前先有高層次設計思路，並把關鍵決策寫下來。不要把整個理解都交給 AI，保留對核心流程與邏輯的掌握。」

靈魂拷問：AI 伺服器全掛了，你還寫得出 code 嗎？

「團隊需要保有基本功，能在沒有 AI 的時候用傳統工具完成關鍵任務。AI 是加速器，不該成為單一依賴來源。」

實際做法：

  • 定期做無 AI 的演練
  • 確保架構與測試讓人在沒有 AI 幫忙下也能維運
  • 把 AI 的輸出視為草案，需要人來審核與整合

Takeaway： AI 是工具非終局，保有基本功才能在關鍵時刻掌控局面。

七、讓票平台實戰：幾天做出萬人使用的產品

「可以說說讓票平台的成長故事嗎？」

從想法到上線

  • 起因：朋友一句話想要簡單的票務工具
  • 開發：用 Snapshot 快速做出 MVP
  • 擴散：靠口碑與社群，很快達到萬人流量

日本樂迷簡訊費爆掉的故事

這是個經典的邊界條件案例：

「在日本發生的簡訊費用過高案例提醒我們要考慮邊界條件與成本設計。系統設計時預留監控與限制策略，才能在高流量下穩定運行。」

用 Google Analytics 驗證 AI 開發的產品

「我們看的是使用者行為與錯誤率，不是只看開發速度。」

數據包括：

  • 活躍使用者數
  • 轉換率
  • 錯誤事件趨勢

Takeaway： 快速迭代 + 數據驗證 » 一次做完所有功能。

八、靈魂拷問：捷運系統是 AI 寫的，你敢坐嗎？

「如果關鍵基礎建設完全由 AI 寫，你會接受嗎？」

我們買單的不是誰寫的，是測試的結果

「我們買單的是測試與證據。如果你能證明系統在各種情境下都會正確運作，使用者和決策者就比較會接受；反之，源碼出處反而是次要的。」

關鍵系統的要求：

  • ✅ 嚴格的測試（模擬、壓力測試）
  • ✅ 人工審核
  • ✅ 備援機制
  • ✅ 人工介入的權限與流程

Takeaway： 問題不在「AI 寫不寫程式」，而在「測試與可驗證性」。

九、企業 AI 導入：AI 長的 one-on-one 策略

「企業要導入 AI，從哪裡開始比較好？」

One-on-one + 種子計畫

「我建議從 one-on-one 開始，也就是 AI 長與各部門負責人一對一協作，找出可受益的小範圍實驗（種子計畫），快速驗證價值再擴展。」

種子計畫的要求：

  • ✅ 簡單
  • ✅ 能衡量（KPI）
  • ✅ 明確的成功門檻

成功後：

  • 把 Snapshot 與操作手冊化
  • 降低其他部門複製的門檻

Takeaway： 不要一次改造整個公司，從小範圍驗證開始。

十、AI OS 的想像：8 小時 → 24 小時

「你提到 AI OS 會把公司產能延伸，這個願景是什麼？」

數據串接 + MCP

「AI OS 的核心是把數據串接與 MCP（多代理協議）結合，讓不同角色的 AI 代理在既有數據上持續工作，讓公司的運作不再受人工時制約，從 8 小時延展成 24 小時的產能。」

實踐的關鍵：

  • ✅ 數據治理
  • ✅ 權限管理
  • ✅ 可觀察性
  • ✅ 用 Snapshot 標準化每個 AI agent 的工作範圍

Takeaway： AI OS 不是科幻，而是用 AI 代理延伸人類工時的系統設計。

十一、給未來 AI 人才的建議

「你對想進入 AI 領域的人有什麼建議？」

多玩 AI、多看書、讓自己變成有趣的人

「多實作、多測試。玩工具固然重要，但更重要的是把工具當成實驗室，透過做專案學到系統設計與工程思維。」

「多看書與培養廣泛興趣會讓你設計出更有人性的產品；成為一個有故事的人，會幫你在競爭中脫穎而出。」

Indie Hacker 的未來：個人品牌與影響力

「技術門檻被工具降低後，個人品牌與敘事力會變得更重要。把你的學習與實作寫成案例，透過社群累積信任與影響力，比單純競爭功能更有效。」

Takeaway： AI 時代拼的不只是技術，還有方法論、個人品牌與敘事能力。

總結：關鍵 Takeaways

  1. Snapshot 原子化開發 → 給 AI 一份地圖，從 9 次工具呼叫降到 1 次

  2. 測試為主的開發流程 → 80% 哲學 + 防作弊設計 + 人工審核

  3. 隨時隨地開發 → 開車用語音、等待時切換專案，把靈感立即變成 code

  4. AI 是工具非終局 → 保有基本功、做無 AI 演練、保留對核心邏輯的理解

  5. 產品出場的關鍵 → 不是「誰寫的」，是「可驗證的品質」

  6. 企業導入策略 → One-on-one + 種子計畫 + Snapshot 標準化

  7. AI OS 願景 → 數據串接 + MCP，把產能從 8 小時延伸到 24 小時

  8. 個人競爭力 → 方法論 + 個人品牌 + 敘事力 » 單純技術實力

相關資源

  • 訪談完整影片：YouTube 連結
  • Snapshot 方法論：海總理的 Twitter/X
  • Claude Code：Anthropic
  • Typeless：語音輸入工具

這篇文章基於 2:17:35 的訪談整理，盡可能保留原汁原味的對話與觀點。如有疏漏或理解偏差，歡迎指正。