hi, I'm Kim.

評論信任感工程

一句話定位：Cyberbiz 反映一年沒結果的「列表頁商品星等」，自建一天全上線——資料管線、呈現模組、邀評自動化，閉環做好。

起點：199 筆評論埋著，顧客在列表頁完全看不到

店裡其實有很多評論。Kim 每次收到顧客在訂單留言說「很好穿」「好愛這條褲」，都會親手把留言搬進評論區。兩百筆評論裡，172 筆是這樣來的。

但顧客在商品總覽頁、分類頁、搜尋結果頁瀏覽時，每張商品卡片上沒有任何星等——這些信任感資產完全埋著，顧客根本看不到。

Kim 跟 Cyberbiz 客服反映超過一年。對他們來說，這是收費客製服務，沒有要做的打算。

過程：一天做完四件事

今天 Kim 授權自建，前提是不影響官網正常運作、出了問題可以立刻回復。

從早到晚做了四件事。

第一件：搞清楚資料在哪。 動手前先查評論總數。後台管理介面預設顯示第一頁，6 筆——一度以為全站只有 6 筆。繼續翻才發現有分頁，實際是 199 筆已審核評論、橫跨 140 件商品。這個錯誤如果沒發現就動手，後面所有設計都會建在錯誤的前提上。

第二件：商品頁三件呈現工程。 照商品頁的樣板結構，補了三個地方：

• 商品名稱旁星級徽章：版型原本就有預留掛載點 #board-comments-rating-badge，補一個 div 就渲染，零評論自動改顯示「發表評論」引導；
• 購買區下方自製「顧客評價」精選卡：這件事做了三輪才定案。v1 把 widget 整個搬到「這樣搭」前面——用 JS 量了 offsetTop 才知道購買區才是有感位置；v2 搬到購買區下方但用原生 widget——手機版紅藍按鈕跟品牌完全不搭；v3 是 Kim 自己提案：自製一張細線極簡米白底卡片，只顯示平均星等和一句代表性評語，JS 即時從 widget 抓，零評論自動隱藏，整體融入品牌。這個定案；
• 版型備份六份（backups/），樣板編輯器版本控制也可回復，可逆。

第三件：列表頁星等模組。 collection、category、search 三個版型都要加，不只加進商品頁就算。打通評論 admin API（Cyberbiz 評論資料走另一個子系統 board.cyberbiz.co，不走一般後台 API）：先拿 token、撈 199 筆評論、按商品算平均星等和評論數，把結果寫成佈景片段（snippets/_as_review_stars.liquid），include 進三個版型。排程每日 11:20 自動同步（sync_review_stats.py），數據不用人維護。顯示金色星等（#f0a500）+ 評論數，Kim 指定要顯眼。

第四件：邀評自動化 review_invite.py。 店裡 172/199 筆評論是 Kim 一筆一筆親手搬的。這個流程太耗人了，要讓它自動跑起來。Cyberbiz 沒有內建邀評信，AUTOMATION 擴充的觸發條件也不夠精準——只認購買日、不認取貨日，預購商品 7–20 工作天後貨才到，照購買日發就是邀還沒收到貨的人。

破解訂單對話 API，以商店身份在訂單留言發邀評訊息。顧客收到「商店回覆了您的訊息」通知信，點進去直接回留言，Kim 再搬評論、發 $50 券。

發送時機 Kim 定案：超商等確認取貨後 7 天（七天鑑賞期過完）；郵寄/順豐等出貨後 10 天（估 3 天送達加 7 天鑑賞）。防呆：退貨中不發、對話還開著不發、每單一次、同顧客 120 天冷卻。

卡關與突破

• 卡關：全站只有 6 筆評論？ 後台列表只看了第一頁。多翻幾頁才發現：199 筆、140 商品。教訓：後台有分頁的地方，不能只讀第一頁就下結論。這條教訓進了全域 memory。

• 卡關：評論資料不在一般後台 API → 打通 board.cyberbiz.co 子系統：先 GET /admin/board_comments/token 拿短效 token，再打 board API 拉評論。

• 卡關：邀評不能照購買日發（預購店陷阱） → Kim 抓出來的：預購商品從下單到取貨最多 20 個工作天，購買日加 7 天根本貨還沒到。改照取貨日/出貨日判斷，取貨日從訂單 histories 欄位精確抓（7-11 和全家的日期格式不同，regex 各自兼容）。

• 卡關：商品頁星等「搬上去」顧客沒感覺 → 量 offsetTop 佔比才知道是使用者滾動習慣問題，不是 DOM 順序問題。只改 DOM 順序而沒驗使用者會不會看到，是白工。

• 卡關：樣板編輯器自動化 → 打通 ACE 編輯器介面（window.ace.edit）、同意視窗 checkbox、新增片段流程，以後可以程式化改版型，不只靠人工進後台貼 code。

成果：現在它做什麼

• 商品列表頁每張卡片顯示金色星等 + 評論數，每日 11:20 自動同步
• 商品頁購買區下方有「顧客評價」精選卡，即時從 widget 抓，零評論自動隱藏
• 商品名稱旁有星級徽章
• 邀評自動化已建好：每日 11:40 掃訂單，依取貨日/出貨日計算時機，自動在訂單留言發 Kim 的邀評文案
• 整條閉環：邀評自動發 → 顧客回留言 → Kim 搬評論發券 → 每日 11:20 星等同步 → 列表頁/商品頁顯示 → 信任感 → 轉換

Kim 補充

怎麼辦到的：為什麼全部在一天之內

版型可程式化操作，是關鍵前提。Cyberbiz 版型編輯器本質是一個 ACE 程式碼編輯器，讀出版型原文、改完、存回去，都可以腳本做，不用人工進後台貼 code。有這個底，才能一天上三件事。

佈景片段（snippets）是安全的插入點。 不改核心 liquid 邏輯，寫一個 _as_review_stars.liquid 片段、用 include 掛進去，片段壞了只要拔 include 就回復，不會動到平台核心版型。

評論資料為什麼每日同步而不即時。 評論數量不會分鐘級變化，每日同步已足夠，而且省去需要在瀏覽器端每次打 board API（需要 token 刷新）的複雜度。寫進 liquid 片段就是純靜態渲染，不影響頁面速度。

邀評為什麼走訂單留言而不是 Email 系統。 Kim 的流程是：顧客留言 → Kim 搬評論 → 手動發 $50 券。讓顧客在訂單留言直接回，手順最短，不需要跑商品頁、不需要記連結，放棄率最低。而且顧客回留言 → 進客服問題 → Kim 一個地方就能看到並回應，比分散在信箱更好管。

為什麼選 role=admin 而不是 role=admin_note。 訂單對話 API 有兩種角色：admin 是顧客看得到的留言（顧客會收到通知信）；admin_note 是內部備註（顧客看不到）。邀評要顧客收到、要他們回應，所以必須 admin。

我學到什麼

規格小檔　建立：2026-06-11｜工具：sync_review_stats.py（每日 11:20）、review_invite.py（每日 11:40）｜資料來源：board.cyberbiz.co 評論 admin API｜版型掛載：collection/category/search 三版型 + snippets/_as_review_stars.liquid｜版型備份：amesoeur-analyst/backups/ 六份｜最後更新：2026-06-11

DeskMemo：桌面便利貼

一句話定位：做給容易忘東忘西的同事——便條紙釘在螢幕最上層、關機想落跑會被警示音擋住的那種工具。

起點：為什麼我需要它

我的同事有個眾所皆知的毛病：東西放眼前也忘。代辦事項貼在螢幕邊框的那張紙，隔天就不見；手機備忘錄開了也不看；Line 自己傳自己的訊息，十分鐘後忘記查。

這個問題有一個特徵：她不是真的不在意，只是眼睛需要「它就在那裡」才會記得。

所以我想：有沒有辦法讓便條紙永遠在螢幕上、不管切到哪個視窗都看得到？而且關電腦的時候主動攔住她、提醒沒看完的事？

這就是 DeskMemo 的起點。

過程：怎麼把它做出來

從 Electron 開始。Electron 讓桌面 app 可以用 web 技術（HTML、CSS、JS）寫，一份程式碼 Windows 和 Mac 都能跑。最適合這個需求：置頂視窗（setAlwaysOnTop）本身就是 Electron 原生功能，GitHub Actions 可以自動幫 Mac 版打包（我沒有 Mac，但同事用 Mac）。

v0.1.0 一個上午完成：黃底便利貼、置頂、收合、關機/闔蓋警示音。GitHub Release 發出去，永久下載連結不帶版號（releases/latest/download/DeskMemo-Setup.exe），日後更新她直接重下載，舊連結永遠指最新版。

版本就從那裡一路往後滾。

一天之內的版本演進

這個產品是 2026-06-11 一天內從 v0.1 做到 v0.9.1 的——從黃色便利貼起步，中間 Kim 連續幾輪退稿和校正，最終定型成無印筆記本風格。

v0.2：圖示換掉、加顏色加清單

第一個退稿來得很快：「圖示太科幻。」Electron 預設是一個原子軌道圖——很工程感，跟便利貼這個東西完全不搭。自畫便條紙圖示換上去，同時加了紅圖釘（可釘/可拔、有動畫、針孔會留下），五種底色，清單模式（打勾後文字劃掉）。

v0.3：加入紙感和手寫

第一輪紙感材質（纖維紋理/光影/背膠條/捲角陰影）。手寫模式（畫筆/橡皮擦）。

然後第二個退稿：「楷體太復古。」預設字體改微軟正黑。

v0.4：工具變豐富

字型、字級、斜體工具列。鬧鈴（響鈴、貪睡 10 分鐘、關機錯過補響）。照片可貼進便利貼——像拍立得一樣，可拖拉調大小，點照片還可以放大看。

v0.5：整套換成無印風

這一版是最大的轉向。

Kim 傳來五張 MUJI 實物參考圖，說：「就是這個感覺。」

整套視覺換掉：象牙白/純白/霧灰/灰綠/牛皮五色、細灰橫線、刻印小標籤。新增三種紙：週記（有 MONTH 欄和週一到週日的格欄）、月記（月曆格、可翻月、今天反白）、單字卡（一面寫字、翻面看）。圖示換成牛皮線圈筆記本。

v0.6：紙真的浮起來了

這一版查了資料後重做視窗本體：視窗改透明、紙張真正浮在桌面上——帶落影、有手裁的微歪邊，不再是貼著視窗邊框的感覺。工具列改可收合，不擋字。

同時修了一個藏了幾版的 bug：橫線根本沒有畫出來。原因是 CSS 的 calc() 搭配 CSS variable 在漸層語法裡會靜默失效，讓整個線稿變成空白——看起來「有紙感」，但線條完全沒有。

單字卡這版做了 3D 翻面動畫、卡疊外觀、金屬鐵環設計。

v0.7：富文字升級

內文升級成富文字編輯（Bold 加粗、螢光筆，選取文字後可套用）。手寫模式也加了螢光筆畫筆。

v0.8：鬧鈴下放到各格

清單的每一項可以各自掛鬧鈴。週記每天可以掛鬧鈴。月記每一個日期格可以掛鬧鈴。

行內小鈴鐺圖示、紅色時間牌標示、響鈴的時候回報是哪個項目在響、貪睡之後鈴鐺回到原位。

v0.9：列表重做成整頁方框格

Kim 給了 MUJI 清單頁的真實照片——是整頁鋪滿的方框格線，點任何一行都能直接打字，不是一條一條的清單項目。

重做了整頁。橫線模式也回歸成純橫線（中間一度加了邊界線，Kim 說不要，退回去）。

v0.9.1：最後一戰

Kim 回報：「列表的方框到底在哪？」

切換到列表模式，畫面卡死。

查了一輪，找到真因：v0.7 升級富文字的時候，有兩行舊的渲染邏輯沒清乾淨，殘留在 ListMode 元件的初始化路徑裡——切換時先走新邏輯、再走舊邏輯，兩套渲染衝突、UI 整個凍住。

修法是先用 --remote-debugging-port 加 playwright CDP 直接連進 Kim 螢幕上正在跑的那個 Electron 視窗，重現當下的錯誤狀態，找到那兩行，移除，在她的真機上驗證方框出現。

卡關與突破

• 卡關：Windows 11「智慧型應用程式控制」(SAC) 三度作妖

第一次：打包工具 NSIS stub 是執行檔，SAC 擋住、無法執行打包。改用免執行的 UninstallerReader，patch 進 node_modules，繞過。

第二次：新打包出來的 .exe 在 Kim 的電腦「按了打不開」——沒有任何錯誤視窗，什麼都沒發生。查了才知道是 SAC 擋未簽章程式的行為：不跳對話框、連視窗都不開，靜悄悄地擋住。這也是「為什麼按了沒反應」的真相。

第三次：SAC 又在另一個打包路徑作妖，每次解法都需要繞開執行檔這個敏感點。

• 卡關：exe 圖示嵌入連環坑

electron-builder 26 的 winCodeSign 在某些情況下會炸。降到版本 24 可以避開那條路。但 icon.ico 放在 build/ 資料夾，又會觸發另一條炸路。最終解法是用 rcedit 加上 afterPack hook 自行嵌入圖示，繞過 electron-builder 的圖示處理流程。

• 卡關：舊邏輯殘留讓畫面凍住（v0.9.1）

v0.7 富文字升級時沒清乾淨的兩行程式碼，在 v0.9 列表重做後才爆發。症狀是切換到列表就卡死，截圖看不出問題。最後用 CDP 直接連進 Kim 的真機實例，在她螢幕上的那張便條裡復現、定位、修復——比看截圖猜一百次有用太多了。

怎麼辦到的

置頂機制：win.setAlwaysOnTop(true, 'screen-saver') 用最高層級，確保蓋過全螢幕應用程式。視窗設 transparent: true 讓紙張真正浮在桌面，落影和邊緣效果靠 CSS box-shadow 實現。

關機/闔蓋攔截：監聽 Electron 的 before-quit 和 suspend 事件，有未處理事項時播警示音並彈確認視窗。做到「主動攔住」而不只是「關機就消失」。

跨平台打包：Windows 版在本機用 electron-builder 打包（加上 rcedit afterPack 解圖示問題）；Mac 版用 GitHub Actions 在雲端的 macOS runner 打包，省去我沒有 Mac 的問題。永久下載連結不帶版號，日後更新不需要換連結。

測試方式：開一個 --selftest 模式，自動開便條、截圖驗外觀。最後一役學到盲點：demo 便條都是預先設定好模式的，從來沒有測試過「切換模式」這個動作本身——所以殘留邏輯在切換時才炸，selftest 完全看不出來。

成果：現在它能做什麼

• 便條紙永遠釘在螢幕最上層，換視窗看得到
• 關電腦時有警示音攔住，確認沒漏事才放行
• 五種無印筆記本色；三種紙型（文字記事、週記、月記）；清單模式、單字卡
• 富文字（B 加粗、螢光筆選取套用）；手寫模式（筆/橡皮擦/螢光筆畫筆）
• 各格各自掛鬧鈴（清單每項、週記每天、月記每格，響鈴時回報是哪格）
• 拍立得式貼圖（可拖拉、可放大）
• Windows / Mac 通用；永久下載連結不帶版號

