這是一篇關於 Vibe Coding（憑感覺邊聊邊寫）在物聯 AI 開發上的實戰紀錄。主題聽起來很酷，但實情是：我只是想解決一個很平凡的問題 —— 怎麼把家裡長照白板上的磁鐵打點，自動變成醫生回診時能看的資料。

這篇會誠實記錄這一晚跟 AI 協作的過程、做對的決策、撞到的牆、以及學到的方法論。不是成功故事，中間我還沒跑出一份真正可用的資料。但我覺得過程本身比結果更值得寫下來。

什麼是 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 試。

寫完測下去，兩個結論：

1. Gemma 4 確實吃圖 —— 這是好消息
2. 但它嚴重幻覺 —— 它把日期讀成「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，核心設計有四塊：

1. 嚴格列出 12 個欄位名稱 + 每個欄位的合法 enum，告訴模型「只能從清單裡選，不要自由發揮」
2. 明確定義磁鐵規則：磁鐵貼在選項上 = 選中；磁鐵在左側待命區 / 沒看到磁鐵 = 未填（null）
3. 強制輸出信心度：high / medium / low，並規定「寧可標 low 也不要亂猜」
4. 禁止事項明確化：不要輸出清單外的項目、不要用清單外的值、不要把空白當選中

這個 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 成功，但沒有 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：

1. 晚上 8 點我拍一張白板照片
2. Telegram 分享給 @your_bot_name
3. Bot 跑 OCR + 寫 iDempiere + 回覆結果（10~20 秒）
4. 看到有讀錯的，打開 iDempiere 手動改
5. 居服員白天在 LINE 的回報，我看到時直接貼到 bot，自動 prepend 到今天的 Description
6. 月底回診時點開 iDempiere 給醫生看趨勢

總結：這篇文章的「二階 vibe coding」

這篇文章本身也是 vibe coding 的產物 —— 我叫 AI 把兩天的工作回溯成一篇技術文，自己只負責審核跟指正敏感資料。這種「AI 幫你跟 AI 協作的過程寫回顧」也算是一種 meta-loop：決策的當下有 AI 幫忙驗證，事後有 AI 幫忙紀錄。我負責方向跟價值判斷，剩下的雜活都給 AI。

兩天下來最重要的一句話：「vibe coding 不是減少思考，是加速思考。」 AI 幫你快速驗證假設、生成原型、寫測試、跑實驗、甚至幫你寫反思文章。但你要知道該往哪個方向走、什麼時候該 pivot、什麼時候該停手。AI 是踏板車，你是駕駛。