Overpower 的 AI 架構，現在是可控、可追、可學習的純腳本系統。
我們把舊的模型入口保留成相容介面，但正式核心已改成站內 script adapter。 聊天草稿、欄位建議、OCR、報表、pending summary 與 pipeline， 都回到同一套本地邏輯裡完成。
聊天草稿、欄位建議、OCR、報表皆由站內腳本處理
所有舊介面仍可走同一層，但底層已改成 local script
工作流、聊天、vision、reports、pipeline
回應 shape 由程式定義，不再依賴外部模型自由發揮
資料從哪裡進，腳本在哪裡學，結果又怎麼輸出
現在的架構不是把 prompt 丟出去等回覆，而是先把資料結構化，再由記憶、規則與固定輸出骨架完成整條鏈。
LINE、聊天紀錄、最近回覆語氣
tabular、key-value、半結構化文字
尺寸檢測、OCR、連結/日期/金額抽取
欄位、pending、狀態、歷史操作
舊介面還在，但現在不會把資料送出去找外部模型。 Adapter 只負責把舊入口轉接到本地腳本引擎，確保任何遺漏 import 也不會悄悄回退到遠端模式。
- 把訊息、匯入文字、圖片 OCR 與案件資料轉成統一結構。
- 日期、網址、金額、status、欄位別名都先在這層整理。
- 聊天草稿會讀 recent messages、ai_memory 與相似回覆範例。
- 學習能力來自工作區資料與歷史訊息，不是外部模型權重。
- 哪些欄位該補、哪些情境要 follow-up，都由明確規則決定。
- 報表、pending、operator 與 workflow 共用相同的輸出邏輯。
draft、summary、priority、next action
date、url、number、status、short text
OCR lines、dates、phones、amounts、urls
title、markdown、charts、weekly/monthly summaries
因為每條輸出路徑的來源資料、規則順序、fallback 方式都寫在程式裡， 所以我們可以真正測、真正 diff、真正修，而不是只調 prompt。
每個功能都有自己的腳本決策鏈
你可以把它理解成多條專用工作流，而不是一個萬能黑盒。每一條鏈都針對產品實際操作去設計。
聊天草稿不是猜一句，而是讀整段關係
訊息進站後，腳本會先抓最近對話、語氣範例、pending 線索，再輸出草稿與下一步。
收進 inbound message 並回補 recent chat history。
讀 ai_memory、最近草稿與常見回覆範例。
判斷情緒、類型、是否需要人工介入。
依工作區語氣與上下文產生可直接送出的 draft。
輸出 draft、summary、priority、humanNeeded 與 nextAction，不再只是一段自由文字。
"engine": "local-script",
"shape": "stable",
"fallback": "programmed",
"debuggable": true
}
因為產品裡真正需要的不是無上限發揮，而是可驗證、可追蹤、可控成本的輸出。 這種架構最適合 CRM、案件管理、聊天草稿與報表場景。
腳本式 AI 和舊式 token AI 的差異，不只是成本
我們不是單純把模型拔掉，而是把整套邏輯改成更適合產品工作流的形狀。優勢變清楚，邊界也要說清楚。
- 回傳格式穩定，debug 時可以直接追到程式與資料來源。
- 成本可控，不會因 provider 漂移或 prompt 波動造成回應失真。
- 聊天、匯入、OCR、報表能共享同一套規則與記憶。
- 它擅長結構化工作流，不是拿來做無邊界的創意寫作模型。
- 照片場景理解目前聚焦 OCR 與版面資訊，通用物件辨識仍有上限。
- 若未來重新引入外部模型，會被隔離在明確的 opt-in 路徑內。
真正撐住這套架構的，是這幾個核心檔案
這不是只有一頁文案。聊天、匯入、OCR、報表與 adapter 之間現在已經共享同一個 local-script surface， 所以未來要補能力，也能沿著同一條路往前擴。