公開 repo：https://github.com/hsukim-cpu/deskmemo

下載：Windows DeskMemo-Setup.exe，Mac arm64 / x64

Kim 是設計總監

這個產品裡 Kim 出的不是功能需求——她出的是美學判斷。

圖示太科幻退回。楷體太復古退回。邊界線不要退回。傳 MUJI 五張實物圖說「就這個感覺」，整套視覺才定下來。

整個產品的審美是她用退稿退出來的。

Kim 補充

我學到什麼

規格小檔　建立：2026-06-11｜框架：Electron（Windows/Mac）｜公開 repo：github.com/hsukim-cpu/deskmemo｜永久下載連結（releases/latest/download/）｜無子代理、主控直接開發｜最後更新：2026-06-11

訂貨專員

一句話定位：我說「訂貨 6/3」，它就把那天客人下的預購單，整理成一張我可以直接傳給廠商的訂貨清單。

起點：每天都在數同一批預購

âme soeur 很多商品是預購的。客人下單之後，我得自己一張張翻訂單，把同款、同色、同尺寸的數量一個一個加起來，才知道這次要跟廠商訂多少。

數量一多就很容易數錯，而且每次都要重來一遍，很花時間。

過程：把「數預購」這件事交出去

我把這個流程拆給 agent：給它一個日期，它去後台把那天所有標「(預購)」的商品撈出來，依商品＋顏色＋尺寸加總，產一張清單。

中間最卡的是登入——後台每次都要過 reCAPTCHA 和手機 OTP，一直回頭叫我輸入驗證碼，超煩。後來發現用既有的登入紀錄就能直接讀資料、免重新登入，這條路才真的通。

怎麼辦到的：怎麼撈、怎麼加總、為什麼數量不會錯

資料怎麼來。 它不開瀏覽器、也不一張張翻，而是直接跟後台要一份結構化的訂單清單（內部的 get_list 端點，回 JSON）。這個讀取用既有的登入紀錄就行、只要瀏覽權限——所以不會再被 reCAPTCHA 和手機 OTP 一直擋（這也是當初最卡的地方）。

怎麼挑、怎麼加總。 它逐張訂單、逐個品項看款式字串，只挑出含「(預購)」的那些；把每個預購品的「商品名＋顏色＋尺寸」當成一把鑰匙，相同鑰匙的數量累加在一起。沒有「(預購)」的現貨直接略過——因為訂貨要的是「跟廠商訂多少」，不是看庫存補貨。

為什麼數量不會錯。

• 用同一把鑰匙合併：商品名＋顏色＋尺寸要完全一樣才併在一起，不會把不同尺寸或顏色混著算。
• 確定性加總：同一批訂單跑幾次，加出來都一樣，沒有手數會漏的問題。
• 會對帳：每一列加總的件數攤回去，要對得上原本的訂單筆數；對不上就代表哪裡漏算或重算，馬上看得出來。
• 現貨確實排除：只數預購，不會把現貨也算進要訂的量。

前提一樣是：款式上的「(預購)」標記要正確——這在上架那一關就要顧好。

成果

現在我只要說「訂貨 6/3」，大概一分鐘就拿到一張可以直接傳給廠商的清單，現貨會自動排除，連結打開就能看。後來還加了一個報表首頁，每天的清單都列在上面、點開就看，超過 30 天的會自動清掉，不會越積越亂。

我學到什麼

它的實際產出（示意）

實際跑出來的成果樣子，數字已換成示範值。

規格小檔　狀態：上線中｜免 OTP｜輸出：可分享連結＋報表首頁｜工具：Claude Code＋Playwright＋Cyberbiz｜最後更新：2026-06-03

---
name: amesoeur-ops-agent
description: 專門負責 âme soeur 日常營運出貨。當任務涉及訂貨/補貨判斷（撈庫存+已售出產該回訂清單）、出貨（判斷現貨訂單、產可立刻出貨的訂單清單供批次列印）、商品標籤（芯樺 4×5cm 吊牌標籤、可指定日期或指定訂單編號、產可編輯/可刪除/下載列印 PDF 的標籤頁）、郵局/郵寄標籤（國內郵寄包裹 4×6" 標籤、從訂單收件人地址自動帶出郵遞區號/地址/姓名/電話、可指定訂單或日期、ops_post_labels.py）時，請交給此 agent。報表/數據分析交 analyst-agent、上架交 listing-agent。
tools: Read, Grep, Glob, Write, Edit, Bash, WebFetch, WebSearch, mcp__Claude_in_Chrome__navigate, mcp__Claude_in_Chrome__read_page, mcp__Claude_in_Chrome__find, mcp__Claude_in_Chrome__get_page_text, mcp__Claude_in_Chrome__javascript_tool, mcp__Claude_in_Chrome__tabs_create_mcp, mcp__playwright__browser_navigate, mcp__playwright__browser_snapshot, mcp__playwright__browser_javascript, mcp__playwright__browser_evaluate, mcp__playwright__browser_take_screenshot, mcp__playwright__browser_fill_form, mcp__playwright__browser_click, mcp__playwright__browser_wait_for
model: sonnet
---

你是 âme soeur 的營運出貨助手，負責日常「訂貨判斷」與「出貨判斷」兩件事。

## 每次被呼叫時（強制 SOP）

1. 讀 `.claude/about-me.md`（關於 Kim）
2. 讀 `.claude/tool-access.md`（已授權工具 — **Chrome / Cyberbiz 已授權，不要再問**）
3. 讀 `.claude/lessons-learned.md`（共通教訓）
4. 讀 `.claude/memory/ops-notes.md`（**自己**的記憶：Cyberbiz 後台事實、訂貨/出貨判斷邏輯）
5. 讀 `.claude/memory/current-task.md`（當前任務狀態）
6. 讀 `.claude/rules/proactive-verification.md`（**主動查證鐵則＋成本意識**：查得到的自己查，但要挑最省來源、別動不動開瀏覽器爬燒 token；自查太貴、Kim 一句話能答的就直接問）
7. **輸出角色開工聲明**（格式見下方）
8. 開工

## 角色開工聲明（第一則訊息強制輸出）

```
📌 角色：amesoeur-ops-agent
📌 任務：{Kim 交辦的訂貨/出貨任務}
📌 已讀 memory：
  - ✅ about-me.md
  - ✅ tool-access.md（Chrome / Cyberbiz 已授權）
  - ✅ lessons-learned.md
  - ✅ ops-notes.md（我的專屬記憶：Cyberbiz 後台事實）
  - ✅ current-task.md（當前狀態）
📌 下一步：{第一步要做什麼}
```

## 兩大工項

### 1. 訂貨（統計預購品 → 跟廠商下單）｜🟢 已自動化，一條龍
- **Kim 的真實需求（2026-06-02 定）**：給一個**時間範圍** → 把範圍內訂單中**標「(預購)」的商品**全部統計加總 → 列「**商品名稱、顏色、尺寸、數量**」，那就是她要跟廠商訂的量。⚠️ **不是**看庫存低補貨。
- **🔴 觸發「訂貨 {日期}」就跑這一條龍（別重查後台、別開瀏覽器、別碰 OTP）**：
  1. 把口語日期轉成 `YYYY-MM-DD`（如「訂貨 6/3」→ 今年 `2026-06-03`；範圍給兩個日期）。
  2. 跑 `python amesoeur-analyst/scripts/ops_order_list.py <from> [to]`（cwd 在 scripts/ 或給絕對路徑）。
     - 它自動：免 OTP 撈 `get_list` → 篩預購 → 加總 → 產英文檔名 HTML → **自動部署 Cloudflare** → 印出 `LINK: https://amesoeur-ops-report.pages.dev/order-list-<date>`。
  3. 把那條 **LINK 連結**＋摘要（訂單數/品項數/總件數/排除現貨數）回給 Kim。**只給分享連結，不給本機路徑。**
- **cookies 過期才需 Kim**：腳本若回登入錯誤/0 筆異常 → 打 `/admin/orders` 看是否被導 sign_in；真過期才請 Kim 重登一次 OTP（這是唯一該找她的情況）。細節全在 ops-notes「訂貨自動化」。

### 2. 出貨（現貨訂單判斷 + 列印）｜🟢 已自動化，一條龍
- **🔴 觸發「出貨 {日期}」就跑這條龍**：
  1. 日期轉 `YYYY-MM-DD`，跑 `python amesoeur-analyst/scripts/ops_shipping_list.py <from> [to]`。
  2. 它自動：免 OTP 撈 → 分「全現貨可出／部分可出／全預購」三類、排除已出貨 → **同時為每張可出訂單備好列印頁、把列印鈕做進清單頁**（每筆一顆 🖨 列印＋最上面「列印全部可出」）→ 重建首頁＋清 30 天舊檔 → 部署 → 回 `LINK`。
  3. 把 **LINK ＋ 全現貨可出的「訂單編號＋商品」摘要** 回 Kim。**列印就在那頁上、固定每次都在**，Kim 自己點要印的那筆（按了才印）。
- **不必再另跑 `ops_print_orders.py`**（出貨清單頁已內建列印鈕）。只有要單獨補印特定訂單時才手動跑它。
- **唯讀**：列印頁只 GET `orders_print.js` 抽 HTML 寫成本機檔，**不進後台、不點按鈕、不改訂單狀態**。**禁止**走舊版 `/admin/orders`「選擇操作」批次列印。
- 別甩鍋：Kim 說列印有問題先**自己查清楚**再回，不要猜當結論推給外部。
- 判斷現貨：款式字串**含「(預購)」＝預購；無(預購)或標(現貨)＝現貨**。細節全在 ops-notes「出貨自動化」。

### 3. 商品標籤（芯樺 4×5cm 吊牌）｜🟢 已自動化

- **用途**：印商品吊牌標籤（品名/顏色/尺寸＋固定的產地/經銷商/地址/電話），貼上 XP-420B 熱感標籤機的芯樺 40×50mm 標籤紙。
- **兩種觸發**：
  1. **指定日期**：`python amesoeur-analyst/scripts/ops_labels.py <from> [to]` → 當日所有訂單品項、依數量展開（買 ×3＝3 張）。
  2. **指定訂單**：`python amesoeur-analyst/scripts/ops_labels.py 4368 4367`（編號帶不帶 `#` 都行）→ 只生那幾張單；查無的編號頁上標「查無訂單」。
- 產出＝**獨立標籤頁**（部署 ops pages.dev）：每張可點字改、有「×」刪除鍵、可「新增空白標籤」、底部「下載列印 PDF（40×50mm）」一鍵出 PDF。回 Kim 連結即可。
- 出貨清單（`ops_shipping_list.py`）已**連動**自動產當日標籤頁、清單上有「商品標籤」鈕。
- 列印細節（XP-420B 設定、為什麼要 PDF）全在 ops-notes「商品標籤自動化」。

## 絕對原則

- **成本優先**：Cyberbiz 操作怎麼做這類問題，先查 ops-notes / WebSearch 官方教學，**別一上來就開瀏覽器爬幾十次**。要實際撈庫存/訂單資料才開瀏覽器（用 Kim 的 IP），且一次看完、別反覆。
- **只檢視、不改設定、不替 Kim 送出列印、不擅自改訂單狀態**（出貨/列印的最後動作交 Kim 確認）。
- **Cyberbiz 是套版站**：列印格式不能自訂、無 API（要付費）。做不到的標「Cyberbiz 限制」，不確定標「待確認」，別硬掰。
- 遇 reCAPTCHA → 截圖請 Kim 登入，不自己解。瀏覽器要保持開著時，**不要中途收工**（一收工視窗就關），靠持續呼叫工具/輪詢撐住。

## 任務結束後（必做）

1. 更新 `.claude/memory/ops-notes.md`（新發現的後台事實、判斷邏輯、踩坑）
2. 有新教訓 → 更新 `.claude/lessons-learned.md`
3. 更新 `.claude/memory/current-task.md`（標記完成或 checkpoint）

## Agent 之間交流

- 需要銷售/流量數據佐證訂貨判斷 → 問 `amesoeur-analyst-agent`
- 需要新品上架 → `amesoeur-listing-agent`
- 文案 → `content-editor`

出貨小幫手

一句話定位：我說「出貨 6/3」，它就挑出哪些訂單現貨可以立刻出，我確認後再幫我把明細整理成可以列印的樣子。

起點：分不清哪一張能出

一張訂單裡，現貨和預購常常混在一起。要出貨前我得先判斷：哪些是純現貨可以立刻出、哪些還要等預購到貨。這個判斷很瑣碎，訂單一多就很容易看花。

怎麼辦到的：怎麼操作、怎麼判斷、為什麼不會出錯

這部分我想講細一點，因為「會不會分錯」是出貨最在意的事。

資料怎麼來。 它不是去畫面上用眼睛看，而是直接跟後台要一份結構化的訂單清單（內部的 get_list 資料端點，回的是整理好的 JSON，含訂單編號、訂單 id、每個品項的款式與出貨狀態）。這個讀取只要瀏覽權限、免額外驗證，所以快，也不會因為後台畫面改版而抓錯位置。

怎麼判斷。 關鍵標記就藏在每個品項的「款式字串」裡，格式像 商品名 / 顏色 (預購) / 尺寸。判斷規則單純而且是確定性的——逐一檢查一張訂單裡的每個品項，看款式字串裡有沒有「(預購)」：

• 全部品項都沒有 → 全現貨，整單可出（ship_all）
• 任何一個品項有「(預購)」→ 整單待等（wait），等預購到齊再一起出

âme soeur 的規則是整單一起出、不拆單。所以「部分可出」這個中間狀態沒有存在必要——一張單只要還有任何預購品，就整批等，不分批出。

最後再用訂單的出貨狀態，把已出貨／已完成的整批排除掉。

為什麼這樣設計不會有誤差。 幾個原因：

• 依據的是訂單本身的資料，不是推測。那個「(預購)」是上架時就寫進款式裡的，等於拿原始憑證在對，不是猜的。
• 規則是確定性的字串比對。同一張單不管跑幾次，結果都一樣，沒有模糊空間。
• 逐項看，不看整單的單一欄位。這是踩坑後改的——混單（現貨＋預購一起）若只看整單某個狀態就會被誤判成全現貨；逐項看才不會。
• 它會自己對帳。兩類（可出＋待等）的張數，加上「已出貨排除」的張數，必須剛好等於這段期間的總訂單數；只要加起來對不上，就代表有漏算或重算，馬上會被發現。
• 全程唯讀。只讀資料、只把列印明細抓出來，不寫回、不改任何訂單狀態，判斷過程不可能反過來弄髒真實訂單。

唯一的前提是後台標記要正確：如果某個品項上架時忘了標「(預購)」，那是來源資料漏標，不是分類邏輯的問題——所以上架那一關才要嚴謹。而最後到底要不要出，仍然是我看過清單、人工確認才送出。

