---
title: AI 聊天助手
eyebrow: Guidant AI 資安檢視 · 模組報告
h1: AI 聊天助手（jedi-ai-bot）
lede: 使用者打字問問題、系統轉給外部 AI 回答的那個聊天框。**這是整輪檢視裡最乾淨的一塊**——只找到一件事，但那一件事一個普通員工就能讓整個系統停止回應。
---

## 這塊在產品裡做什麼

產品裡有一個聊天框：使用者打字問問題，系統把訊息原封不動送到外部的 AI 服務（Anthropic Claude），拿回答顯示回畫面。對話紀錄暫存在快取裡，一小時沒動就自動清掉。

功能本身很單純——它不查資料庫、不碰客戶資料、也不做任何權限判斷，就是一個轉接窗口。

::: grid2
::: {.card .plain}
#### 它平常在做什麼
1. 收下使用者打的字
2. **送到公司網路外面**給 AI
3. 把回答送回畫面，順手存進對話紀錄
:::
::: {.card .warn}
#### 為什麼它值得單獨查
這是全部模組裡**唯一會把使用者輸入的原文送到公司網路外面**的一塊，也是**唯一每被呼叫一次就直接產生金錢成本**的一塊。

風險的形狀跟其他模組完全不同——不是「誰看得到誰的資料」，而是「誰能把公司的資源用光」。
:::
:::

---

## 檢視軌跡

**檢視期間**：2026-09-10（單日完成）｜**範圍**：14 個檔案（套件本體；另有 3 個接線檔約 89 行由統籌者全文讀過）｜**共 1 輪**

