冰棒訂購系統與多據點營運系統 — 客製接案完整規劃

兩案都可行，2026-09-23 已完成主要架構定案，尚未進入開發（等訪談與簽約，見 待開工前檢核）。

第一案（冰棒／食品廠，已報 20～25 萬，定案後上修 22～24 萬）：官網＋散客商店改用 WordPress + WooCommerce（匯款／超商取貨付款／藍新或綠界金流三種付款方式，標準配置無授權費）；廠商 B2B 系統維持 Django + PostgreSQL。兩者同一台主機、不同容器、不同資料庫，網路互相隔離；散客與廠商訂單靠 WooCommerce Webhook + REST API 整合進銷存，不直連資料庫。

第二案（多據點營運，28～35 萬）：海生館先試點，核心是把手寫進銷存電子化成「資料底座」，AI 排班／預測留到累積 3～6 個月乾淨資料之後才談。

開工前必辦：範圍文件客戶簽認、與表妹的書面約定（里程碑、退出通知期）、WT 接案身分與發票決定、兩客戶的必要訪談項目（見 訪談清單）。

整理日期：2026-09-21 狀態：需求整理中，尚未簽約。兩案為不同客戶（彼此認識），不能共用資料模型，但可以共用技術架構與開發流程。

1. 兩案一句話定位

2. 可行性總評

2.1 技術：可行，兩案都不需要冒險的技術

• 第一案是標準的「帳號 / 商品 / 訂單 / 後台」系統，加上 LINE Messaging API。全部都是成熟技術，有大量中文教學與範例。
• 第二案技術更輕：一個手機好填的表單 + 資料庫 + 報表工具。真正的難度在資料欄位設計和導入。
• 唯一領域邏輯複雜的是第一案的「配方成本 / 損耗 / 毛利」，這塊必須第二期，且訪談要另開兩三輪。

2.2 能力：可行，但要把「執行者是大二學生」寫進計畫

團隊分工建議：

這位外援怎麼用（原則）：

• 定位是「外援」，不是團隊裡的固定角色——不掛名、不寫規格、不簽驗收，需要時調用，平常不占用他的時間。
• 不是執行者，是「第二意見」：他說的話要認真聽，尤其是他熟悉的部分。
• 三個時間點各安排一次諮詢，不要等出事才找他：①簽約前（範圍、報價是否合理）②開發中期（架構與資料模型是否有業界常見的坑）③上線前（驗收清單有沒有漏掉這行業的慣例）。
• 每次找他前，WT 先把具體問題列出來，不要空手去聊（見 07 檔 3b）。
• 他若跟這份規劃書的判斷衝突，以他的專業意見為準去覆核，不要因為文件已經寫好就不改——這份文件是 WT 和 Claude 商業／技術判斷的產物，不是請他來背書用的。

要正視的事實：

• 表妹「知識比你多一點，經驗不比你多」→ 她會寫程式，但不會自然知道要做備份、權限檢查、輸入驗證、錯誤處理。這些必須寫成明確的驗收條件，不能靠她自覺。
• 她有課業：10 月底期中、12 月期末（2026-09-25 會議確認：11 月沒有考試）。開發時程要避開，或那兩週不排交付。
• 人員風險：學生可能中途沒空。所有程式碼必須在 git、有 README、有部署文件，任何人接手能在一天內跑起來。這是你保護自己的方式。
• 你自己的位置：你不寫程式，但你要看得懂進度。每週一次 30 分鐘 demo（在測試環境實際點給你看），不接受口頭「做好了」。

對策（已寫進各案規劃）：

1. 規格書先行，表妹拿到的是「要做什麼、驗收怎麼算過」，不是模糊描述。
2. Claude 做程式碼審查與測試案例設計，補她經驗的缺口。
3. 用「後台自動生成」的框架（Django admin）省掉最花時間又最容易做爛的後台 UI。
4. 時程估算 ×1.5，並保留 2 週緩衝不排任何事。

2.3 時間：緊，兩案必須錯開；第一案現在有兩個硬期限

你目前手上：嘖嘖募資（9/21–24 定案）、TTQS 評核簡報、研考會簡報案（下週交初版）。

2026-09-23 更新：第一案客戶端有外部硬期限——10/15 要交一版 Demo（給客戶寫企劃申請補助用）、11/30 要交一版初步可執行的系統。這把第一案的開發壓縮到原本規劃的一半左右，詳細拆解與風險見 01 檔第 4 節。第二案時程不受影響，維持原規劃。

2026-09-25 會議修正：表妹期中考是 10 月底（不是原先誤植的 11 月初），11 月沒有考試，下一次考試是 12 月期末。這代表 10/15 Demo 之後、11/30 執行版本之前的空檔要讓她準備期中考，但 11 月整月反而可以全力衝刺，時程表已依此調整。

兩案同時全速開發本來就不建議，現在第一案還被壓縮，第二案的開發實質上要往後延，維持「先做需求訪談與資料設計，12 月起才真的開發」的節奏。

2.4 價格：第一案要靠範圍文件保護，第二案要把導入算進去

詳見各案規劃書的「報價拆解」。原則：

• 已報區間不推翻，定義為「第一階段範圍」。
• 建置費之外，主機月費與維護合約一定分開列。不列就是免費包一年。
• 第一案 B2B「廠商只看自己的訂單」是基本功能，不是加購。

3. 共用技術架構（兩案一致，降低表妹的學習成本）

使用者（手機 / 電腦 / LINE 內）
        | HTTPS
        v
Cloudflare（DNS、憑證、基本防護）
        |
        v
