今天這套營運跑在 8 條流程線、55 個節點、18 個資料斷層上，靠 AM／OP／PD／業助／司機／小作所六種角色的默契撐住。 這份是另一種可能：同一套流程，一個人 ＋ 八個常駐 Agent。人不再是節拍器，只在三個地方按下決定。 2026-07-20 已依循環服務系統討論會議更新。 先看那八條線怎麼變成一條、這套系統實際上要蓋什麼（一個循環包裝資料庫，外面包三個入口）， 再看那一天的 24 小時與要走到那裡的實際路線。
現況的路網圖有 8 條線、55 個站，因為每條流程都自己長了一套做法。但抽象之後會發現： 2B 出貨、回收、清潔、開發、2C 出貨、產製、業助、永續電商——全部都是同樣六件事在不同場景重複發生。 所以未來不需要八條線，只需要一條。八條線降級成「進口標籤」，55 站全部歸位到六個站。
上一節講的是「流程」——事情怎麼跑。這一節講的是「東西」——真的要蓋，蓋出來的是什麼。 一句話：一個循環包裝資料庫，外面包三個入口、三個出口。 它長得像一套 SaaS，但第一個客戶是配客嘉自己——先把自己的 55 站跑順，架構上再談對外。
現況 21 個斷層裡最貴的五個，全部卡在「資料進不來」。三個入口分別對付三種進不來的方式。
要解的問題：電話是四種管道裡唯一零記錄的（2026-07-20 會議再次確認）。小作所開發、世界先進稽查臨時特收、司機在廠區找不到窗口、追款——講完就消失，換個人接手等於從零開始。
怎麼做：公司號碼走雲端總機。通話自動錄音 → 逐字稿 → AI 抽出關鍵欄位（對象、主題、承諾了什麼、日期、數量）→ 生成一筆「聯絡紀錄」自動掛到對應的客戶／小作所／司機身上。抽不確定的欄位標成待補，不猜。
也能外撥：例行催收、開發名單初訪——AI 先撥通、講開場，接通後轉人，或留下結構化的回覆紀錄。
邊界：AI 不做承諾、不議價、不報價。它只負責兩件事——留下痕跡、抽出欄位。
要解的問題：LINE 是日常主力——三家物流商各一群、每個小作所各一群、醫院回收群、部分客戶群，加上付款末五碼散在私訊。有記錄，但非結構化，全靠人逐句轉填表格。這是全系統最大的資料斷層。07-20 會議確認得比原本更嚴重：司機實收數的回報流程「其實沒有」，小作所到貨也只會說「大概幾板」、不點品項與 pcs。
怎麼做：助手常駐在既有的群組裡，不建新群、不換工具、不改變任何人的習慣。老師照原本的方式回一句話，助手把它變成欄位：
也會主動：週四詢量話術自動發、沒回的下午自動再催一次、規則能確定的事當場回（滿不滿門檻、走專車還是大榮）。司機回報短收時，自動比對「不回收或短收須經配客嘉同意」，不符就開例外任務。
邊界：不代替人回答客戶的商業問題。只收資料，只回規則能確定的事；規則判不了的，往上丟給人。
要解的問題：禾洛後台、大榮 webEDI、上海商銀網銀、ERP、五個電商平台後台——資料都在，但要人每天去點、去查、去搬。
怎麼做：純爬蟲與 API，這一路沒有 AI。穩定比聰明重要：貨態自動回填、ERP↔禾洛庫存每日比對告警、銀行明細用金額＋末五碼自動匹配 AR。順便把永續線那台裸 IP 轉檔測試機轉成正式服務。
兩張核心表就夠：主資料（誰是誰——客戶、廠區、供應商、小作所、物流商、司機、產品、倉庫）與 物流事件檯（每一次流動只登記一次）。主鍵＝ERP 單號 ＋ 產製批號。
它真正的價值是把一個箱子的一生接起來：
現在這條命線斷在好幾個地方——產製批次在叫貨總表、入倉登記、物流總表之間沒有共同的 key。 接起來之後才會有真正的循環次數、真正的碳排、真正的資產盤點，而不是估的。
現有的 Google Sheets 與 bitable 不會消失，也不用大家搬家——它們變成這顆心臟的視圖，人只填一次。
任務、警示、文件。派車單、放行單、對帳單、小作所收據、嘜頭——從資料庫取數套模板，不再人工重排。
DAN、雙向滿載率、服務疊加深度、循環次數中位數、資產現在在哪裡。現在是月底人工湊，之後是即時的。
ESG 報表、單一箱體的循環履歷、EPR／PPWR 合規數據。這是三個出口裡唯一未來真的可能收費的東西——但前提是前兩個先跑順。
為什麼這個形狀既能自用、也留著對外的餘地：
還沒解決的題目：電話錄音與 LINE 訊息裡有大量個資與商業資訊。保存多久、誰能看、客戶與小作所要不要事前告知——這在真的接線之前就得先定，不是上線後再補。
切換不同的日子看——營運的節拍不是每天一樣的：週四要詢量、週五要媒合派車、每月 25 號要月結。 橘色卡片＝需要你本人的三個決策點，其餘全部無人值守。
3 個決策 · 約 40 分鐘 · 其餘時間，八個 Agent 輪班。（平日兩件，週五多一件量能取捨）
共同點：每一個決策都是「只有人能給的事實或取捨」——規則衝突要定版、量能缺口要選方案、新規則要不要收編。 沒有一件是搬資料、查單號、轉填表格。
不是把七條流程各寫一套程式。抽象之後全部都是同一件事：被觸發 → 確認幾件事 → 依規則判斷 → 產出文件或通知 → 登記 → 對帳。 所以只需要八個模組，每個模組長成一個 Agent。
現況版網站上那 18 個紅色 ⚠ 標記，逐條對上負責消除它的 Agent 與階段。這張表就是開發的驗收清單——每消掉一條，就在路網圖上熄掉一個紅點。
| # | 現況 Gap | 誰來消 | 階段 |
|---|
不是一次做完。順序是有理由的：先做最省人力又不動現有任何表的，最後才做地基以外的華麗功能。 Phase 0 今天就能做，而且不用寫程式。
| 階段 | 做什麼 | 為什麼是這個順序 | 大約 |
|---|---|---|---|
| Phase 0 不寫程式 |
把事實對齊。①定版守品 EBHA 包裝數（G11 800 還是 700）②統一命名規範為「公司全名（品牌名）」（G15）③訂出貫穿產製→入倉→出貨的統一批號規範（G9）④明確廢止停更的舊表（G18） |
這四件事不做，後面所有系統都會把矛盾寫進資料庫。批號是資料模型地基，做中台前一定要先定。 | 1–2 週 |
| Phase 1 | M3 最小版 ＋ M2 最小版。挑一個小作所群組做 LINE 結構化回報落表；規則引擎只放兩條（15 箱專車/大榮分流、回收滿 3 箱門檻） | 不動現有任何表，兩週能上線驗證，直接省掉每週四逐所詢量再手動謄寫的工。錯了也只影響一個群組。 | 2–3 週 |
| Phase 2 | M5 事件檯 ＋ M7 缺漏警示（先只做 2B 出貨線）。以 ERP 單號＋批號為主鍵，現有各張表改成它的視圖 | 資料模型地基。其他七個模組都是往這張檯帳上讀寫的介面。48 小時未登記的警示先用人工週檢也能跑。 | 1–2 個月 |
| Phase 3 | M6 文件生成 ＋ M8 外部整合。三家物流表單／司機放行單自動出；禾洛貨態、大榮 webEDI、銀行明細自動回填 | 依賴 M1／M5 的資料才有東西可生成。此時把裸 IP 轉檔測試機（G16）一起轉正式服務。 | 1–2 個月 |
| Phase 4 | M4 全面排程化 ＋ M7 銀行對帳自動匹配。週四詢量、週五媒合、每日貨態、月結、每季採購、每週庫存巡檢全部自動開單 | 收尾。把人從「記得週四要問、週二要給車牌、25 號要對帳」的節拍器角色解放出來。 | 1 個月 |
刻意不自建。全部押在你已經在用、團隊已經有習慣的東西上——換工具的成本比寫程式高。
| 模組 | 建議載體 | 理由 |
|---|---|---|
| M5 事件檯 | Lark bitable（或 Postgres + bitable 當視圖） | 團隊已在 bitable 上工作；先求單一真相，不求技術漂亮 |
| M3 結構化回報 | LINE Messaging API + Claude 解析自然語言回覆 | 在對話發生的地方收資料，不逼小作所老師與司機換工具 |
| M2 規則引擎 | bitable 設定表 + 判斷函式 | 規則要讓 OP 主管自己改，不能寫死在程式裡 |
| M4 排程 | Lark 任務 + cron | 現有習慣，薄薄一層即可 |
| M6 文件生成 | 模板引擎輸出 PDF | 從 M1＋M5 取數套模板，各物流商一種模板 |
| M8 連接器 | 既有禾洛爬蟲升級 + 大榮 webEDI + 銀行明細匯入 | 爬蟲雛形已經有了，升級成每日自動即可 |
| 部署 | Zeabur（與現有站同一套流程） | 已驗證過的部署路徑，不新增維運面 |
哪些是事實，哪些是想像：