嗨大家，我是 Debuguy。

三十天前，我給這個系列取了個名字：「AI 產品架構之旅：從 0 到 1，再到 Day 2」

這個標題不是隨便取的，它其實隱含了兩個最核心的問題：

從 0 到 1：我們到底在創造什麼？
從 Day 1 到 Day 2：它要如何在真實世界存活？

今天，讓我們回到這兩個問題的本質。

第一個問題：從 0 到 1，我們在創造什麼？

不是第 n+1 個工具，而是一個會「思考」的夥伴

Peter Thiel 在《Zero to One》說：從 1 到 n 是複製，從 0 到 1 是創造。

當我開始做這個專案時，公司已經有很多 Slack Bot 了

我可以做第 n+1 個「更智慧的自動化工具」。

但那不是從 0 到 1，那只是從 n 到 n+1。

真正的突破：讓 Bot 知道「我是誰」

Day 3 的時候，我做了一個看似簡單的改動：

Your name is {{botName}}.
Your Slack ID is {{botUserId}}.
You are not just executing commands; 
you are participating in conversations as a helpful team member.

這是一個根本性的轉變：

Before（工具思維）：

User 輸入指令 → Bot 執行任務 → 回傳結果

After（夥伴思維）：

User 開啟對話 → Bot 理解脈絡 → 參與討論 → 協作解決

當 LLM 能區分「我」「你」「他」時，它不再是執行指令的工具，而是參與對話的一員。

這才是從 0 到 1：不是技術的複製，而是互動模式的創造。

設計哲學：讓複雜自然湧現

Day 7 我部署了兩個 Bot，它們自己開始討論問題了。

我沒有寫任何「協作系統」的程式碼，為什麼會這樣？

因為當系統的基礎規則設計正確時，複雜行為會自然湧現：

• Bot 知道自己是誰（身份認知）
• Bot 會 tag 回使用者（創造互動循環）
• Bot 能讀懂對話歷史（理解脈絡）

→ 自然形成 N-N 協作

這就是「從 0 到 1」的架構設計思維：

不是實現複雜功能，而是設計簡單規則，讓複雜功能自然湧現。

第二個問題：從 Day 1 到 Day 2，它如何存活？

Day 2 思維：產品上線只是開始

DevOps 裡有個概念：

• Day 0：設計規劃
• Day 1：建置部署
• Day 2：維運，讓它持續運作

大部分人專注在 Day 1（能動就好），但真正的挑戰是 Day 2：如何在生產環境活下去？

原型的三個致命缺陷

Day 11 檢視原型時，會發現三個問題：

1. 安全性崩潰：

// 每個開發者都拿真實的 Gemini API Key
apiKey: process.env['GEMINI_API_KEY']

→ 就像給每個員工公司金庫的鑰匙

2. 可觀測性為零：

console.log('Error:', error);  // 這就是全部的監控

→ 出問題只能靠猜

3. 擴展性受限：

單體架構 + Socket Mode 10 連線上限 = 天花板

原型驗證「能不能做」，Day 2 考驗「能不能活」。

三個關鍵決策

決策一：Virtual Key 架構（Day 14-16）

不是技術選擇，而是安全模型的重構：

Before: 團隊共用真實 Key
After: [開發者] → Virtual Key → [LiteLLM] → Real Key

得到的不只是安全性，還有：

• 預算控制（每個 Key 有額度）
• 權限管理（離職立刻撤銷）
• 使用追蹤（誰用了多少一目了然）

決策二：Langfuse 可觀測性（Day 17）

GenKit Developer UI 很好用，但它會把所有 trace 讀進記憶體。

在生產環境：

Pod Status: OOMKilled
Reason: Container exceeded memory limit

它叫 Developer UI，不是 Production UI。

Langfuse 帶來的不只是監控，而是：

• 每次對話的成本追蹤
• 完整的錯誤堆疊
• 效能瓶頸分析
• Self-hosted 的資料掌控

決策三：微服務化（Day 13）

Socket Mode 有 10 連線上限，單體架構被綁死。

拆分後：

• Slack Service：10 個 replica，榨乾連線數
• GenKit Service：獨立 scale，不受 Slack 限制
• MCP Service：高記憶體機器，專門跑瀏覽器

從 Day 1 到 Day 2，核心是「可持續性」而非「可行性」。

兩個視角的交織：產品架構設計

產品驅動架構，架構保證產品

這三十天文章想傳達的是：產品思維和工程思維不是對立的，而是互相成就的。

產品視角（從 0 到 1）：

• 定義了「我們要創造什麼」
• 身份認知、對話容器、自然協作
• 這些決定了架構的「方向」

工程視角（從 Day 1 到 Day 2）：

• 確保了「它能持續運作」
• Virtual Key、可觀測性、微服務化
• 這些決定了架構的「韌性」

舉個例子：

Day 5 選擇「用 Slack Thread 當對話容器」，這是產品決策。

但它同時解決了工程問題：

• 不用自己建資料庫（省維護）
• 不用處理狀態同步（省複雜度）
• 符合使用者習慣（省學習成本）

好的產品架構，是讓產品思維和工程思維互相增強。

Day 22 的教訓：Trade-off 是常態

重構到 LiteLLM 後，Gemini thinking 串流消失了。

選擇 A（直接用 Google AI Plugin）：

• ✅ 原生支援所有 Gemini 功能
• ❌ 沒有安全保護
• ❌ 沒有成本控制

選擇 B（透過 LiteLLM）：

• ✅ Virtual Key 安全機制
• ✅ 預算控制
• ❌ 失去 thinking 即時串流

最後的決定：

• 安全性 > 即時體驗
• 長期提 PR 修 compat-oai

產品架構設計不是找「完美解」，而是在 trade-off 中找「最適解」。

這趟旅程的真正價值

不是技術清單，是思維框架

三十天下來，我們建了：

• Slack ChatBot
• MCP 工具整合
• 微服務架構
• Virtual Key 安全層
• Langfuse 監控

但這些都不是重點。

重點是：

我們建立了一個「從產品願景到生產部署」的完整思維框架。

這個框架包含三個層次：

1. 產品層：從 0 到 1 的創造

   • 定義核心價值（對話夥伴 vs 自動化工具）
   • 設計互動模式（參與 vs 執行）
   • 讓複雜湧現（規則 vs 實現）

2. 工程層：從 Day 1 到 Day 2 的存活

   • 安全性（Virtual Key）
   • 可觀測性（Langfuse）
   • 可擴展性（微服務）

3. 決策層：在 Trade-off 中前進

   • 沒有完美解
   • 只有最適解
   • 持續演進

給未來的自己

如果未來要做另一個 AI 產品，記得問自己：

從 0 到 1：

• 我在創造什麼新的價值？（不是複製）
• 這個價值的本質是什麼？（不是功能）
• 如何用最簡單的規則實現？（不是複雜度）

從 Day 1 到 Day 2：

• 它能在生產環境活多久？（不只是能動）
• 安全、可觀測、可擴展都考慮了嗎？（不只是功能）
• Trade-off 的優先順序是什麼？（不是全都要）

產品架構設計：

• 產品思維驅動方向
• 工程思維保證韌性
• 在 trade-off 中持續前進

結語

從 0 到 1，我們創造了價值。
從 Day 1 到 Day 2，我們讓價值持續。
這就是「AI 產品架構之旅」的完整意義。

感謝有看完三十天的你。

完整的原始碼在這裡。

我們有緣再見。🚀

也歡迎追蹤我的 Threads @debuguy.dev