VPS 一台（Docker）
  +- Django 應用（官網頁面、廠商下單頁、API、後台 = Django admin）
  +- PostgreSQL（資料庫）
  +- [第二案] Metabase（報表與儀表板，自架免費）
  `- 每日備份 → 物件儲存（Cloudflare R2 或 S3）
        |
        v
LINE Messaging API（webhook 進、push / reply 出）

為什麼是 Django：

• 後台免費：Django admin 自動生成商品／訂單／廠商管理介面，含權限。第一案的「後台管理」模組因此省掉 30～40% 工時，而且是學生做不壞的部分。
• Python：你自己用過 FastAPI + SQLAlchemy，看得懂；學生在校多半學過 Python；AI 輔助寫 Django 的品質穩定。
• 一套架構兩案共用，第二案的輸入表單直接沿用第一案的專案骨架。

不選的理由：

• Next.js + Supabase：學生可能更熟 React，但後台要自己刻，且你看不懂 JS 生態的問題。
• 純低代碼（AppSheet / Airtable）：第二案曾考慮，但既然表妹能寫程式、第一案已經要建 Django 骨架，第二案用同一套比較划算，而且資料在客戶自己的資料庫裡（客戶會在意）。報表層仍用 Metabase，不自己畫圖表。

主機成本估算（給客戶的月費）：VPS 約 NT$300～600／月、網域約 NT$500／年、R2 備份幾十元、LINE 官方帳號依用量 0～1,400／月。

4. 合約與流程（兩案共用）

1. 需求訪談（1～2 次，用 04_需求訪談問題清單.md）
2. 規格書 + 範圍文件簽認（在範圍／不在範圍／另計清單、驗收條件）→ 這一步是防爆範圍的唯一保障
3. 簽約與付款：30%（簽約）／40%（測試環境驗收）／30%（上線驗收）
4. 開發：每週 demo 一次，測試環境給客戶點
5. 驗收：對照驗收清單逐條打勾，不接受「感覺不對」
6. 保固 30 天：修 bug，不加功能
7. 維護合約：月費（含主機）或年約，另簽
8. 變更單：任何範圍外需求走變更單，寫清楚工時與費用，客戶簽了才做

帳號歸屬（一定要在客戶名下，不然違反平台條款或日後糾紛）：

• 網域、主機、Cloudflare：客戶的帳號，你們是協作者
• LINE 官方帳號 / LINE Developers Provider：客戶的 LINE Business ID（LINE 條款規定 channel 資料屬於 provider，代客建在自己名下可被停權）
• 程式碼：git，交付後歸客戶，你保留可展示權（寫進合約）

5. 你可能還沒想到、但要放進報價或合約的

• 個資法：廠商帳號、消費者詢價資料 → 網站要有隱私權聲明，資料只用於訂單。你不做法律諮詢，但要提醒客戶。
• 電子發票：第一案若日後對消費者線上販售，發票是跑不掉的，屬第二期金流範圍。
• LINE 費用是客戶付的：訊息費、聊天進階方案 100／月，寫進「客戶自付項目」。
• 資料所有權與退出：合約寫明客戶隨時可取得完整資料庫匯出。
• 停機與備援：不承諾 99.9%，承諾「每日備份、故障 1 個工作天內回應」。
• 訓練與文件：操作手冊 + 一次教學，另外的教學按次計費。
• 表妹的酬勞與交接條款：你跟她之間也要有簡單的書面約定（里程碑付款、程式碼歸專案），避免中途變數。

6. 檔案索引

• 01_第一案_冰棒訂購系統_規劃.md — 模組、階段、資料模型、驗收、報價拆解
• 02_LINE官方帳號_可行性與下單流程研究.md — LINE AI 回覆、費用、個人 LINE 下單進資料庫的四種做法
• 03_第二案_多據點營運系統_規劃.md — 資料模型、輸入設計、報表、導入計畫、報價拆解
• 04_需求訪談問題清單.md — 兩案訪談題目
• 05_客戶溝通_範圍說法與交付項目表.md — 對客戶的說法、交付項目表、合約附件草稿
• 06_風險與問題預估_應對手冊.md — 依階段列出可能發生的問題、徵兆、預防與應對（★ 為最關鍵）
• 07_待補資訊與開工前檢核.md — 要跟客戶、表妹拿的資訊，你要做的決定，開工前檢核表
• 08_技術方案_WordPress可行性評估.md — 第一案能不能用 WordPress：分模組可行性、外掛與費用、資安風險數字、三個方案比較

已報區間：20～25 萬（定義為第一期）；因散客購物車＋金流併入第一期（2026-09-23 定案），實際報價上修為 22～24 萬，仍落在區間內 定位：把現有的 LINE 訂購流程電子化，不是做漂亮網站。響應式網站＋散客商店（WordPress） + B2B 廠商下單 + 後台管理 + 資料庫 + LINE 入口／通知 不做：App、B2B 廠商端金流（廠商仍走匯款、月結；金流僅用於散客商店）、庫存成本與批次到期（第一期）、AI 客服自建、完整 LINE Bot 對話流程 最大風險：客戶以為 22～24 萬包含整套完整系統（尤其是庫存成本這塊）→ 用 05 檔的範圍文件在簽約前釘死

技術架構定案（2026-09-23）：本案是兩個獨立系統，都在第一期交付：

1. 官網＋散客商店：WordPress + WooCommerce，含品牌介紹、商品展示、消費者購物車、三種付款方式（匯款／超商取貨付款／藍新或綠界金流）。標準配置，不是客製開發，無 B2B 那類授權費風險。詳見 08 檔 第 1、6 節。下面 A、B 模組的內容已由 WordPress 取代，保留在此僅供對照，實際規格與驗收以 08 檔為準。
2. 廠商 B2B 系統（下面模組 C 廠商下單、D 後台、E LINE 整合）：維持 Django + PostgreSQL，是本檔主要規劃內容。

兩者跑在同一台主機的獨立容器、獨立資料庫，用子網域分流，網路互相隔離（08 檔 6.2 節）。兩邊訂單資料要匯總成進銷存，做法是 WooCommerce 內建 Webhook 推送訂單到 Django 的接收端點，不是直接連資料庫（08 檔 6.5 節）——這個接收端點的「輕量版」（先忠實記錄散客訂單，不做完整庫存計算）可以在第一期先做，完整庫存扣減／回寫留第二期，見下面模組 E2 與報價。

1. 階段切分

第一期 MVP（20～25 萬）— 目標：廠商可以在 LINE 裡下單，老闆在後台處理，全程有紀錄

第二期（另計，依需求選購）

進階擴充（第三期以後）

• 多品牌／多站
• 與會計軟體串接
• 廠商 App（只有在 LIFF 明顯不夠用時才考慮）

1b. 進銷存三層資料庫設計（2026-09-25 會議定案，第二期範圍）

WT 與表妹開會把「庫存／成本／毛利」這塊原本模糊的第二期項目談出具體架構。核心問題：一支冰棒可能用多種原料（例如百香果冰棒＝百香果＋檸檬），同一種原料也可能被多種冰棒共用（檸檬同時用在百香果冰棒和荔枝冰棒）——這是多對多關係，資料庫要拆成三層，同一個資料庫、三張資料表，不是三個獨立資料庫（避免跨資料庫同步失敗，例如扣了 A 表但 B 表沒扣成功，資料就對不上）。

三層結構

第一層：原料進貨與損耗（RawMaterial + RawMaterialBatch）
  - 採購紀錄：原料名稱、供應商、進貨重量、進貨價格、進貨日期
  - 處理後可用量：去皮／去籽／清洗後實際剩下多少（例如 1000 斤西瓜 → 去皮後剩 500 斤瓜肉）
  - 長期累積這兩筆數字，可以自動算出平均損耗率／去皮率
        |
        v（配方比例連結）
第二層：配方表（Recipe，商品 × 原料的關聯表）
  - 每一種冰棒對應用了哪些原料、各自用量（例如：百香果冰棒 = 百香果 80g + 檸檬 20g）
  - 這一層專門解決「一對多、多對多」的原料關係，不會因為原料共用就重複記錄
        |
        v（依配方比例換算耗用量）
第三層：成品／庫存（FinishedGoods + StockLocation）
  - 已完成的成品數量、存放地點（**可能有 2～3 個不同存貨地點**，不能預設只有一處）
  - 賣出後扣減庫存，回傳給網頁顯示「還有幾支可以用」

關鍵設計原則（會議中確認）

• 原料實際使用量是「批次事後記錄」，不是即時扣庫存：工廠可能一整週處理完一批草莓才回填紀錄，不是做的當下即時扣。這代表系統只能事後知道「這批用超了／剩太多」，不是即時庫存動態——這個限制要讓客戶知道，不是系統做不到，是工廠實際作業流程就是批次處理。
• 加分功能（非核心，第二期做完基礎再加）：損耗率超過閾值（例如 30%）提示「建議換一家供應商」；依計畫用量與實際剩餘比對，提示「買超了」或「不夠做，要多買」。這些是 if-else 規則，不是 AI，先把「記錄」這件事做對，這些提醒是之後可以順手加的。
• 多存貨地點：進貨時要能標註「跟哪一家買的」，成品要能標註「存放在哪個地點」，不能寫死成單一地點。

對 01 檔資料模型的影響

第二期會新增 Material（原料主檔）、MaterialBatch（進貨與處理批次）、Recipe（配方，商品↔原料的多對多關聯＋比例）、StockLocation（存貨地點）、FinishedGoodsStock（成品庫存，依地點分）。第一期的 Product 只代表「成品」概念，不需要現在就建這些表，但命名與外鍵預留要對得上，避免第二期要大改第一期的表結構。

2. 資料模型（第一期）

Product        商品：名稱、分類、規格、單位（箱／支）、每箱數量、圖片、狀態、消費者顯示價
PriceList      價格表：廠商 × 商品 → 單價、最小訂量（廠商專屬價格）
Vendor         廠商：公司名、聯絡人、電話、地址、付款條件、狀態
VendorUser     廠商使用者：帳號、密碼（可空）、LINE userId（可空）、所屬廠商、角色
Order          訂單：編號、廠商、配送日、時段、狀態、備註、建立來源（web / liff / manual）、建立時間、操作紀錄
OrderItem      訂單品項：訂單、商品、數量、單價快照、小計
Inquiry        消費者詢價：姓名、電話、品項、數量、備註、處理狀態（歷史保留，WooCommerce 上線後新詢價改在 WordPress 端）
Notification   通知紀錄：對象、類型、訊息、送出結果（成功／額度不足／失敗）
RetailSaleLog  散客銷售紀錄（E2，第一期輕量版）：WooCommerce 訂單編號、品項（商品對應、數量、單價）、下單時間、Webhook 簽章驗證結果、原始 JSON 備查；**不含庫存扣減欄位**，第二期升級時才加

設計重點：

• OrderItem.單價快照：訂單成立時把價格複製進去，之後改價不影響歷史訂單。
• Order.建立來源：日後分析廠商用 LINE 還是網頁下單。
• Notification：推播失敗要留紀錄，額度用完時後台看得出來。
• RetailSaleLog 是唯讀的原始紀錄，第一期只負責「存下來」，不碰庫存數字；第二期庫存模組會把它跟 Order（廠商）合併算出真正的庫存異動。
• 第二期的庫存模組會加 Material、Recipe、StockMovement，第一期的 Product 要預留「成品」概念不衝突；StockMovement 上線後才把散客與廠商兩個通路的扣庫邏輯統一進去。

3. 技術與部署

• Django 5 + PostgreSQL + Docker；前端用 Django template + 少量 JS（HTMX 或 Alpine），LIFF 頁用 LIFF SDK。
• 後台 = Django admin 客製（列表欄位、篩選、狀態動作按鈕、匯出）。
• LINE：line-bot-sdk Python；webhook 端點驗證簽章；耗時工作丟背景（Django-Q 或 Celery 擇一輕量）。
• WooCommerce Webhook 接收端點（E2）：獨立路由，驗證 X-WC-Webhook-Signature 標頭（HMAC-SHA256 + base64，用原始請求內容比對，原理與 LINE webhook 驗證相同，可共用同一套驗證邏輯）；第二期回寫庫存則用官方 woocommerce Python 套件呼叫 WooCommerce REST API（Consumer Key/Secret，WooCommerce 後台設定 > 進階 > REST API 產生），技術細節見 08 檔 6.5.1 節。
• 官網＋散客商店：獨立的 WordPress + WooCommerce 部署（自己的容器、自己的 MySQL），不算在本檔 Django 技術棧內，見 08 檔第 6.1 節。
• 部署：VPS（Linode／Hetzner／DigitalOcean 最小型即可）+ Cloudflare；docker compose up（同一個 compose 檔管理 Django 容器 + WordPress 容器，兩者網路隔離）；每日 pg_dump／mysqldump 各自上傳 R2。
• 測試：pytest，至少涵蓋「廠商權限隔離」「訂單狀態流轉」「價格快照」「LINE 綁定」「WooCommerce Webhook 簽章驗證」五組。
• 錯誤監控：Sentry 免費方案或簡單的 Email 通知。

4. 時程（2026-09-23 改版：兩個外部硬期限）

WT 確認的硬期限：

• 10 月中（抓 10/15）要有一版 Demo，給客戶拿去寫企劃、申請補助
• 11 月底（抓 11/30）要有一版「初步可以執行」的系統

從今天（9/23）到 10/15 只有約 3 週，扣掉訪談與簽約，實際能寫程式的時間更短；到 11/30 也只有約 9.5 週。這個時程比原本規劃的 ×1.5＋緩衝壓縮很多，是目前最大的風險，見 06 檔新增的風險項。

2026-09-25 會議修正：表妹期中考是 10 月底（不是原先誤植的 11 月初），11 月沒有考試，下一次是 12 月期末考。時程表已依此調整——期中考週落在 10/27–10/31，剛好卡在 Demo 之後、衝刺開發之前，11 月整月反而沒有考試干擾。

4.1 Demo（10/15）：目的是給客戶寫企劃書用，不是完整系統

Demo 的目標是「讓人看得懂、看得出可行」，不是「每個功能都能用」。建議範圍：

這份技術頁的流程圖（LINE LIFF、Webhook 整合）本身就是很好的補助企劃素材——不用等系統做出來，用圖說明「這是我們規劃的架構」，對申請補助反而更清楚。

4.2 初步可執行版本（11/30）

在 Demo 基礎上，把「真的能用」的部分做出來：廠商登入下單全流程（含權限隔離）、後台訂單處理、LINE 綁定與基本通知。WooCommerce↔Django 的自動化進銷存整合、完整資安檢查、多廠商試營運，可以留到 11/30 之後繼續做，不強求這個時間點就要有。

4.3 時程表

這張表是壓力測試後的樂觀版本，不是保證。 如果 9/23–9/29 這週訪談與簽約卡住，後面全部要往後推；不建議為了趕日期跳過範圍文件簽認（06 檔 A1）。

5. 報價拆解（第一期，供你內部參考與對客戶解釋）

落在 20～25 萬內，餘裕縮小到約 1～3 萬（因為併入了原第二期的購物車功能）。若客戶砍價，先砍 E2（改成第二期再做，資料不會漏，只是慢一步整合），不砍權限與備份。

客戶自付、不含在內：兩個網域或一個網域＋子網域（約 500／年）、主機（約 300～1,000／月，視 WordPress+Django 合併資源需求）、LINE 官方帳號方案（0～1,400／月）、聊天進階方案（100／月）、金流交易手續費（藍新／綠界 1.85%～3%，依實際交易額）、超商取貨物流費（約 NT$60～70／件，由消費者或店家吸收，依定價策略）。

維護合約（另簽）：月費 3,000～5,000（含主機代管、bug 修正、小調整 2 小時／月、每月備份檢查），WordPress 那側因外掛更新頻率較高，建議加購外掛與資安掃描追蹤（見 08 檔 2.4 節），維護月費可能需上調至 4,000～6,000，或年約 4.8～7.2 萬。

6. 驗收清單（合約附件用，節錄）

• ☐ 兩個廠商帳號互相看不到對方的訂單、價格
• ☐ 廠商下單後 10 秒內 LINE 收到確認卡，內容與訂單一致
• ☐ 老闆改狀態為「已出貨」，廠商 LINE 收到通知；推播失敗時後台有紀錄
• ☐ 商品改價後，舊訂單金額不變
• ☐ 後台匯出 Excel 欄位齊全
• ☐ 手機、平板、電腦三種裝置下單流程正常
• ☐ WordPress 商店測試下單後，Django 資料庫的 RetailSaleLog 能看到對應紀錄，品項與數量一致
• ☐ 偽造（無正確簽章）的 Webhook 請求被拒絕，不會寫入資料庫
• ☐ 從 WordPress 容器嘗試連線 Django 資料庫連接埠，確認被阻擋（網路隔離驗證）
• ☐ 備份檔可在測試環境還原成功
• ☐ 操作手冊、部署文件、帳號清單交付

資安驗收（2026-09-24 補充，具體化，見 08 檔「資安強化清單」）

• ☐ IDOR 系統性測試：每一個會回傳廠商資料的 API／頁面，都用廠商 A 的帳號嘗試存取廠商 B 的訂單編號、廠商編號，一律應被拒絕（不是測一次，是每個端點都測）
• ☐ Django admin 路徑改成非預設值；帳密符合強度要求
• ☐ 廠商登入、Django admin 登入都有速率限制（防暴力破解）
• ☐ 正式環境 DEBUG=False，確認錯誤畫面不會外洩程式碼路徑或環境變數
• ☐ Cookie 設定 Secure／HttpOnly／SameSite
• ☐ 密碼以雜湊儲存、全站 HTTPS、表單有輸入驗證（原條目具體化）
• ☐ 登入失敗、Webhook 簽章驗證失敗都有留紀錄，可觀察異常量
• ☐ GitHub Dependabot（或同等工具）已啟用，追蹤套件已知漏洞
• ☐ WordPress 外掛數量控制在必要範圍內，且都是必要、有維護的外掛

研究日期：2026-09-21。資料來源列在文末；價格與功能以 LINE 官方頁面為準，β 功能隨時可能變動。

0. 結論先講

1. LINE 內建的「AI 聊天機器人（β）」只能回答 FAQ，不能下單、不能查訂單、不能寫資料庫。 它適合處理「營業時間、配送範圍、最低訂量、付款方式」這類問題，月費 NT$100（聊天進階方案）。第一期直接用它當客服，不要自建 LLM 客服。
2. 廠商從個人 LINE 對官方帳號下單，最務實的做法是「LIFF 下單頁」：廠商點選單 → 在 LINE 裡打開你們的下單網頁（自動知道他是誰）→ 送出 → 寫入資料庫 → LINE 回一張訂單確認卡。這是第一期就能做、成本可控、廠商不用學新東西的方案。
3. 「打字就下單」（自然語言 → LLM 解析 → 建單）技術上可行，但要放第二期，而且設計原則是 LLM 只產生「草稿」，廠商按確認才成立訂單。
4. 回覆訊息免費、主動推播計費。 訂單確認用回覆（免費），出貨通知用推播（計費）。30 家廠商規模估每月 500～1,000 則推播，落在中用量方案（2026/11/1 起 NT$1,000／月）。
5. LINE 官方帳號與 Developers Provider 要建在客戶自己的 LINE Business ID 下，這是條款要求，也是日後交接的保障。

1. LINE 官方帳號本身有什麼（不用寫程式的部分）

1.1 AI 聊天機器人（β）的能與不能

能：

• 從你上傳的價目表、常見問答自動生成回覆；有測試區；全部在 LINE 後台完成，不用寫程式。
• 可與手動聊天並用；可設營業時間內外不同回應方式。
• 上傳的資料不會用於 AI 訓練。

不能／限制：

• 只會「回答」，不會「執行」：不能建立訂單、不能查詢某廠商的訂單狀態、不能碰你的資料庫。
• β 版有每月回覆上限（官方未公布數字），建議好友數低於 25,000 的商家使用。
• LINE 明講「不保證準確性」；醫療、金融、宗教、政治、法律業種不可用（食品廠不受限）。
• 「自動回應訊息」（關鍵字）優先於 AI 回覆。
• 與 Webhook 的並存要在客戶帳號實測：LINE 從 2022 年起允許「聊天」與「Webhook」同時啟用，但 AI 聊天機器人（β）和你們的 bot 若同時對同一句話回覆，廠商會收到兩則。設計上要分工：訂單相關由 bot 處理，其餘交 AI；上線前實測。

注意：網路上還有一個更早的「AI 自動回應訊息（Smart chat）」，那是舊功能，2024 年 5 月已停止。現在講的是 2025 年 11 月的「AI 聊天機器人（β）」，兩者不同。

1.2 建議

第一期：開聊天進階方案（100／月），把「配送區域、最低訂量、付款方式、出貨時間、商品規格」做成 FAQ 餵給 AI 聊天機器人。省掉自建客服的成本與風險。日後若客戶要「AI 幫我看訂單」，那是第二期的自然語言下單，不是這個功能能做的。

2. 費用（台灣，2026-11-01 起新價）

計費規則（對系統設計最重要的部分）：

• 回覆訊息（Reply）不計費：使用者先傳訊息、你在 reply token 有效期內回，不論人工、自動回應或 webhook 回覆，都免費。
• 推播（Push / Multicast / Broadcast / Narrowcast）計費：你主動發的都算，按收件人數計。
• 超過額度：API 回傳錯誤、訊息不送出（不會自動升級）。輕／中用量用完就停，只有高用量能加購。
• 聊天進階方案 100／月另計。

用量估算（假設 30 家廠商、每家每週 3 單）：

• 每單「訂單成立確認」用 reply（免費）
• 每單「已出貨」推播 1 則 → 30 × 3 × 4.3 ≈ 390 則／月
• 加上「訂單有異動」「每週提醒訂貨」等 → 抓 600～1,000 則／月
• → 中用量方案 1,000／月足夠；廠商數到 60 家以上或要每日推播才需高用量。

設計上的省錢原則：

1. 能用 reply 的不用 push（廠商送出訂單當下就回確認卡）。
2. 狀態通知合併（同一天的多筆變更合成一則）。
3. 額度用完的 fallback：後台仍可看到訂單狀態，並記錄「通知未送出」；必要時人工聊天回覆（免費）。

3. 個人 LINE → 官方帳號下單 → 資料庫：四個層級

從最便宜到最花錢。建議第一期做 L1 + L2，L3 放第二期，L4 不做。

L0：純人工（零開發，過渡期）

廠商在聊天室打字 → 老闆在 LINE 官方帳號 App 看到 → 自己到系統後台登打訂單。

• 用途：系統上線前、或廠商還不習慣時的備援。永遠保留這條路。

L1：導流到下單頁（第一期，基本）

圖文選單「我要訂貨」→ 開啟網站的廠商登入頁 → 廠商用帳號密碼登入 → 下單。

• 缺點：廠商要記帳號密碼；在 LINE 內開外部瀏覽器體驗較差。
• 做這層的目的是「沒有 LINE 也能用」，是 L2 的基底。

L2：LIFF 下單頁（第一期，建議主流程）

LIFF = 把你們的網頁嵌在 LINE 裡打開，並自動拿到使用者的 LINE userId。

廠商（個人 LINE）
   | 點圖文選單「我要訂貨」
   v
LIFF 頁面在 LINE 內開啟
   | liff.init() → 取得 userId、displayName
   v
後端查 userId 是否已綁定廠商
   +- 未綁定 → 顯示「輸入廠商代碼 + 老闆給的邀請碼」→ 綁定（一次性）
   `- 已綁定 → 顯示該廠商的專屬商品清單與價格
   | 填數量、配送日、備註 → 送出
   v
