心得報告：LINE Bot 智慧股票聊天助手

本專案的心得報告著重於反思「Skill 設計」與開發過程中的 AI 協作經驗。

---

Q1. 你在 linebot-dev Skill 的「注意事項」寫了哪些規則？寫這些規則的原因是什麼？

在 linebot-dev (開發技能指南) 中，我定義了以下幾個關鍵規則：

1. Webhook 必須立即回傳 HTTP 200，且以 asyncio.create_task() 非同步處理訊息。
   • 原因：LINE Platform 規定 Webhook 必須在短時間內得到回應，否則會判定為失敗並重試。若把 AI 呼叫（可能耗時數十秒）放在主線程，會導致 Webhook 阻塞崩潰。
2. 所有外部呼叫 (MiMo/Gemini API, twstock, LINE Reply) 都必須包在 try/except 中，並給予降級回覆。
   • 原因：外部網路或 API 極不穩定，如果不捕獲例外，錯誤會傳播到頂層導致服務 500 崩潰，讓使用者完全收不到任何訊息（也就是「已讀不回」的狀況）。
3. 資料庫操作必須使用參數化查詢與 aiosqlite 非同步操作。
   • 原因：避免阻塞 FastAPI 的事件迴圈，並防範 SQL Injection。

Q2. 你的 Skill 第一次執行後，AI 產出的程式直接能跑嗎？如果不能，你需要修改哪些地方？修改後有沒有更新 Skill？

第一次執行後並不能完全直接順利運行，我們經歷了幾次修改：

1. API 模型相容性問題：原本設計使用 Google 原生 Gemini SDK，但後來切換到小米 MiMo v2 Flash（使用 OpenAI 相容介面），然後又切換到 gemini-3.1-flash-lite-preview 模型。這需要我們頻繁修改 config.py 和 ai_chat.py 內的 SDK 呼叫方式。
2. Timeout 逾時設定太短：原先設定 AI 請求的 timeout 為 10 秒。但 gemini-3.1-flash-lite-preview 預覽版模型有時回應較慢，導致常常出現「AI 暫時無法回應」的錯誤。後續將 Timeout 延長為 30 秒解決了不穩定的問題。
3. (已更新 Skill)：在遇到這些問題後，我們將「設定適當的 Timeout」以及「確保例外被安全記錄」的規則補充到了設計與開發規範中。

Q3. 你遇到什麼問題是 AI 沒辦法自己解決、需要你介入的？

開發過程中有幾個關鍵環節是 AI 完全無法代勞，必須依賴我（開發者）親自處理的：

1. 認證金鑰錯誤 (401 Unauthorized)：日誌顯示 LINE Reply 失敗並回傳 401 錯誤。這是因為我的 LINE_CHANNEL_ACCESS_TOKEN 無效或過期，AI 只能幫我抓出錯誤原因，但我必須親自登入 LINE Developers Console 重新核發 Token 並貼到 .env 檔案裡。
2. Webhook URL 綁定：AI 可以幫我在本機啟動 ngrok 並產生公開的 HTTPS 網址，但 AI 無法進入我的 LINE 後台把這串網址填入 Webhook 設定中，也無法幫我點擊 "Verify"。
3. ngrok 斷線問題：本地端的網路環境或終端機關閉導致 ngrok 隧道崩潰，外部請求無法進來，這需要我確保本機環境持續運作。

Q4. 如果你要把這個 LINE Bot 讓朋友使用，你還需要做什麼？

如果只是要讓朋友「立刻」測試，只要請他們掃描 LINE Bot 的 QR Code 加為好友即可（因為目前 ngrok 已經公開對外）。但如果是要作為長期穩定的產品讓朋友使用，還需要做以下幾件事：

1. 雲端部署 (Cloud Deployment)：不能一直依賴我電腦裡的 ngrok。必須將程式碼打包上傳到 Render、Railway 或 Zeabur 等雲端平台，讓伺服器 24 小時運作。
2. 環境變數設定：在雲端平台的 Dashboard 裡，重新填寫所有的環境變數（LINE Token、Gemini API Key 等），絕不能把 .env 檔案 push 到 GitHub 上。
3. 資料庫持久化遷移：雲端平台的本地檔案系統通常是暫時的（Ephemeral），每次重新部署 SQLite 的 conversations.db 就會被清空。必須將 SQLite 改為連接真正的 PostgreSQL 資料庫，或是掛載持久化硬碟 (Persistent Volume)。
4. 更新正式 Webhook：將 LINE Developers Console 的 Webhook URL 更新為雲端平台提供的永久網址。