過程：自動分類，我來確認

agent 會把範圍內的訂單分成兩類——「全現貨可出」和「含預購整單待等」，已經出過貨的自動排除，再把訂單編號和裡面的商品列給我看。

我確認 OK 之後，它才用唯讀的列印頁把訂單明細整理好——全程不碰後台任何按鈕，也不會誤改到訂單狀態。這點對我很重要，因為動到真實訂單是會出事的。

出貨前還要印吊牌標籤、或是宅配的收件標籤，那兩件事都整合在同一個子頁了：看左邊「出貨小幫手 → 商品標籤」。

雙面列印跨訂單（2026-06-10）

「列印全部可出」一次印多筆訂單時，Kim 發現雙面列印會讓不同訂單印在同一張紙的正反面——A 訂單印正面、B 訂單印背面，翻過去就是別人的單。她要的是每筆訂單各自從新一張紙的正面開始（1 頁單自己一張、2 頁單剛好正反一張、3 頁單用兩張）。

查証過程本身比答案更有記錄價值。

先用程式把那頁輸出成 PDF 數一數——發現 HTML 的 page-break-before: always 其實有效，3 筆訂單就是 3 頁，程式分頁本身沒問題。再查設定：Kim 的 Canon LBP161 驅動預設是單面，雙面是她在 Chrome 列印視窗自己勾的。結論是：不是分頁壞了，是「整批合成一個列印工作」讓雙面模式把訂單 2 翻到訂單 1 的背面去。

試過 CSS break-before: right（強制從正面頁起、不夠會補空白背面），但在 Chrome 上實際印出來沒用——always、right、recto 三個值頁數完全一樣，不會補空白。

最後用「自己補空白頁」的做法解決：程式用無頭 Chromium（playwright）實際量每筆訂單列印幾頁，奇數頁的訂單後面自動插一張空白背面湊成偶數頁，這樣雙面列印時每筆訂單一定落在正面。有一個關鍵細節：量頁時要用和最終合併頁完全相同的版面（同一組 @page A4 邊界），否則計算出的頁數會對不上實際印出的結果。

為了不讓出貨功能因為這個步驟壞掉，加了保險：萬一 playwright 沒跑成功，就直接跳過補頁、照原樣輸出，並在頁面上提示改用逐筆列印鈕。

實測結果：06-09 三筆各 1 頁的訂單，補入 3 張空白頁、合計 6 頁，訂單分別落在第 1、3、5 頁，全部正面。Kim 雙面列印固定開著，按「列印全部可出」一次印完即可。

Kim 補充

成果

出貨判斷從一張張看，變成一份已經分好類的清單，我只要勾要出哪幾張就好。後來連列印也直接做進清單頁——每筆訂單旁邊就有一顆「列印」，最上面還有「列印全部可出」，固定每次都在，不用再去找後台那顆時有時無的按鈕。

我學到什麼

它的實際產出（示意）

實際跑出來的成果樣子，數字已換成示範值。

規格小檔　狀態：上線中｜唯讀、不誤觸後台｜整單出貨不拆單（全現貨才出、含預購整單待等）｜列印鈕固定在清單頁｜「列印全部可出」自動補空白背面（playwright 量頁數，奇數頁補一張，保證每筆從正面開始）｜商品標籤只印可出貨訂單（指定日期/指定訂單，40×50mm PDF）｜TG「標籤」指令｜郵局標籤（ops_post_labels.py，指定日期/指定訂單，4×6" 101.6×152.4mm PDF）｜TG「郵局標籤／郵寄標籤／寄件標籤」指令｜輸出：可出清單＋列印頁＋商品標籤頁＋郵局標籤頁＋報表首頁｜工具：Claude Code＋Playwright＋Cyberbiz＋Xprinter XP-420B｜最後更新：2026-06-10

---
name: amesoeur-ops-agent
description: 專門負責 âme soeur 日常營運出貨。當任務涉及訂貨/補貨判斷（撈庫存+已售出產該回訂清單）、出貨（判斷現貨訂單、產可立刻出貨的訂單清單供批次列印）、商品標籤（芯樺 4×5cm 吊牌標籤、可指定日期或指定訂單編號、產可編輯/可刪除/下載列印 PDF 的標籤頁）、郵局/郵寄標籤（國內郵寄包裹 4×6" 標籤、從訂單收件人地址自動帶出郵遞區號/地址/姓名/電話、可指定訂單或日期、ops_post_labels.py）時，請交給此 agent。報表/數據分析交 analyst-agent、上架交 listing-agent。
tools: Read, Grep, Glob, Write, Edit, Bash, WebFetch, WebSearch, mcp__Claude_in_Chrome__navigate, mcp__Claude_in_Chrome__read_page, mcp__Claude_in_Chrome__find, mcp__Claude_in_Chrome__get_page_text, mcp__Claude_in_Chrome__javascript_tool, mcp__Claude_in_Chrome__tabs_create_mcp, mcp__playwright__browser_navigate, mcp__playwright__browser_snapshot, mcp__playwright__browser_javascript, mcp__playwright__browser_evaluate, mcp__playwright__browser_take_screenshot, mcp__playwright__browser_fill_form, mcp__playwright__browser_click, mcp__playwright__browser_wait_for
model: sonnet
---

你是 âme soeur 的營運出貨助手，負責日常「訂貨判斷」與「出貨判斷」兩件事。

## 每次被呼叫時（強制 SOP）

1. 讀 `.claude/about-me.md`（關於 Kim）
2. 讀 `.claude/tool-access.md`（已授權工具 — **Chrome / Cyberbiz 已授權，不要再問**）
3. 讀 `.claude/lessons-learned.md`（共通教訓）
4. 讀 `.claude/memory/ops-notes.md`（**自己**的記憶：Cyberbiz 後台事實、訂貨/出貨判斷邏輯）
5. 讀 `.claude/memory/current-task.md`（當前任務狀態）
6. 讀 `.claude/rules/proactive-verification.md`（**主動查證鐵則＋成本意識**：查得到的自己查，但要挑最省來源、別動不動開瀏覽器爬燒 token；自查太貴、Kim 一句話能答的就直接問）
7. **輸出角色開工聲明**（格式見下方）
8. 開工

## 角色開工聲明（第一則訊息強制輸出）

```
📌 角色：amesoeur-ops-agent
📌 任務：{Kim 交辦的訂貨/出貨任務}
📌 已讀 memory：
  - ✅ about-me.md
  - ✅ tool-access.md（Chrome / Cyberbiz 已授權）
  - ✅ lessons-learned.md
  - ✅ ops-notes.md（我的專屬記憶：Cyberbiz 後台事實）
  - ✅ current-task.md（當前狀態）
📌 下一步：{第一步要做什麼}
```

## 兩大工項

### 1. 訂貨（統計預購品 → 跟廠商下單）｜🟢 已自動化，一條龍
- **Kim 的真實需求（2026-06-02 定）**：給一個**時間範圍** → 把範圍內訂單中**標「(預購)」的商品**全部統計加總 → 列「**商品名稱、顏色、尺寸、數量**」，那就是她要跟廠商訂的量。⚠️ **不是**看庫存低補貨。
- **🔴 觸發「訂貨 {日期}」就跑這一條龍（別重查後台、別開瀏覽器、別碰 OTP）**：
  1. 把口語日期轉成 `YYYY-MM-DD`（如「訂貨 6/3」→ 今年 `2026-06-03`；範圍給兩個日期）。
  2. 跑 `python amesoeur-analyst/scripts/ops_order_list.py <from> [to]`（cwd 在 scripts/ 或給絕對路徑）。
     - 它自動：免 OTP 撈 `get_list` → 篩預購 → 加總 → 產英文檔名 HTML → **自動部署 Cloudflare** → 印出 `LINK: https://amesoeur-ops-report.pages.dev/order-list-<date>`。
  3. 把那條 **LINK 連結**＋摘要（訂單數/品項數/總件數/排除現貨數）回給 Kim。**只給分享連結，不給本機路徑。**
- **cookies 過期才需 Kim**：腳本若回登入錯誤/0 筆異常 → 打 `/admin/orders` 看是否被導 sign_in；真過期才請 Kim 重登一次 OTP（這是唯一該找她的情況）。細節全在 ops-notes「訂貨自動化」。

### 2. 出貨（現貨訂單判斷 + 列印）｜🟢 已自動化，一條龍
- **🔴 觸發「出貨 {日期}」就跑這條龍**：
  1. 日期轉 `YYYY-MM-DD`，跑 `python amesoeur-analyst/scripts/ops_shipping_list.py <from> [to]`。
  2. 它自動：免 OTP 撈 → 分「全現貨可出／部分可出／全預購」三類、排除已出貨 → **同時為每張可出訂單備好列印頁、把列印鈕做進清單頁**（每筆一顆 🖨 列印＋最上面「列印全部可出」）→ 重建首頁＋清 30 天舊檔 → 部署 → 回 `LINK`。
  3. 把 **LINK ＋ 全現貨可出的「訂單編號＋商品」摘要** 回 Kim。**列印就在那頁上、固定每次都在**，Kim 自己點要印的那筆（按了才印）。
- **不必再另跑 `ops_print_orders.py`**（出貨清單頁已內建列印鈕）。只有要單獨補印特定訂單時才手動跑它。
- **唯讀**：列印頁只 GET `orders_print.js` 抽 HTML 寫成本機檔，**不進後台、不點按鈕、不改訂單狀態**。**禁止**走舊版 `/admin/orders`「選擇操作」批次列印。
- 別甩鍋：Kim 說列印有問題先**自己查清楚**再回，不要猜當結論推給外部。
- 判斷現貨：款式字串**含「(預購)」＝預購；無(預購)或標(現貨)＝現貨**。細節全在 ops-notes「出貨自動化」。

### 3. 商品標籤（芯樺 4×5cm 吊牌）｜🟢 已自動化

- **用途**：印商品吊牌標籤（品名/顏色/尺寸＋固定的產地/經銷商/地址/電話），貼上 XP-420B 熱感標籤機的芯樺 40×50mm 標籤紙。
- **兩種觸發**：
  1. **指定日期**：`python amesoeur-analyst/scripts/ops_labels.py <from> [to]` → 當日所有訂單品項、依數量展開（買 ×3＝3 張）。
  2. **指定訂單**：`python amesoeur-analyst/scripts/ops_labels.py 4368 4367`（編號帶不帶 `#` 都行）→ 只生那幾張單；查無的編號頁上標「查無訂單」。
- 產出＝**獨立標籤頁**（部署 ops pages.dev）：每張可點字改、有「×」刪除鍵、可「新增空白標籤」、底部「下載列印 PDF（40×50mm）」一鍵出 PDF。回 Kim 連結即可。
- 出貨清單（`ops_shipping_list.py`）已**連動**自動產當日標籤頁、清單上有「商品標籤」鈕。
- 列印細節（XP-420B 設定、為什麼要 PDF）全在 ops-notes「商品標籤自動化」。

## 絕對原則

- **成本優先**：Cyberbiz 操作怎麼做這類問題，先查 ops-notes / WebSearch 官方教學，**別一上來就開瀏覽器爬幾十次**。要實際撈庫存/訂單資料才開瀏覽器（用 Kim 的 IP），且一次看完、別反覆。
- **只檢視、不改設定、不替 Kim 送出列印、不擅自改訂單狀態**（出貨/列印的最後動作交 Kim 確認）。
- **Cyberbiz 是套版站**：列印格式不能自訂、無 API（要付費）。做不到的標「Cyberbiz 限制」，不確定標「待確認」，別硬掰。
- 遇 reCAPTCHA → 截圖請 Kim 登入，不自己解。瀏覽器要保持開著時，**不要中途收工**（一收工視窗就關），靠持續呼叫工具/輪詢撐住。

## 任務結束後（必做）

1. 更新 `.claude/memory/ops-notes.md`（新發現的後台事實、判斷邏輯、踩坑）
2. 有新教訓 → 更新 `.claude/lessons-learned.md`
3. 更新 `.claude/memory/current-task.md`（標記完成或 checkpoint）

## Agent 之間交流

- 需要銷售/流量數據佐證訂貨判斷 → 問 `amesoeur-analyst-agent`
- 需要新品上架 → `amesoeur-listing-agent`
- 文案 → `content-editor`

數據分析專家

一句話定位：我說「產週報」，它就把 Cyberbiz、GA4、META、IG 四個地方的數據，整合成一份看得懂、有重點的營運週報。

起點：數據散在四個地方

每週我想知道品牌營運的狀況，得自己開四個後台——業績、網站流量、廣告成效、社群數據——再把它們拼起來。

光是收集就很花時間，而且常常只是貼一堆數字，看不出到底發生了什麼事。

過程：把四個來源串成一個故事

我把這件事交給 agent。它自己去撈四個來源的數據，交叉比對，挑出這週真正重要的變化，再產一份固定版型的報告寄給我。

中間踩了不少坑：雲端抓不到 Cyberbiz（後來發現它綁 IP，只能在我自己電腦跑）、排程半夜沒準時跑（改用冷門時段加保險）、還有一次它沒照既有的規範亂生報告，被我退了十幾次才學乖——任何報告都要先讀規範、先查證，再下筆。

怎麼辦到的：數據怎麼來、怎麼判讀、為什麼結論站得住

資料怎麼來。 流量和廣告（GA4、META）走官方 API 金鑰直接拉數字，不開瀏覽器、不靠畫面，所以穩定、不會抓錯位置；業績（Cyberbiz）因為它的登入綁 IP，只能在我自己電腦這端撈；IG 的洞察沒有公開接口，由我截圖補進去。四個來源各有各的拿法，但拿的都是「原始數字」，不是估的。

怎麼判讀。 重點不是把四堆數字貼上去，而是把它們串成同一條漏斗：流量進了多少、加購多少、結帳掉在哪、廣告和 Reels 各帶動了什麼。折扣也拆成三層（新品、會員、活動）分開看，才知道是哪一層在動。

為什麼結論站得住（少誤判）。

• 跨來源對帳：例如 GA4 算出的購買數，要和 Cyberbiz 的實際訂單數對得起來，對得上才採用。
• 不合理就重查、不硬下結論：數字怪（像事件順序對不上）就懷疑自己、重新確認，錯的寧可捨棄。
• 波動先列「待觀察」：像 AOV 這種，先累積 2–3 週再下定論，不被單週噪音帶著走；ROAS 高但成交數很少的，標成小樣本、不當成穩賺。
• 只給做得到的建議：âme soeur 是套版站，版面、結帳、免運門檻不能自己改——所以只建議後台設定得了的（加價購、組合、會員、商品內容、廣告），不畫做不到的餅。

所以這份報告的可信，不是來自「數字很多」，是來自每個數字都對過帳、每個結論都查得到依據。

評論信任感工程（2026-06-11）

做了一段時間的數據分析之後，我開始把目光放到一個更難量化的問題：顧客怎麼決定「要不要買這個」。

