嗨大家，我是 Debuguy。

前面我們建立了完整的 AI DevOps Squad：Grafana 看監控、Elasticsearch 查 Log、kubectl-ai 查資源、Playwright 確認使用者體驗。但還是會遇到一個尷尬的場景...

凌晨的終極考驗：AI 看不懂你的 Code

當警報遇上自訂邏輯

📱 凌晨 3:27
🚨 [CRITICAL] Payment Service Error
付款失敗率暴增，檢測到異常的狀態碼 418

@on-call-engineer

你問 Bot：

@debuguy_bot 幫我看看為什麼會出現 418 狀態碼

Bot 的回應：

根據 Log 分析，系統回傳了 418 I'm a teapot 狀態碼。
這是一個來自 RFC 2324 的愚人節笑話狀態碼，通常不應該在生產環境出現...

「所以你是在跟我說我們的付款系統變成茶壺了？這什麼鬼！」

你真正想問的是：

「為什麼我們的程式碼會在這個時候回傳 418？」
「是哪段邏輯觸發的？」
「該不會是哪個工程師覺得好玩亂加的吧？」

問題的根源：AI 不懂你的程式碼

Bot 很會查 Log、看 Metrics、檢查 K8s 資源，但它不知道你的程式碼長什麼樣子。

它可以告訴你：

• ✅ 哪個 Pod 在哪個時間點出錯
• ✅ Error message 是什麼
• ✅ 影響了多少 requests

但它沒辦法告訴你：

• ❌ 這個錯誤是從哪個 function 拋出來的
• ❌ 可能是哪段程式碼邏輯有問題
• ❌ 最近的 PR 是不是改了相關的地方
• ❌ 為什麼你們會用茶壺狀態碼

「如果 AI 能直接『看過』我的程式碼就好了...」

Repomix：把整個 Repo 塞給 AI

什麼是 Repomix？

Repomix 是一個神奇的工具，它能把你的整個 Git repository 打包成一個單一檔案，而且：

• ✅ 保留完整的目錄結構
• ✅ 每行程式碼都有行號
• ✅ 自動過濾 .gitignore 的檔案
• ✅ 支援各種程式語言
• ✅ 輸出格式友善 LLM 閱讀

為什麼需要它？

傳統做法：一個一個檔案複製貼上

請你幫我看這段程式碼：
[貼上 api.ts]

還有這個 service：
[貼上 payment.service.ts]

喔對了還有這個 util：
[貼上 error-handler.ts]

「貼到手痠，而且 AI 的 context 還爆掉了...」

用 Repomix：一次搞定

repomix --output-show-line-numbers

產生一個 repomix-output.xml，裡面包含：

📦 Repository: payment-service
📂 src/
  ├─ api.ts (lines 1-150)
  ├─ services/
  │  └─ payment.service.ts (lines 151-300)
  └─ utils/
     └─ error-handler.ts (lines 301-350)

==================== File: src/api.ts ====================
1: import express from 'express';
2: import { PaymentService } from './services/payment.service';
3: 
4: const app = express();
...

然後直接塞到 System Prompt！

Gemini 1M Token 的優勢

1M Context Window

「1M tokens 大概是多少程式碼？」

粗估：

• 1 token ≈ 0.75 個英文單字
• 1M tokens ≈ 750K 個單字
• 平均 1 行程式碼 ≈ 10-15 tokens
• 1M tokens ≈ 66K-100K 行程式碼

這代表：

• ✅ 可以放下整個微服務的 codebase
• ✅ 包含所有的 business logic
• ✅ 還有 utils、models、configs

為什麼不用 RAG？

你可能會想：「為什麼不用 RAG（Retrieval-Augmented Generation）？」

RAG 的問題：

1. 需要事先建立索引：要先跑過一遍所有程式碼
2. 相關性判斷不精確：可能檢索不到關鍵的檔案
3. 上下文碎片化：程式碼的 import、function call 關係可能斷掉

直接塞進 System Prompt：

1. AI 完整理解整個架構
2. 看得到所有的 import 和依賴關係
3. 能追蹤 function call chain

「就像一個新同事 onboarding，直接把整個 codebase 給他看一遍。」

實作：把 Repomix 整合到 ChatBot

Step 1: 安裝 Repomix

# 全域安裝
npm install -g repomix

# 或是用 npx (不需安裝)
npx repomix

Step 2: 產生 Repository 單一檔案

在你的專案目錄執行：

cd /path/to/your/project

# 產生帶行號的完整程式碼
repomix --output-show-line-numbers

# 預設會產生 repomix-output.xml

進階參數：

# 排除特定目錄
repomix --ignore "node_modules,dist,build"

# 只包含特定檔案類型
repomix --include "**/*.ts,**/*.js"

