JLC 客服溝通
目標有兩個：每則訊息都要換到能驗證的答覆；任何回覆都不能被當成你批准了什麼。
硬規則
以下動作每一次都要使用者在聊天中明確同意，不能從先前的同意類推：
- 寄出信件或送出聊天訊息（草稿可以先寫）
- 從網站下載工廠的生產稿或其他檔案
- 上傳檔案、接受條款、提交訂單（包含「只送審不付款」）
- 接受加費、補償或優惠方案
- 確認生產稿（Confirm Production）或貼裝確認（Confirm Parts Placement）
- 修改設計或製造檔
唯一的例外：使用者可以明確說出範圍和期限，事先授權「催辦」與「純技術澄清」兩種訊息，例如「到這張訂單出貨前，帶界線句的催辦可以直接送」。
- 例外要寫進專案的 WORKLOG。
- 例外內的每則訊息都要帶界線句，寄出後記錄時間與內容。
- 例外永遠不包含上面清單的其他動作：確認、費用、補償、訂單、上傳、下載、設計修改。
- 範圍不清楚或期限已過，就回到逐次確認。
付款、身分證號、清關資料由使用者本人在網頁填寫。agent 不讀取、不記錄、不轉述這些內容。
跟訂單有關的信，一律從訂單註冊信箱寄出，並回在原信串。寄信工具如果連到別的帳號，先停下來告訴使用者。
寫訊息前先核對
工具與退路見下方「工具搭配」。
- 打開網站訂單頁，看詳細狀態，不要只看頁首的徽章。頁首寫 In Production 時，詳細狀態可能還是 Data Preparation。
- 搜尋註冊信箱，垃圾信也要看；再讀上一次的客服對話。
- 記下所有編號（購物車儲存後可能改號，新舊編號都要記）、狀態、核對時間與時區。
- 客服說「信已寄出」或「已處理」時，先查信箱再回覆。這類說法曾被同一家公司的另一位客服推翻。
訊息結構
每則訊息依序包含：
- 主旨：
<要求的動作> — <訂單編號> - 問候
- 一行背景：編號、剛核對到的狀態、時間與時區
- 一句影響（例如假期將至、期限倒數）
- 編號問題，能寫成二選一就寫成二選一
- 退路：拿不到完成時間時，請對方給負責人和下次更新時間（含時區）
- 界線句，例如：
This is not approval of DFM/production, design changes or extra fees. Please keep manual confirmation. - 致謝與署名
寫作規則：
- 第一則訊息要能獨立看懂。 線上客服會輪替，接手的人只看得到這一則。
- 跨日寫絕對日期。 過了午夜才寄，就把「今天」改成「9 月 28 日」。
- 一封信只談一件事。 退款、合規這類問題混在長信末段，連問三次都沒人回答。這類問題要開獨立信串；信尾有 Escalate Case 連結時，可以請使用者決定是否使用。
- 大部分問題答完後，只追問剩下的那一點。
- 把籠統答覆逼成明確確認。 對方說「別擔心」或「選 Yes 就好」時，回問二選一，例如「是 5 片全部，還是只有 2 片？」
- 網站和客服說法衝突時，貼網站原文。
- 核心問題解決前不接受補償。 在信中明寫「尚未接受 <補償> 作為解決方案」。
工程澄清
- 寫明座標系、平移量和 mm 數值，例如
original (12.3, 4.5) mm single-board coordinates; CAM offset (+23, +17)。 - 主動排除誤解：說明「並非指稱斷路」，或「這個讀數可能是游標位置或料庫原點」。
- 請對方附上標註圖。
- 不要為了讓顯示數值對齊而改設計；先確認那個數值代表什麼。
- 重要要求同時寫進訂單備註和附件（裝配圖 PDF），工廠 CAM 端看得到備註。
管道
| 管道 | 用途 |
|---|---|
| 線上聊天 | 即時問答、催辦；結束前確認拿到一個能驗證的承諾 |
| 註冊信箱 | 需要書面證據、附件、工程澄清；回在同一信串 |
| 業務或合作窗口 | 窗口失效或要協調多個部門時才找。先報進度、說明影響，再提出請求 |
| 訂單備註＋附件 | 送單時就把工序要求寫進去，讓 CAM 端看得到 |
期限倒數
收到生產稿或貼裝確認信時，立刻算出到期的絕對時間（含時區），寫進 WORKLOG 並告訴使用者。用本 skill 的腳本計算，不要心算：
python -I scripts/deadline.py --received "<收信時間>" --tz +08:00 --hours 72
退出碼 0 代表還沒到期、1 代表已過期、2 代表輸入錯誤。輸出的「deadline」那幾行照抄進 WORKLOG。有些確認稿逾期會直接投產，在期限前必須讓使用者做出決定。
過去觀察到的期限見 references/deadlines.md。那是快照，以當下的信件與網站為準。
節奏與停止條件
- 對方沒有承諾時間時，主動催辦至少相隔 4 小時；只查不催的監控可以更密。對方給了時間，就照那個時間。這是間隔的下限，不是自動寄出的許可：每則催辦仍要使用者同意，或落在硬規則的限定例外內。
- 以下情況通知使用者：有實質進展、出現失敗、需要使用者決定、期限倒數。
- 以下情況停止：對方最終拒絕；已取得報告並交給使用者；登入或瀏覽器中斷（通知一次後暫停）；使用者說暫停。
- 對方說「會寄信」「正在催」，不算結案。
工具搭配
原則：MCP 只用來看當下狀態，腳本用來算期限、做判定。MCP 回覆「成功」不代表訊息已送達或狀態已改變，要讀回確認。
| 步驟 | MCP／工具 | 腳本（相對於本 skill 資料夾） | 限制 |
|---|---|---|---|
| 看訂單詳細狀態、客服對話 | 瀏覽器：Claude in Chrome（Claude Code）；ChatGPT browser extension（Codex 桌面版 @Chrome，Codex CLI 不支援） | — | 只讀；不點 Confirm、Submit，不改選項，不下載 |
| 搜註冊信箱、讀信串 | 信箱：Gmail connector（claude.ai 或 ChatGPT） | — | 先確認連到訂單註冊帳號；寄出另依硬規則 |
| 起草訊息 | — | — | 草稿可以先寫；寄出等使用者同意 |
| 算確認稿到期時間 | — | scripts/deadline.py | 結果寫進 WORKLOG |
| 生產稿、貼裝確認的比對 | — | 交給 jlc-production-review skill | 本 skill 只負責把它的待問清單寫成澄清信 |
- 上表只列實際用過的工具。其他瀏覽器或信箱工具未驗證，用之前先列出實際工具與 schema，不要猜參數。
- 沒有工具時的退路：沒有瀏覽器或信箱工具（例如在 Codex CLI 裡），請使用者貼上訂單頁的詳細狀態、相關信件與上次對話，再起草。草稿的核對紀錄註明「狀態由使用者提供，未直接核對」。
交付草稿時附上
每份草稿前面先給使用者看這幾項，方便使用者決定：
- 核對紀錄：看了哪些來源（訂單頁、信箱、上次對話）、核對時間與時區；沒直接核對的註明。
- 訊息類型：需要逐次同意，或落在使用者事先授權的例外內（寫出是哪一條授權）。
- 建議管道：線上聊天、註冊信箱原信串，或業務窗口，以及理由。
- 期限：相關確認稿的到期時間（含時區）與剩餘時間。
- 草稿本文：英文，含界線句。
證據
- 每次對話保存聊天全文 txt、寄出畫面截圖，記下對方角色與時間（含時區）。
- 證據放在專案的私有目錄。截圖常含姓名、信箱、電話、地址，公開前必須去除。
- agent 寫的摘要不算證據。
參考
- references/templates.md：催辦、取消恢復、技術澄清、報價優惠、付款後請對方負責到底、退款追問六種範本
- references/pitfalls.md：踩過的雷與教訓
- references/deadlines.md：觀察到的期限與客服時段（快照）
- references/case-study.md：一次完整訂單的匿名時間線
- scripts/deadline.py：確認稿到期時間計算（只用標準庫）