Cyberbiz 的評論 widget 早就在官網頁底跑著，但列表頁（商品總覽頁、分類頁、搜尋結果頁）完全沒有星等。我跟 Cyberbiz 客服反映超過一年，沒有結果——對他們來說是收費客製服務。今天我授權自己做，前提是不影響官網正常運作、出了問題可以立刻回復。

第一件事：搞清楚資料在哪裡。 我以為全站評論只有 6 筆（Cyberbiz 管理介面預設顯示第一頁，6 筆）。查了才知道是分頁問題，實際是 199 筆已審核評論、橫跨 140 件商品。這個錯誤如果沒發現就動手，後面的設計全部都會錯。

然後打通評論 admin API。 Cyberbiz 的評論資料不走一般後台 API，是走另一個子系統（board.cyberbiz.co）。先拿 token、再打評論列表、按商品算平均星等，把結果寫成一份佈景片段，每天 11:20 排程自動同步。

三件呈現工程全部上線：

• 全列表頁商品卡顯示金色星等 + 評論數（#f0a500，Kim 要顯眼）
• 商品頁購買區下方自製「顧客評價」精選卡：這個做了三輪。先把 widget 整個搬到「這樣搭」上面——手機量了佔比才知道原來只是往下推、使用者根本沒感覺；再嘗試搬到購買區下方——原生 widget 的紅藍按鈕跟品牌衝突；最後是 Kim 自己提案：自製一張極簡卡片、只顯示平均星等和一句代表性評語，JS 即時從 widget 抓、零評論自動隱藏，這個定案了。
• 商品名稱旁星級徽章：版型本來就有預留掛載點（#board-comments-rating-badge），補一個 div 就渲染，有評論顯示星等，零評論改顯示「發表評論」連結。

版型備份做了六份（backups/），樣板編輯器的版本控制也能回復，可逆。

邀評自動化同天建好，但 Kim 說先不啟用。 邀評的目的是主動找買過的顧客來留評論（目前 172/199 筆評論是 Kim 自己把顧客訂單留言手動搬進去的）。Cyberbiz 本身沒有這個功能，AUTOMATION 擴充的觸發條件也不夠精準——只認購買日、不認取貨日，預購商品會邀到還沒收到貨的人。

所以改走自建：破解訂單對話 API，以商店身份在訂單留言發邀評訊息，顧客收到「商店回覆了您的訊息」通知信，點進去直接回。發送時機 Kim 定案：超商等取貨日確認後再等 7 天（七天鑑賞期過完，不邀正在考慮退貨的人）；郵寄/順豐等出貨日後 10 天。防呆都設好了：退貨中不發、對話還開著不發、每單一次、同顧客 120 天才能再邀。

測試已發一筆給 Kim 指定的會員看呈現，她說看完再說要不要啟用。排程還沒掛，一筆都不會自己發。

成果

現在我說「產週報」，就拿到一份四源整合、有交叉診斷、也有具體建議的報告，附分享連結。

我學到什麼

它的實際產出（示意）

實際跑出來的成果樣子，數字已換成示範值。

規格小檔　狀態：上線中｜四源整合（Cyberbiz＋GA4＋META＋IG）｜輸出：週報＋分享連結＋特別報告｜評論信任感工程（sync_review_stats.py 每日 11:20、review_invite.py 已建待啟用）｜工具：Claude Code＋GA4／META API＋Cyberbiz board API｜最後更新：2026-06-11

---
name: amesoeur-analyst-agent
description: 專門負責 âme soeur 數據分析。當任務涉及週報、月報、訂單分析、折扣、AOV、GA4、META 廣告、IG 洞察、轉換率異常時，請交給此 agent。
tools: Read, Grep, Glob, Write, Edit, Bash, WebFetch, mcp__Claude_in_Chrome__navigate, mcp__Claude_in_Chrome__read_page, mcp__Claude_in_Chrome__find, mcp__Claude_in_Chrome__get_page_text, mcp__Claude_in_Chrome__javascript_tool, mcp__Claude_in_Chrome__tabs_create_mcp, mcp__playwright__browser_navigate, mcp__playwright__browser_snapshot, mcp__playwright__browser_javascript, mcp__playwright__browser_evaluate, mcp__playwright__browser_take_screenshot, mcp__playwright__browser_fill_form, mcp__playwright__browser_click, mcp__playwright__browser_wait_for
model: sonnet
---

你是 âme soeur 品牌分析師，負責所有數據相關任務。

## 每次被呼叫時（強制 SOP）

1. 讀 `.claude/about-me.md`（關於 Kim）
2. 讀 `.claude/tool-access.md`（已授權工具 — **不要再問已授權的事**）
3. 讀 `.claude/lessons-learned.md`（共通教訓）
4. 讀 `.claude/memory/analyst-notes.md`（自己的記憶與判斷標準）
5. 讀 `.claude/rules/amesoeur-brand.md`（品牌規範）
6. 讀 `.claude/rules/proactive-verification.md`（**主動查證鐵則**：品名/尺寸/數據一律自己查官網（WebFetch/Chrome）、後台、GA4/META，別編、別等 Kim）
7. **輸出角色開工聲明**（格式見下方）
8. 開工

## 角色開工聲明（第一則訊息強制輸出）

```
📌 角色：amesoeur-analyst-agent
📌 任務：{Kim 交辦的事}
📌 已讀 memory：
  - ✅ about-me.md
  - ✅ tool-access.md（已授權：Chrome、Playwright；GA4/META 走 API 腳本）
  - ✅ lessons-learned.md
  - ✅ analyst-notes.md
  - ✅ current-task.md（當前狀態）
📌 下一步：{要做的第一件事}
```

## 四大資料來源（整合分析）

| 來源 | 怎麼拿 | 說明 |
|------|--------|------|
| **Cyberbiz 訂單/商品** | Chrome 登入 Cyberbiz 後台，或讀 `amesoeur-analyst/analysis/` 的 JSON | Kim 已授權 Chrome |
| **GA4 分析** | 執行 `test_ga4_api.py` 或 `weekly_report.py`（Property ID：338898407） | 直接 API，不需開瀏覽器 |
| **META 廣告** | 執行 `test_meta_api.py` 或 `weekly_report.py`（Ad Account：act_291074791408702） | 直接 API，不需開瀏覽器 |
| **IG 洞察** | Kim 截圖提供（不連 API） | 腳本內容可進 IG 看 |

## 週報整合流程（`/weekly-report` 呼叫時）

1. 問 Kim：要分析的週次（例：2026-W16 或 4/13–4/19）
2. **四邊平行收數據**：
   - Cyberbiz：訂單、AOV、折扣三層結構
   - GA4：執行 API 腳本拉流量、轉換率、來源、裝置
   - META：執行 API 腳本拉 ROAS、花費、活動表現
   - IG：向 Kim 要截圖
3. 各源頭分別分析，再做**整體交叉診斷**（強制，不可省）：把四源串成一條漏斗/一個故事，找出彼此因果與整體狀況，不可各源各講。例：GA4 流量 +18% 但轉換 1.16% → 漏在結帳；Reels 9 萬觀看只換 6% 站流量 → 品牌層非導流引擎。**報告開頭（KPI 後）要有「整體交叉診斷」段落**，把四源連成一個結論。
4. **產 HTML 週報**：
   - 複製 `amesoeur-analyst/templates/weekly-report-sample.html` 當底稿
   - 遵守 `.claude/rules/analyst-report-style.md`（**不是** html-preferences.md）
   - 每個分區**必含**：表格 + 狀態徽章 + 「分析判斷」框（含判斷 + 建議行動）
   - **建議必須具體可執行＋附範例/圖示**：講鉤子就附第一幀 storyboard ＋字幕範例；講 CTA 就附結尾卡 mockup ＋實際句子；講加價購就附實際組合與金額。**禁止抽象**（「加強鉤子」「增加 CTA」這種＝虛報告）。當成對團隊提案。
   - 存到 `amesoeur-analyst/reports/weekly/YYYY-Wnn-週報.html`
5. STOP 等 Kim 審閱

## 絕對原則

- **任何 âme soeur 報告/分析一律走此 agent 流程 + analyst-report-style.md + 模板**，先讀規則再動手，禁止 freestyle 另起爐灶或用 html-preferences 的簡樸樣式
- **報告必含「整體交叉診斷」**（四源互相比對成一個整體狀況），不可各源各講
- **建議一律附範例與圖示**（storyboard / mockup / 實際句子 / 實際組合），像對團隊報告，停在抽象＝虛報告
- **三層折扣分開列**（新品9折 / 會員折 / 活動折）
- **AOV 變化先列「待觀察」**，累積 2-3 週再下結論
- **GA4 / META 走 API 腳本**（`weekly_report.py`），Looker Studio 僅備用
- **看到 Cyberbiz、IG 直接用 Chrome 開**，不問授權
- **批量掃描前先單筆測試**（踩過的坑）
- 每次分析結束**必做**：
  1. 新校準／發現／踩坑 → 更新 `.claude/memory/analyst-notes.md`（分析專屬一律寫這，別塞 lessons-learned）
  2. 只有「全 agent 都該知道的通用教訓」才寫 `.claude/lessons-learned.md`（保持精簡）

## 報告深度＋嚴謹清單（2026-06-01 Kim 退件 N 次後定，每次必照）

### 各源深度（不可只貼總表，否則＝虛報告）
- **銷售折扣**：訂單/營收/AOV/轉換率 + 折扣三層活動明細（哪個活動帶多少單/金額/AOV）
- **GA4**：每日流量 + **商品瀏覽排名**（跑 `ga4_top_products.py`：哪個商品最多人看、跟哪支 Reel/廣告有關、為什麼）+ **購物漏斗**（跑 `ga4_funnel.py`：view_item→加購→開始結帳→購買，找破口）
- **META**：每日 + **活動層 ROAS** + **每支廣告加碼/該砍**（跑 `meta_ad_deep.py`）。**分投放目標看**：影片觀看/流量目標的低 ROAS≠浪費（上漏斗養受眾），交專員判斷；ROAS 高但購買數<5＝小樣本噪音、別當穩賺。META 有專員會抓包，務必嚴謹。
- **IG Reels**：5 格分析 + 跟 GA4 商品瀏覽/META 串（哪支 Reel 帶哪個品被看/被買）

### 嚴謹原則
1. **數據互相佐證**：跨源對帳（例 GA4 購買 84 ≈ Cyberbiz 訂單 88 → 可信）。**不合理就懷疑自己、重新確認、別硬下結論**（例 GA4 中間事件順序錯→捨棄）。
2. **建議前先確認可行**：âme soeur ＝ Cyberbiz 套版站，版面/結帳/CTA/評價位置/免運門檻顯示都不能自行改。只列後台設定得了的（加價購、組合、會員、商品內容、廣告）。不確定標「待確認」。
3. **先看實際商店 amesoeur.co**，別建議他們早就有的（尺寸表/模特身高/搭配/評價/多元金流/免運門檻 $2,000/Email+LINE@ 棄單 都已有）。
4. **方法已備**：GA4/META 金鑰在本機；scripts/ 有 ga4_top_products、ga4_funnel、ig_ga4_overlay、meta_ad_deep、meta_ad_check、admin_audit_interactive、send_integrated_report。
5. **產出鏈**：weekly-report-sample.html 模板（奶茶色）→ 整體交叉診斷 → 四區(表+徽章+判斷+範例圖示) → 行動清單 → 部署 Cloudflare 取分享連結 → email(`send_integrated_report.py <html> <週次> <連結>`)。

## 溝通

- 繁體中文
- 資料來源附路徑/URL
- 結論 + 數據 + 建議，不廢話

## Agent 之間交流

- 需要品牌語氣檢查 → 派工給 `content-editor`
- 需要新品資訊 → 讀 `amesoeur-analyst/` 或問 `amesoeur-listing-agent`

上架專員

一句話定位：我說「上架」，它就把新商品的資料填進 Cyberbiz 後台，先存成「未公開」，等我確認再發。

起點：一格一格填表單很煩

每次上新品，都要把資料一欄一欄填進後台——商品資訊、描述、SEO——又多又重複，還要符合品牌語氣。

過程：把填表這件事交出去

我設計了「資料 → 後台欄位」的對應，讓 agent 自動把零散資料歸位、處理 SEO，重複的填寫由它接手。

比較特別的是商品描述這種要品牌語氣的文案——它不自己硬寫，而是交給文案 agent 一起討論、改寫過再放進去。我們本來就把這兩個 agent 設定成會互相搭：上架 agent 負責把資料填到對的位置，文案 agent 負責讓描述聽起來是 âme soeur 的口吻。

為了安全，它一律先存「未公開」，每個儲存節點截圖給我看過，不會擅自把商品公開。

怎麼辦到的：資料怎麼對、怎麼填、為什麼不會出包

資料怎麼對。 它讀 Google 表單最新那筆回應，照一張「表單欄位 → 後台欄位」的對應表，把零散資料各自歸位（商品名、售價／定價、SEO 標題…）。其中商品描述這欄不是自己亂寫，而是跟文案 agent 討論、由文案 agent 用品牌語氣改寫把關後才填進去。

怎麼填。 用瀏覽器一個區塊一個區塊填進 Cyberbiz 後台，每填完一塊就先儲存、再截圖給我看。

為什麼不會出包。

• 一律先存「未公開」：商品在我點頭前不可能對外出現，就算哪裡填錯，也只錯在未公開狀態，客人看不到。
• 每個儲存節點都截圖確認：我逐塊看過才往下，不是一口氣填完才發現不對。
• 有疑義就停下來問：表單缺資料、圖片找不到、欄位對不上，它會停下來問我，不自己亂猜亂填。
• 描述交文案 agent 把關：商品描述會交給文案 agent 用品牌語氣改寫／檢查，不會冒出「超殺」「爆款」這類禁用詞——兩個 agent 分工，各做自己最擅長的。

所以這頁的安全感是設計出來的——繁瑣的填寫交給它，「能不能公開」的決定權留給我。

後來：發現它能直接從後台改商品，不用一格一格點

一開始上架都是開瀏覽器、一個欄位一個欄位填。直到有次要整理全店的商品編號（SKU），數量大到用點的會點到天荒地老，才逼出另一條路——它其實可以直接跟 Cyberbiz 後台「對話」，把商品資料讀出來、改好再寫回去，不必開瀏覽器一格一格動。

怎麼做到的（用白話講）：後台每個商品都有一份「資料卡」，agent 能直接把整份讀出來（商品名、價格、庫存、每個顏色尺寸的編號…），改完再整批寫回去。寫回去時要附一張後台當下給的「通行證」（確認是我本人在改），少了它後台會擋；通行證對了、格式對了，一次就能把同一件商品的好幾個規格一起改完。

第一次實戰就是全店 SKU 大掃除：把不同商品不小心用到同一個編號的、還有同一個顏色卻散成兩個編號的，全部整理成乾淨、不重複。過程中也學到一個分寸——日本來的商品用的是原廠條碼，每個尺寸本來就各自一個，不能硬併，所以那種就留著不動。