> **原始技術報告**放在需求中心的 [FR-082 站](https://guidantai-feature-doc.jedicotech.com/FR-082-2609-ai-bot-security-scan/)，檔名見下表最後一欄。那裡有每一輪的完整技術細節、檔案清單與逐條推理，供需要深究或稽核抽查時查閱。

| 輪次 | 查什麼 | 檔數 | 覆核投票 | 結果 | 原始報告檔名 |
|---|---|---:|---|---|---|
| **A1** | 對話會不會跑到別人那裡、能不能無限次呼叫把資源用光 | 14 | 9 票全投完，零中斷 | 通過 1 條，**這輪的品質是整批檢視裡最好的一次** | `scan-A1-ai-bot` |

::: {.callout .ok}
**為什麼說「這輪的品質是最好的一次」**

覆核程序跑完時會留下一份紀錄，上面除了票數，還有一欄「被退回的項目」——前一個案子六輪裡有五輪帶著退回標記。**這一輪那一欄是空的**，九票全數投出、沒有任何一票中斷或漏投。

覆核者還主動追出模組之外去查：他們翻了主系統的設定與對外的網頁伺服器設定，確認那兩層也沒有任何次數限制。**這不是讀這個模組就能知道的事，是自己追出去查的。**
:::

::: {.callout .warn}
**有一件事工具沒做，必須說清楚**

派工時點名了兩個一定要有答案的問題（對話會不會跑到別人那裡、少了登入設定時會怎樣），**工具一個都沒回答**——兩個答案都是統籌者事後自己開檔查出來的。

**兩個答案都是好消息**（見下方「另外查證的兩件事」），但那不是工具給的。這一輪能宣稱的是「工具報的這一條是真的」，不能宣稱「這個模組只有這一條」。

**沒有重跑補查的原因**：這個模組只有 14 個檔案、且其中 4 個是空的，統籌者自己逐檔讀完比重跑一輪快。
:::

---

## 問題一覽

**只有一條。**「出事會怎樣」那欄講的是**業務影響**——誰受影響、損失什麼，不是技術現象。

| # | 問題 | 風險 | 分類 | 出事會怎樣（誰受影響） | 怎麼修 | 狀態 |
|---|---|---|---|---|---|---|
| **1** | 聊天沒有長度上限，也沒有次數限制 | 🟡 中 | 資源耗盡 | **整個產品對所有人停止回應**——不只聊天功能，連登入都會逾時。做得到的人是**任何一個最基層的員工**，四到八個連線就夠，不需要特殊權限。另一種後果是**把公司共用的 AI 額度燒光**，直接變成帳單 | 加訊息長度上限、加等待逾時、開一個「每人每分鐘最多問幾次」的插槽給主系統接。實際做法：訊息長度上限 4000 字、外部 AI 呼叫 60 秒逾時、每人每分鐘 10 次上限（超過回 429） | ✅ **已修（CM-2064）** |

---

## 第 1 條：沒有長度上限、也沒有次數限制

### 問題是什麼

使用者在聊天框打什麼、打多長，系統完全不管，直接轉給外部 AI。也沒有「一個人一分鐘最多問幾次」這種限制。

**為什麼「整個產品停不了」比「燒錢」更嚴重**——覆核者把這條鏈追得很完整：

| 環節 | 實際狀況 |
|---|---|
| 系統同時能處理幾個請求 | **只有 4 個**（正式部署的預設值） |
| 一個請求處理多久 | 呼叫外部 AI 本來就慢 |
| 外部 AI 沒回應時要等多久 | **10 分鐘**（套件的預設值，我們從來沒改過） |
| 系統多久會強制砍掉卡住的請求 | 120 秒 |

把這四件事串起來：**四到八個連線各送一則超大訊息，就把系統能同時處理的量全部佔滿**。其他人這段時間連登入畫面都打不開。

系統確實有一道「整站請求不得超過 50MB」的限制擋在前面，但**50MB 對一則聊天訊息來說等於沒擋**。

### 建議怎麼修

| 步驟 | 做什麼 | 為什麼不能省 |
|---|---|---|
| **一** | 訊息長度設上限（建議 4000 字），超過就直接退回 | 這是最小、最快的止血，改一個檔就好 |
| **二** | 呼叫外部 AI 時設等待逾時 | **讓系統自己放棄，不要等到被強制砍掉**——目前是等 10 分鐘、系統 120 秒就砍，這中間的落差正是被佔住的原因 |
| **三** | 開一個「每人每分鐘最多幾次」的插槽，由主系統接上既有的計次機制 | 「怎麼限制」是產品規則，該由主系統決定；但「有沒有這個插槽」該由這個模組提供。不開插槽，下一個接手的人只能在模組裡硬寫一套 |

**已裁定與 AI 儀表板那塊的同款問題（見 [AI 儀表板報告](M15-ai-dashboard.html)）合併處理**——兩邊共用同一把 AI 金鑰，而且 AI 儀表板那邊一次請求會呼叫兩次 AI，情況更嚴重。

---

## 另外查證的兩件事（都是好消息）

這兩件是派工時特別點名要查、但工具沒答，由統籌者事後自己開檔確認的。

| 要查的事 | 結論 |
|---|---|
| **對話紀錄會不會跑到別人那裡？** | ❌ **不會。** 存放位置的第一段是使用者編號，而那一段**由伺服器自己填、是純數字**，呼叫端偽造不了。原本的擔心不成立。<br>⚠️ 但這道保護完全靠「編號由伺服器填、而且排在最前面」這件事撐著——哪天有人調動順序，保護就沒了。建議在程式旁加一行說明，寫清楚順序為什麼不能動 |
| **主系統忘了設定登入檢查時會怎樣？** | ✅ **會直接啟動失敗，是安全的。** 不會變成「不用登入就能用」的公開入口。錯誤訊息不如其他模組清楚，但**安全性上沒有缺口** |

---

## 這塊的結論

::: {.callout .ok}
**一句話**：這塊只有一件事要修，而且工單早就開好躺著等排期——**它是整輪檢視裡體質最好的一塊**。

**已裁定要修**，照三步做：訊息長度上限、呼叫外部 AI 設等待逾時、開一個「每人每分鐘最多問幾次」的插槽。**修起來很便宜**（兩個小改動），而且**裁定與 AI 儀表板那塊的同款問題合併處理**，共用同一次改動。

**不能宣稱的事**：這一輪的覆核品質很高，但工具沒有留下逐檔閱讀紀錄，而且它跳過了派工時點名的兩個重點。**能說的是「找到的這一條是真的」，不能說「這裡只有這一條」。**
:::

| 統計 | |
|---|---|
| 檢視輪數 | 1 輪、14 個檔案 |
| 通過的發現 | 1 條 |
| 最嚴重 | 0 條 |
| 已修 | 0 條 |
| 已開工單未排期 | 1 張（CM-1638） |

---

| 你想知道 | 看哪裡 |
|---|---|
| 我們用什麼方法查、結果有多可信 | [檢視方法與工具](GUIDE-01-method-and-tools.html) |
| 其他模組的檢視結果 | [回總報告首頁](index.html) |