嗨大家，我是 Debuguy。

昨天我們回顧了「從 0 到 1」的原型設計回顧，驗證了 Slack ChatBot 的核心概念。但作為一個資深工程師，我在設計原型的時候就已經在思考：這個架構要如何才能真正在生產環境中存活？

讓我們直接看程式碼，分析為什麼現有架構無法滿足生產環境的品質要求。

現有架構快速回顧

// src/index.ts - 所有功能都在一個 process
async function main() {
  await Promise.all([
    startGenkitFlow(),  // LLM 處理邏輯
    startSlackBolt()    // Slack 連線管理
  ]);
}

// Slack Bot 處理
app.event('app_mention', async ({ event, say, client }) => {
  const messages = await formatMessages(event, client);
  const result = streamFlow({
    url: 'http://127.0.0.1:3400/chatFlow',
    input: { messages }
  });
  // ... 串流處理
});

// GenKit Flow 處理
const chatFlow = ai.defineFlow({
  // ...
}, async ({ messages }, { sendChunk }) => {
  const tools = await host.getActiveTools(ai);
  return (await ai.prompt('chatbot')({ /* ... */ })).text;
});

# template.env
SLACK_BOT_USER_ID=${SLACK_BOT_USER_ID}
SLACK_BOT_TOKEN=${SLACK_BOT_TOKEN}
SLACK_APP_TOKEN=${SLACK_APP_TOKEN}
GEMINI_API_KEY=${GEMINI_API_KEY}

🔒 安全性：API Key 洩漏

問題程式碼：

// src/index.ts
const ai = genkit({
  plugins: [
    googleAI({
      apiKey: process.env['GEMINI_API_KEY']!  // 團隊必須拿到真實的 API Key
    }),
  ],
});

# 每個開發者都需要真實的 Gemini API Key
GEMINI_API_KEY=AIzaSyC_your_precious_api_key

致命缺陷：

• 團隊成員必須持有真實的 Gemini API Key 才能開發
• 無法限制個別開發者的使用額度和權限
• 無法追蹤 API 調用的具體來源和用途
• 越多人擁有真實的 API key 越容易洩漏

📈 擴展性：單體架構遇上連線上限

問題程式碼：

// src/index.ts - 典型的單體式服務
async function main() {
  await Promise.all([
    startGenkitFlow(),  // LLM 處理邏輯
    startSlackBolt()    // Slack 連線管理
  ]);
}

致命缺陷：

• 單體架構：所有功能綁定在同一個 process，必須整體擴展
• Slack Socket Mode 上限：每個 App Token 最多 10 條並發連接
• 整個系統的擴展上限被 Socket 連線數限制住

💰 成本可控性：無上限的黑卡

問題程式碼：

// 完全不記錄成本
const response = await ai.prompt('chatbot')({
  botUserId: process.env['SLACK_BOT_USER_ID']!,
  prompt: newMessages,
}, {
  messages: history,
  tools,
  resources,
  toolChoice: 'auto',
});

// 用戶完全不知道花費
await say({ text: response, thread_ts: event.thread_ts || event.ts });

致命缺陷：

• 使用者不知道每次對話的成本
• 管理層無法預估和控制預算
• 沒有機制防止意外高額消費
• 無法按部門或專案分攤成本

👁️ 可觀測性：除錯只能靠猜

問題程式碼：

// 錯誤處理簡陋
try {
  await client.chat.update({
    channel: event.channel,
    text: slackifyMarkdown(accumulatedReasoning),
    ts: reasoningMessageTs!
  });
} catch (reasoningError) {
  console.log("accumulatedReasoning: ", accumulatedReasoning);
  console.error('Error sending/updating reasoning to Slack:', reasoningError);
}

致命缺陷：

• 只有簡單的 console.log，沒有結構化日誌
• 目前的可觀測性是使用 GenKit Dev UI 但它不是為了生產環境設計

小結：現實檢查完畢

現有的架構作為原型很成功，但要上生產環境還有明顯的gap：

原型只是驗證了軟體能力，部署到生產環境才是考驗工程能力的時候。

明天開始，我們一步一步把這個原型改造成真正能在企業環境中運行的生產級系統。

AI 的發展變化很快，目前這個想法以及專案也還在實驗中。但也許透過這個過程大家可以有一些經驗和想法互相交流，歡迎大家追蹤這個系列。

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