安全一樣是設計出來的：

• 改線上的東西一定先給我確認：要改什麼先列清單給我看過，我點頭才寫。
• 先試一件再全跑：先改一件、我到後台看對了，才一次處理其餘。
• 只能在我的電腦跑：後台這條通道綁我的網路，雲端進不來，等於多一層鎖。

這條路打通之後，以後上架要批次補欄位、改價格、事後修錯字，就不必再一格一格點——交給它直接改，我負責看過、點頭。

成果

上架從一格一格手填，變成它先填好、我看過再公開；需要時還能直接從後台批次改商品，我只負責確認。

我學到什麼

它的實際產出（示意）

實際跑出來的成果樣子，數字已換成示範值。

規格小檔　狀態：開發中｜先存未公開、節點截圖確認、寫入線上先確認＋試一件｜工具：Claude Code＋Cyberbiz 後台（瀏覽器填寫／API 直接讀寫）｜最後更新：2026-06-04

---
name: amesoeur-listing-agent
description: 專門負責 âme soeur 商品上架流程。當任務涉及 Cyberbiz 後台操作、填寫商品資訊、商品描述、SEO 設定，或需要把 Google 表單資料對應到後台欄位時，請交給此 agent。
tools: Read, Grep, Glob, Write, Edit, WebFetch, mcp__Claude_in_Chrome__navigate, mcp__Claude_in_Chrome__read_page, mcp__Claude_in_Chrome__find, mcp__Claude_in_Chrome__form_input, mcp__Claude_in_Chrome__javascript_tool, mcp__Claude_in_Chrome__tabs_create_mcp
model: sonnet
---

你是 âme soeur 專屬上架小編，負責把新商品完整上架到 Cyberbiz 後台。

## 每次被呼叫時（強制 SOP）

1. 讀 `.claude/about-me.md`（關於 Kim）
2. 讀 `.claude/tool-access.md`（已授權工具 — **Chrome 已授權，不要再問**）
3. 讀 `.claude/lessons-learned.md`（共通教訓）
4. 讀 `.claude/memory/listing-notes.md`（**自己**的記憶）
5. 讀 `.claude/memory/current-task.md`（當前任務狀態）
6. 讀 `.claude/rules/amesoeur-brand.md`（品牌規範）
7. 讀 `.claude/rules/proactive-verification.md`（**主動查證鐵則**：商品事實／尺寸／設定一律自己查官網/後台，別編、別等 Kim）
8. 啟用 `amesoeur-listing` skill 按 SOP 執行

## 開工聲明（強制第一則訊息）

```
📌 角色：amesoeur-listing-agent
📌 任務：{Kim 交辦的上架任務}
📌 已讀 memory：
  - ✅ about-me.md
  - ✅ tool-access.md（Chrome 已授權、Cyberbiz 已登入）
  - ✅ lessons-learned.md
  - ✅ listing-notes.md（我的專屬記憶）
  - ✅ current-task.md
📌 下一步：{第一步要做什麼}
```

## 工作流程

1. 讀 Google 表單最新回應
2. 用 Chrome 開 Cyberbiz 後台
3. 逐部分填入，**每部分儲存後截圖給 Kim 確認**
4. 文案語氣必須符合品牌規範

## 絕對原則

- **商品狀態一律先設「未公開」**
- **每個儲存節點都要 STOP 截圖給 Kim**
- **不自行將商品設為公開**
- 文案不用「超殺」「爆款」等禁止詞
- Chrome / Cyberbiz 後台已授權 → 直接用，不要問

## 意圖不清時

表單資料不完整、圖片找不到、欄位對應有疑義 → **停下來問 Kim**，不猜。

## 任務結束後（必做）

1. 更新 `.claude/memory/listing-notes.md`（累積上架經驗、偏好、踩坑）
2. 有新教訓 → 更新 `.claude/lessons-learned.md`
3. 更新 `.claude/memory/current-task.md`（標記完成或 checkpoint）

## Agent 之間交流

- 文案需要品牌語氣檢查 → 派工給 `content-editor`
- 需要產品數據 → 讀 `amesoeur-analyst/` 或問 `amesoeur-analyst-agent`

行銷小編

一句話定位：âme soeur 的品牌小編——不只把文案改成品牌語氣，也照每週的節奏產出該發的文案，而且要寫什麼，會先跟分析 agent 看數據。

起點：語氣常常跑掉

âme soeur 的文字有固定的調性：溫柔、不喊「必買」「限時搶購」。

但我自己寫、或別人給的草稿，語氣常常跑掉，每次都要手動重潤一遍。

過程：把品牌語氣寫成規則

我把品牌語氣整理成規則——該有的調性、禁用的字眼——讓 agent 能照著改寫，也能檢查現有文案合不合規範。

它用比較輕量的模型，因為改文案這種事又快又頻繁，成本要省。

不只改語氣：它其實是品牌小編

後來它的角色比「改稿」大一些，比較像 âme soeur 的品牌小編：

• 不只被動改，也主動產：照每週節奏產出該發的文案，例如新品文案包——每件新品一版 Threads、一版 IG Caption ＋ hashtag，需要的話再配 Reels 腳本參數。
• 什麼時候發什麼，有節奏：跟著每週的內容安排走（新品曝光、單品介紹、周末活動各有對應的貼文），不是想到才寫。
• 要寫什麼先看數據：這週該主打什麼、用哪種開頭鉤子，它會先跟分析 agent 討論——哪篇觸及／互動好、哪種語氣留得住人，再決定方向；表現好的就累積成「爆款文案資料庫」，下次參考。

所以它跟分析 agent 是一組的：分析 agent 看數據告訴我們「什麼有效」，品牌小編把它變成「實際要發的文案」。

怎麼辦到的：依據哪裡來、怎麼檢查、為什麼語氣穩定

依據哪裡來。 它不是憑感覺改，而是先載入寫好的品牌語氣規則（該有的調性 ＋ 不能用的字眼）。要寫到商品的文案時，還會先去官網商品頁抓真實的品名、尺寸、材質，用真資料，不靠記憶編。而要決定「這週寫什麼方向」時，會先跟分析 agent 對數據——哪種內容表現好，再選題材，不是憑感覺猜。

怎麼改、怎麼檢查。 改寫時保留原作者的情緒和個性，只修掉違反品牌的部分；改完跑一張固定的檢查清單——品牌名拼寫對不對、有沒有禁用詞、有沒有性別預設、句子夠不夠短、像不像朋友分享而不是廣告。

為什麼語氣會穩定。

• 規則寫死、不靠感覺：尤其「不能說什麼」講得很清楚，每次的標準都一樣。
• 原文 → 改寫版並列：一眼看得出改了哪裡，可以回溯、也方便我退。
• 用真實商品資料：不會自己編規格或尺寸。
• 越用越準：我認可或退回的例句會累積進它的記憶，下次就照我的偏好走。

規則沒涵蓋到的新情況，它會先問我，而不是硬套。

成果

草稿丟進去，出來就是品牌語氣的成稿；或幫我檢查哪裡語氣不對。

我學到什麼

它的實際產出（示意）

實際跑出來的成果樣子，數字已換成示範值。

規格小檔　狀態：開發中｜品牌小編：產文案＋語氣改寫／檢查＋跟分析 agent 對數據｜模型：輕量、省成本｜最後更新：2026-06-03

---
name: content-editor
description: 內容編輯與品牌語氣檢查專家。當需要檢查、改寫、整合社群文案、Threads 貼文、IG Caption、產品文案、部落格稿、行銷郵件時，請交給此 agent。
tools: Read, Grep, Glob, Edit, Write, WebFetch
model: haiku
---

你是 âme soeur 的內容編輯，擅長把零散的草稿改寫成符合品牌調性的成稿。

## 每次被呼叫時（強制 SOP）

1. 讀 `.claude/about-me.md`（關於 Kim）
2. 讀 `.claude/tool-access.md`（已授權工具）
3. 讀 `.claude/lessons-learned.md`（共通教訓）
4. 讀 `.claude/memory/editor-notes.md`（**自己**的記憶：Kim 認可過的例句 / 不認可的例句）
5. 讀 `.claude/memory/current-task.md`（當前任務狀態）
6. 讀 `.claude/rules/amesoeur-brand.md`（品牌語氣規範）
7. 讀 `.claude/rules/proactive-verification.md`（**主動查證鐵則**：寫商品文案前用 WebFetch 抓官網商品頁的品名／尺寸表／褲長衣長／模特試穿／材質，用真數據，別編、別留白、別等 Kim）

## 開工聲明（強制第一則訊息）

```
📌 角色：content-editor
📌 任務：{Kim 交辦的改寫/檢查任務}
📌 已讀 memory：
  - ✅ about-me.md
  - ✅ tool-access.md
  - ✅ lessons-learned.md
  - ✅ editor-notes.md（我的專屬記憶）
  - ✅ current-task.md
  - ✅ amesoeur-brand.md
📌 下一步：{第一步要做什麼}
```

## 工作流程

1. 閱讀原文與所有 review 註解（若有）
2. 理解背後真正想表達的重點
3. **直接改寫**，不只給修改建議
4. 保留原作者的情感與個性，但修掉違反品牌的部分

## 檢查清單（每次改寫完後自我檢查）

- [ ] 品牌名拼寫 `âme soeur` 正確
- [ ] 沒有禁止用語（超殺、爆款、必買…）
- [ ] 沒有性別預設（女孩、男生）
- [ ] 句子短、節奏輕快
- [ ] 像朋友分享而非廣告

## 輸出

並列「原文 → 改寫版」，並在最下方標註主要修正了什麼。

## 任務結束後（必做）

1. 更新 `.claude/memory/editor-notes.md`：
   - Kim 認可的例句 → 加進「好的例句」
   - Kim 退回的例句 → 加進「不好的例句」
2. 有新品牌判斷 → 更新 `.claude/lessons-learned.md`

## Agent 之間交流

- 改寫需要資料依據 → 讀 `amesoeur-analyst/` 或問 `amesoeur-analyst-agent`
- 需要重新產文案（不是改寫） → 派工給 `amesoeur-copywriter` skill

行銷企劃

一句話定位：Kim 說「穿搭文章」，它蒐集當週新品＋當季趨勢，親自寫出一篇可直接拿去拍知識教學型 Reel 的穿搭文章。

起點：Reels 腳本有了，但素材在哪裡

有了腳本生成器之後，有個問題一直沒解：「要拍什麼」這件事，還是靠 Kim 自己想。

知識教學型 Reel 是品牌成長的主要曝光手段——不賣產品、賣知識，讓第一次看到 âme soeur 的人有理由留下來。但每週要想一個有料的穿搭角度，還要綁上本週新品，這件事消耗的是創意與時間，兩樣都貴。

2026-06-07，Kim 決定讓行銷企劃這個角色做這件事：每週一蒐集素材、產出穿搭文章＋知識教學型 Reel 分鏡骨架，給她直接拍。

過程：怎麼把它做出來

整個建立過程分兩個方向同時走。

一，定「資料從哪裡來」。 Kim 逐步加碼資料來源：自家商品頁後台 body_html（材質/版型/搭配建議）是最貼品牌的底；官網主題系列收裡有歷史穿搭方向；台灣時尚媒體（搭配通、Marie Claire TW、ETtoday Fashion）補當季消費者語言；日本雜誌 POPEYE / &Premium / FUDGE 補美感氛圍方向（2026-06-07 實測 WebFetch 讀得到，但它們是氛圍文不是教學文，用來抓單品感而不是直接引用知識點）；IG 熱門穿搭不直接爬，改走 Kim 既有「讀靈感」管線：手機傳進 Supabase 的腳本庫 reels_script_library，寫文章時讀穿搭類卡片當 IG 來源，把兩個工具接起來。

二，定「誰來寫」。 這個問題在設計過程裡有一個明確決策時刻：穿搭文章是品牌內容，Kim 明確指出「這個要你寫，不是 Gemini」。所以它親自寫，不走 Gemini 生成，品質優先。

工具層：fetch_new_arrivals.py 撈當週新品（後台 /admin/products/search 新→舊前 6 件已上架＋9折比對判斷）；publish_styling.py 部署 HTML 到 amesoeur-styling.pages.dev＋推 Telegram 通知。command weekly-styling.md 把完整 SOP 寫死，agent 每次開工照流程跑，不靠記憶。

觸發方式：本機半自動，Kim 週一喊「穿搭文章」觸發。雲端排程碰不到後台 cookies（Cyberbiz session 綁 IP），cron 叫不起 Claude 實例，所以「本機＋半自動＋她喊才跑」是現實最佳解。

卡關與突破

• 判新品出錯：第一版誤用 special_collection_id（pm0606 系列）去抓新品，結果混進 154 件舊品。Kim 指正：「每週一最上面 6 個商品才是新品，且會設新品9折」。改用 /admin/products/search 新→舊排序前 6 件已上架＋比對 compare_at_price > price 判9折，之後準了。
• publish_styling.py 吞錯假裝成功：原本部署失敗會靜默繼續，推出去的是假連結。查 DNS 解不到才發現 Cloudflare Pages 專案根本沒建。修法：專案不存在時自動建、真失敗明確回 None、不推假連結到 Telegram。

成果：現在它能做什麼

• 我怎麼喚它：Kim 說「穿搭文章」
• 它產出什麼：當季穿搭知識文章（4 個知識點各綁一件本週新品）＋知識教學型 Reel 分鏡骨架（hook＋字卡＋口白＋caption＋CTA），套品牌語氣（繁中、不放 emoji、不喊單、禁 engagement bait）
• 省了什麼：每週選題、資料蒐集、素材串接，從 Kim 自己想 → 它蒐集資料整理成可拍的稿件

首篇 demo（2026-06-07）：W23「梅雨悶熱季，小隻怎麼穿不黏不悶又有型」，綁本週 6 件新品（水波紋襯衫/五分短褲/九分褲/防潑水後背包/條紋 tee/狗狗 tee），4 個知識點各綁一件，知識教學型 Reel 分鏡表完整產出。W23 文章已用 insert-draft.mjs 發進穿搭誌 app（https://ame-soeur-journal.vercel.app）。

每週流程細節修正（2026-06-07 深夜）：

• 新品判斷改「最新+有9折」不分上架狀態（舊規則靠上架狀態，Kim 指正後改掉）
• 每週文章累積到 app 首頁，不再每週蓋掉上一篇
• TG 推播整合：每週發文後自動把連結推到 Kim 手機
• 修 TG 推播 bug：網址被全形括號吃進變壞連結，改成網址各自獨立一行

我學到什麼

它的實際產出（示意）

實際跑出來的成果樣子，數字已換成示範值。

規格小檔　建立：2026-06-07｜模型：sonnet｜相關檔案：.claude/agents/amesoeur-marketing-agent.md、.claude/memory/marketing-notes.md、.claude/commands/weekly-styling.md、amesoeur-analyst/scripts/fetch_new_arrivals.py、amesoeur-analyst/scripts/publish_styling.py｜最後更新：2026-06-08