後端 API：驗證 → 寫入 orders / order_items → 回傳訂單編號
   |
   +- 頁面顯示「訂單已送出」
   `- 用 Messaging API 傳一張 Flex Message 訂單確認卡到聊天室
       （若在 webhook 事件內可用 reply，否則用 push）
   v
老闆後台（Django admin）看到新訂單 → 改狀態「已確認 / 已出貨」
   |
   v
狀態變更 → push 通知廠商（計費）

技術要點：

• 身分綁定：LINE userId 是「每個 Provider 底下唯一」。Messaging API channel 和 LINE Login channel（LIFF 用）必須在同一個 Provider 下，userId 才一致。這是新手最常踩的坑。
• 一個廠商可綁多個 LINE（老闆 + 採購各一個）；後台可解除綁定。
• LIFF 必須 HTTPS；endpoint URL 就是你們的下單頁。
• 廠商不需要帳號密碼，體驗跟「在 LINE 裡填表」一樣。
• 官網版（L1）與 LIFF 版共用同一個下單頁，只是登入方式不同。

工時：在 Django 下單頁已存在的前提下，LIFF 綁定 + 圖文選單 + 確認卡 + 狀態推播約 3～5 個工作天（表妹執行、含測試）。

L3：自然語言下單（第二期）

廠商直接打字：「明天送 芒果 20 箱、草莓 10 箱，下午到」

webhook 收到文字訊息
   |（1 秒內回 200，處理放背景）
   v
LLM 結構化：{品項:[{名稱:"芒果冰棒", 數量:20, 單位:"箱"}, ...], 配送日:"2026-09-22", 時段:"下午"}
   |
   v
比對商品主檔（該廠商可訂的品項、單位、最小量）
   +- 全部匹配 → 回 Flex「訂單草稿」卡片，附【確認】【修改】按鈕（postback）
   +- 部分不確定 → 卡片標示「以下品項請確認」
   `- 完全看不懂 → 回「已轉交人員」+ 在後台標記待人工
   |
   v
廠商按【確認】→ postback 事件 → 才正式寫入 orders

設計原則（不能省）：

