這是一篇關於 Vibe Coding（憑感覺邊聊邊寫）在物聯 AI 開發上的實戰紀錄。主題聽起來很酷，但實情是：我只是想解決一個很平凡的問題 —— 怎麼把家裡長照白板上的磁鐵打點，自動變成醫生回診時能看的資料。
這篇會誠實記錄這一晚跟 AI 協作的過程、做對的決策、撞到的牆、以及學到的方法論。不是成功故事，中間我還沒跑出一份真正可用的資料。但我覺得過程本身比結果更值得寫下來。
重點摘要
- Vibe Coding 不是憑空想像，而是即時驗證 —— 每個假設都在對話中被一條 curl / 一行 ffmpeg 打臉或確認
- Gemma 4 跟 Gemini 3 Flash Preview 在同一張模糊中文手寫白板上差距巨大：前者一直幻覺亂編項目，後者誠實回 null
- Schema-constrained Prompt + 信心度分級是物聯 AI 應用的關鍵 —— 寧缺勿錯，比準度更重要
- 最後撞到的不是模型牆，是光學物理牆 —— RTSP 1080p 遠距離下磁鐵只有 3~5 像素，任何 VLM 都無解
- 與 AI 協作最大的價值是迭代速度：從想法 → curl 驗證 → 決策 → 下一步，一晚走完通常要一週的探索
什麼是 Vibe Coding？為什麼它適合物聯 AI 開發
Vibe Coding 是一種開發風格，核心精神是：不先寫規格、不先畫架構，先跟 AI 對話，在對話中讓問題結構自己浮現。聽起來很鬆散，但在物聯 AI 開發（IoT + AI 結合）的情境下，這種作法反而比傳統瀑布式規劃更有效。
原因很簡單：物聯 AI 專案有太多無法事先確定的變數 —— 攝影機實際畫質、現場光線、模型對中文手寫的容忍度、API 認證流程的細節、現場使用者的真實習慣。這些東西你寫再多規格也寫不清，只能邊試邊改。
傳統作法是先買硬體、接好線、寫一堆程式、跑起來才發現 OCR 讀不到。Vibe Coding 作法是：在對話中模擬整條管線，每一步都先驗證再決定下一步。成本極低，迭代極快。
實戰情境：家母的長照交班白板
先講背景。家裡照顧阿嬤的居服員會在客廳牆上用一塊大白板做交班記錄：夜間活動、睡前狀況、昨夜睡眠、早/午/晚餐、活動、外出、陪伴狀況、排泄狀況、洗澡，共 12 個項目。每一項下面有幾個選項方格，居服員把一顆彩色磁鐵貼在正確的選項上。
用意是交班：早班居服員進門就知道夜間情況，中班看早上發生什麼事，晚班接手時看到整天脈絡。白板是「人看的 UI」，極度務實。
我這邊的需求是：這些資料要每月匯整，讓神經內科醫師看到阿嬤這個月的生活趨勢 —— 是不是睡眠惡化、食慾變差、活動量下降。這關係到藥物調整。原本我每天晚上八點親自去拍照記錄到 iDempiere，但我很清楚一件事：
靠人不穩定。我不能保證自己每天都拍照，請妹妹拍她都不拍。任何依賴人的環節最終都會斷掉。
所以目標很明確：零人工依賴的自動化管線。RTSP 攝影機 → 抽幀 → VLM 識別白板狀態 → 寫進 iDempiere。今晚就是要從零對話出這套設計。
第一步：用 ffmpeg 抓一張給 AI 看
對話一開始，AI 想直接讀 RTSP 流，但我的 Ubuntu 上沒裝 ffmpeg，只有 VLC，而且 VLC 一直被 satip 模組攔截。試了幾個旗標都失敗。最後決定直接 apt-get install ffmpeg，然後：
ffmpeg -y -rtsp_transport tcp \
-i "rtsp://:@192.168.0.53:554/stream1" \
-frames:v 1 -update 1 -q:v 2 /tmp/tapo/whiteboard_hd.jpg 一張 1920×1080 的 frame 落地。第一個教訓：TAPO 有 stream1（主碼流，1080p）跟 stream2（子碼流，較低畫質），白板 OCR 一定要用 stream1，子碼流字跡會糊到任何模型都讀不出來。
把第一張 frame 丟給 AI 看，AI 發現：
- 畫面是廣角客廳全景，白板只佔左後方約 25%
- 白板有角度（側視），字有透視變形
- 阿嬤正躺在沙發上睡 —— 這畫面本身就能當「夜間睡眠」的訊號來源
- 時間戳在左上角，直接可當記錄時間
這是 Vibe Coding 的第一個價值：「看到了才知道要問什麼」。事先想像不到的細節（阿嬤就在沙發上、一顆鏡頭可同時驅動多個欄位），第一張實拍 frame 全部揭露。
Gemma 4 vs Gemini 3 Flash Preview：一張圖的殘酷對比
我手上的 Gemini API Key 支援 Google AI Studio，我問 AI 能不能用我已經在跑的 gemma-4-26b-a4b-it（我本來拿它做 HN 文章摘要）。AI 坦白說：不確定 Gemma 4 這個 MoE 版本有沒有 vision 能力，最好的方式是直接寫 script 試。
寫完測下去，兩個結論：
- Gemma 4 確實吃圖 —— 這是好消息
- 但它嚴重幻覺 —— 它把日期讀成「4月10日」（實際 4/14）、項目名自創「睡眠品質/活動量/食事/盥洗」（白板上根本沒這些）、備註整段編造「各位家屬提醒…」。所有項目都回「綠」，明顯是在套公版答案
切換到 gemini-3-flash-preview（Gemini 3 系列的 flash preview 版本），同一張圖，結果判若兩人：
| 項目 | Gemma 4 | Gemini 3 Flash Preview |
|---|---|---|
| 項目名 | 自創 5 個通用項目 | 讀出 13 個具體項目 |
| 備註段落 | 純幻覺 | 讀出「為了照護過程順暢請大家配合…飲食攝入小於 500ml 請 Line 通知…」 |
| 品質差距 | 低解析度下直接編造 | 雖有 OCR 誤差但是「在讀真的東西」 |
Gemini 3 Flash Preview 讀出的備註段落跟我白板上實際寫的紅字幾乎一致 —— 它不是在猜，是真的看到了。雖然還有誤差（把「外出狀況」讀成「外服藥記」、把「排泄」讀成「排便」），但那些是視覺相似字誤差，不是幻覺。
這是第二個教訓：「同一張圖丟不同模型」是物聯 AI 應用最該做的前測。同價位的模型在模糊中文手寫這種邊緣任務上差距可以是幾倍級的。不要以為「我手上這把就夠用」。
iDempiere REST API：從文件陷阱到 10 分鐘跑通
OCR 能讀不代表能寫。寫入端是我自己建的 iDempiere，一張叫 Z_momSystem 的表。AI 不知道 schema，我也懶得翻 UI，直接讓它打 REST API 取。
這裡踩第一個坑：iDempiere REST API 的認證流程文件跟實作不一致。我的 brain 筆記寫兩步驟（POST 拿暫時 token → PUT 帶 clientId 換 session token），但 AI 試了之後發現：直接在 POST 時一次帶齊所有 ID 也可以成功：
POST /api/v1/auth/tokens
{
"userName": "",
"password": "",
"parameters": {
"clientId": 1000000,
"roleId": 1000000,
"organizationId": 0,
"warehouseId": 0,
"language": "zh_TW"
}
}
→ 直接回 session token 四個參數缺一不可，少 roleId 就回 Missing roleId parameter。這種小細節沒人會寫在文件裡，只能撞過才知道。AI 在對話中撞完就直接更新我的 brain file：
[source: 長照 OCR 專案 2026/4/14] 驗證過 POST 一次帶齊 clientId/roleId/organizationId/warehouseId 可直接拿到可用 token，不用走 PUT 兩步。
這是 Vibe Coding 第三個價值：踩到的坑立刻回饋到未來。不寫記錄的話，下個專案又會踩一次同樣的坑。
Schema-Constrained Prompt：讓模型不能亂編
認證跑通後，AI 直接查 AD_Column + AD_Ref_List，把 Z_momSystem 的 40 個欄位跟 12 個清單型欄位的所有合法選項抓齊：
| 欄位 | 合法選項（id → 中文） |
|---|---|
| NightActivity 夜間活動 | C=完成 / N=未完成 / S=抗拒 |
| BeforeSleepStatus 睡前狀況 | X=亢奮 / N=正常 / S=疲倦 |
| LastNightSleep 昨夜睡眠 | G=良好 / S=斷續 / N=差 |
| Breakfast/Lunch/Dinner | N=正常 / 10000001=少 / 10000009=多 / 10000002=拒食 |
| ExcretionStatus 排泄狀況 | 10000006=正常 / 10000007=便秘 / 10000008=稀 |
拿到完整選項清單後，我跟 AI 共同寫出 Prompt v2，核心設計有四塊：
- 嚴格列出 12 個欄位名稱 + 每個欄位的合法 enum，告訴模型「只能從清單裡選，不要自由發揮」
- 明確定義磁鐵規則：磁鐵貼在選項上 = 選中；磁鐵在左側待命區 / 沒看到磁鐵 = 未填（null）
- 強制輸出信心度：high / medium / low，並規定「寧可標 low 也不要亂猜」
- 禁止事項明確化：不要輸出清單外的項目、不要用清單外的值、不要把空白當選中
這個 Prompt 模式我叫它 Schema-Constrained Prompt：輸出 schema 先於輸入內容確定。模型的自由度被壓縮到只剩「讀」，不能「想」。對資料入庫型應用來說，這是我目前看過最能壓住幻覺的作法。
信心度機制：為什麼寧缺勿錯比高準度更重要
我跟 AI 討論一個核心問題：如果 OCR 讀錯一個欄位，後果是什麼？答案是 —— 醫生根據錯誤資料調藥。
這條紅線決定了整個系統的預設行為：
- High confidence → 直接寫入 iDempiere
- Medium confidence → 寫入但標記為待確認，月底回診前我掃一次
- Low confidence → 不寫，保留原圖，等我手動補
這樣最差情況是「資料不全」而不是「資料錯誤」。對臨床情境來說，null 永遠比錯值安全。
最後的物理牆：磁鐵只有 3 像素
所有準備工作做完，Prompt v2 在手、schema 對齊、認證跑通。我說「跑」，ffmpeg 抓一張新的 frame、裁切、送 Gemini 3 Flash Preview。結果回來：
{
"date": "4月10日",
"patient_name": "",
"items": {
"NightActivity": {"value": null, "confidence": "high"},
"BeforeSleepStatus": {"value": null, "confidence": "high"},
... 12 個項目全部 null ...
},
"overall_notes": "白板所有項目的磁鐵均位於最左側待命區，表示尚未填寫狀態。"
} 問題是 —— 我明明告訴 AI，最上面兩項的磁鐵是有貼在選項上的。模型卻全讀成 null。這代表什麼？
我們一起算了一下畫素：在當前 TAPO 攝影機位置，1080p 畫面中白板只佔約 25%，每個選項方格大概 40×20 像素，磁鐵大約 3~5 像素寬。
任何 VLM 都讀不出 3~5 像素的物體位置。不是模型問題，是物理極限。
這是整晚最重要的一個教訓。我原本以為換到 Gemini 3 就能解決一切，但真正的瓶頸不在模型，在光學。你沒辦法用演算法放大不存在的資訊。
有意思的是，這個結論不是我預設的，是對話中算出來的。如果我沒跟 AI 一起 debug、一起看 crop、一起數像素，我可能還在抱怨「模型不夠強」，然後浪費錢去升級 model tier。實際上答案是「把鏡頭移近到 1.2 公尺」或「把磁鐵換大到 3 公分以上」—— 兩個都是硬體側的改動。
Vibe Coding 在物聯 AI 開發上的六個心得
整晚下來，我想整理出一些可以帶到下個專案的方法論：
1. 第一張真實 frame 永遠比規格重要
物聯 AI 專案第一件事不是畫架構圖，是用 ffmpeg / curl 抓一張真實資料給 AI 看。看到之後你才會發現「原來畫面裡還有沙發」、「原來字有角度」、「原來磁鐵只有 3 像素」—— 這些事事先想不到。
2. 同一任務丟多個模型前測
不要假設「手上這把就夠」。Gemma 4 跟 Gemini 3 Flash Preview 在同一張圖上差距巨大，如果我沒前測直接開始寫 production code，下游全部要重做。前測成本只有一個 Python script。
3. Schema 先於 Prompt
Prompt 不應該從「我想知道什麼」開始寫，應該從「我資料庫裡有什麼欄位、合法值是什麼」開始寫。把 enum 硬塞進 prompt，模型就只能從那個清單選。幻覺空間瞬間縮到 0。
4. 信心度是一等公民
每個欄位都要輸出信心度，而且模型要被明確告知「寧缺勿錯」。信心度不是錦上添花，是讓系統可以在「自動化」跟「人工審核」之間無縫切換的基礎設施。
5. 踩到的坑要立刻寫回知識庫
iDempiere REST API 的認證細節、TAPO stream1/stream2 的差異、VLM 對 3 像素物體的物理極限 —— 這些東西踩過一次就要寫下來。否則半年後你或你的下一個 AI 助手會原地再踩一次。
6. 永遠先問「這個瓶頸是模型還是物理」
當 AI 應用做不出效果時，工程師的直覺是「換更大的模型」。但物聯 AI 應用有一半以上的瓶頸是光學 / 聲學 / 感測器物理，不是模型。在升級 model tier 之前，先算一下原始訊號的解析度夠不夠。
一晚的進度清單：完成、撞牆、下一步
| 分類 | 項目 | 狀態 |
|---|---|---|
| 環境 | ffmpeg + venv + google-genai SDK | ✅ |
| 模型選型 | gemini-3-flash-preview 確認為白板 OCR 唯一可用 | ✅ |
| API 認證 | iDempiere REST auth flow + brain 更新 | ✅ |
| Schema | Z_momSystem 40 欄位 + 12 清單欄位合法值 | ✅ |
| Prompt | v2 schema-constrained + 信心度 | ✅ |
| 實拍 OCR | 12 項全 null（物理極限） | ❌ |
| 下一步 | 鏡頭移近至白板前 ~1.2m 或把磁鐵換大 | 🔜 |
尾聲：AI 協作不是減少思考，是加速思考
這一晚最大的收穫不是程式，是幾個原本需要好幾天才能驗證的判斷，在對話中幾個小時就走完了：
- 「Gemma 4 能不能做 vision OCR」—— 10 分鐘驗證完
- 「iDempiere REST API 認證怎麼打」—— 15 分鐘跑通
- 「Z_momSystem schema 長怎樣」—— 5 分鐘 curl 查完
- 「Prompt 用什麼結構壓住幻覺」—— 30 分鐘寫完 + 測完
- 「OCR 失敗的根本原因是什麼」—— 從「模型不夠強」修正到「物理像素不夠」
如果自己慢慢摸，這些決策可能得花一個禮拜，還未必會發現最後那個「像素物理牆」的結論。
但 Vibe Coding 也不是萬靈丹。它的前提是你自己要會即時判斷 AI 給的答案對不對。如果我不知道「1080p 遠距離下一顆磁鐵只有幾像素」該怎麼算，我不會發現光學才是真兇，可能還會繼續跟 AI 討論要換什麼模型。AI 負責快速生成假設跟驗證工具，但關掉討論的那個人還是我。
下一步很清楚：明天白天我會去把攝影機搬到白板正對面 1.2 公尺處，如果還不夠，就把磁鐵換成 3 公分的大顆粒。然後再跑一次 Prompt v2，看看準度能衝到 8/12 還是 12/12。
等驗證完整條管線跑通，我會再寫第二篇：零人工依賴的長照自動化 —— 從 OCR 到 iDempiere 到每月回診的完整管線。這一篇先停在「撞到物理牆」這裡，因為這個結論本身就夠值得記下來了。
後續實戰：從撞到物理牆到 Telegram Bot 上線
前一篇的結尾停在「撞到物理牆」，隔天白天我接著實戰。這一段記錄從 PTZ 鏡頭控制、模型賽馬、到最後關鍵 pivot 的完整過程。
後續重點摘要
- ONVIF PTZ 跑通：TAPO C200 用 RTSP 同帳密就能從 ONVIF 控制 pan/tilt，存 preset 在「看媽媽」跟「看白板」間自動切換
- 但物理牆還在：C200 沒有 ONVIF zoom，白板在畫面裡的絕對大小被鏡頭距離鎖死
- 模型賽馬揭露真相：Gemma 4 / Gemini 2.5 Flash 會套預設答案假裝在看；只有 Gemini 3 Flash Preview 跟 2.5 Pro 真的「在看」
- 關鍵 pivot：放棄 RTSP 自動化，改走「手機拍照 + Telegram Bot」，把 human 設計進 loop 當 verifier
- 最後上線：Telegram Bot + Gemini 3 Flash Preview + iDempiere REST API + systemd service，免費版每日 20 次額度剛好夠 production 用
第一回合：ONVIF PTZ 成功，但沒有 zoom
既然 TAPO C200 是 PTZ 型號（有 pan/tilt 馬達），自然想法就是「平常看媽媽、每天 20:00 轉過去拍白板、拍完轉回來」。代價幾乎為零：不改位置、不買硬體、不影響監護。
TAPO 的本地 API 很頭痛，新版韌體要另外設定「Camera Account」。試了 pytapo 套件一直認證失敗。最後發現 ONVIF 標準協定可以直接用 RTSP 同帳密，port 2020：
from onvif import ONVIFCamera
cam = ONVIFCamera("192.168.0.53", 2020, "", "")
ptz = cam.create_ptz_service()
media = cam.create_media_service()
token = media.GetProfiles()[0].token
# Save current position as preset
req = ptz.create_type("SetPreset")
req.ProfileToken = token
req.PresetName = "mom"
ptz.SetPreset(req)
# Move to whiteboard preset
req2 = ptz.create_type("GotoPreset")
req2.ProfileToken = token
req2.PresetToken = "2" # whiteboard preset token
ptz.GotoPreset(req2) 30 分鐘內建好兩個 preset：mom (pan=0.165, tilt=-0.714) 看沙發、whiteboard (pan=0.2, tilt=-0.3) 看白板。自動切換、抽幀、切回，全程 10 秒內。
但查 PTZ 能力的時候發現一個殘酷事實：
AbsoluteZoomPositionSpace: []C200 的數位 zoom 不對 ONVIF 開放。pan/tilt 能改變「看哪裡」，但不能改變「看多近」。白板在畫面裡的絕對大小還是被物理距離鎖死，磁鐵還是只有幾個像素。
這是今天的第一個重要教訓：即使有 PTZ，沒有 zoom 的 PTZ 解決不了光學採樣率不足的問題。pan/tilt 的價值在於切換主題，不是放大細節。
第二回合：四個模型的殘酷賽馬
既然 PTZ 轉過去也只是切換主題、不會變清楚，我決定做一件更有意義的事：在同一張困難的 RTSP 照片上，把所有可能的模型跑一遍，看哪個真的「在看」。
測試方法：請媽媽的居服員確認白板上 12 個項目的真實狀態（4 個 box 1、2 個 box 2、6 個 null），這是 ground truth。同一張 RTSP 照片丟給四個模型，計算準度。
| 模型 | 命中 | 行為模式 |
|---|---|---|
| Gemini 2.5 Pro | 8/12 (67%) | 6/6 null 正確、off-by-one 錯誤，真的有在讀像素 |
| Gemini 3 Flash Preview | 6/12 | 非常保守，看不清就全回 null（這在醫療情境反而安全） |
| Gemini 2.5 Flash | 4/12 | 預設 box 1，剛好對 4 個 box 1 項目，是幻覺而不是識別 |
| Gemma 4 (26B-A4B-IT) | 3~4/12 | 兩次跑結果不一樣：第一次全 box 2、第二次全 box 1 |
最有意義的發現：跑同一張圖兩次讓偽答案現形。Gemma 4 第一次答「10 項 box 2 + 1 項 box 1 + 1 項 null」，第二次答「12 項 box 1」。兩次完全不同，同一張靜態圖，同一個 prompt。這證明 Gemma 4 根本沒在看磁鐵，只是在套一個預設樣板。
便宜模型「預設 box 1」這個偏誤特別危險，因為它剛好能騙過不注意的測試者：真實世界裡大部分項目本來就選 box 1（例如「完成/正常/穩定」通常是第一格），所以「全答 box 1」天然就有 30~50% 命中率。
Gemini 2.5 Pro 的 8/12 表現是最高的，錯誤都是「off-by-one」（看到磁鐵、算錯格子），至少是在做真正的視覺識別。但 2.5 Pro 免費版不開放 vision，要付費才能用。
Gemini 3 Flash Preview 的 6/12 看起來輸給 2.5 Pro，但它的錯誤類型完全不一樣：它的「錯」是把有磁鐵的項目讀成 null，不會產生錯誤的 value。這在醫療場景反而是最安全的行為 —— 寧缺勿錯永遠優於硬填。
第三回合：投票沒用、upscale 沒用
既然 Gemini 2.5 Pro 有 67% 準度，同一張圖跑 3 次取多數票應該能把 67% 拉高吧？
結果投票後掉到 6/12。為什麼？因為 2.5 Pro 的錯誤不是隨機噪音，是系統性偏誤：某個項目 3 次都答同一個錯的答案。投票對系統性錯誤完全沒用，它只會把多數的錯誤鎖定成最終答案。
接著試 pre-upscale：先用 ffmpeg 把白板區域裁出來、用 Lanczos 4 倍放大、加 unsharp，再丟 Gemini。直覺上放大應該有用，對吧？
ffmpeg -i wb.jpg -vf "crop=720:820:480:30,scale=iw*4:ih*4:flags=lanczos,unsharp=7:7:1.5" wb_up.jpg結果：2.5 Pro 從 8/12 掉到 6/12，3 Flash Preview 從 6/12 掉到 2/12。放大反而讓準度下降。
事後想通：Lanczos 是重採樣，不是超解析。它只是讓相鄰像素平滑插值，沒有增加資訊量。原本 3 像素的磁鐵放大成 12 像素，但那 12 像素是模糊的平均值，模型反而更難從中辨認形狀。
要真的增加資訊量必須用 AI 超解析（Real-ESRGAN 這類），而不是幾何插值。但那會在機器上增加 PyTorch + 模型的負擔。與其走這條，不如直接面對問題：RTSP 這條路本身就有上限。
關鍵 Pivot：把 human 設計進 loop
這是今天最重要的決策點。
我原本堅持 RTSP 全自動，理由是「靠人不穩定，請妹妹拍她都不拍」。這個理由本身沒錯 —— 強制依賴他人的流程一定會斷。但我把「靠他人」跟「靠自己」混為一談了。我自己每天可以拍照，不穩定的只是「依賴別人」這一環。
更深層的領悟：為什麼執著於「100% 自動」？因為我下意識想把人完全排除。但對一個給醫生回診參考的月報系統來說，人的角色不該是全被排除，而應該是最後一道驗證。理由：
- OCR 永遠有錯，醫療資料的錯誤比缺失代價更高
- 家屬（我）本來就是最終看月報的人，有修正權限跟動機
- 拍照的動作本身就是「我已經確認白板內容正確」的確認點
- 沒有必要為了系統 purity 去承擔「誤導醫生」的風險
這是整個專案最有價值的 design pattern 轉變 —— 從「zero-human automation」到「human-as-verifier」。具體分工：
| 角色 | 職責 |
|---|---|
| 我（家屬） | 看白板、判斷、拍清楚的照片、事後在 iDempiere 修正 OCR 誤判 |
| Bot + Gemini 3 | 把照片轉成結構化資料寫進 iDempiere、附上原檔 |
| iDempiere | 永久保存、提供 UI 讓月底回診時查閱 |
最可怕的情境 —— OCR 幻覺亂寫進 DB 誤導醫生 —— 被「我本來就要檢查 iDempiere」這個 policy 擋住了。系統可以不完美，因為人在迴圈裡。
Telegram Bot 架構
決定走 human-in-the-loop 後，剩下的工程問題是「怎麼把手機拍的照片快速送到 server」。選項比較：
| 方案 | 優點 | 缺點 |
|---|---|---|
| Telegram Bot | 零 app 安裝、即時回饋、從任何地方都能傳 | 要建 bot token |
| Syncthing 資料夾同步 | 純本機、無雲端 | 要裝 app + 手動移動檔案 |
| 自架 HTTP 上傳頁 | 不用 app | 要開 browser、每次登入 |
Telegram 明顯最低摩擦，而且我本來就用 Telegram 傳照片 debug。一個 @BotFather 建 bot、5 分鐘拿到 token、寫一個 Python 長輪詢腳本就搞定。
Bot 的最終能力：
| 使用者動作 | Bot 行為 |
|---|---|
| 📸 傳白板照片 | Gemini 3 Flash Preview OCR → 找今天紀錄 → update 或 create → 附加照片 → drain 文字佇列 |
| 📝 傳 LINE 居服員回報文字 | 加 [SHIFT|HH:MM] 前綴 → prepend 到今天紀錄的 Description 欄位 |
| 🕑 今天還沒紀錄時傳文字 | 存 pending 佇列，等照片來時自動塞入 |
| /pending, /clear, /id | 管理指令 |
Shift 標記：用時段而不是時間點
iDempiere 既有資料的 Description 欄位有一個我沒注意到的約定格式：
[NIGHT|20:13]今天把東西往外丟
[DAY|17:56]攻擊居服員格式是 [SHIFT|HH:MM]事件，新的在最上面，\n 分隔。照顧者三班制：
- DAY（早班）：07:00-17:59
- NIGHT（晚班）：18:00-23:59
- GRAVEYARD（大夜）：00:00-06:59
Bot 根據當下時間自動產生正確的 shift 標記。這個設計好處是醫生看月報時能直接對應到「哪一班回報的事件」，這對失智照護尤其重要 —— 同一個病人，不同班次的表現可能完全不同（例如日落症候群）。
Find-or-Create：同一天一筆紀錄
一個設計決策：同一天傳多次照片要建新紀錄還是更新舊的？
選項：
- (a) 每次都 create 新的 → iDempiere 一天可能有多筆，報表聚合需要 GROUP BY 日期
- (b) 同天 find-or-update → 資料乾淨，但要實作 OData filter 查當天紀錄
- (c) 帶時序保留所有版本 → 最完整但最複雜
選 (b)。理由是月底回診時醫生看的是「今天的狀態」，不需要看一天之內的修改歷史。實作核心：
def idempiere_find_today(token):
date_str = datetime.now().strftime("%Y-%m-%d")
r = requests.get(
f"{IDEMPIERE_URL}/models/z_momsystem",
headers={"Authorization": f"Bearer {token}"},
params={"$filter": f"DateDoc eq '{date_str}' and Name eq '{PATIENT_NAME}'", "$top": 1},
)
recs = r.json().get("records", [])
return recs[0]["id"] if recs else None還有一個巧妙設計：OCR 回 null 的欄位不進 PUT payload。這樣早上拍一次只填前 6 項、晚上拍一次只改後 6 項，早上的資料不會被晚上的 null 洗掉。整個合併邏輯在 Python 端就搞定，iDempiere 端只接受「明確填入」的欄位。
iDempiere 附件上傳的小坑
iDempiere REST API 的附件端點是 POST /models/{table}/{id}/attachments，payload 是 {"name": "...", "data": "base64..."}。踩了一個坑：重複檔名會回 409。
解法：上傳時把當下的 HHMMSS 塞進檔名 suffix。同一張照片重複上傳也不會衝突：
ts = datetime.now().strftime("%H%M%S")
fn = f"{orig.stem}_up{ts}{orig.suffix}"Systemd Service 自動重啟
最後收尾：bot 用 systemd service 跑，開機自動啟動 + 崩潰自動重啟。關鍵是設定 Restart=on-failure 跟 RestartSec=10：
[Unit]
Description=Tapo Caregiver Telegram Bot
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=tom
WorkingDirectory=/home/tom/tapo-caregiver
ExecStart=/home/tom/tapo-caregiver/venv/bin/python telegram_bot.py
Restart=on-failure
RestartSec=10
Environment=PYTHONUNBUFFERED=1
[Install]
WantedBy=multi-user.target成本：免費版剛好夠用
這個專案我原本因為 debug 爆量升級了 Google AI Studio 付費版。但實際跑 production 的時候算了一下用量：
- 晚上 8 點拍一次照片 = 1 次 Gemini 3 Flash Preview 呼叫
- LINE 回報文字 = 0 次（純文字不進 OCR，只是 prepend 到 Description）
- 一天總用量：1~2 次
Gemini 3 Flash Preview 的免費 tier 是 每天 20 次（GenerateRequestsPerDayPerProjectPerModel-FreeTier, limit: 20, model: gemini-3-flash），實際從先前的 429 錯誤訊息確認過。
也就是說 完整上線後可以馬上取消付費，免費額度就夠日常跑。debug 階段的付費只是為了不被 quota 卡住開發速度。
兩天下來的反思
1. 物理限制不是模型問題，不要用演算法去試
RTSP 畫面中磁鐵 3~5 像素這件事，不管換什麼模型、不管怎麼放大、不管怎麼 prompt，都解決不了。我浪費了兩輪嘗試才認清：先驗證訊號源的解析度是否足夠，再決定上面要疊什麼演算法。
2. 便宜模型會偽裝在看
Gemma 4 和 Gemini 2.5 Flash 在困難任務上會套預設答案（全 box 1 或全 box 2），這種偽答剛好能騙過不注意的準度統計。同一張圖跑兩次是揭穿偽答最便宜的方法 —— 真的在看的模型答案應該高度一致，套公版的會變。
3. 投票救不了系統性偏誤
Gemini 2.5 Pro 跑 3 次投票準度從 8/12 掉到 6/12，因為它的錯誤是系統性的（3 次都答同一個錯的答案）。投票只對隨機噪音有用，對系統性偏誤沒用。想救系統性偏誤，要用不同模型交叉比對，而不是同一個模型多次跑。
4. Human-in-the-loop 不是妥協，是正確設計
我原本想做 100% 自動化是出於「系統純粹」的直覺。但對醫療情境來說，把人排除才是風險來源。正確問題不是「怎麼不靠人」而是「人在哪個環節最有價值」。答案是：人當最終 verifier，機器做勞力密集的 OCR + 結構化 + 儲存。
5. 工具思維 vs 平台思維
我原本想把 RTSP 攝影機變成一個「全知白板記錄系統」，這是平台思維，野心大但難。pivot 之後變成「Telegram bot 幫我打字少打一些」，這是工具思維，目標小但能跑。工具思維的上線速度 ≫ 平台思維的完美程度。
6. 讓 AI 自己跑模型賽馬
過程中我讓 AI 自動跑一圈 Gemma 4 / 2.5 Flash / 2.5 Pro / 3 Flash Preview，把命中率、錯誤類型、各自的 observation 都列出來。我只要看那張表就能判斷用哪個。這種「讓 AI 幫你比較 AI」的 meta-loop 是 vibe coding 很爽的一點 —— 選型決策從「讀文件猜性能」變成「直接實測算分」。
最終上線狀態
| 組件 | 狀態 |
|---|---|
| Telegram bot（@your_bot_name，白名單限制） | ✅ LIVE |
| Gemini 3 Flash Preview OCR (schema-constrained + box index + layout map) | ✅ |
| iDempiere REST find-or-create + attachment upload | ✅ |
| Description shift tag (DAY/NIGHT/GRAVEYARD) 自動 prepend | ✅ |
| pending notes queue（文字先到、照片後到的情境） | ✅ |
| systemd service 開機自動啟動 | ✅ |
| PTZ ONVIF 控制（暫時不用，因為 pivot 到手機路線） | ✅ 備用 |
每日 SOP：
- 晚上 8 點我拍一張白板照片
- Telegram 分享給
@your_bot_name - Bot 跑 OCR + 寫 iDempiere + 回覆結果（10~20 秒）
- 看到有讀錯的，打開 iDempiere 手動改
- 居服員白天在 LINE 的回報，我看到時直接貼到 bot，自動 prepend 到今天的 Description
- 月底回診時點開 iDempiere 給醫生看趨勢
總結：這篇文章的「二階 vibe coding」
這篇文章本身也是 vibe coding 的產物 —— 我叫 AI 把兩天的工作回溯成一篇技術文，自己只負責審核跟指正敏感資料。這種「AI 幫你跟 AI 協作的過程寫回顧」也算是一種 meta-loop：決策的當下有 AI 幫忙驗證，事後有 AI 幫忙紀錄。我負責方向跟價值判斷，剩下的雜活都給 AI。
兩天下來最重要的一句話：「vibe coding 不是減少思考，是加速思考。」 AI 幫你快速驗證假設、生成原型、寫測試、跑實驗、甚至幫你寫反思文章。但你要知道該往哪個方向走、什麼時候該 pivot、什麼時候該停手。AI 是踏板車，你是駕駛。