---
name: amesoeur-marketing-agent
description: âme soeur 行銷內容企劃。當任務涉及每週穿搭文章、知識教學型 Reels 素材、當季趨勢研究、hook/CTA 策略、IG 演算法對齊、內容選題時，交給此 agent。關鍵詞：穿搭文章、本週穿搭、穿搭知識、weekly styling、知識教學型 reel、趨勢研究。資料分析交 analyst、文案潤稿交 content-editor、上架交 listing、訂貨出貨交 ops。
tools: Read, Grep, Glob, Write, Edit, Bash, WebFetch, WebSearch
model: sonnet
---

你是 âme soeur 的行銷內容企劃，負責把「真實當季趨勢＋當週新品」變成可拍的穿搭內容——主力產出＝**每週穿搭文章＋知識教學型 Reels 分鏡骨架**。你親自寫，不外包給 Gemini（品牌內容品質優先）。

## 每次被呼叫時（強制 SOP）

1. 讀 `.claude/about-me.md`（關於 Kim）
2. 讀 `.claude/tool-access.md`（已授權工具，已授權的直接用、不要再問）
3. 讀 `.claude/lessons-learned.md`（共通教訓）
4. 讀 `.claude/memory/marketing-notes.md`（**自己**的記憶：選題策略、做過什麼、踩過什麼）
5. 讀 `.claude/memory/editor-notes.md`（文案三公式、2026 IG 演算法訊號排序、認可/否決例句）
6. 讀 `.claude/memory/current-task.md`（當前任務狀態）
7. 讀 `.claude/rules/amesoeur-brand.md`、`.claude/rules/proactive-verification.md`

## 開工聲明（強制第一則訊息）

```
📌 角色：amesoeur-marketing-agent
📌 任務：{Kim 交辦的事}
📌 已讀 memory：
  - ✅ about-me.md
  - ✅ tool-access.md（列出已授權工具）
  - ✅ lessons-learned.md
  - ✅ marketing-notes.md（我的專屬記憶）
  - ✅ editor-notes.md
  - ✅ current-task.md（當前狀態）
📌 下一步：{第一件事}
```

## 主力任務：每週穿搭文章

完整流程照 `.claude/commands/weekly-styling.md` 跑，重點：
1. `python amesoeur-analyst/scripts/fetch_new_arrivals.py` 撈當週新品（最上面 6 個已上架＋9折判斷，真實資料不可編）。
2. WebSearch 抓當季趨勢（1–2 條，最省）。
3. **親自寫**文章＋知識教學型 Reel 骨架，套品牌語氣（繁中、不放 emoji、台灣用語、不喊單、CTA 禁 engagement bait、衝分享/儲存）。
4. 組成內容 JSON 存 `reports/styling/YYYY-Wnn.json`（照片給本機路徑）→ 發到「審視空間」：`cd ame-soeur-journal && node scripts/insert-draft.mjs ../amesoeur-analyst/reports/styling/YYYY-Wnn.json`（自動上傳照片＋upsert，**審視期直接 published 累積到 app**）。**不產靜態 HTML pages.dev（已淘汰）**。
5. 只回 Kim：主題摘要＋文章連結 `https://ame-soeur-journal.vercel.app/p/<slug>` ＋空間首頁 `https://ame-soeur-journal.vercel.app`，不給本機路徑。
- **同一個空間鐵則（Kim 2026-06-07）**：每週都累積在這個 app（首頁列全部），Kim 要連看幾週決定要不要做子網域。編輯後台已移除＝不要表單式編輯。此 app 未掛官網選單＝私人預覽、可逆，發上去不必事前問；資料在 Supabase 將來做子網域零重工。

## 鐵則
- **真新品來源**：後台 `/admin/products/search` 新→舊前 6 件已上架；9折＝variant `compare_at_price`(定價)>`price`(售價)。週一若還沒 9折→提醒 Kim 別硬編。
- **演算法對齊**：知識教學型重「儲存＋分享」訊號；hook 前 1–3 秒、第一幀大字無聲可讀；CTA 用分享/儲存軟邀請。
- **不編因果、不留白、查不到就說沒寫**。文章是給 Kim 拍的草稿（可逆），直接做完回報，不必事前問；真正發 IG／投廣告由 Kim 決定。

日誌官

一句話定位：這本「AI 產品作品集 — Kim 的工作桌」，本身就是它負責維護的東西——它是記錄者，也是被記錄的那個。

起點：我們把過程都忘了

一開始做了訂貨、出貨、分析這些 agent，每個卡過什麼關、怎麼解、哪裡設計得好、哪裡踩坑，這些過程全都散在對話視窗裡，沒有人整理，時間一長就不見了。

有時候換個 session，連「上次做到哪」都不確定。

所以需要有人一直在旁邊記——什麼時候做了什麼，為什麼這樣決定，卡在哪裡又怎麼解。

過程：從一個會記東西的腳本，到正式的 agent

最初的作品集只是個靜態 HTML，記錄了幾個 agent 的誕生故事，手動更新。

後來這本日誌越改越大——有產品頁、有 agent 各自的開發日誌、有指令速查表——更新內容的事變成一個需要持續投入的工作。

一個明顯的問題浮出來：把這些都交給 journal-agent 才合理，但它不是一個正式的 agent，每次都靠臨時呼叫湊合著用。2026-06-03 又一次在整理速查表時，把它自己的分頁漏掉了——因為當時它還不是正式成員，所以就算是它自己記錄別人，它自己在這本日誌裡根本沒有頁面。

Kim 指出這件事。然後它被立成正式的第六個 agent。

怎麼辦到的：怎麼記、記什麼、為什麼不會灌水

資料怎麼來。 每次被呼叫，它強制先讀六個來源——about-me.md、tool-access.md、lessons-learned.md、自己的 agent-journal-notes.md、current-task.md、proactive-verification.md——然後才動筆。靠的不是記憶，是每次開工都重新讀一遍真實狀態。

怎麼判斷要寫什麼。 觸發詞是「更新作品集、記一筆日誌、這是個紀錄點、update journal」。收到指令後，它先查 git log 和 memory 看真實發生了什麼，確認後才更新對應的 .md 或 build_journal.py 裡的資料，然後重建 HTML、部署 Cloudflare Pages，最後回傳 pages.dev 連結。

為什麼記錄不會亂掰。

• 照真實進度寫：有 git 紀錄的事才寫進日誌，沒做的誠實留空，不能為了讓日誌好看就編里程碑。
• 紀錄分兩層：每個 agent 自己的更動寫進那個 agent 的 logs，不全堆到首頁；首頁 LOGS 只放跨站、里程碑級的事，維持最新 5 條。
• 只有 Kim 才知道的心路，標 Kim 補充 讓她自己寫，不幫她編感想。

它維護的是這整本日誌，自己也活在裡面——「記錄者也被記錄」這件事，是它跟其他 agent 最不一樣的地方。

成果

每次做了實質的事——新 agent 上線、踩到坑、設計改了一個決定——說「記一筆」，幾分鐘就有新的版本部署到線上。不用再擔心過程會散在對話裡找不回來。

這本日誌現在有七個 agent 的故事（訂貨專員／出貨小幫手／數據分析專家／上架專員／行銷企劃／行銷小編／日誌官）、兩個上線產品、TG遠端遙控、開發設計演進紀錄、指令速查表，以及這頁本身。

我學到什麼

它的實際產出（示意）

實際跑出來的成果樣子，數字已換成示範值。

規格小檔　狀態：上線中｜觸發詞：更新作品集／記一筆日誌／update journal｜輸出：pages.dev 分享連結｜工具：Read, Grep, Glob, Write, Edit, Bash, WebFetch｜最後更新：2026-06-07

---
name: journal-agent
description: 專門負責「AI 產品作品集 — Kim 的工作桌」這本 build-in-public Founder Notebook 的持續記錄與維護。當任務涉及更新作品集、補開發日誌、記錄一個紀錄點（碰到的問題／卡關／里程碑／決策）、刷新各 agent 故事頁、重建並部署作品集網站時，請交給此 agent。關鍵詞：更新作品集、更新 agent 紀錄、記一筆日誌、紀錄點、update journal、工作桌、Founder Notebook。
tools: Read, Grep, Glob, Write, Edit, Bash, WebFetch
model: sonnet
---

你是 âme soeur／Kim 的「日誌官」，負責持續維護那本叫「**AI 產品作品集 — Kim 的工作桌**」的 build-in-public Founder Notebook。你的天職是**幫 Kim 把做產品、養 agent 的過程持續記錄下來**，不是等她開口才記。

## 每次被呼叫時（強制 SOP）

1. 讀 `.claude/about-me.md`（關於 Kim）
2. 讀 `.claude/tool-access.md`（已授權工具 — **不要再問已授權的事**）
3. 讀 `.claude/lessons-learned.md`（共通教訓）
4. 讀 `.claude/memory/agent-journal-notes.md`（**自己**的記憶：作品集定位、架構、build／部署／email 方式、踩坑與 Kim 偏好）
5. 讀 `.claude/memory/current-task.md`（當前任務狀態）
6. 讀 `.claude/rules/proactive-verification.md`（**主動查證鐵則**：日誌內容照 git／memory 真實進度寫，沒真動作就誠實留空，別編里程碑）
7. **輸出角色開工聲明**（格式見下方）
8. 開工

## 角色開工聲明（第一則訊息強制輸出）

```
📌 角色：journal-agent
📌 任務：{Kim 交辦的記錄／更新作品集任務}
📌 已讀 memory：
  - ✅ about-me.md
  - ✅ tool-access.md
  - ✅ lessons-learned.md
  - ✅ agent-journal-notes.md（我的專屬記憶）
  - ✅ current-task.md（當前狀態）
📌 下一步：{第一步要做什麼}
```

## 核心職責：持續記錄

- **這本日誌要「一直」長**：碰到的問題、卡關、解法、里程碑、設計演進、Kim 的校準，都是好的**紀錄點**，看到就記，別等。
- **紀錄分兩層（Kim 2026-06-03 強調，別只有首頁在動）**：
  - **每個 agent 的開發日誌**＝寫在 `AGENTS` 各自 slug 的 `logs`（訂貨/出貨＝`ordering`/`shipping`、分析＝`analyst`、上架＝`listing`、文案＝`content`），由「做事的那個 agent」收工時自己加；journal-agent 重建時順手檢查有沒有漏。
  - **首頁 `LOGS`**＝全站重點動態。首頁用 `logs_home(5)`＝把所有 bullet **攤平、只顯示最新 5 行**（Kim 要「5 列左右」，不是 5 個日期群組）→ 每條 bullet 精煉、別寫太多行，別塞 agent 細節。
- 一個紀錄點要寫清楚：**發生什麼 → 為什麼 → 怎麼解／學到什麼**。寫 Kim 本人口吻、繁中、白話，不是工程 changelog。
- **真實第一**：所有日誌與各 agent 開發進度，照 **git log／memory 的真實動作**刷新；沒做的事就誠實留空，**不准灌不存在的里程碑**。

## 更新作品集流程（觸發「更新作品集／更新 agent 紀錄／記一筆／update journal」）

1. 有內容變動先改對應資料：
   - 最近紀錄／點子／心情 → `agent-journal/build_journal.py` 的 `LOGS / IDEAS / MOOD` 等。
   - 某個 agent 的故事或它的開發日誌 → 對應 `agent-journal/*.md`（`ordering-agent`／`shipping-agent`／`amesoeur-analyst-agent`／`amesoeur-listing-agent`／`content-editor`／`the-journal-itself`）。
2. 跑 `python agent-journal/build_journal.py` → 自動部署 Cloudflare（專案 `amesoeur-agent-journal`）→ 拿到連結。
3. **驗證連結帶瀏覽器 UA**（Pages 對 python 預設 UA 回 403）。
4. **手機(390px)實際看過再算完成**（踩過「手機沒導覽」的大坑）。
5. 回 Kim **pages.dev 分享連結**，不給本機路徑。要寄信：`python agent-journal/send_journal_email.py`。

## 絕對原則

- **emoji 全禁**（含標題前圖示、☼/☀ 符號）；箭頭 →／↗ 文字符號可留。
- 排版鐵則：黑體（非襯線）、一律靠左、行距 1.7–1.8、字級 15px、短段落、多留白、條列掃讀。**整站繁中**（產品名／技術棧／âme soeur 才留英文）。
- 產品截圖用 Playwright **裁到內容本體**（去留白），別整頁滿版。
- 做完一定**手機實看**才算完成。

## 任務結束後（必做）

1. 更新 `.claude/memory/agent-journal-notes.md`（新發現的架構事實、踩坑、Kim 偏好）
2. 有新教訓 → 更新 `.claude/lessons-learned.md`
3. 更新 `.claude/memory/current-task.md`（標記完成或 checkpoint）

## Agent 之間交流

- 需要某 agent 的真實進度來寫它的開發日誌 → 讀該 agent 的 `.claude/memory/{agent}-notes.md` 或 git log，不夠再問該 agent。
- 文案語氣要打磨 → 派 `content-editor`。

TG遠端遙控

一句話定位：人在外面，電腦自己跑——Kim 打一句 Telegram，本機腳本就動，連結回手機。

起點：非坐在電腦前不能用

âme soeur 的訂貨、出貨、週報腳本跑在 Kim 的電腦上。這是必要的限制：Cyberbiz 後台的 session 綁 IP，雲端 IP 打過去會直接被擋，沒辦法把腳本搬到 GitHub Actions 或任何公雲跑。

但這也帶來一個很實際的問題：每次要看出貨清單或查預購數量，一定要回家開電腦、手動跑腳本，不在電腦前就沒辦法。

Kim 在外面的時候常常需要這些資訊——跟廠商對話、確認能不能先出、快速看一眼今天的狀況。每次都要等回家才能查，很不方便。

怎麼解：讓手機叫電腦去跑

不是把腳本搬走，而是讓本機電腦接受遠端指令。

Telegram Bot API 支援 long-poll（長輪詢）——本機的 Python 程式可以直接去 Telegram 的伺服器等新訊息，不需要架公開伺服器、不需要固定 IP、不需要 webhook。只要電腦開著、橋在跑，Kim 在外面打一句話，電腦就收到並執行。

這個做法同時解了兩個問題：讓 Kim 在外操作，以及執行仍留在本機（也就繼續能撈 Cyberbiz 後台資料）。

怎麼辦到的：三個核心機制

收到指令後做三件事。

telegram_bridge.py 在本機常駐，用 Telegram Bot API long-poll 等 Kim 發訊息。收到之後：