1. LLM 永遠只產生草稿，訂單成立一定經過廠商按確認。否則 LLM 誤判「20 箱」成「20 支」就是真金白銀的損失。
2. 商品主檔要有「別名」欄位（「芒果」= 「芒果冰棒 10 支裝」），LLM 比對用。
3. 每次解析要記錄原文與結果，方便事後查。
4. 費用：每則解析走一次模型（用便宜模型即可，例如 Haiku 等級），一個月幾百單成本可忽略；但開發與測試工時約 8～12 個工作天，加上錯誤案例的迭代。
5. 要準備「廠商打錯 / 改單 / 取消」的對話流程，這才是花時間的地方。

為什麼放第二期：第一期先讓廠商習慣 LIFF 表單、累積真實訂單文字（廠商以前怎麼在 LINE 打字訂貨的紀錄），第二期做 L3 時才有測試資料。

L4：在 LINE 群組裡下單（不建議）

有些廠商習慣拉群組。技術上 bot 可加入群組收訊息，但：

• 群組內取得個別成員 userId 有限制、訊息雜、隱私問題（其他廠商看得到）。
• 建議做法：老闆保留群組聊天，但下單一律引導到官方帳號的一對一。

4. 真人接手與例外處理

• 回應設定選「聊天 + Webhook 同時啟用」：bot 處理訂單，老闆隨時能在 LINE 官方帳號 App 看到所有對話並手動回。
• bot 收到非訂單訊息（問問題、抱怨）→ 不回或回「人員將回覆」，交 AI 聊天機器人或人工。
• 廠商說「取消」「改單」→ 第一期一律轉人工（後台改），第二期再自動化。
• 訂單卡片上放「有問題請直接回覆此訊息」，讓廠商知道有人看。

4.1 限制只有合作工廠能觸發下單（2026-09-25 會議補充）

官方 LINE 帳號本質是公開的——任何人加好友都能傳訊息。這裡要解決的是「怎麼確保只有真正合作的廠商能觸發下單流程，不是隨便一個人傳訊息都建單」。討論出兩個做法：

1. 資料庫比對（建議）：bot 收到訊息時，先用 LINE userId 查 VendorUser 表，確認是不是已綁定的合作廠商。是才進下單流程；不是就回一般訊息或轉人工，不觸發建單。這跟 L2 LIFF 流程本來就規劃的「查 userId 是否已綁定廠商」是同一套機制，不用另外做。
2. 備案（如果 1 做起來有困難）：乾脆讓這個官方 LINE 帳號整個帳號都只做下單用途，不承載其他客服／行銷功能，降低誤觸發或被騷擾的影響範圍。

第一期用做法 1，因為 LIFF 綁定流程本來就會做這個檢查，不是額外工作。

5. 現成方案比較（要不要買而不是做）

結論：訂單流程自建（因為要接自家後台與日後的庫存成本），FAQ 客服用 LINE 內建 AI，行銷推播用 LINE 後台群發。不買第三方平台。

6. 風險與對策

7. 開發時需要的帳號與設定清單（給表妹）

1. 客戶的 LINE Business ID → 建官方帳號（若已有就用既有）
2. 官方帳號後台 → 啟用 Messaging API → 產生 Provider（客戶名下）
3. LINE Developers Console → 同一個 Provider 下建 LINE Login channel → 新增 LIFF app（endpoint = 下單頁 URL，scope: profile, openid）
4. Messaging API channel：取得 channel secret、channel access token；設定 webhook URL（HTTPS）
5. 回應設定：聊天 ✔、Webhook ✔、自動回應訊息（關鍵字「訂貨」→ 連結）
6. 圖文選單：「我要訂貨」（LIFF URL）、「查訂單」（LIFF URL）、「聯絡我們」
7. 聊天進階方案（100／月）→ 上傳 FAQ 給 AI 聊天機器人
8. 測試：用 3 個真實 LINE 帳號走完「綁定 → 下單 → 確認卡 → 後台改狀態 → 推播」

資料來源

• LINE Biz-Solutions：AI 聊天機器人 24 小時接單
• LINE 官方帳號支援中心：AI 聊天機器人（β）
• LINE Biz-Solutions：2026 年 LINE 官方帳號方案價格調整
• LINE Biz-Solutions：訊息費用的計價方式
• LINE Developers：Messaging API pricing
• LINE Biz-Solutions：聊天進階方案
• no8.io：2022 回應功能開放聊天及 Webhook 並存
• FIRST LINE：LIFF 設定指南
• Omnichat 文件：LIFF 需與 Messaging API 同 Provider
• no8.io：B2B 案例：海陸家赫 LINE 串接 CRM
• 94iplay：LINE 官方帳號串接 AI 客服：Webhook 架構到訂單自動化
• 賴管家：2026/11/1 新方案與則數計算

已報區間：28～35 萬（定義為第一期） 現況：沒有 POS（2026-09-25 會議確認：現場有租用 POS 機，但只給總營收，沒有逐品項明細，這是客戶想系統化的原因之一），但每天有手寫的進銷存紀錄，且至少有超過一年的歷史資料。營業額可由進銷存推算。 定位：把手寫進銷存變成手機輸入 → 自動算出每店營收／成本／損益／商品表現／人力成本比 → 儀表板 → 之後才談預測與排班。

2026-09-25 會議發現：這案客戶是第一案客戶的下游採購方之一——多據點店會跟第一案的冰棒工廠叫貨（賣的品項之一就是冰棒），另一項主力商品是冷泡茶等現場泡製飲料。兩案仍是不同客戶、分別簽約報價，資料庫也不共用，但業務上有實際供應鏈關係，之後若客戶想把「叫貨」這段接進第一案的 B2B 訂購系統，屬於全新的整合需求，不在任一案現有報價內，需另外評估。

0. 關鍵判斷

1. 這案的產品是「每天 5 分鐘填完的手機表單」，不是儀表板。 表單不好填，後面全是空的。所以第一週要做的事是拿到客戶現在的手寫表格，一格一格對照。
2. 資料來源：進銷存是手寫；結帳端的 POS 是租的，只有總營收、沒有逐品項明細，確認不能串（2026-09-25 會議已證實，非推測）。第一期一律用「手動輸入 + 拍照上傳備查」，POS 串接明確排除。「歷史手寫資料要不要補登」另計。
3. 報表不要自己畫：用 Metabase（自架、免費）接資料庫做儀表板，把工時放在資料正確性與導入。
4. 「AI 排班／預測」第一期不承諾。沒有 3～6 個月乾淨資料，任何預測都是猜的，客戶會失望。錄音原話方向一致：先做「資料底座」。
5. 屏東海生館（國立海洋生物博物館）先試點。 客戶有 3～4 家店面，海生館是影響最重的點、品項較少、適合先做。第一期以海生館為主要試點，其他據點在試點跑順後複製。海生館主賣兩類：冰棒（第一案工廠供貨）與冷泡茶等現場泡製飲料。
6. 保存期限與報廢是這案的核心欄位，不是加分項。 椰子水、冷泡茶等只能放兩天，做太多遇雨天就整批報廢。系統要看的不只是庫存量，是「到期風險」。
7. 人力痛點具體數字：平日 1 人、假日 2 人、暑假 7–8 月到 2.5 人，另有發券人力、下午加人做現場銷售；7–8 月人事成本接近 10 萬／月，已超過營業額三成，還不含勞健保與電費。這是報表的第一優先：人力成本比與每人每小時產值。
8. 三個核心面向（錄音整理）：①進銷存／商品銷售 ②天氣／溫度／活動等外部因素 ③成本／人力／營業額／產值。第一期把三塊資料收齊並對齊到同一個「店別 × 日期」，第二期才做交叉分析與建議。
9. 邊界：副手／臨時補班調度不在第一期。

1. 階段切分

第一期（28～35 萬）— 目標：每店每天資料進系統，老闆每週看得到每店賺不賺、哪些商品該補該減、人力成本比多少

第二期（另計）

2. 資料模型（第一期）

客戶自己（2026-09-25 會議轉述）把需求想成五張表：產品資料、銷售紀錄、銷售排名（判斷熱銷用）、進貨紀錄、人事排班紀錄。這跟我們原本規劃的表基本對得上，下面用我們的欄位細節版本，但保留客戶的分類方式方便溝通。

Store            店別：名稱、地點類型（入口／出口／園區內／海邊）、營業時間、固定成本（月租、水電估算、勞健保估算）
Product          商品：名稱、分類（冰品／飲料／冷泡茶／椰子水…）、售價、成本、保存天數、前置準備時間、狀態
Employee         員工：姓名、店別、角色（正職／PT／發券／支援）、薪資方式（時薪／月薪）、時薪
DailyReport      每日回報：店別、日期、填報人、天氣（自動）、假日／活動標籤、營收（推算或輸入）、折扣／招待金額、備註、手寫表照片、POS 結帳畫面照片、狀態（草稿／已送出／已修正）
DailyItem        每日品項：回報、商品、期初、進貨／製備、銷量、報廢（數量、原因：到期／雨天／其他）、期末
Shift            班次：回報、員工、角色、上班、下班、工時、當日人事成本
Calendar         日曆：日期、假日、活動名稱、影響店別
WeatherHistory   歷史天氣實況：店別（或地區）、日期、最高溫、降雨量、是否下雨、天氣描述
WeatherForecast  天氣預報：店別（或地區）、預報發布時間、預測目標日、降雨機率、預估溫度

天氣要拆兩張表，不是一張（2026-09-25 會議澄清）：WeatherHistory 記錄「今天實際有沒有下雨」，用來回測過去營收跟天氣的關聯；WeatherForecast 記錄「預報說明天可能下雨」，用來預測未來、輔助排班決策。這是兩種不同用途的資料，混在一張表會讓「回測」跟「預測」的邏輯打架——回測只需要「有沒有發生」，不需要「當時預估幾%機率」。

推算邏輯（要客戶簽認）：

• 銷量 = 期初 + 進貨 − 報廢 − 期末（若店長直接填銷量，則期末由系統算，二選一，不要兩個都填）
• 營收 = Σ 銷量 × 售價（若有折扣，先用「當日折扣金額」一欄粗略處理）
• 毛利 = 營收 − Σ 銷量 × 成本
• 人事成本 = Σ 工時 × 時薪（月薪制按當月營業日攤）
• 損益 = 毛利 − 人事成本 − 固定成本日攤
• 人力成本比 = 人事成本 ÷ 營收（客戶說已超過 30%，用系統第一個月的數字驗證這個說法）
• 每人每小時產值 = 營收 ÷ 總工時
• 報廢率 = 報廢數量 ÷（期初 + 進貨）；報廢金額 = Σ 報廢數量 × 成本
• 人力配置對照 = 以「當日人數」分組，比較平均營收、毛利、每人產值（這是第二期排班建議的基礎，第一期只做分組比較）
• 當日門市邊際貢獻（2026-09-25 客戶提出的公式，術語照抄）= 當日營業額 − 銷貨成本 − 人事成本 − 耗損率報廢成本。這是客戶自己在用的概念，跟上面的「損益」邏輯一致，只是客戶習慣的講法把報廢成本獨立列一項——報表用詞照客戶說法呈現，不要自創新名詞讓客戶要重新對應。

