JLC 客服溝通

目標有兩個：每則訊息都要換到能驗證的答覆；任何回覆都不能被當成你批准了什麼。

硬規則

以下動作每一次都要使用者在聊天中明確同意，不能從先前的同意類推：

• 寄出信件或送出聊天訊息（草稿可以先寫）
• 從網站下載工廠的生產稿或其他檔案
• 上傳檔案、接受條款、提交訂單（包含「只送審不付款」）
• 接受加費、補償或優惠方案
• 確認生產稿（Confirm Production）或貼裝確認（Confirm Parts Placement）
• 修改設計或製造檔

唯一的例外：使用者可以明確說出範圍和期限，事先授權「催辦」與「純技術澄清」兩種訊息，例如「到這張訂單出貨前，帶界線句的催辦可以直接送」。

• 例外要寫進專案的 WORKLOG。
• 例外內的每則訊息都要帶界線句，寄出後記錄時間與內容。
• 例外永遠不包含上面清單的其他動作：確認、費用、補償、訂單、上傳、下載、設計修改。
• 範圍不清楚或期限已過，就回到逐次確認。

付款、身分證號、清關資料由使用者本人在網頁填寫。agent 不讀取、不記錄、不轉述這些內容。

跟訂單有關的信，一律從訂單註冊信箱寄出，並回在原信串。寄信工具如果連到別的帳號，先停下來告訴使用者。

寫訊息前先核對

工具與退路見下方「工具搭配」。

1. 打開網站訂單頁，看詳細狀態，不要只看頁首的徽章。頁首寫 In Production 時，詳細狀態可能還是 Data Preparation。
2. 搜尋註冊信箱，垃圾信也要看；再讀上一次的客服對話。
3. 記下所有編號（購物車儲存後可能改號，新舊編號都要記）、狀態、核對時間與時區。
4. 客服說「信已寄出」或「已處理」時，先查信箱再回覆。這類說法曾被同一家公司的另一位客服推翻。

訊息結構

每則訊息依序包含：

1. 主旨：<要求的動作> — <訂單編號>
2. 問候
3. 一行背景：編號、剛核對到的狀態、時間與時區
4. 一句影響（例如假期將至、期限倒數）
5. 編號問題，能寫成二選一就寫成二選一
6. 退路：拿不到完成時間時，請對方給負責人和下次更新時間（含時區）
7. 界線句，例如：This is not approval of DFM/production, design changes or extra fees. Please keep manual confirmation.
8. 致謝與署名

寫作規則：

• 第一則訊息要能獨立看懂。 線上客服會輪替，接手的人只看得到這一則。
• 跨日寫絕對日期。 過了午夜才寄，就把「今天」改成「9 月 28 日」。
• 一封信只談一件事。 退款、合規這類問題混在長信末段，連問三次都沒人回答。這類問題要開獨立信串；信尾有 Escalate Case 連結時，可以請使用者決定是否使用。
• 大部分問題答完後，只追問剩下的那一點。
• 把籠統答覆逼成明確確認。 對方說「別擔心」或「選 Yes 就好」時，回問二選一，例如「是 5 片全部，還是只有 2 片？」
• 網站和客服說法衝突時，貼網站原文。
• 核心問題解決前不接受補償。 在信中明寫「尚未接受 <補償> 作為解決方案」。

工程澄清

• 寫明座標系、平移量和 mm 數值，例如 original (12.3, 4.5) mm single-board coordinates; CAM offset (+23, +17)。
• 主動排除誤解：說明「並非指稱斷路」，或「這個讀數可能是游標位置或料庫原點」。
• 請對方附上標註圖。
• 不要為了讓顯示數值對齊而改設計；先確認那個數值代表什麼。
• 重要要求同時寫進訂單備註和附件（裝配圖 PDF），工廠 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 回覆「成功」不代表訊息已送達或狀態已改變，要讀回確認。

• 上表只列實際用過的工具。其他瀏覽器或信箱工具未驗證，用之前先列出實際工具與 schema，不要猜參數。
• 沒有工具時的退路：沒有瀏覽器或信箱工具（例如在 Codex CLI 裡），請使用者貼上訂單頁的詳細狀態、相關信件與上次對話，再起草。草稿的核對紀錄註明「狀態由使用者提供，未直接核對」。

交付草稿時附上

每份草稿前面先給使用者看這幾項，方便使用者決定：

1. 核對紀錄：看了哪些來源（訂單頁、信箱、上次對話）、核對時間與時區；沒直接核對的註明。
2. 訊息類型：需要逐次同意，或落在使用者事先授權的例外內（寫出是哪一條授權）。
3. 建議管道：線上聊天、註冊信箱原信串，或業務窗口，以及理由。
4. 期限：相關確認稿的到期時間（含時區）與剩餘時間。
5. 草稿本文：英文，含界線句。

證據

• 每次對話保存聊天全文 txt、寄出畫面截圖，記下對方角色與時間（含時區）。
• 證據放在專案的私有目錄。截圖常含姓名、信箱、電話、地址，公開前必須去除。
• agent 寫的摘要不算證據。

參考

• references/templates.md：催辦、取消恢復、技術澄清、報價優惠、付款後請對方負責到底、退款追問六種範本
• references/pitfalls.md：踩過的雷與教訓
• references/deadlines.md：觀察到的期限與客服時段（快照）
• references/case-study.md：一次完整訂單的匿名時間線
• scripts/deadline.py：確認稿到期時間計算（只用標準庫）