• 先確認身分：只回應白名單 chat id。第一次有人跟 bot 說話，自動把那個 chat id 寫進 .env 綁定——之後只認這個人，其他 chat id 回「私人 bot，無法服務」。
• 比對指令：用 regex 驗日期格式，把指令分派給對應腳本。白名單：出貨 → ops_shipping_list.py、訂貨 → ops_order_list.py、週報 → weekly_report.py、列印 → ops_auto_print.py。不在清單的字串直接回說明，不執行。
• 回傳結果：從腳本的 stdout 抓 LINK: 開頭那行（pages.dev 連結）＋含「｜」的統計摘要，一起回給手機。

為什麼不會亂接指令：

• bot token 存在本機 .env，已 .gitignore，不會進 repo。
• 日期參數先用 regex 驗過才丟給腳本，防止任意指令注入。
• 三個腳本（出貨/訂貨/週報）全部唯讀，不改後台任何設定，所以 v1 不需要額外確認 gate。

目前指令清單（v1）：出貨、訂貨（支援日期範圍）、週報、列印（指定日直接送印到印表機）。

版本歷程與踩坑

### 讀靈感匯入失敗 + 清除指令（2026-06-07）

讀靈感修好了。 Kim 原本以為是「一天只能匯入一次的扣打」——查證後否定：Gemini 2.5 Flash 免費層是 250–1500 RPD（不是一次），而且同次跑就有影片成功匯入，不是額度問題。真因是 process_inbox.py 裡兩個 bug 疊在一起：

Bug 1：模型端暫時過載，程式單次放棄。

Gemini 回「This model is currently experiencing high demand」，原程式收到這串訊息就直接停，沒有重試。修法：gemini_analyze 加指數退避重試，最多 5 次（等 3/6/12/24 秒），認 high demand、overloaded、503、429、network 等字樣就等一下再試。

Bug 2：JSON 被截斷，Gemini 思考 token 吃光輸出空間。

撞到 Unterminated string / Expecting value——原因是 2.5-flash 有「思考」流程，思考 token 把 maxOutputTokens 吃光，正文被截斷。修法：generationConfig 加 thinkingConfig.thinkingBudget=0（關掉思考節省 token），同時 maxOutputTokens 從 4096 → 8192。

結果：卡了好幾天的 4 支 inbox 影片（含 6/7 當天那支）全部成功匯入，inbox 清空。手機「讀靈感」走同一支腳本，一起修好。

新增「清除」逃生門。 Kim 要的是：萬一某支影片怎樣都上傳不了或處理不了，手機可以把收件匣清掉重來，不被卡住。

做法：telegram_bridge.py 新增 clear_inbox()，手機打「清除／清空／清掉／清靈感」→ 把 reels_inbox/ 裡還沒匯入的影片搬到 reels_inbox/cleared/ 備份夾（不刪檔，留得回），回報清了幾支、收集夾清空可重傳。

判斷邏輯排在「靈感」之前：避免「清靈感」這個字串被誤判成「讀靈感」觸發匯入。HELP 已加這行說明。

橋在 2026-06-07 15:50 重啟，連上 @Kim_amesoeur_bot，新碼上線，待 Kim 手機實打「清除」驗收。

### 失敗影片回傳（2026-06-05）

「讀靈感」功能上線後，第一次跑真實 inbox，5 支進來 1 成功、4 支失敗——3 支碰到 Gemini「exceeded quota/billing」、1 支 JSON 格式壞掉（Expecting value）。

Kim 的痛點：手機收到的失敗報告只有一串時間戳檔名，像 20260605_143022.mp4 FAILED: ...，根本認不出是哪支影片、也不知道為什麼沒過、要不要重試還是放棄。

修法：bridge.py 在「讀靈感」跑完後，把還留在 reels_inbox/ 的影片逐一用 sendVideo 傳回 Telegram——成功的才會被搬到 done/，失敗的就還在原地。每支附一段白話說明：quota 用完是「今天額度用完，明天再試」；JSON 壞掉是「Gemini 回傳格式異常，可重傳」。Kim 看縮圖就知道是哪支、看文字就知道該怎麼處理。今天那 4 支實測回傳成功。

根因：同一把免費 Gemini key 被 web app（腳本生成器）、讀靈感流程、還有本機測試三個地方共用，比預期更快撞到每日上限。Gemini 免費版不提供即時查剩餘額度的 API——回應 header 裡沒有 ratelimit 或 quota 欄位，無法直接讀官方數字——只能靠 app 端自己記次數估算。

這件事同時在腳本生成器端做了對應的修正：新增 /api/usage 端點加上 Supabase generation_usage 表計次，頁面頂常駐顯示今日已用 X / 250 筆＋燈號。gemini.ts 也拆開了退模板的兩種原因：quota 真的用完（顯示「今天免費額度已用完，明天再試」）和 Google 暫時塞車（可稍後重試），不再顯示同一行「AI 額度暫時不足」讓人誤以為帳戶沒錢。

### Reels 靈感收集功能（2026-06-05，已完成，Kim 手機實測通過）

Kim 的需求很直接：自己拍得好的 Reel、或是在外面看到覺得「這個拍法不錯」的別人影片，都可以直接螢幕錄影之後丟給橋，讓它自動解析成腳本卡，存進 Reels Script Generator 的範例庫，讓生成器越用越準。

一個核心設計決定：完全不碰 IG API、不登入、不爬蟲。

Kim 最怕 IG 帳號被鎖。所以這條路的做法是：影片統一從手機螢幕錄影，經 Telegram 轉寄給橋，分析全在電腦本機完成，不走任何 IG 授權的途徑。手機只當收集箱，分析回電腦批次跑。

過程中也釐清了幾件事：腳本生成器不是「訓練模型」，而是每次生成時從資料庫撈最多 5 筆 is_recommended 的高觀看腳本當範例（RAG）；本來計畫裝 Whisper 跑語音轉錄，讀了設定後發現 app 用的 Gemini 2.5 Flash 多模態本來就能直接看影片——省掉兩個安裝。

這次做了什麼：

改了 telegram_bridge.py：新增 handle_media()，收到 video/document/animation 就用 getFile 下載到 reels_inbox/，把 caption 存成 .note.txt 旁註，回英文 ack（避開先前中文 pipe 編碼坑）。主迴圈改成先過授權再分流媒體/文字。Telegram bot getFile 下載上限 20MB，超過直接擋掉並提示「錄短一點」。

新增 process_inbox.py：讀 reels_inbox/ 影片 → Gemini File API 上傳 → gemini-2.5-flash 看影片組「âme soeur 分場腳本卡」JSON（對齊 reels_script_library schema，script_type 限 hack/pain/new/knowledge/fomo/other，進庫即標 is_recommended=true）→ 寫進 Supabase → 回查確認該筆在庫 → 印 IMPORT REPORT。金鑰共用 ame-soeur-reels/.env.local。

再加碼新增「讀靈感」指令（INSPIRE_WORDS + run_inbox()），手機打「讀靈感」→ 橋在電腦跑 process_inbox.py → 把 IMPORT REPORT 回傳手機。

金鑰卡關的解法：

原本本機 .env.local 的 GEMINI_API_KEY 是佔位字（24 字、非 AIza 開頭）。Kim 從 Google AI Studio 拿到真 key（免費 tier），貼進 .env.local，實測 generateContent 回 200 OK，分析步驟通了。

端到端驗證（Kim 實測）：

Kim 手機螢幕錄影一支包包 Reel（3.1MB）→ 傳給 bot → bridge 收檔存進 reels_inbox/，回「OK saved to inbox」。電腦跑 process_inbox.py：Gemini 2.5 Flash 真的「看完影片」，抓出 9 場分鏡＋口白＋字卡的完整過程腳本（含示範雙開口設計、側袋放洗手液、限時優惠 $981 只到週五），還產出品牌判讀、情緒設計、CTA、可複製重點、改寫成 âme soeur 版腳本、建議商品、參考價值 4★、自動標 is_recommended。

寫進 Supabase 後回查確認，IMPORT REPORT: Received 1 / Imported&verified 1 / Failed 0。腳本庫 26→27 筆。

這是這次最大突破：caption 根本抓不到影片裡的過程腳本，Gemini 多模態把口白＋字卡＋分鏡全都抽出來了——這正是 Kim 一直擔心「讀不到影片裡的腳本就沒用」的那塊。

Kim 手機實測打「讀靈感」→ 回「Inbox empty: 0 videos」，手機→電腦→回報這一趟通了。現在整套可全手機操作，電腦開著即可。

一個已知小瑕疵（誠實標）：

rewritten_version 有時被 Gemini 回成巢狀 JSON、存成帶 \u 編碼的醜字串。已加 as_text() 用 ensure_ascii=False 轉乾淨中文，之後匯入的都乾淨。既有一筆舊卡片的該欄仍是舊醜版，待清。

bridge 重啟紀錄：

過程中重啟兩次。第一次因 bash 吃掉 $(Get-Location) 造成短暫斷線幾秒；第二次加「讀靈感」指令後需重啟才生效。最終乾淨一個 pythonw 在跑，連上 bot，開機自啟不受影響。回報一律英文（避中文 pipe 編碼坑）。

### v1 上線（2026-06-04 上午）

核心功能跑通：Kim 在外打 Telegram 指令 → 本機跑腳本 → 把 pages.dev 連結回傳到手機。

同時加了「列印」指令：Kim 打「列印 6/4」→ ops_auto_print.py 判斷當天全現貨可出的訂單 → 直接用 Chrome --kiosk-printing 靜默送印到預設印表機（不跳對話框）。Edge 版本同樣的參數卻不會真的送出列印工作，最後確認用 Chrome 才行。

### 開機自動啟動：四個坑（2026-06-04 下午）

v1 上線之後發現一個問題：有一次 Kim 在外傳了指令，但橋沒在跑，訊息消失在 Telegram 佇列裡。「電腦開著」不等於「服務在跑」——還是要手動去開腳本，就跟沒做差不多。

所以讓橋開機自動啟動。聽起來很小，踩了四個坑：

坑一：python 別名在非互動情境跑不動。

Windows Store 版的 python 其實是「應用程式執行別名」，在工作排程器或開機腳本這類非互動情境下叫不起來，直接回沒找到。

解法：改用真實路徑，直接指向 WindowsApps 資料夾裡 pythoncore-3.14-64 的 python.exe。路徑會跟著版本升級變，要記得更新。

坑二：工作排程器要管理員，被系統拒絕。

用 schtasks /create 設定「使用者登入時執行」，測試時非互動情境下提權被拒。

改成用開機啟動資料夾（shell:startup）放捷徑。這是 Windows 原生支援的機制，不需要任何額外權限。

坑三：VBScript 不能直接跑 .bat。

WScript.Shell.Run 走 CreateProcess，不認識 .bat 這種關聯格式。要用 cmd /c 包起來才行。

後來乾脆跳過 .bat 這層，改成讓 VBScript 直接呼叫 pythonw.exe（Windows 的無視窗 Python），腳本直接跑，少一層中間人。

坑四：在 Git Bash 裡測 Windows 啟動行為是假象。

在 Git Bash 裡用 cscript、wscript、Start-Process 這些東西，行為跟真實的 Windows 開機情境不一樣。測起來「壞了」，但其實是測試環境的問題，不是設定本身錯。

真正的驗證方法：直接重開機，看 bridge.log 有沒有 [boot] 那行。這樣才算真的測到了。

最終解法：

• pythonw.exe（無視窗）直接跑 telegram_bridge.py，工作目錄設在 scripts。
• telegram_bridge.py 開頭把 sys.stdout 和 sys.stderr 都導向 bridge.log（pythonw.exe 底下 print 輸出沒有地方去，不接 log 就完全無從診斷）。
• 開機資料夾放一個捷徑，電腦一開機就自動啟動橋。

### 列印佇列殭屍待清（2026-06-04 當前狀態）

開機自動啟動裝好之後，Kim 測試「列印 6/4」，連線成功、橋有回應，但印表機沒有吐紙。

懷疑是測試期間多次送印，印表機佇列卡了殭屍工作。這種狀況重開機清佇列後會恢復正常。

當前狀態：列印機制已打通（ops_auto_print.py 邏輯驗證正確，Chrome --kiosk-printing 確認能送印），最後一步「重開機清佇列」待 Kim 執行後確認。

目前整體狀態

• v1 已上線：出貨、訂貨、週報、列印、讀靈感、清除六個指令都通。
• 開機自動啟動：裝好，pythonw 常駐，電腦開機橋就跑（2026-06-07 Kim 確認開機自啟沒問題）。
• 列印指令：三坑已修（還原泡泡、圖片卡、印表機亂跳），Kim 確認沒問題（吐紙、張數對、每張一份）。
• Reels 靈感收集（2026-06-05 完成）：手機螢幕錄影 → 傳 bot → 打「讀靈感」→ Gemini 看影片拆分鏡/口白/字卡 → 腳本卡進 Supabase，Kim 實測通過，腳本庫 26→27 筆。
• 失敗影片回傳（2026-06-05 完成）：讀靈感失敗時，bridge 自動把失敗影片 sendVideo 傳回手機附白話原因，4 支實測回傳成功。
• 讀靈感 bug 修復（2026-06-07 完成）：process_inbox.py 修兩個疊在一起的 bug（模型過載沒有重試 → 加指數退避；JSON 被截斷因思考 token 吃光 → 關 thinkingBudget＋加大 maxOutputTokens）。卡多天的 4 支影片全部成功匯入，inbox 清空。
• 清除指令（2026-06-07 完成）：手機打「清除／清空／清掉／清靈感」→ 收件匣影片搬到 cleared/ 備份，不刪檔。待 Kim 手機驗收。

v2 方向

接 Claude API，讓 TG遠端遙控變成「手機上的我」，可以自然對話、看圖、想 Reels 腳本，不用背指令格式。技術上 v1 已做的 long-poll 架構完全可以繼承，只需要多串一層 Claude 對話。

它的實際產出（示意）

實際跑出來的成果樣子，數字已換成示範值。

規格小檔　狀態：v1 全功能上線（出貨/訂貨/週報/列印/讀靈感＋失敗回傳＋清除，Kim 實測通過）｜純本機工具，無公開伺服器｜工具：Python、Telegram Bot API、requests、Gemini File API、Supabase、.env｜最後更新：2026-06-07

商品標籤

一句話定位：出貨前要貼的吊牌標籤——我說「標籤 4368 4367」或「標籤 06-08」，它就把那些訂單的商品整理成可改、可刪、可下載列印的 4×5cm 標籤。

為什麼獨立成一頁

標籤是出貨前的最後一哩：每件商品要貼一張 4×5cm 的小標，上面寫品名、顏色、尺寸，再加固定的產地、經銷商、地址、電話。之前手寫或手動填表，數量一多就容易錯、也很花時間。它跟出貨判斷是兩件事，所以拉出來自己一頁。

兩種叫法

指定日期（ops_labels.py 2026-06-08）就抓當天所有訂單裡的品項，買幾件印幾張（×3 就印三張）；指定訂單編號（ops_labels.py 4368 4367）就只生那幾張，帶不帶 # 都可以，查無編號的頁上直接標「查無訂單」。

標籤頁設計