每日盤點如何自動算出銷量（會議中的具體範例，可直接拿給表妹當測試案例）

重點：店員只要「盤點今天剩多少」，不用自己心算賣了多少。 一整天賣很多雜項時，要求店員每筆都心算會漏、會錯；系統用「期初+進貨−期末」自動反推，這是這個表單設計最重要的原則，也是店長願不願意持續填報的關鍵。

3. 填報 UX 原則（這是成敗關鍵）

1. 昨日數字自動帶入，店長只改有變動的格子。
2. 品項順序照手寫表的順序，不要照系統字母序。
3. 可以「先送出、明天補」，缺的欄位標黃不擋送出。
4. 店長填完看到當日營收與昨日比較 —— 給他一個填的理由。
5. 手寫表拍照上傳，糾紛時可對照。
6. 老闆端有「今日未填報店別」提醒（LINE 推播或 Email）。

3b. Metabase 使用方式與帳號安全（2026-09-25 會議澄清，表妹當時的疑慮）

表妹擔心的問題：如果用 Metabase 直接連資料庫查資料，會不會不小心把原始資料改壞？以及 Metabase 報表頁面會不會被 Google 搜尋到、被外部看到？兩個問題的答案：

1. 使用者的操作路徑分成兩條，不會混在一起：填寫資料一律走「每日回報表單」（B 模組），查資料一律走「Metabase 報表頁面」。兩者是完全不同的介面，使用者不會、也沒有管道從報表頁面回頭改到原始資料。
2. 給 Metabase 連資料庫用的帳號要設成唯讀（read-only），不要用有寫入權限的帳號。這不只是防止誤改——如果 Metabase 在背景跑分析查詢時剛好卡住某張表（鎖表），唯讀帳號的影響範圍比讀寫帳號小很多，不會拖累主系統的正常運作。
3. Metabase 不是公開網站，不會被搜尋引擎索引：它是內部工具，網址不會被拿去做 SEO 或提交搜尋引擎，訪問要先登入帳號。
4. 權限依角色分級：老闆能看全部店的報表；店長只能看自己店的；一般員工可能完全看不到報表（只填表單）。用帳號登入搭配權限設定做到，不是「有網址就人人能看」。

這幾點寫進 01 檔／08 檔的資安強化清單同樣適用（唯讀帳號、權限分級、不對外索引），第二案沒有另外重複的必要，這裡點出即可。

4. 時程（表妹執行，含 ×1.5 與緩衝；可與第一案錯開）

避開表妹期末（12 月，2026-09-25 修正，原誤植 1 月中）——這代表第二案原訂 12 月中～1 月的開發／試跑期，要重新對齊期末考時間，開工前再核實。

5. 報價拆解（第一期）

落在 28～35 萬內。這案的價值在「導入」與「推算邏輯」，對客戶解釋時強調這兩塊是顧問工作，不是寫程式。

客戶自付：主機（可與第一案分開，約 300～600／月）、網域。 維護合約：月費 3,000～5,000，或加「每月營運分析」變成 1～2 萬／月的顧問合約 —— 這是這案最值得談的長期收入。

6. 驗收清單（節錄）

• ☐ 手寫表每一欄都能在系統對應到欄位
• ☐ 店長在手機 5 分鐘內完成一日填報（實測 3 位店長）
• ☐ 抽 3 天資料，系統算出的營收、毛利與手工核算一致
• ☐ 天氣資料每日自動寫入，缺資料有提示
• ☐ 儀表板在手機可看：每店損益、商品排行、人力成本比、店間比較
• ☐ 試跑 4 週填報率 ≥ 90%
• ☐ 備份可還原；資料可整批匯出 Excel
• ☐ 操作手冊、店長版一頁說明、部署文件交付

用法：訪談前先給客戶看「範圍說法」（05 檔），訪談中逐題問、當場記錄答案，訪談後整理成規格書請客戶簽認。每題後面的【】是為什麼要問。

共同題（兩案都問）

1. 誰是最終決策者？誰是日常使用者？誰負責驗收？【避免做完換人否決】
2. 期望上線日期？有沒有硬截止（旺季、活動）？【排時程】
3. 網域、主機、LINE 帳號，有沒有既有的？帳號在誰名下？【帳號歸屬】
4. 上線後誰負責維護？有沒有 IT 人員？【維護合約】
5. 資料保存要求？有沒有需要匯出給會計師？【匯出格式】
6. 預算是否含稅？付款方式與階段可否接受 30／40／30？【現金流】
7. 有沒有看過類似系統或競品？喜歡／不喜歡什麼？【對齊期待】

第一案：冰棒／食品廠訂購系統

A. 廠商與訂購現況

1. 目前有幾家廠商？每週訂單量？旺淡季差多少？【推播用量、規模】
2. 廠商現在怎麼下單？（LINE 打字、電話、傳真、LINE 群組）請給 5～10 則真實的 LINE 訂貨訊息截圖。【第二期自然語言下單的樣本】
3. 每家廠商價格一樣嗎？有沒有折扣、階梯價、月結？【價格表設計】
4. 最小訂量、配送日規則（幾天前訂、哪些天送、哪些區域）？【下單規則】
5. 訂單改單、取消的頻率？怎麼處理？【第一期轉人工是否可接受】
6. 廠商的 LINE 是老闆個人號還是公司號？一家廠商會有幾個人下單？【多 LINE 綁定】
7. 廠商年齡層與手機使用習慣？願意換新方式的比例？【採用風險】

B. LINE 串接程度（給客戶四選一）

1. 你希望 LINE 是：①只放連結 ②收通知 ③在 LINE 裡填表下單 ④打字就下單？【定義範圍，③是第一期】
2. 要不要 AI 回答常見問題（營業時間、配送、付款）？可否提供 FAQ 內容與價目表 PDF？【LINE 內建 AI 聊天機器人】
3. 誰負責在 LINE 官方帳號回訊息？幾點到幾點？【回應設定】
4. 現在有 LINE 官方帳號嗎？方案是哪個？好友數？【費用】

C. 訂單處理與後台

1. 訂單狀態有哪些？（新訂單、已確認、備貨中、已出貨、完成、取消）誰改狀態？【狀態流轉】
2. 需要列印出貨單或撿貨單嗎？格式？【後台功能】
3. 需要哪些匯出？（月結對帳、廠商別報表）【匯出】
4. 後台有幾個人用？要不要分權限？【第一期兩角色是否夠】

D. 庫存與成本（第二期範圍，但現在先問清楚深度）

1. 原料有哪些？（水果種類、糖、包材）進貨頻率？【資料量】
2. 有沒有配方表？每種冰棒用多少原料？損耗率（去皮去籽）有沒有數字？【BOM 可行性】
3. 現在怎麼算成本？多久算一次？誰在算？【現況與痛點】
4. 庫存盤點頻率？有沒有現成的 Excel？【資料格式】
5. 第一期不做庫存成本，可接受嗎？希望第二期什麼時候開始？【範圍確認】

E. 消費者端與金流

1. 消費者可以線上下單嗎？還是只詢價？【範圍】
2. 收款方式？（匯款、貨到付款、月結）第一期不串金流可接受嗎？【金流】
3. 需要開發票嗎？電子發票？【第二期範圍】

F. 品牌與內容

1. 有 Logo、品牌色、商品照片嗎？誰提供文案？【素材時程】
2. 官網要幾頁？參考網站？【官網範圍】

第二案：多據點營運決策系統

A. 據點與人員

1. 幾個據點？各自的地點類型（入口、出口、園區內、海邊）？營業時間？【店別主檔】
2. 每店幾位員工？時薪還是月薪？有兼職嗎？【人事成本算法】
3. 誰排班？多久排一次？排好後改動的頻率？【排班在第二期的可行性】
4. 店長會用手機填表嗎？年齡層？現在有用什麼 App？【填報 UX】

B. 現有手寫進銷存（最重要，請帶實體表格來）

1. 請提供最近一週每店的手寫進銷存表（拍照即可）。【欄位對照】
2. 表上有哪些欄位？每個欄位誰填、什麼時候填？【填報流程】
3. 銷量是直接記，還是用「期初 + 進貨 − 期末」算的？【推算邏輯】
4. 有折扣、招待、員工餐嗎？怎麼記？【營收誤差來源】
5. 報廢、短保存商品到期怎麼記？【損耗】
6. 商品有幾種？多久新增或下架？【商品主檔維護】
7. 商品成本知道嗎？多久變動？【毛利算法】
8. 現在這些表最後去哪裡？有人彙總嗎？用 Excel？【現況與痛點】
9. 歷史紙本要補登嗎？補多久？誰補？【第二期／另計】

C. 成本與損益

1. 固定成本（租金、水電、權利金）有數字嗎？按店分嗎？【損益算法】
2. 人事成本目前占營收多少？怎麼算出來的？【驗證用】
3. 老闆最想知道的三個數字是什麼？【報表優先順序】

D. 天氣與活動

1. 哪些天氣影響最大？（雨、颱風、高溫）有印象中的例子嗎？【天氣欄位】
2. 園區／水族館的活動或人流資料拿得到嗎？（官方公告、票務）【外部資料】
3. 假日定義：國定假日、寒暑假、連假？【日曆】

E. 報表與決策

1. 老闆多久看一次報表？在手機看還是電腦？【Metabase 手機版】
2. 需要店長看到自己店的數據嗎？看得到別店嗎？【權限】
3. 「明年排班參考」具體想看到什麼？（例如：去年同週各時段人數與營收）【第二期定義】
4. 「AI 排班」在你心中是什麼樣子？【降期待，明確第二期】

F. 導入

1. 願意先挑 2～3 店試跑 4 週嗎？哪幾店？【導入計畫】
2. 店長不填怎麼辦？有沒有獎懲或 KPI？【填報率保障】
3. 誰負責建商品主檔與員工資料？【資料建檔分工】

1. 對客戶的說法（口頭或訊息，兩案通用）

要點：區間沒變，是範圍被定義清楚了。不用道歉，也不用說「我當初估錯」。

2. 交付項目表 — 第一案（合約附件草稿）

2.1 第一階段交付項目

2.2 不包含（第二階段另計）

