本卡屬 FR-082（母卡 CM-1636），修 A1 棒的 F1。嚴重度 🟡 中（三個檢查員 3:0 全票確認）。依決策者既有裁定：本卡為歸檔，PM 統一安排時才派工。

問題是什麼（白話）

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

兩種後果，第一種更嚴重：

• ① 整個產品停止回應——系統只有 4 個工作程序，一個一次處理一個請求。攻擊者開 4～8 個連線各送一則接近 50MB 的訊息，就佔滿全部工作程序，其他人連登入都會逾時。不只聊天壞掉，是所有功能都停。
• ② 燒公司的錢——AI 金鑰是全公司共用一把，任何登入者可無限次呼叫，每次都用接近上限的內容量。帳單與速率額度都是共用資源。

為什麼「停止回應」比「燒錢」嚴重（檢查員追出來的完整鏈）

主專案跑 4 個同步工作程序（main.py:258）
    ↓ 一個工作程序一次只能處理一個請求
呼叫 Claude 本來就慢
    ↓ 而 Anthropic 套件的預設逾時是 10 分鐘，這個套件從來沒改過
工作程序被佔住
    ↓ 系統要等 120 秒才會強制砍掉卡住的工作程序
4～8 個並發請求 → 全部工作程序被佔滿
    ↓
整個產品的所有功能都停止回應

單則訊息的天花板是 50MB——主專案的全站請求上限（CM-1587 訂的）擋得到這裡，但 50MB 對一則聊天訊息來說等於沒擋。

在哪裡

jedi-ai-bot/jedi_ai_bot/api/ai_bot_route.py

:57   message = (payload.get('message') or '').strip()   ← 只去頭尾空白
:58   session_id = (payload.get('session_id') or 'default').strip()
:60   if not message: return ...400                      ← 只檢查空字串
:64   reply = ctx.service.chat(ctx.current_user_id(), session_id, message)
      ↑ 沒有長度檢查、沒有次數限制，直接送出去

jedi-ai-bot/jedi_ai_bot/app/service/ai_bot_service.py

:94-100  client = Anthropic(api_key=self._api_key)
         response = client.messages.create(...)
         ↑ 沒有傳 timeout，吃 SDK 預設的 10 分鐘

檢查員已做過額外查證：去主專案與 nginx 設定裡找有沒有其他層擋著頻率——沒有找到任何頻率限制。

怎麼修（三項，都在套件層）

① 長度上限（route 層，最快見效）

• 在 AiBotRoute.post 送出前檢查 message 與 session_id 長度，超過回 400。
• 上限值做成 AiBotConfig 的可調欄位（建議預設 max_message_length=4000、max_session_id_length=64），不要寫死——不同產品的合理值不同，這正是 config 插槽存在的理由。
• error code 走套件既有的 jedi_ai_bot/common/response.py 或新增，先查既有的再新增。

② 上游呼叫逾時（service 層）

• AiBotService.__init__ 加 request_timeout 參數（建議預設 60 秒，遠低於 gunicorn 的 120 秒），傳給 Anthropic(api_key=..., timeout=...)。
• 理由：讓上游卡住時套件自己放棄，不要等系統砍工作程序。這一項單獨做就能大幅降低「癱瘓全站」的風險。