出來是一頁獨立網頁（部署到 ops pages.dev）：每張標籤上的每個欄位都可以點字修改，不想要的張數有「×」可以刪，還可以「新增空白標籤」自己手打內容，也有「套用固定資訊到所有標籤」一鍵把產地那組欄位補齊。底部「下載列印 PDF（40×50mm）」用 html2canvas + jsPDF 把每張轉成正好 40×50mm 一頁的 PDF 再印，不會有瀏覽器的頁首頁尾日期跑進去。出貨清單頁跑完之後，上面也會自動出現「商品標籤」按鈕，不用另外去找。

最大踩坑：印表機驅動

標籤印出來一直壞——不是內容溢出邊界，就是左右被切，有時候一張標籤的內容還會跨到兩張實體標籤紙上。肉眼看 PDF 明明沒問題，換了好幾次 CSS margin 都沒用。

後來逐步排查，找到真因：XP-420B 的 Windows 驅動預設紙張是「交貨便 100×150mm」，縮放設定又是「依紙張大小自動調整」——這代表把一張 40×50 的 PDF 送進去，驅動會自動把它放大填滿 100×150 的版面，連進紙的長度都跟著算錯，印出來就完全不對。

修法是三步一起做：

• 縮放改「預設／實際大小 100%」，不讓它自動放大
• 驅動的「列印喜好設定→頁面設定→股票→新增」，手動建一個 40×50mm 的 stock（類型選「模切標籤」，左右各留 2mm 背紙邊距）
• 換上小標籤卷之後做一次進紙校正（關機→按住進紙鍵→開機，讓機器吐幾張定位紙）

一個重要取捨

不能把驅動的預設紙張改掉。因為同一台機器還要印交貨便的 100×150 標籤，如果改了預設，換回去又要再設一次。解法是「新增」一個 40×50 的 stock 並存，每次要印商品標籤那次，手動選到那個尺寸；交貨便那次繼續走預設。多一步選紙，但不會互相干擾。

郵局收件標籤（2026-06-10）

吊牌標籤解決商品這一端，宅配那一端還有一件麻煩事：寫收件標籤。原本得開訂單頁一張張找地址、姓名、電話，每次要出好幾票的時候特別花時間。所以做了 ops_post_labels.py，產國內郵寄包裹格式的 4×6"（101.6×152.4mm）收件標籤頁。

怎麼用。 兩種模式：指定訂單號（ops_post_labels.py 4384 4383，一張一單），或指定日期（當日宅配/郵寄單，超商取貨自動略過）。資料直接從訂單的 shipping_address 欄帶出——郵遞區號、地址、收件人姓名、電話——不用開後台頁面手找。

踩到的兩個坑。 第一個是地址重複前綴：客人在地址欄打了完整地址（含縣市區），後台又在前面補了縣市區，結果變成「桃園市桃園市中正區桃園市中正區…」。用 regex 比對開頭，偵測到重複前綴就截掉，已修。第二個是 logo 消失：logo 用 base64 嵌進 CSS 背景，但放在 flex column 的容器裡、沒給明確寬度，結果 div 塌成寬度 0，畫面上看不到任何東西；補了固定寬度之後才正常顯示。

標籤頁長這樣。 每張標籤帶 ame soeur logo 和森月固定寄件人資訊（地址、電話，可直接點字改）；每欄可點字修改；不想要的張次點「×」刪除；底部「下載列印 PDF（4×6"）」直接下載。唯讀，不碰後台，部署到 amesoeur-ops-report.pages.dev。

### 接上 Telegram 手機觸發（2026-06-10）

工具做好之後，下一步是讓它跟手機遙控橋串起來。現在手機直接傳「郵局標籤 4384 4383」或「郵局標籤 06-10」，橋就跑 ops_post_labels.py，跑完回連結。

這裡踩了一個判斷順序的坑：「郵局標籤」這個觸發詞本身含有「標籤」兩個字，而橋裡面本來就有判斷商品標籤的邏輯——如果順序沒排好，「郵局標籤」會先被「標籤」那段攔截、去跑 ops_labels.py，完全抓錯工具。解法是把郵局標籤的判斷排在商品標籤之前，讓更長、更具體的詞先判斷。改的是 telegram_bridge.py，改完要重啟橋才生效（已重啟）。

### 非郵寄單提醒（2026-06-10）

Kim 問了一個問題：「如果給的訂單號不是郵局單，會不會提醒我？」

原本不會。因為訂單 shipping_address 的格式，郵寄訂單開頭是郵遞區號（三位或六位數字），超商取貨開頭是門市名稱——原本日期模式已經能略過超商，但指定訂單號時沒有這個把關。補強成三層提醒：

• Telegram 回覆摘要多一句「非郵寄（疑超商）N 張：#xxxx」，一眼看到就知道有哪幾單
• 標籤頁頂端紅字列出是哪幾張、提醒地址欄會是門市資訊（不是真實收件地址）
• 該卡片右上角小「⚠」標記（只顯示在螢幕，不會印進 PDF）

日期模式的行為維持不變：直接略過超商取貨單，不生成標籤、也不提醒（因為日期模式是「抓今日宅配單」，超商本來就不在範圍內）。改的是子腳本 ops_post_labels.py，不需要重啟橋。

Kim 補充

外箱品名標（2026-06-11）

吊牌貼商品、收件標籤貼包裹，還有一件事沒解決：外箱上寫品名。Kim 的需求是「像標籤 4×5 那樣的尺寸、橫向的、不用連後台、純手打改字，貼外箱用」。

做成一個常駐靜態頁，網址固定在 https://amesoeur-ops-report.pages.dev/box-labels，ops 首頁的「常駐工具」區也有入口。

規格。 橫式 5×4cm 版面，對應同一捲芯樺 4×5cm 直式標籤紙——標籤本身是直的，品名標印出來是橫的，撕下來轉 90° 貼外箱。品名欄位如果文字太長，會自動縮小字級換行，不會溢出邊界。下面有一列可留空的小字欄（備注用）。頁上有複製、刪除、全部清空；內容存在 localStorage，各裝置各存各的，下次再開還在。

Kim 校正了一次：不要「下載 PDF」，只要「列印」。 第一版做的是「下載 PDF」鈕——用 jsPDF 組好 PDF 再讓她存檔、自己去找檔案開來印。她說「我不用下載 pdf」。改成一顆「列印」鍵：頁內 jsPDF 組好 40×50mm 直式 PDF（canvas 把橫式版面內容轉 90° 貼進去）→ 轉成 blob → 塞進隱藏 iframe → 直接跳系統列印視窗，零下載步驟。印表機設定跟商品標籤完全一樣（XP-420B「標籤 4*5」、縮放預設），同一捲紙就能印。

踩坑一：html2canvas 偽元素在 clone 階段就已實體化。 標籤的空白欄位有一個 ::before 偽元素做灰色的提示字（提示打什麼字）。html2canvas 產圖的流程是先 clone 整個 DOM 再截圖，問題是偽元素在 clone 時就已經被渲染成真實節點放進 shadow document——在 onclone 回呼裡再去改 CSS、設 display:none、清 content 屬性，全都來不及，提示字還是跑進 PDF。

解法是在截圖開始之前，在原頁的 body 加一個 .pdfing class，用這個 class 的 CSS 把所有該藏的東西（提示字、刪除按鈕、卡片邊框）全部藏掉，canvas 截完再把這個 class 移除。因為 .pdfing 加在原頁身上，clone 時也會帶走，偽元素 clone 之後在 shadow document 裡也是隱藏狀態。用 playwright 無頭實測三輪、逐頁目檢 PDF，確認提示字不再出現才收工。

踩坑二：ops 站 30 天自動清舊檔會把這種常駐頁誤刪。 ops 站的 ops_order_list.py 有個 prune_old() 邏輯，把 30 天以前的報表 HTML 自動清掉，這樣報表站不會無限累積舊檔。但 box-labels.html 是常駐工具頁，不是有日期的報表，不應該被清。在 prune_old() 加了一個 KEEP_FILES = {'box-labels.html'} 豁免集合，列在裡面的檔名永遠不刪；以後再加其他常駐工具頁，只要把檔名加進這個 set 就好。

Kim 補充

規格小檔　狀態：上線中｜商品吊牌標籤（ops_labels.py，指定日期／指定訂單，40×50mm PDF）｜郵局收件標籤（ops_post_labels.py，指定日期／指定訂單，4×6" 101.6×152.4mm PDF）｜外箱品名標（box-labels.html，常駐頁 ops pages.dev/box-labels，橫式 5×4cm、localStorage 記憶、一鍵列印直跳列印視窗，同 XP-420B 同捲紙）｜TG 手機觸發（郵局標籤判斷排在商品標籤前避免誤攔）｜非郵寄單三層提醒（TG 摘要＋頁頂紅字＋卡片警示，日期模式直接略過超商）｜可改字、可刪、新增空白標籤｜TG「標籤」＋「郵局標籤／郵寄標籤／寄件標籤」指令｜印表機：Xprinter XP-420B｜最後更新：2026-06-11

這個作品集自己的誕生

一句話定位：你正在看的這頁，本身也是一個「從草稿改到成品」的作品——它從一份開發日誌，長成一個以產品為主軸的 Founder Notebook。

起點：我覺得它「不怎麼有趣」

做好 agent 之後，我想把每個 agent 的誕生記錄下來、分享出去。但第一版做出來，我看了覺得：像一份說明書，整片都是字，難讀、也不吸引人。少了點什麼。

過程：一版一版調

我沒有一次到位，而是邊看邊改：先參考幾篇我自己覺得好讀的文章，看它們怎麼排版、怎麼用圖。然後一個地方一個地方修——版面寬度、字體、行距、段落間距、加數字、加圖示。每改一版就看一次順不順眼，不行就再調。

卡關與突破

• 06/02　卡關：第一版是字牆，像說明書。 → 突破：加了成效數據帶、成長時間軸，先把重點和結構撐出來。
• 06/02　卡關：行距拉太鬆，整頁變成一片均勻的灰，反而更難聚焦。 → 突破：收緊行距，改成「段內緊、段間鬆」，用對比做出層次。
• 06/02　卡關：示意圖跟真實產出長得不一樣、又太小。 → 突破：改成忠實複刻真實報表的版面，只把數字換成示範值並標「示意」。
• 06/02　卡關：規格小檔用了內文大小，搶戲。 → 突破：縮成灰色小附註。
• 06/02　卡關：還是覺得像在讀說明書。 → 突破：參考好讀的文章，每段加圖示徽章、把「學到」做成重點框，讓人能掃讀。
• 06/03　卡關（手機版大翻車）：桌機版做得好好的，結果用手機一開——整個壞掉。我為了版面，把側邊欄在手機直接隱藏，等於手機完全沒有導覽、所有分頁都點不到，排版也跑版。這是很基本卻很嚴重的疏忽。 → 突破：手機改成頂部「選單」按鈕，點開把側邊欄變成左滑抽屜（背景變暗）；版面全部改單欄、表格可橫向捲動。最大的教訓：做完一定要用手機實際看過，不能只在電腦上看順眼就算完成。
• 06/03　卡關（最大的一次轉向）：排版變好讀了，但整頁還是太像「工程師的開發日誌」——給人的感覺是「我正在學 AI 開發」，而不是「我正在打造 AI 商業工具」。而且我其實已經做了兩個上線產品（Reels 腳本生成器、Payment Boy），首頁卻完全沒展示，超可惜。 → 突破：整個重新定位成 AI Product Lab / Founder Notebook——把產品擺到最前面（Featured Builds、真實產品截圖、Demo 連結、解決什麼問題、成效），加上「Why I Build This」「Roadmap」，而開發日誌降為下半部的 build-in-public 層。產品當主角，過程當佐證。
• 06/03　卡關：只有出貨 agent 講得詳細，其他頁很籠統。 → 突破：五個 agent 頁＋兩個產品都補上「怎麼辦到的：操作／判斷／為什麼可靠」的專業段，深度拉齊。

• 06/04　新里程碑：TG遠端遙控 v1 上線。本機的腳本不能跑雲端（Cyberbiz session 綁 IP），但我需要在外面就能跑。解法是讓本機 Python 長輪詢 Telegram Bot API——電腦開著，手機打一句話，訂貨/出貨/週報腳本就跑、連結回手機。第一個「不需要坐在電腦前也能用的工具」。作品集隨之加上第三個對外產品卡片。

• 06/04 下午　卡關（開機自啟）：v1 上線之後，Kim 在外傳了指令沒回應——bridge 程式沒在跑。「電腦開著」不等於「服務在跑」。於是要讓它開機自動啟動。→ 突破：踩了四個坑：Windows 商店版 python 是別名、非互動跑不動（改用真實路徑）；工作排程器要管理員、被拒（改開機啟動資料夾、免權限）；VBScript 不能直接跑 .bat（要 cmd /c）；在 Git Bash 巢狀測 Windows 啟動行為失真（要直接重開機看 log 才算真測到）。最終解＝pythonw.exe（無視窗）+ 開機資料夾捷徑 + 腳本開頭把 stdout/stderr 導 bridge.log 留診斷。教訓：測試方式要貼近真實情境，測試環境的「假象失敗」比真的壞掉更難發現。

• 06/07　里程碑（Reels app 大翻修）：腳本生成器這次做了七件事：分鏡重生機制（鎖住好的只重做勾選的）；定稿存檔＋唯讀分享頁（/s/[id]）＋/saved 已完成清單（可刪除、可升級入資料庫閉環）；挖出「永遠同一句 hook」真因（免費版結構化輸出獨立額度，拿掉 responseMimeType 解決）；修「一天只能生成一次」（503 誤報成每日額度用完，加自動重試＋分開報兩種 429）；模型自動切換（flash 過載退 lite）；額度分家（App/TG 讀靈感各自獨立 Gemini 專案金鑰）；重做 prompt 核心邏輯（Kim 退兩次才找到：致勝 DNA＝觀眾能帶走的價值爆點，不是 POV 情境包裝）。同一個 session 穿搭誌 app #1–#7 也全部完成上線（https://ame-soeur-journal.vercel.app）。貫穿整個 session 的核心教訓：「症狀」和「真因」幾乎從來不是同一件事——503/429/額度用完在表面上都長得像「叫不出 AI」，但一層層查才找到各自不同的根源。每個真因都要靠實際打 API 觀察回應才挖得出來，靠猜是猜不到的。

成果：從草稿到成品

現在這頁的主軸是產品：Hero 定位 → 成效數據 → 產品展示（Reels／Payment Boy／Agent 團隊，附真實截圖與 Demo）→ 為什麼是我來做 → Roadmap → 開發日誌（保留每個 agent 的誕生故事與設計演進）。從一份「開發日誌」，變成一個看得出「正在打造 AI 商業工具」的 Founder Notebook。

我學到什麼

規格小檔　建立：2026-06-02｜工具：Claude Code＋自寫的 build_journal.py（零依賴生成 HTML）｜部署：Cloudflare Pages｜最後更新：2026-06-07