• 廠商以文字訊息自動下單（自然語言解析）
• 庫存、原料、配方、損耗、成本、毛利
• 消費者購物車、第三方金流、電子發票
• 細粒度權限（業務員、多倉）
• 自動補貨／訂貨提醒
• 進階報表、AI 摘要
• App
• 超過 8 頁的官網頁面、文案撰寫、商品攝影

2.3 客戶自備／自付

• 網域、主機（約 NT$300～600／月）、Cloudflare 帳號
• LINE 官方帳號（方案費 0～1,400／月）與聊天進階方案（100／月）
• Logo、品牌素材、商品照片、文案、商品與廠商資料
• 個資／發票／稅務等法規遵循

2.4 付款與時程

• 30% 簽約｜40% 測試環境驗收｜30% 正式上線驗收
• 預計 10 週（自簽約與素材到齊起算），含 2 週緩衝
• 客戶回饋逾 5 個工作天未回覆，時程順延

2.5 變更

• 範圍外需求以變更單記錄工時與費用，雙方簽認後執行

2.6 維護（另簽）

• 月費 NT$3,000～5,000：主機代管、bug 修正、小調整 2 小時／月、備份檢查、LINE 費用監控

3. 交付項目表 — 第二案（合約附件草稿）

3.1 第一階段交付項目

3.2 不包含（第二階段另計）

• 歷史手寫資料補登
• 排班建議、人力預測
• 備料建議、自動採購
• AI 摘要、異常標記、自動提醒（基礎「未填報提醒」除外）
• POS 或其他系統串接
• 每月營運分析報告（可另簽顧問合約）

3.3 客戶自備／自付

• 主機、網域
• 商品成本、固定成本、員工薪資等基礎資料
• 店長填報的紀律與管理

3.4 付款與時程

• 30% 簽約｜40% 試跑開始（測試驗收）｜30% 全店上線驗收
• 預計 12 週（含 4 週試跑與 2 週緩衝）

3.5 維護與顧問（另簽）

• 維護月費 NT$3,000～5,000
• 或「維護 + 每月營運分析一頁建議」NT$10,000～20,000／月

4. 簽約前一定要確認的五句話（放在合約首頁）

1. 本合約範圍以「交付項目表」為準，未列者不在範圍。
2. 網域、主機、LINE 帳號皆登記於甲方名下，乙方為協作者。
3. 程式碼於尾款付清後交付甲方；乙方保留作品展示權。
4. 甲方提供素材與回饋之延遲，時程相應順延。
5. 範圍外需求以變更單處理，未簽認不執行。

用法：這是「事情發生時翻的那一頁」。每條寫：會怎麼發生、你怎麼看得出來、現在先做什麼、發生了怎麼辦。標 ★ 的是最可能真的發生、且代價最高的。

A. 售前與簽約

B. 需求訪談與規格

C. 開發執行（表妹）

D. LINE 特有

E. 上線與驗收

F. 導入（第二案為主）

G. 維運（交付後 1～12 個月）

H. 商務、法律、人

I. 你自己

最後三條，比全部加起來都重要

1. 沒簽認的範圍文件，不開工。 A1 是所有問題的源頭。
2. 每週看一次實機 demo。 C1 是你唯一能早期發現問題的方法。
3. 保留人工路徑。 第一案的 L0、第二案的手寫表照片——系統出問題時客戶的生意不能停，這也是客戶信任你的原因。

用法：分四個來源——客戶一、客戶二、表妹、你自己。每項標「必要」（沒有不能簽約／開工）或「可延後」（上線前補即可）。最後是開工前的檢核表。

1. 要跟第一案客戶（冰棒／食品廠）拿的

必要（簽約前）

• ☐ 廠商數量、每週訂單量、旺淡季（決定推播用量與 LINE 方案）
• ☐ 5～10 則真實的 LINE 訂貨訊息截圖（第二期自然語言下單的樣本；也讓你看清楚現在的流程）
• ☐ 價格是否每家不同；有無階梯價、月結
• ☐ 配送規則：幾天前訂、哪些天送、區域、最小訂量
• ☐ 訂單狀態有哪些、誰改
• ☐ LINE 是要到哪一層（①連結 ②通知 ③LINE 內填表 ④打字下單）——客戶親口選
• ☐ 現有 LINE 官方帳號？方案？好友數？帳號在誰名下？
• ☐ 網域、主機有沒有既有的？在誰名下？
• ☐ 廠商收款方式（匯款／月結，B2B 端第一期仍不串金流）
• ✅ 客戶端有沒有營業登記 — WT 於 2026-09-23 初步確認「有」，散客商店的藍新／綠界金流申請需要用到；訪談時核實統編是否對應到要申請金流的法人（08 檔第 5 節）
• ☐ 散客商店：三種付款方式（匯款／超商取貨付款／藍新或綠界）客戶偏好哪個優先上，收款帳戶資訊
• ☐ 後台使用者有幾人；兩角色（老闆／廠商）是否夠
• ☐ 誰是決策者、誰驗收、誰日常操作
• ☐ 期望上線日；有無硬截止
• ☐ 要不要發票（影響你的報價結構；散客商店若量大，電子發票是第二期項目，見 01 檔）

可延後（上線前）

• ☐ Logo、品牌色、商品照片、文案（W6 官網前）
• ☐ 商品清單、規格、單位、每箱數量（W8 建檔前，用你給的 Excel 模板）
• ☐ 廠商清單與聯絡人（W8）
• ☐ FAQ 內容與價目表 PDF（餵 LINE AI 聊天機器人，W7）
• ☐ 誰負責在 LINE 回訊息、幾點到幾點
• ☐ 庫存／配方／損耗的現況（第二期訪談用，現在只要知道「有沒有配方表」）

2. 要跟第二案客戶（多據點冰品飲料店）拿的

必要（簽約前）

• ☐ 每店最近一週的手寫進銷存表（拍照）——沒有這個不能定欄位
• ☐ 據點清單：幾店、類型（海生館／海邊／入口／出口）、營業時間
• ☐ 海生館的品項清單（試點用）
• ☐ 各店員工數、時薪／月薪、角色（正職／PT／發券／支援）
• ☐ 現有 POS 是什麼、結帳畫面能不能拍、有沒有日結報表可拍
• ☐ 銷量是直接記還是用期初期末算；折扣、招待、員工餐怎麼記
• ☐ 哪些商品有保存期限、幾天；報廢現在怎麼記
• ☐ 老闆最想知道的三個數字（決定報表優先順序）
• ☐ 老闆心中的「AI 排班」長什麼樣（當場降期待）
• ☐ 願意海生館先試跑 4 週？誰是海生館店長？
• ☐ 店長填報的紀律由誰保證（老闆親口承諾）
• ☐ 誰維護商品主檔
• ☐ 決策者、驗收者
• ☐ 要不要發票

可延後

• ☐ 商品成本（可先空白）
• ☐ 固定成本：租金、水電、勞健保估算（可先空白，但報表會標「不完整」）
• ☐ 過去的營收數字（驗證推算邏輯用；也決定要不要補登歷史）
• ☐ 園區／海生館活動行事曆來源
• ☐ 老闆看報表的裝置與頻率

3. 要跟表妹確認的

• ☐ 每週可投入時數（誠實的數字，不是願意的數字）
• ☐ 期中、期末、寒假、實習的日期
• ☐ 熟不熟 Python／Django／SQL／git／Docker（各 1～5 分自評；低於 3 的先花一週補）
• ☐ 有沒有部署過任何東西到伺服器（有／無，無就多排一週）
• ☐ 手上有沒有 Claude／Codex 帳號與額度
• ☐ 酬勞方式（里程碑／時薪）、金額、書面約定
• ☐ 她跟客戶的溝通規則（只進技術群）
• ☐ 退出通知期（至少兩週）與交接義務

3b. 外援顧問（2026-09-23 新增角色，可延後）

• ☐ 他方便的諮詢方式與頻率（電話／見面／訊息，大概多久回應）
• ☐ 是否需要付費或答謝（專業諮詢即使是人情，也建議明確一次，避免後續尷尬）
• ☐ 簽約前那次諮詢要問的具體問題先列出來，不要空手去聊（見 00 檔「這位外援怎麼用」）

3c. 補助企劃會議後要追蹤的（2026-09-25 新增）

• ☐ 週一晚上跟寫補助企劃的人開完會後，把「Demo 具體要交付什麼格式／內容」問清楚——目前 01 檔的 Demo 範圍（4.1 節）是我們自己推的，補助企劃書實際要求的呈現方式（例如要不要截圖、要不要現場操作、要不要書面架構圖）可能會回頭調整 Demo 範圍
• ☐ 確認補助申請本身的時程／截止日，跟 10/15 Demo、11/30 執行版本這兩個日期對齊，避免補助流程臨時改期程

4. 你自己要決定的

5. 開工前檢核（Definition of Ready）

第一案開發（W3）開始前，以下全部打勾：

• ☐ 範圍文件（05 檔）客戶簽認
• ☐ 合約簽、30% 到帳
• ☐ 訪談摘要客戶確認
• ☐ 網域、主機、Cloudflare、LINE Business ID 在客戶名下，你們有協作權限
• ☐ LINE Developers Provider 建好、Messaging API channel + LINE Login channel 同 Provider（截圖存證）
• ☐ git repo 建好、.gitignore、.env 範本、README 骨架
• ☐ 測試環境網址可開（哪怕只是「Hello」）
• ☐ 每週 demo 時間定好
• ☐ 表妹書面約定簽好
• ☐ 這份資料夾的文件她讀過並回饋問題

第二案開發（12 月）開始前：

• ☐ 以上通用項目
• ☐ 海生館手寫表逐格對照完成，欄位定義客戶簽認
• ☐ 推算邏輯（03 檔第 2 節）客戶簽認
• ☐ 海生館店長知道試跑計畫、同意
• ☐ 商品主檔（海生館）建好
• ☐ 天氣 API 測試成功（氣象署開放資料平台會員與 API key）

6. 之後若要再找 Claude 或其他人接手，給他們這些

1. 這個資料夾的 00～07
2. 訪談摘要（客戶確認版）
3. 簽認的範圍文件與合約
4. git repo 與部署文件
5. 帳號清單（存在密碼管理器，不在文件裡）
6. 最新一次週 demo 的紀錄（做到哪、卡在哪）

有這六樣，任何懂 Django 的人或任何 AI 都能在一天內接上。

背景：01 檔原規劃技術架構為 Django + PostgreSQL。2026-09-23 WT 提出：之前跟表妹討論其實是往 WordPress 方向。本檔評估可行性、風險與費用差異，供決策。此問題只涉及第一案（有公開網站與交易流程）；第二案是內部資料系統，沒有 WordPress 的用武之地，不適用。

