預算有限，不代表只能用撐不久的臨時系統。

小企業真正怕的，不只是開發費

一套系統上線後，還有主機、資料庫、備份、憑證、寄信、網域與監控。當使用量不大時，傳統架構的固定成本與維護工作，往往比實際流量更重。

這也是許多數位轉型專案一開始就做得太大：為了預想未來所有需求，企業先買下一整套基礎設施，卻還沒證明第一個流程是否有人願意使用。

我們希望成本跟著實際使用成長，而不是在第一天就為還沒發生的規模付費。

店小二目前實際使用哪些 Cloudflare 服務？

Workers：同一個入口處理網站、API 與 LINE Webhook

管理介面、登入流程、庫存 API 與 LINE Webhook 都由 Cloudflare Workers 執行。企業不需要另外維護一台長時間開機的應用伺服器；部署版本、網域與執行紀錄也能集中管理。

D1：保存企業、庫存與同步紀錄

D1 是相容 SQLite 的受管資料庫。店小二用它保存企業帳號、庫存品項、資料來源設定與同步結果，並在每次查詢時限制資料只能由所屬企業存取。

D1 不是 PostgreSQL，也不應被包裝成適合所有資料規模。現階段庫存搜尋採品號與品名前綴查詢，匯入也保留筆數限制；如果未來的搜尋型態與資料量超過它合適的範圍，應該根據實際瓶頸更換對應元件，而不是假裝沒有取捨。

Cron Triggers：定時同步，不需要常駐排程主機

企業可以讓店小二定期讀取既有庫存 API。排程會隔離每個資料來源：單一來源失敗不會中斷其他企業，卡住過久的同步也能被標記失敗並重新執行。

Email Service：寄送一次性登入連結

登入不要求另外記一組密碼，而是寄送短時間有效的 Magic Link。連結只能使用一次，建立使用者、企業與登入 Session 的資料庫操作會一起成功或一起失敗，避免連結被消耗卻沒有完成登入。

「統一管理」對預算有限的企業有什麼意義？

• 少一組基礎設施：應用程式、資料庫、排程、寄信與網域集中在同一平台。
• 先承擔實際流量：不用為早期低使用量準備常駐的大型主機。
• 部署可追蹤：每次上線都有版本，失敗時能確認目前運行的是哪一版。
• 權限可分離：部署 Token 只開必要資源，不必分享完整帳號權限。
• 擴充有路徑：先用薄的查貨流程，需求成立後再加入新的服務。

這不代表「永遠免費」。Cloudflare 各項服務都有方案、額度與計費方式，企業用量成長後仍會產生成本。真正的優勢是固定負擔較小，並能讓成本與實際使用更接近。

資料與憑證怎麼處理？

庫存 API Token 與 LINE 憑證不會以明文回傳到管理畫面。寫入前會加密，管理 API 只顯示「已設定」狀態。每筆庫存、資料來源與 LINE 串接也都帶有企業邊界，避免不同公司的資料混在一起。

任何雲端平台都不能自動保證安全。應用程式仍必須做好輸入驗證、權限檢查、同源保護、錯誤隔離、秘密管理與資料刪除流程。Built on Cloudflare 是架構事實，不是 Cloudflare 對店小二的官方背書。

什麼時候才需要 Durable Objects？

目前的免費查貨功能不需要 Durable Objects。查詢、同步與管理操作可以由 Workers 加 D1 完成，刻意加入更多元件只會增加理解與維護成本。

當企業需要真正的數位店小二，下面這些情境才可能需要具狀態協調：

• 同一個任務要跨越數分鐘、數小時，等待人工核准後繼續。
• 同一位客戶或同一張訂單的事件必須依順序處理。
• 多個 Agent 工具不能同時重複建立訂單或送出報價。
• 管理者需要即時看到任務進度或與 Agent 保持長連線。
• 工作暫停後必須從原本狀態恢復，而不是重新開始。

我們如何決定要不要增加一項技術？

1. 先確認問題真的存在：沒有具體失敗情境，不先加新服務。
2. 選最薄的可行邊界：能直接修正來源，就不再包一層一次性工具。
3. 把企業資料與執行狀態分開：資料保存、任務協調各自使用合適元件。
4. 保留人工接手：自動化失敗或超出權限時，流程必須安全停下並交給人。
5. 用實際用量決定下一步：根據延遲、錯誤率與成本調整，而不是為技術名稱升級。

Cloudflare 是基礎，企業流程才是產品

好的平台讓我們少花時間照顧主機，把時間放在資料 Mapping、LINE 分流、權限與企業規則。但客戶真正購買的不是 Workers 或 Durable Objects，而是更少的重複工作與更可靠的交付流程。

所以店小二會繼續維持這個順序：先用簡單功能證明價值；遇到真實流程，再用必要的技術把它可靠地完成。