# 客製化輸出檔名
repomix --output codebase-snapshot.txt

Step 3: 把程式碼加到 System Prompt

更新你的 .prompt 檔案：

# prompts/chatbot.prompt
---
model: gemini-2.5-flash
config:
  temperature: 0.7
input:
    schema:
        repomix: string
---

You are Debuguy Bot, an AI DevOps assistant with deep knowledge of our codebase.

## Complete Codebase Knowledge

You have access to the ENTIRE codebase with line numbers. The codebase structure is below:

{{repomix}}

When analyzing errors or issues:
1. Reference specific files and line numbers
2. Understand the full context of function calls
3. Trace execution flow across multiple files
4. Identify potential bugs based on actual implementation

## Your Capabilities

With access to:
- ✅ Grafana for metrics
- ✅ Elasticsearch for logs  
- ✅ kubectl-ai for K8s resources
- ✅ **Complete codebase understanding**

You can now provide:
- Root cause analysis with code references
- Specific file and line number suggestions
- Impact assessment based on actual implementation
- Code-aware debugging strategies

實際使用場景

1. 模擬場景一：揭開 418 茶壺之謎

工程師: @debuguy_bot 幫我看看為什麼會出現 418 狀態碼

Bot: 找到了！讓我來揭開這個「茶壺之謎」🫖

🔍 錯誤發生在 `src/api/payment.ts:67-72`

根據程式碼邏輯，418 是我們自訂的狀態碼（沒錯，就是那個茶壺），用來表示：
- 客戶端請求超時（payment.service.ts:145 設定的 30 秒 timeout）
- 第三方支付 API 回應時間過長

程式碼註解寫著：

// 當第三方 API timeout 時，回傳 418 "I'm a teapot"
// 因為我們不想沖咖啡（處理付款），我們是茶壺（超時了）
// - 某位有幽默感的工程師，2024-03-15

📊 從 Grafana 看到：
- 第三方 API 平均回應時間從 2s 飆到 28s
- 觸發我們的「茶壺防禦機制」

💡 建議：
1. 檢查第三方支付 API 是否有問題
2. 考慮調整 timeout 設定（目前 30s 可能太短）
3. 加入 retry 機制（目前 payment.service.ts:150 沒有 retry）
4. 順便考慮換個比較正經的狀態碼？😅

價值：

• ✅ 精確指出程式碼位置
• ✅ 解釋自訂邏輯的意圖（和冷笑話）
• ✅ 結合 Metrics 給出完整分析
• ✅ 還能吐槽工程師的幽默感

2. 模擬場景二：找 Bug

工程師: @debuguy_bot 昨天晚上 8 點到 9 點之間有很多 null pointer exception，幫我查一下

Bot: 找到問題了！

🐛 Bug 位置：`src/services/user.service.ts:89`

程式碼：
88: const user = await this.userRepository.findById(userId);
89: const userName = user.profile.name;  // ❌ 這裡沒有檢查 null
90: return userName;

📋 Log 證據：
昨晚 20:15-21:00 有 237 筆 "Cannot read property 'name' of undefined"

🔎 根因：
- 新用戶註冊時 profile 可能是 undefined
- 昨晚剛好有一波新用戶註冊活動

💡 建議修復：
```typescript
const userName = user?.profile?.name ?? 'Anonymous';

或在 line 88 後加入：

if (!user.profile) {
  throw new UserProfileNotFoundError(userId);
}

**價值：**
- ✅ 直接找到 bug 的位置
- ✅ 給出具體的修復建議
- ✅ 加碼提供更好的錯誤處理方式

### 3. 安全性考量

**敏感資訊過濾：**
```bash
# .repomixignore (類似 .gitignore)
.env
.env.*
*.key
*.pem
secrets/
config/production.yaml

Repomix 自動遵守 .gitignore：

• API keys、credentials 不會被包含
• 但要注意 hard code 在程式碼中的 secrets

建議：

• 在 snapshot 產生後掃描敏感資訊

小結：DevOps 自動化的最後一塊拼圖

今天我們完成了 AI DevOps Squad 的終極升級：

現在 AI 真的能做到：

1. 🔍 分析 Grafana 警報細節
2. 📊 查詢 Elasticsearch logs
3. 🎯 檢查 Kubernetes 資源狀態
4. 🖥️ 確認用戶看到的影響
5. 💻 精準定位程式碼問題（包括那些茶壺彩蛋）

你只需要根據這些證據，決定下一步行動。

當凌晨警報響起時，Bot 不只告訴你「發生了什麼」，還能告訴你「為什麼會發生」和「程式碼的哪裡有問題」。甚至還能發現某位工程師在 2024 年 3 月 15 日留下的茶壺梗。

這就是我們想要的 AI DevOps 助手。

完整的原始碼在這裡

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

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