研究日期：2026-09-23。外掛價格、方案狀態、漏洞數字會隨時間變動，簽約前建議重新核對。

2026-09-23 追加澄清（定案）：WT 確認 WordPress 的範圍只服務官網與散客商店（一般消費者買冰棒），完全不涉及廠商 B2B 下單。廠商 B2B 系統（專屬價格、只看自己訂單、LINE 整合）維持獨立系統，架構是「同一台主機、不同容器、各自資料庫、子網域分流」。這代表下面第 2 節（B2B 交易系統）討論的 WooCommerce B2B 外掛、年費、免費替代方案全部不適用於 WordPress 那一側——那些是給散客商店以外、真正的廠商系統用的分析，但廠商系統本來就走獨立的 Django（不是 WordPress），所以第 2 節純供對照參考，不影響最終架構。真正適用的是第 1 節（官網）與第 6 節（架構總覽、金流三方式、資安隔離）。

0. 結論（依 2026-09-23 定案更新）

最終架構是兩個獨立系統，各自用最適合的工具：

兩個系統跑在同一台 VPS 上，用不同容器、不同資料庫、不同（子）網域區隔，中間不互通資料（散客買冰棒的紀錄跟廠商訂貨的紀錄本來就是兩件事，不需要打通）。

下面第 2～2.6 節是「如果 WordPress 也要扛 B2B」的分析，現在確定用不到，保留是因為如果未來範圍變動（例如客戶要求官網也能給廠商登入），可以直接回頭看。目前請直接跳到第 1 節和第 6 節。

1. 官網（強烈建議 WordPress，無論交易系統選什麼）

• Gutenberg 區塊編輯器：老闆自己改文案、換圖片，不必找你們或表妹。這是 Django 版本做不到的（Django admin 是給操作訂單用的介面，不是給人寫文案用的 CMS）。
• SEO 外掛（Yoast、Rank Math）生態成熟，呼應之前查過鯤航 SEO 的邏輯，也適用這個案子。
• 主機選擇多、便宜（共享主機或雲端 WordPress 代管，約 NT$300～1,000／月），比 VPS + Docker 對非工程背景的人更友善。

建議：無論 B2B 系統選什麼架構，官網都用 WordPress。 就算交易系統走 Django，官網也可以是獨立的 WordPress，兩者用「訂購入口」連結串起來，不衝突。

2. B2B 交易系統：WooCommerce + 外掛的實際狀況

2.0 先釐清：哪些是免費、哪些真的要花錢（2026-09-23 補充）

WT 提出的疑問很關鍵，這裡先把三件事分開講清楚，因為它們常被混在一起：

你之前用過的「訂單系統」和「金流」，這兩塊確實免費，你的印象沒錯。 我之前的 08 檔內容容易讓人誤以為「B2B 這整塊都要年費」，這裡更正：真正要花錢或花工時的，只有「每家廠商價格不一樣」這一件事，不是整個訂單流程。

2.1 現成的 B2B 外掛（付費，功能齊全）

主要選項：B2BKing、Wholesale Suite、B2B Pricing（WooCommerce 官方）。共同能力：

• 依角色設定批發價、階梯折扣、固定廠商價
• 隱藏價格／分類給未登入或非核准角色
• 客戶註冊審核流程
• 子帳號、報價單、採購單結帳（B2BKing 較完整）

價格：B2BKing Pro 年費約 US$250（約 NT$8,000）；同類外掛多在這個量級或更高。這是持續性費用，要放進客戶自付清單，且逐年續。

2.1b 免費替代方案（夠不夠用，取決於廠商數量與需求深度）

查到幾個免費的角色定價外掛：ELEX Role Based Pricing、Wholesale Essentials、DreamFox Role & Wholesale Pricing。這些能做「依會員角色設定不同價格」，且不用年費。

限制：免費版通常是「一個角色一個折扣％」，適合「批發會員」「零售會員」這種少數幾種身分的定價。如果你們是「每一家廠商都有各自談好的價格」（不是統一批發價），免費外掛要嘛：

• 幫每家廠商各開一個角色（廠商多了會很難管理，10 家廠商就要維護 10 個角色）
• 或者做不到，還是得客製

這裡的實際判斷點是：這些廠商的價格差異，是「統一批發價 vs 零售價」這種一兩層，還是「每家都不同」？ 這件事訪談時（04 檔 A2 題）就會問到，答案會決定免費外掛夠不夠用。

2.1c 第三個選項：自己客製一個小功能，不買整套 B2B 外掛

如果廠商數量不多（例如 5～20 家）、且你們只需要「每家看到自己的價格、下單、看自己的訂單」，不需要報價單、子帳號、審核流程這些額外功能，那麼寫一個小型自訂外掛（用 WooCommerce 的 woocommerce_product_get_price 這類 hook，掛一張「廠商 × 商品 × 價格」對照表）通常比買 B2BKing 划算：

• 一次性開發成本，沒有年費
• 剛好對應你們的資料模型（跟 01 檔原本 Django 版本的 PriceList 表是同一個邏輯，只是換 PHP 寫）
• 缺點：客製的東西以後要客製的人維護，不像買外掛有官方更新（但這跟自己寫 Django 的取捨完全一樣）

這是我目前傾向的建議：先訪談確認廠商定價的複雜度，如果只是「每家不同價格」這麼單純，不建議花年費買 B2BKing 整套，客製一個小功能就夠；如果客戶還想要報價單、審核流程、子帳號這些，再評估買外掛划不划算。

限制：這些外掛解決的是「定價與可見性」，不是你們規格裡的細節（配送日、時段、備註、廠商多 LINE 帳號綁定、訂單狀態流轉的客製規則）。這些超出外掛預設的部分，仍要有人寫 PHP 自訂外掛或改布景主題函式庫（functions.php），工作量與 Django 客製資料模型是同一個量級，只是換語言寫。

2.2 訂單資料模型的變動：HPOS

WooCommerce 2026 年新站已預設採用 HPOS（High-Performance Order Storage），訂單資料存在專屬 SQL 表，取代舊版把訂單塞進「文章＋meta」的做法，效能已大幅改善，這點對 WordPress 是好消息。

但要注意：WooCommerce 10.7（2026 年 4 月）關閉了「寫回舊表」的預設同步。如果日後裝的某個外掛還在用舊方式寫訂單資料（許多外掛尚未跟上這個變動），資料可能悄悄不同步、你們不會馬上發現。外掛相容性是持續要盯的風險，不是裝好就結束。

2.3 LINE 整合：比原先預期成熟，但仍有缺口

台灣有專門做 WordPress + LINE 整合的外掛商，以歐博能（oberonlai.blog）的產品線為代表：

這些外掛都是為 B2C 零售場景設計：一般消費者用 LINE 登入、下單、收通知。你們要的是 B2B 場景：廠商登入後只看到自己的專屬價格與訂單，在 LINE 裡填表下單、系統自動辨識身分寫入訂單——這個特定流程沒有對應的現成外掛，仍要客製寫 WordPress REST API endpoint 接 LINE webhook 與 LIFF。

結論：LINE「登入綁定」與「通知推播」這兩塊，WordPress 生態比自己從零刻（不管哪個框架）省事；但「LIFF 辨識廠商身分 + 自動建單」這個核心流程，仍要客製開發，工作量與 Django + line-bot-sdk 的做法相近，只是換 PHP 寫。

2.4 資安維護負擔（實際數字，2026）

• WordPress 生態系統 2025 年新增 11,334 個漏洞，91% 出在外掛（非 WordPress 核心）
• 平均一個正式站台裝 30 個以上外掛，每個外掛的資料庫與檔案系統存取權限等同核心本身——外掛越多、攻擊面越大
• 43% 的漏洞不需要登入即可被利用
• 2026 年 6 月一次有 6 個 CVSS 9.8（滿分等級）漏洞同時被實際攻擊，影響 114 萬個站台
• WordPress 目前占全球網站 41.5%，是全網最大的攻擊面

你們這系統存廠商聯絡人、專屬價格、訂單資料，不是普通內容站。若走 WordPress，維護合約必須包含：外掛與核心定期更新、資安掃描服務（如 Wordfence Premium 或 Patchstack，另有費用），且負擔隨外掛數量增加。

Django 版本因為沒有外掛市集，這類風險小很多，但仍要自己顧好系統套件更新（Python 套件、作業系統安全更新）——負擔換位置存在，不是消失，只是規模與來源不同。

2.5 金流串接：免費外掛＋交易手續費，安全性務必用官方外掛，不要自己寫（2026-09-23 補充）

WT 問到：金流跟安全比較有關係，會不會別人寫的比較好？答案是肯定的，而且這點跟選 WordPress 或 Django 無關，是任何框架都該遵守的規則。

費用模式：台灣主要金流商的 WooCommerce 官方外掛本身都免費下載，收費方式是交易手續費（％），不是外掛授權費：

這對應到 07 檔已經提過的決定：藍新（甚至部分金流商）要求營業登記才能申請，這就是為什麼「你的接案身分」要先決定——這不只影響你自己的稅務，也影響客戶端能不能順利申請到金流（客戶當然是用自己的公司登記申請，但如果客戶本身還沒有商業登記，金流這塊會卡關，訪談時要確認客戶有沒有營業登記）。

安全性：不要自己寫信用卡處理邏輯，用官方「跳轉頁」模式

這是你的直覺完全正確的地方。原因很技術但很重要：

• 官方外掛用的是「頁面跳轉」付款：消費者的信用卡號直接輸入在金流商的加密頁面，你們的網站或伺服器完全不會接觸或儲存卡號。
• 這代表 PCI-DSS（信用卡資料安全標準）的合規責任主要由金流商承擔——他們是通過最高等級認證的專業機構。
• 如果自己寫程式處理信用卡資料（不管用 Django 還是 WordPress），等於要自己去符合 PCI-DSS，這對一個小型系統來說幾乎不可能達到，也不應該去嘗試：一旦你們的伺服器經手卡號，合規範圍、稽核成本都會跳好幾個等級，而且真的出資安事件，最高可能面臨每筆交易罰款等級的責任。

結論：金流這塊，不管最後選 WordPress 還是 Django，都是「串官方 SDK／外掛，讓消費者在金流商的頁面輸入卡號」，絕對不要自己刻收單邏輯。 WordPress 的優勢在這裡是「外掛已經幫你把跳轉流程包好了，裝上去、填 API 金鑰就能用」；Django 版本一樣可以做到同等安全（呼叫綠界／藍新的官方 API 做跳轉），只是需要工程師自己寫這段串接，工作量稍微多一點，但安全性原理完全一樣——不是 WordPress 比較安全，是「用官方跳轉頁」這件事本身安全，兩個框架都要這樣做。

跟第一期範圍的關係：01 檔原規劃第一期就不含金流（廠商採匯款、月結，出貨前付款），這件事現在不用改變。金流是第二期才會用到的功能，這裡先研究清楚是為了讓你們評估架構時心裡有數：金流這塊不會因為選 WordPress 而變貴或變便宜，兩邊都是「外掛/SDK 免費、交易抽成」的相同模式。

2.6 第二期庫存／成本／BOM：不會因換框架而變簡單

原料、配方（BOM）、處理損耗率、成品批次與到期日、成本回推——這是你們這個案子獨有的業務邏輯，市場上沒有通用外掛對應這類食品業的庫存邏輯。WordPress 的「文章＋自訂欄位（postmeta）」資料模型處理這種多層關聯資料，效能與可維護性通常不如關聯式資料庫的原生設計（Django ORM 或直接寫 SQL）。這塊無論選哪個框架都是硬功夫，WordPress 沒有捷徑，也不會更便宜。

3. 費用差異總表（相對於 01 檔原報價）

淨效果：官網省下的開發工時，多半被 B2B 外掛年費與更高的維護費抵銷。真正的差異在表妹的學習曲線與部署難易度，這是純技術規格算不出來的，取決於她的實際背景。

4. 三個方案（2026-09-23：已定案選 A）

5. 需要確認才能定案的事（已定案項目標記 ✅）

1. 表妹對 PHP 的真實熟悉度 — ✅ 不影響定案：B2B 系統維持 Django，WordPress 那側是標準 WooCommerce 設定，難度低，不需要表妹會寫自訂 PHP 外掛。
2. 廠商定價的複雜度 — ✅ 不適用：廠商 B2B 系統不在 WordPress 裡，第 2 節的外掛年費討論用不到。
3. 同一台主機的網路隔離要在 W1 建置時就設好：WordPress 容器不能連到 B2B 系統的資料庫連接埠，反之亦然。見第 6 節。
4. 子網域與 SSL 規劃：主網域（官網＋商店）與子網域（B2B 系統，例如 order.客戶網域.com）各自的憑證與 DNS 設定，W1 訪談時連同「網域在誰名下」一起確認（04 檔共同題 3）。
5. 金流第一期不做（01 檔已定：廠商採匯款、月結），但散客商店的金流／物流是另一件事，若要在第一期就做（見追加澄清），需要把 01 檔的「消費者端」模組從「僅詢價」升級為「完整下單＋付款」，報價要相應調整（見第 6.4 節）。
6. 訪談時確認客戶有沒有營業登記 — ✅ WT 於 2026-09-23 初步確認客戶端有營業登記；細節（統編是否對應到要申請金流的法人）留待訪談時核實。

6. 最終架構總覽（2026-09-23 定案）

6.1 兩個系統，各自獨立

一台 VPS（Docker）
|
+- 容器 A：WordPress + WooCommerce + MySQL
|    網域：主網域（例如 客戶網域.com）
|    服務對象：一般消費者（散客）
|    功能：品牌官網、商品展示、購物車、結帳
|
+- 容器 B：Django + PostgreSQL
|    網域：子網域（例如 order.客戶網域.com）
|    服務對象：廠商（B2B）
|    功能：廠商登入、專屬價格、下單、後台、LINE LIFF 整合
|
`- Cloudflare（DNS、憑證）+ nginx/Caddy（依網域名稱分流到對應容器）

兩個系統不互通資料：散客買冰棒的紀錄跟廠商訂貨的紀錄是兩件事，沒有打通的必要。各自的資料庫也完全分開。

6.2 資安隔離（重要，不是多餘的謹慎）

WordPress 生態 2025 年新增 11,334 個漏洞、91% 出在外掛（見第 2.4 節數字）。這個風險現在雖然只影響散客商店，但如果兩個容器共用同一個資料庫伺服器或同一個內部網路，WordPress 那邊一旦被攻破，攻擊者有機會橫向移動碰到 B2B 那邊的廠商資料。

建置時要做的事（不增加成本，只是要記得設定）：

• 兩個容器用 Docker 的獨立網路（network），預設互不可達
• MySQL（WordPress 用）與 PostgreSQL（Django 用）各自只在自己的容器網路內開放連接埠，不對外、也不對另一個容器開放
• 若日後真的需要兩邊資料互通（例如老闆想在同一個後台看散客與廠商的總營收），透過一個明確定義的 API 呼叫，而不是直接開資料庫存取權限

6.3 三種付款方式的落地方式（確認可行，皆為 WooCommerce 標準做法）

三種都不需要客製開發，是 WooCommerce 最主流的台灣電商標準配置，教學資源非常多，表妹或任何人都能照著文件設定完成。

6.4 這件事跟 01 檔報價的關係（2026-09-23 定案：併入第一期）

01 檔原規劃第一期的「消費者端」只做詢價表單，完整購物車＋金流原本放在第二期。WT 確認：因為這塊是標準 WooCommerce 設定（不是客製開發），併入第一期。 01 檔報價加回約 1.5～2.5 萬（WooCommerce 商城建置＋三種付款方式設定與測試）。

6.5 散客與廠商訂單如何整合進銷存（不要連資料庫，用 Webhook + API）

WT 提出：官網下單後的進出貨資料要跟廠商 B2B 的訂單資料整合成進銷存，因為賣的是同一批貨、兩邊都要扣庫存。這個業務邏輯正確，但實作上不能讓 WordPress 直接連到 Django 那邊的資料庫——這會打破 6.2 節剛建議的網路隔離（WordPress 外掛漏洞多，直連資料庫等於幫攻擊者鋪路），而且 WordPress 用 MySQL、Django 用 PostgreSQL，本來就是兩種資料庫系統，硬接也不穩定。

正確做法：用 WooCommerce 內建的 Webhook，把資料「推」過去，不是把資料庫「連」過去。

消費者在 WooCommerce 下單
   |
   v
WooCommerce 內建 Webhook（設定 > 進階 > Webhook，免費、不用寫程式）
   | 訂單建立／狀態變更時，自動 POST 訂單 JSON（含簽章）到指定網址
   v
Django 接收端點（這是要開發的部分，工作量不大）
   | 驗證簽章 → 解析品項與數量 → 寫入進銷存資料表，標記「通路：散客」
   v
Django 端把散客與廠商（B2B，本來就直接寫在 Django）兩個通路的資料匯總
   |
   v
（第二期完整庫存模組）Django 算出最新可售庫存
   | 透過 WooCommerce 官方 REST API 回寫庫存數字
   v
WooCommerce 商品頁庫存同步更新，避免賣超

分工與時程：

• WooCommerce 設定 Webhook：設定而非開發，成本幾乎零，第一期可以直接設好。
• Django 接收端點（驗證簽章、解析、寫入原始銷售紀錄）：第一期可以先做「輕量版」，忠實記錄散客訂單資料，不急著做完整庫存計算，這樣資料不會漏掉，第二期接上完整邏輯時不用回頭補資料。這塊是小工程，若要在第一期加做，抓 0.5～1 萬。
• 完整的庫存扣減、配方成本、批次到期、回寫 WooCommerce 庫存：維持第二期，跟 01 檔庫存模組原規劃一致，不會因為現在多接一個 Webhook 就變簡單或提前。

6.5.1 技術細節：自架 API，不需要第三方服務（2026-09-23 補充）

WT 問：能不能自己架 API 讓資料庫串接？可以，而且這就是標準做法——Django 本身就是這支 API，不需要另外找服務。 兩個方向的具體規格：

方向 1：WooCommerce → Django（散客訂單通知，第一期 E2）

方向 2：Django → WooCommerce（第二期，回寫庫存數字）

兩個方向合起來，整個「串接」就是兩組有驗證機制保護的 HTTP 呼叫，沒有任何一邊拿到對方資料庫的帳號密碼，維持 6.2 節的隔離原則。這兩段是 E2（第一期）與庫存模組（第二期）本來就包含的工作，不會因為釐清做法而追加費用。

7. 資安強化清單（2026-09-24 新增）

背景：WT 問「這個架構的資安，別人想打的話容易不容易」。老實回答：照著架構本身的隔離設計（WordPress／Django 分容器、官方金流跳轉頁、Webhook 簽章驗證）能擋掉大部分自動化攻擊與亂槍打鳥，但沒有專業資安審查、又是時程壓縮下由學生＋AI 協作寫出來的，對「有目的的針對性攻擊」不算難打。 最大的單一弱點是 IDOR（廠商 A 猜／改網址參數看到廠商 B 的資料）——這是 Django 不會自動擋、必須工程師每個端點都手動檢查的東西，也是真實世界資料外洩最常見的原因之一，偏偏又是趕時程時最容易被漏測的項目（頁面「看起來能動」，功能測試會過）。

7.1 免費或低成本，應該直接做（已寫進 01 檔驗收清單）

7.2 要花錢或花時間，值得評估

7.3 結論

7.1 是紀律問題，不是預算問題，不建議因為時程壓縮而跳過；7.2 可以先緩，等系統穩定運作、有真實金流之後再評估。

資料來源

• Barn2：The Best WooCommerce B2B Plugins for 2026
• B2BKing：8 Best WooCommerce B2B Plugins for 2026
• WooCommerce Developer Docs：High-Performance Order Storage (HPOS)
• Patchstack：State of WordPress Security in 2026
• Webmastered：250+ Weekly WordPress Plugin Vulnerabilities in 2026
• adyog：June 2026: Six CVSS 9.8 Vulnerabilities, 1.14 Million WordPress Sites
• 歐博能 WP 開發日常：OrderChatz — LINE 推播鎖定真買家、WordPress LINE 登入外掛、給台灣人專用的 WooCommerce 擴充
• Irvinglab：LINE Core 360：LINE 登入、結帳、訂單通知整合
• ELEX：WooCommerce Role Based Pricing Plugin（免費）
• WordPress.org：Wholesale Essentials for WooCommerce（免費）、DreamFox Role & Wholesale Pricing（免費）
• 綠界科技：服務費率表
• WordPress.org：Newebpay Payment 外掛
• WooCommerce：PCI-DSS compliance and WooCommerce
• progressbar.tw：想製作線上支付服務？PCI-DSS 規範
• Hookdeck：Guide to WooCommerce Webhooks Features and Best Practices、How to Secure and Verify WooCommerce Webhooks
• WooCommerce Developer Docs：REST API Authentication、REST API Documentation
• linuxconfig.org：How to work with the WooCommerce REST API with Python