Kim 的工作桌

hi, I'm Kim.

我是 Kim，âme soeur 這家電商服飾品牌的共同創辦人。

原本真的沒想過自己會開始做這些東西。一開始只是因為經營品牌之後，每天都有太多事情一直重複——訂貨、出貨、對帳、商品上架、廣告、SEO、Reels、客服。

那些工作其實不難，但每天一直重複，其實很消耗人。有時候真的會想：「明明有更重要的事要去做。」

後來我就開始一直冒出一個念頭：

這個一定要我自己做嗎？

然後就開始透過 Claude 試著設計各種工具。一開始也只是想說，先做一個小東西看看，結果做著做著，就越做越多了。

現在這裡比較像我的工作桌筆記，記錄那些工具怎麼長出來、怎麼卡住、怎麼重做，還有它們怎麼慢慢開始真的有用。

不是什麼正式 SaaS 官網，也不是工程師技術部落格。比較像是——一個品牌經營者，慢慢把自己的工作流程做成工具的過程。

正在做的東西看全部 →

Reels Script Generator

上線中

用過去有效的腳本，生成新的 Reels 腳本。Gemini API + 腳本資料庫 + 我的觀察。

Hook節奏CTA分鏡語氣PWA

→ 看看

Payment Boy v2

上線中

讓容易忘東忘西的同事，也能記得重要的事。提醒事項 × 遊戲化任務 × 營運管家。

提醒業績遊戲化PWAGBA像素風

→ 看看

TG遠端遙控

上線中

aKim_amesoeur_botbot · 線上

出貨 06/0414:32

出貨清單好了
區間訂單 8｜全現貨可出 3
amesoeur-ops-report.pages.dev ↗14:33

用 Telegram 在外打一句話，本機電腦自動跑訂貨/出貨/週報腳本，把連結回傳到手機。

Telegram BotLong-Poll本機橋接白名單無伺服器

看它怎麼運作 →

âme soeur 穿搭誌

審視期

公開頁已上線（POPEYE 風），每週行銷 agent 產草稿推到 app。表單式後台移除，自由畫布方向待定；子網域架構可行，Kim 先看幾週再決定。

Next.jsSupabasePOPEYE 風可編輯知識教學型 Reel

開啟穿搭誌 →

評論信任感工程

上線中

199 筆評論原本埋在頁底無人看。自建列表頁星等模組＋商品頁精選卡＋邀評自動化，讓信任感資產顯示出來。

Cyberbiz 版型工程評論 API星等模組邀評自動化排程

看完整故事 →

DeskMemo 桌面便利貼

上線中

給容易忘東忘西的同事做的桌面工具。Electron 跨平台，置頂視窗、關機攔截、無印筆記本風格，一天從 v0.1 做到 v0.9.1，第二天靠真實使用者回饋迭代到 v0.10.1（Mac 簽章、下班鬧鈴、開機自啟）。

ElectronWindowsMac置頂視窗關機攔截無印風

公開 repo →

âme soeur Agent 團隊

開發中

今天的 agent 狀態

訂貨專員工作中

出貨小幫手工作中

數據分析專家當機中

上架專員學習中

行銷企劃上線中

行銷小編睡著了

日誌官記錄中

TG遠端遙控上線中

一群正在學著幫我工作的數位同事。把重複的流程，慢慢 agent 化。

訂貨出貨週報上架文案

看每個 agent ↗

正在做的東西

都已經上線、自己每天在用。點連結可以直接玩玩看。

Reels Script Generator

上線中

會跟著品牌一起長大的 Reels 腳本資料庫

這個東西一開始其實只是因為：我發現我根本不知道什麼是「好的腳本」。

自己覺得很認真想的內容，數據不一定好。隨手拍的東西，反而可能大家更喜歡。這件事對我來說滿困惑的。

所以後來我開始回頭看那些數據比較好的內容。像是：

大家會停下來看的開頭
觀看時間比較長的影片
留言比較多的語氣
比較容易被分享的內容

然後把那些腳本留下來。

現在這個 generator 不是叫 AI 自己憑空亂生。它的做法是：把我平常累積的腳本範例，透過 Gemini API 分析之後，再生成新的腳本。

當初會特別串 Gemini，其實只是因為——它免費。（笑）

而且那些腳本範例會一直累積、一直更新，所以它更像一個會跟著品牌一起長大的腳本資料庫。我也還在邊做邊研究：大家到底會對什麼有感覺。

現在它會幫我：

生 Hook、排 Reels 節奏、生 CTA
拆分鏡、調整語氣
保留過去有效內容的感覺

我現在越來越覺得，好的內容不是突然想到的創意。更像是——慢慢觀察大家到底喜歡什麼之後，留下來的東西。

怎麼辦到的

它的底，是一個存在資料庫（Supabase）的腳本範例庫。要生成的時候，前端（Next.js）把我填的商品資訊和選的風格丟出去，後端把對應風格的有效範例一起餵給 Gemini API，請它照那些範例的開頭、節奏、CTA 結構生成新腳本——所以它是「參考真實有效的範例再寫」，不是憑空亂生。

為什麼會越用越準：

範例庫會一直累積、更新：我把數據好的腳本留進去，它的參考就跟著變強，等於跟著品牌一起長大。
生成有結構、不是一坨字：Hook、節奏、CTA、分鏡是分開生的，照我熟悉的格式產出。
打開網址就能用：整個介面部署在 Vercel，手機電腦都能開。

可以吃影片當養分（2026-06-05）

後來加了一條新路：Telegram 遙控橋現在可以接收手機螢幕錄影的 Reel，丟給 Gemini 分析後直接寫進腳本庫。

原本腳本庫靠手動輸入——要自己看影片、自己整理。現在的做法是手機錄完 Reel、轉寄給 bot，bot 把影片送去 Gemini 2.5 Flash，它真的「看完」整支影片，抓出口白、字卡、分鏡節奏，整理成腳本卡存進 Supabase。打「讀靈感」它就去處理整個收件匣。

這件事有趣的地方在於：caption 根本抓不到「過程腳本」——影片裡的口白、字卡、拍攝節奏，只有多模態才能抽出來。

做成可安裝 App（2026-06-05）

這個 generator 現在可以裝到手機主畫面，開起來全螢幕，不會有瀏覽器的地址欄和工具列干擾。

做法是在 Next.js 專案裡加了三個檔案：src/app/manifest.ts（standalone 模式、米色背景 #FAFAF8）、src/app/icon.tsx 和 src/app/apple-icon.tsx（用 next/og 的 ImageResponse 生成圖示，日系簡約米色「âme soeur」字樣）。踩過一個坑：在 Windows 本機 build 時，@vercel/og 的預渲染會報 Invalid URL（fileURLToPath），解法是兩個 icon 路由各加 export const runtime = 'edge'，跳過 Node.js 預渲染走 Edge runtime，之後就過了。本機 npm run build 驗證通過才推上去，push main 之後 Vercel 自動部署。

上線後實測：manifest.webmanifest 回 200、/apple-icon 回 200 image/png。iOS Safari 打開網址→加入主畫面→桌面一顆米色 âme soeur 圖示，點開全螢幕直接用。

用量計數與 fallback 修正（2026-06-05）

Kim 反映頁面出現「AI 額度暫時不足」。查了之後發現事情比較複雜：

這行文字其實是 AI 叫不出來時的 fallback 提示，本意是告知「正在用模板模式」，但措辭讓人以為帳戶沒錢。實際上 Gemini key 正常；真正的問題是免費版每日上限（約 250 次/天）被打到了——那把 key 同時被 web app、Telegram「讀靈感」流程，還有測試共用，撞上的機率比預期高。當天 Telegram 回報 5 支進 1 成功、其餘都收到 exceeded quota / billing 錯誤。

這次的修動有三個：

一是新增 /api/usage 端點，搭配 Supabase 裡一張 generation_usage 表，每次生成都記一筆（ai 或 template + 退模板的原因）。每日上限做成環境變數 GEMINI_DAILY_LIMIT，改數字不用改程式。

二是頁面頂部常駐顯示「今日已生成 X / 250 次」＋燈號（紅/黃/綠）。特別標明這是本站自行統計、非 Google 官方即時值——因為實測 Gemini 回應 header 根本不給 ratelimit 或 quota 欄位，沒辦法直接讀官方數字。

三是把退模板時的提示文案拆開：真的額度用完（quota 錯誤）顯示紅字「今天免費額度已用完，明天再試」；只是 Google 暫時忙碌（503 / overload）顯示「可稍後重試」。gemini.ts 現在會偵測這兩種不同原因、拋不同的 error code，前端再依狀況分別顯示。

學到的事：「餘額不足」很多時候不是帳戶的問題，是 fallback 文案寫得不夠精準。查清楚才能告訴使用者真正該做什麼。

語氣全面校正（2026-06-07）

這次改動的起點是：我發現生成出來的腳本，還是會出現「剁手必收」、「限時9折下單」這類語氣，跟品牌平時說話的方式完全不搭。

所以先去查 2026 IG 官方演算法的訊號排序。查到的結果讓我重新想了一次腳本的設計目標：

Sends（DM 分享）是觸及最強的訊號，權重是讚的 3–5 倍。
Watch time前 3 秒是生死線，留住超過 60% 觸及高出 5–10 倍。
Saves約是讚的 3 倍；Likes反而最弱。
Meta 官方明文：engagement bait（快+1、留言關鍵字才給連結、tag 朋友）會被主動降觸及。

這代表：那些「互動型」CTA 不只沒用，還有反效果。

改動集中在 prompts.ts：BRAND_VOICE 刪掉所有喊單語氣詞彙，emoji 大幅減量，hook 改成三型（共情痛點 / 數字定位 / 好奇缺口），CTA 改軟邀請分享＋儲存，且不 gate 連結（想看再說，不強迫）。scriptStyleDescriptions 和 JSON schema 欄位說明也同步更新。editor-notes 補「2026 IG 演算法訊號排序」整章。

自然流量片 / 廣告素材片雙模式（2026-06-07）

改完語氣之後，Kim 點出了一個很重要的問題：

「促銷片分享都是 0，但那些是廣告素材，本來就不是要人分享——是要投放用的。」

這句話讓我意識到：不同任務目標，腳本策略應該要不一樣。強迫促銷片也跑分享導向邏輯，只會兩邊都不對。

所以加了雙模式：

自然流量片（organic）：新品介紹 / 單品故事，溫柔不推銷，目標是破圈、分享、儲存，禁 engagement bait。
廣告素材片（ad）：促銷活動，可直接講優惠、導連結、CTA 轉換型，放寬 bait 限制（因為是付費投放，不需要演算法自然擴散）——但仍保留品牌底線，不用超殺 / 爆款 / 必買 / 剁手。

改了四個地方：types.ts 加 ReelMode 欄位、prompts.ts 加 AD_CREATIVE_OVERRIDE 並依模式分流 CTA 指引、GenerateForm.tsx 表單最上面加模式選擇器（CTA placeholder 隨模式變）、route 不動（缺 mode 自動當 organic，向下相容）。型別檢查通過，commit aa2e111，Vercel 自動部署。

已知小尾巴：AI 掛掉時的備援模板 template.ts 仍是舊語氣，這次沒動（觸發率低的退路，留著也不影響正常使用）。

分鏡重生：鎖住喜歡的，只重做不好的（2026-06-07）

一開始生成是全有或全無——不喜歡就整份重生，喜歡的幾格也跟著消失，又要多花一次 AI 額度。

加了「重生這格」機制：每個分鏡可以個別勾選，按「重新生成勾選的分鏡」只重做那幾格，鎖住的分鏡當作上下文餵給 AI，讓新生的格子跟整支腳本保持連貫。/api/regenerate + buildRegenerateScenesPrompt，每次吃 1 次 AI 額度，不再整份重來。

定稿存檔＋分享頁（2026-06-07）

以前定稿了也只是關掉頁面，沒地方存、沒辦法給同事看。

加了「完成」按鈕：呼叫 /api/share，把腳本存進 Supabase Storage（app-meta/scripts/{id}.json＋_index.json 索引），回傳唯讀分享頁 /s/[id]——不用登入、手機可看、同事免裝任何東西。/saved 清單頁列出所有已完成腳本，每筆有「刪除」和「存進資料庫（升級成 is_recommended 參考範例）」按鈕，形成閉環：生成 → 留好的 → 升級入庫 → 下次 AI 生得更準。

分享頁走 server component，服務器端用 service key 讀 Storage 再渲染，bucket 不需開公開讀。

挖出「永遠同一句 hook」的真因（2026-06-07）

Kim 反映每次生成 hook 都是「生活已經夠累了，選衣服更不該費力」——感覺 AI 在重複。

我沒有信這個「症狀」，先實際測：純文字請求 200 OK，加上 responseMimeType: 'application/json' 就穩定回 429 RESOURCE_EXHAUSTED（連續三次對照實驗）。

真因是：Gemini 免費版「結構化輸出」是獨立額度，很小、很容易爆——額度一爆 AI 就退到罐頭模板，每次看到一樣的 hook 不是 AI 在重複，而是 app 一直掉回備援模板。

解法：拿掉 responseMimeType，改純文字模式，prompt 要求「只回 JSON、不要 markdown 框」，route 既有的 regex 自己解析。順手移除罐頭模板 fallback（Kim 說：每次一樣根本沒必要），AI 失敗改回老實錯誤訊息，不塞假腳本。

修「一天只能生成一次」（2026-06-07）

症狀：試幾次就說額度用完，隔天才能用。

查了之後才知道不是每日額度，是 Google 端模型過載——gemini-2.5-flash 在 free tier 高峰期常回 503「This model is currently experiencing high demand」。但程式把 503 也歸成 SERVICE_BUSY，訊息又寫成「每分鐘上限」，Kim 誤以為被鎖整天。

再查到另一個坑：所有 429 都被判成「今日額度用完」，但其實 RPM（每分鐘限制）和 RPD（每日限制）是兩回事，前者等 60 秒就好，後者才真的要等明天。修法是從 error.details 的 quotaId 判斷是哪種，分開報不同訊息，只有真·每日才設 quota 旗標。同時加了自動重試：503/RATE_LIMIT 最多 3 次、間隔 1.5s→2.5s，讓 app 自己扛過短暫過載。

模型自動切換（2026-06-07）

實測 gemini-2.5-flash 整段 503 的時候，gemini-2.5-flash-lite 是 200。

加了多模型策略：GEMINI_MODELS=['gemini-2.5-flash','gemini-2.5-flash-lite']，每個模型內重試一次，不行就自動換下一個。flash 有空優先用（品質較高），過載就退 lite（上限更寬），品質優先又生得出來。

重做腳本產出邏輯（2026-06-07）

這個改動是這次最重要的，也是花最多來回的。

Kim 第一次退稿：「跟我自己拍沒什麼差。」輸出都是站白牆、特寫布料、轉身——型錄式展示加念規格，跟她本能就會拍的東西一樣。

第二次退稿：「有 POV 包裝了，但還是型錄包劇情，沒有觀眾可以帶走的東西。」

我去撈她資料庫裡 30 筆 is_recommended 的高績效範例，看欄位 structure_breakdown、emotion_design、reusable_points。發現致勝 DNA 不是拍攝風格，而是每支都有一個觀眾能帶走的「價值爆點」：可複製的小技巧、意外冷知識、Before-After、破解常見錯誤（「褲子太鬆如何用褲環收」「牛仔褲摺法影響顏色」「衣角往後抓改變上半身比例」）。

真正的問題是 referencedScriptsContext 只餵了範例的一行 hook＋主題，最精華的三個欄位根本沒進 prompt。

修法：prompt 加「創意切角（concept）」——要求先想一個觀眾能帶走的價值爆點（可複製技巧、Before-After、冷知識、破解常見錯誤），整支腳本為它服務，POV/情境只能是包裝殼，裡面一定要有爆點，明文禁「穿上轉一圈說好舒服」這種沒價值的型錄腳本。範例改整包精華餵進去，要求「學手法、不抄內容」。輸出加 concept 欄，生成頁和分享頁都顯示。

同時加了品類防呆：prompt 加「嚴格商品限制，只能講本商品品類」（曾把亞麻長褲講成襯衫，因高績效範例剛好是別品項）。溫度從 0.7 調到 0.8（多樣性和不偏離品類的平衡點，0.9 會漂移）。

實測：「寬褲像睡褲？抽繩一拉褲管一捲→Before/After 比例拉高」——對到範例水準。

Next.js 14.2ReactSupabaseGemini APIVercelPWA

Live Demo ↗

看它的實際設定檔（skill md）amesoeur-reels-app-SKILL.md

---
name: amesoeur-reels-app
description: >
  âme soeur Reels 腳本生成器 App 的專屬開發助理技能。
  當 Kim 要做任何與這個 App 相關的工作時，立即啟用此技能，包括但不限於：
  匯入競品 Reels 腳本到資料庫、修改 App 功能或 UI、部署新版本到 Vercel、
  翻譯日文/英文腳本為中文、新增腳本風格、修 bug、調整 AI 提示詞、
  更新資料庫內容、或任何提到「reels app」「腳本app」「ame soeur app」的需求。
---

# âme soeur Reels App 開發助理

你是這個 App 的專屬開發助理，熟知整個系統的架構、資料庫 schema、部署流程和 AI 整合。
每次工作開始時，先讀取 `references/project-context.md` 了解完整背景。

## 快速參考

| 項目 | 內容 |
|------|------|
| App 網址 | https://ame-soeur-reels.vercel.app |
| GitHub | https://github.com/hsukim-cpu/ame-soeur-reels |
| 本機路徑 | `C:\Users\User\Desktop\Claude-workspace\ame-soeur-reels` |
| Claude 內路徑 | `/sessions/relaxed-kind-noether/mnt/Claude-workspace/ame-soeur-reels` |
| Supabase URL | `https://cywohrudgcaynvjsbmgb.supabase.co` |
| AI 模型 | Gemini 2.5 Flash（免費）+ Template fallback |

## 工作流程

### 0. 從橋接文件自動帶入新品（品牌小編協作入口）

當 Kim 說「用橋接文件產出本週 Reels 腳本」或品牌小編觸發時，執行：

1. 讀取橋接文件：
   `C:\Users\User\Desktop\Claude-workspace\amesoeur\weekly-brief\weekly-new-arrivals.json`

2. 將每件新品欄位對應為 `/api/generate` 所需參數：

| 橋接文件欄位 | API 參數 | 說明 |
|------------|---------|------|
| `title` | `productName` | 直接使用 |
| `category` | `productType` | 直接使用 |
| `key_features[0] + [1]` | `coreSelling` | 前兩項合併為一句，用「、」連接 |
| `target_audience` | `targetAudience` | 直接使用 |
| — | `scriptStyle` | 預設 `hack`，Kim 可指定其他風格 |
| — | `ctaGoal` | 預設 `官網下單`，Kim 可調整 |

3. 逐件輸出 Reels 腳本（呼叫 `/api/generate`，或輸出參數包讓 Kim 貼入 App）

4. 腳本產出後，詢問 Kim 是否要存入 Supabase 資料庫

**橋接文件不存在時**：
> 「找不到本週橋接文件，請先請品牌分析師執行本週分析，或直接提供商品資訊。」

---

### 1. 匯入競品 Reels 腳本

當 Kim 貼上 Instagram reel URL，執行以下步驟：

1. 用瀏覽器開啟 `https://www.instagram.com/p/{POST_ID}/`（注意用 `/p/` 格式，不是 `/reel/`）
2. 擷取：品牌名稱、caption 內文、讚數（當作 views_count）、內容主題
3. 分析腳本類型（hack/pain/new/knowledge/fomo）
4. 翻譯並改寫成繁體中文（參考 references/script-writing-guide.md）
5. 用 Supabase REST API 寫入資料庫（參考 references/database-schema.md）

**Supabase 寫入範例（從 app 網域執行 fetch）：**
```javascript
// 必須在 ame-soeur-reels.vercel.app 頁面執行，才不會有 CORS 問題
const res = await fetch('https://cywohrudgcaynvjsbmgb.supabase.co/rest/v1/reels_script_library', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'apikey': SERVICE_KEY,
    'Authorization': `Bearer ${SERVICE_KEY}`,
    'Prefer': 'return=representation'
  },
  body: JSON.stringify([...scripts])
});
```
SERVICE_KEY 從 `.env.local` 的 `SUPABASE_SERVICE_ROLE_KEY` 取得。

### 4. 從橋接文件批量生成本週新品腳本

當 Kim 說「幫我生成本週新品 Reels 腳本」時，執行以下流程：

1. **讀取橋接文件**
   `C:\Users\User\Desktop\Claude-workspace\amesoeur\weekly-brief\weekly-new-arrivals.json`

2. **逐件帶入生成參數**，對每件新品自動組裝 `/api/generate` 所需欄位：

```javascript
// 從橋接文件的每個 new_arrival 項目映射參數
const payload = {
  productName: item.title,
  productType: item.category,
  coreSelling: item.key_features.join('、'),
  targetAudience: item.target_audience,
  scriptStyle: 'hack',    // 預設風格，Kim 可指定覆蓋
  ctaGoal: '留言取連結',  // 預設 CTA，Kim 可指定覆蓋
  additionalInfo: `定價 ${item.compare_at}，新品9折 ${item.sale_price}`
};
```

3. **依序呼叫** `POST https://ame-soeur-reels.vercel.app/api/generate`，每件商品一次

4. **輸出腳本摘要給 Kim**，格式如下：
```
本週新品 Reels 腳本｜YYYY-WXX
━━━━━━━━━━━━━━━━━━
【商品名】
Hook：...
賣點：...
CTA：...
風格：hack / AI生成
━━━━━━━━━━━━━━━━━━
```

5. **確認是否寫入 Supabase**：生成完畢後問 Kim「要存入腳本庫嗎？」確認後再寫入

⚠️ 如果橋接文件不存在，告知 Kim：「找不到本週新品資料，請先執行品牌分析師取得新品清單。」

**重要：Claude 這邊 git push 被 proxy 擋住，每次改完程式碼後要請 Kim 自行 push。**

流程：
1. 直接編輯 `/sessions/relaxed-kind-noether/mnt/Claude-workspace/ame-soeur-reels/` 內的檔案
2. 告訴 Kim 在 PowerShell 執行：
   ```powershell
   cd C:\Users\User\Desktop\Claude-workspace\ame-soeur-reels
   git add <檔案>
   git commit -m "描述"
   git push
   ```
3. Vercel 會自動偵測 GitHub push 並重新部署（約 1-2 分鐘）
4. 部署完成後到 https://ame-soeur-reels.vercel.app 驗證

**HEAD.lock 問題**：如果 git commit 失敗提示 HEAD.lock exists，請 Kim 先執行：
```powershell
Remove-Item "C:\Users\User\Desktop\Claude-workspace\ame-soeur-reels\.git\HEAD.lock" -Force
```

### 3. 驗證 API 運作

從 app 頁面用瀏覽器 JS 測試 `/api/generate`：
```javascript
(async () => {
  const res = await fetch('/api/generate', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      productName: '測試商品', productType: '上衣',
      coreSelling: '測試賣點', targetAudience: '小隻女生',
      scriptStyle: 'hack', ctaGoal: '留言取連結', additionalInfo: ''
    })
  });
  const data = await res.json();
  window._result = { status: res.status, mode: data.mode, hook: data.script?.hook };
})();
```

## 關鍵檔案位置

```
src/
├── app/
│   ├── api/generate/route.ts    # AI 生成 API（Gemini + template fallback）
│   ├── generate/page.tsx        # 生成腳本頁面
│   └── library/                 # 資料庫瀏覽頁面
├── components/generate/
│   ├── GenerateForm.tsx         # 表單元件
│   └── ScriptResult.tsx         # 結果顯示（含 AI/模板 badge）
├── lib/
│   ├── ai/
│   │   ├── gemini.ts            # Gemini 2.5 Flash provider
│   │   ├── template.ts          # Template fallback 生成邏輯
│   │   └── index.ts             # AI provider factory
│   ├── types.ts                 # TypeScript 型別定義
│   ├── prompts.ts               # AI prompt 建構（含品牌語氣）
│   └── supabase.ts              # Supabase client
```

## 環境變數（Vercel 上已設定）

| 變數名稱 | 用途 |
|---------|------|
| `GEMINI_API_KEY` | Gemini 2.5 Flash API key |
| `AI_PROVIDER` | `gemini`（預設） |
| `NEXT_PUBLIC_SUPABASE_URL` | Supabase 資料庫網址 |
| `NEXT_PUBLIC_SUPABASE_ANON_KEY` | 前端讀取用 key |
| `SUPABASE_SERVICE_ROLE_KEY` | 後端寫入用 key |

## 🔗 與其他 Skills 的協作關係

| Skills | 協作方式 |
|--------|---------|
| amesoeur-analyst | 分析師產出 `weekly-new-arrivals.json`，Reels App 讀取自動帶入 |
| amesoeur-copywriter | 小編負責 Threads / IG Caption，Reels 腳本由本 App（Gemini）負責 |

---

## 注意事項

- **免費額度**：Gemini 2.5 Flash 有每日/每分鐘限制，超過自動走模板模式
- **模板模式**：AI 失敗時自動 fallback，前端顯示橘色「📋 模板生成」badge
- **Instagram 抓取**：必須用 `/p/{id}/` 格式，`/reel/` 會導向動態牆
- **CORS**：Supabase fetch 必須從 `ame-soeur-reels.vercel.app` 頁面執行，不能從 Instagram 頁面

## 深入參考

需要更詳細的資訊時，讀取：
- `references/database-schema.md` — 資料庫完整欄位說明與腳本風格定義
- `references/script-writing-guide.md` — 腳本翻譯與撰寫規範（品牌語氣、hook 公式）

---

*Skill version: 1.1 | 建立日期: 原版 | 最後更新: 2026-04-06 | 適用品牌: âme soeur*

Payment Boy v2

上線中

把「很無聊但很重要的事」變得有趣一點的營運管家

這個一開始只是因為我的同事很容易忘東忘西。她的口頭禪就是：「啊我忘了！」

品牌營運有很多事情其實不難，只是數量很多——廣告費、勞健保、稅金、運費、廠商款項、業績目標……漏掉一個就很嚴重。

所以那時候我一直在想：到底要怎麼讓她不要再忘記？！

後來慢慢把它做成現在這個 App。現在它會提醒我們：

哪些東西快到期
這個月還有什麼沒付
業績離目標還差多少
哪些事情該處理了

它已經有點像半個營運管家。

而且我故意把它做成 GBA 像素風，設計得有點像闖關遊戲：每次記得打勾就會升級，每次登記業績，就可以打敗介面的壞蛋。

營運裡有很多事情很枯燥，所以我一直很想把那些「很無聊但又很重要的事」，變得稍微有趣一點。

怎麼辦到的

資料存在 Supabase，每一筆款項都有到期日。它的核心是主動提醒——用 Web Push 在到期前推播到手機，不用人記、不用每天去翻清單。

它怎麼幫我們不漏掉：

到期日驅動的提醒：時間到它自己推播，靠的是排程不是記性。
業績自動對目標：登記後累加、跟目標比，直接算出還差多少。
已裝到手機當 App 在用：整包做成 PWA，可以放到手機主畫面，點開全螢幕，不會有瀏覽器工具列，用起來跟 App 一樣。
刻意遊戲化：打勾升級、登記業績打敗介面壞蛋——把枯燥的事包成闖關，比較有動力持續做。

技術上用 React 18＋Vite，部署在 Vercel，資料存 Supabase 即時同步。多人共用——我跟同事各自登入，資料是同一份。

為什麼做成 GBA 像素風

這一點我自己覺得很重要。

財務、到期款項、業績……這些東西本身很無趣，但又不能不管。我一直很想做一件事：把這種「很重要但讓人提不起勁的事」，包得讓人多少想點開來看。

GBA 像素風就是這個答案。復古、小巧、有點遊戲感——打勾會有過關的感覺，登記業績像是在打怪，比看一張純數字的試算表有趣一點點。

沒有把它做得很複雜的理由：功能夠用就好，主要的精力要放在讓它「每天都想開」這件事上。

React 18ViteSupabaseWeb PushPWAVercel

Live Demo ↗

看它的實際設定檔（skill md）payment-boy-skill-SKILL.md

---
name: payment-boy
description: >
  Project context skill for Payment Boy — a GBA-themed payment & revenue management PWA.
  Use this skill whenever the user mentions "payment-boy", "付款 app", "payment boy",
  "付款管理", or wants to continue development of this project. Also trigger when the
  user says things like "繼續我們的專案", "繼續作業", or "接著做" in the context of
  app development without specifying which project — this is the active project.
  This skill provides all credentials, file paths, DB schema, architecture decisions,
  and current sprint status so development can resume instantly in any new session.
---

# Payment Boy — 專案 Skill

## 立即做的事（每次開新 session 時）

1. 用 Glob 找專案路徑：搜尋 `**/payment-boy/PROGRESS.md`，取得實際路徑
2. 讀取 PROGRESS.md 取得最新進度
3. 確認 git 狀態：`git -C <找到的 payment-boy 路徑> log --oneline -5`
4. 直接繼續 PROGRESS.md 裡「下一批待辦」的第一項，不用問

**專案位置**（Windows）：`Desktop\Claude-workspace\projects\payment-boy\`

---

## 專案概覽

**Payment Boy** 是一個給 ame soeur 品牌使用的內部付款與業績管理 App。
- GBA（Game Boy Advance）風格 UI，復古像素美學
- 多人共用，資料透過 Supabase 即時同步
- PWA，可安裝到手機主畫面
- 背景推播通知（每日早上 09:00 台灣時間提醒到期任務）

---

## 技術棧

| 層 | 技術 |
|---|---|
| 前端 | React 18 + Vite，**單一檔案** `src/App.jsx` |
| 樣式 | Inline styles，Noto Sans TC 字體，SVG pixel art |
| 後端 | Supabase（PostgreSQL + Realtime + Edge Functions） |
| 推播 | Web Push API + VAPID + Service Worker |
| 部署 | Vercel（自動從 GitHub main branch 部署） |
| PWA | vite-plugin-pwa，generateSW mode |

---

## 關鍵路徑

```
專案根目錄：/sessions/loving-pensive-hopper/mnt/Desktop/payment-boy/
主要程式碼：src/App.jsx          ← 幾乎所有 React 程式碼都在這
Service SW：public/sw.js         ← Web Push 事件處理
設定檔：    vite.config.js        ← PWA manifest 設定
進度記錄：  PROGRESS.md          ← 每次 session 開始先讀這個
Edge Func：supabase/functions/daily-notify/index.ts
```

---

## 連線資訊

```
GitHub:      hsukim-cpu/payment-boy
Vercel:      https://payment-boy.vercel.app
Supabase:    https://cywohrudgcaynvjsbmgb.supabase.co
Project ref: cywohrudgcaynvjsbmgb

Anon key (sb_publishable):
  sb_publishable_nJDgmPSGJXbiW7JeEya8Uw_yRlTdSdN

Service role key (JWT):
  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImN5d29ocnVkZ2NheW52anNibWdiIiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTc3MzkyMjM5NiwiZXhwIjoyMDg5NDk4Mzk2fQ.VPwHuHIKluDpUEtD54GYWyvlOEJ8dF-L2yu2q579RGA

VAPID Public Key:
  BEjK3aBqp1bhFaCc1pdFwzfKmsQzhxb8A8X2zpAeKQ1tlA3KZcMbEHt5LPwl2rcV9GYWjzNLrbPCATPCPmKjpyY
VAPID Private Key: 存於 Supabase Secrets（VAPID_PRIVATE_KEY）
```

---

## 資料庫 Schema

```sql
-- 付款任務
tasks (id TEXT PK, label TEXT, emoji TEXT, day INT, color TEXT, cat TEXT)

-- 每月付款記錄（checkbox 狀態）
payment_records (task_id TEXT, month_key TEXT, is_done BOOL, amount NUMERIC, note TEXT)
  PK: (task_id, month_key)
  upsert: onConflict="task_id,month_key"

-- 業績日曆
revenue_records (date DATE PK, amount NUMERIC, note TEXT, updated_at TIMESTAMPTZ)
  upsert: onConflict="date"
  查詢方式: .gte("date", mk+"-01").lt("date", nextMonthMk+"-01")  ← 不能用 LIKE，date 型別

-- 月目標
monthly_targets (month_key TEXT PK, target_amount NUMERIC, updated_at TIMESTAMPTZ)

-- 英雄進度
hero_progress (id INT PK=1, wins INT, updated_at TIMESTAMPTZ)

-- 月達成記錄
monthly_wins (month_key TEXT PK, counted_at TIMESTAMPTZ)

-- Push 訂閱
push_subscriptions (id UUID PK, endpoint TEXT UNIQUE, p256dh TEXT, auth TEXT, updated_at TIMESTAMPTZ)
```

---

## Git 工作流程（重要限制）

VM **無法** push 到 GitHub（網路受限）。工作流程：

1. Claude 在 VM 做修改 → `git add` → `git commit`
2. 告訴 Kim：「請在 PowerShell 執行 `git push origin main`」
3. Kim 在 `C:\Users\User\Desktop\payment-boy>` 目錄下執行
4. Vercel 自動偵測 GitHub push → 重新部署（約 1 分鐘）

**常見問題**：Kim 有時會在錯誤目錄執行，或把多個指令黏在一起。
遇到 "not a git repository" → 提醒先 `cd Desktop\payment-boy`。

---

## Edge Function — daily-notify

- 部署狀態：ACTIVE (version 3)
- cron：`0 1 * * *` UTC = 台灣 09:00
- 每天查 tasks 中 `day = 今日日期` 的任務，發 Web Push 到所有 push_subscriptions
- 已有 Kim 的 iPhone Safari 訂閱（web.push.apple.com）

---

## UI 架構重點

```
App.jsx 結構（單檔）：
  const VAPID_PUBLIC_KEY = import.meta.env.VITE_VAPID_PUBLIC_KEY
  colors: S_BG, S_FG, S_MID, S_DIM, S_SEL, S_LINE, S_GOOD, S_WARN, S_TODAY

  Components（in-file）：
    PX          → 像素字體 span
    PixelIcon   → SVG 付款圖示（money/ad/tax/truck/shield/pill）
    PixelHero   → 動畫英雄 SVG
    PixelDragon → 動畫火龍 SVG
    PixelBarChart → 業績趨勢長條圖
    SalesStats  → 統計小卡（有業績天數/日均/最高/剩餘）
    BattleBar   → 英雄 vs 火龍 HP 進度條
    HistoryModal → 13 個月歷史業績
    DayModal    → 業績日期輸入
    SearchModal → 業績搜尋
    EditDayModal → 修改任務到期日
    NotifBanner → 推播授權提示條

  Page 0 = PayPage（付款清單）
  Page 1 = SalesPage（業績日曆）
```

---

## 驗證方式

測試 Supabase 連線是否正常（從瀏覽器 console 或 Chrome tool）：
```javascript
fetch("https://cywohrudgcaynvjsbmgb.supabase.co/rest/v1/payment_records?select=task_id,month_key,is_done&order=month_key.desc&limit=5", {
  headers: {
    "apikey": "sb_publishable_nJDgmPSGJXbiW7JeEya8Uw_yRlTdSdN",
    "Authorization": "Bearer sb_publishable_nJDgmPSGJXbiW7JeEya8Uw_yRlTdSdN"
  }
}).then(r=>r.json()).then(console.log)
```

---

## 使用 Supabase Management API（需 dashboard auth token）

當需要執行 SQL 或操作 Edge Functions：
```javascript
// 在 supabase.com dashboard 頁面執行
const token = JSON.parse(localStorage.getItem('supabase.dashboard.auth.token')).access_token;
fetch("https://api.supabase.com/v1/projects/cywohrudgcaynvjsbmgb/database/query", {
  method: "POST",
  headers: { "Authorization": "Bearer " + token, "Content-Type": "application/json" },
  body: JSON.stringify({ query: "SELECT ..." })
}).then(r=>r.json()).then(console.log)
```

---

## 開發指引

- 所有 UI 修改都在 `src/App.jsx`，保持單檔架構
- commit message 用英文（feat/fix/docs/style/refactor）
- 每次 commit 後提醒 Kim push
- Vercel 環境變數已設：VITE_SUPABASE_URL、VITE_SUPABASE_ANON_KEY、VITE_VAPID_PUBLIC_KEY
- SW 快取問題：清除方式 → `navigator.serviceWorker.getRegistrations().then(regs=>regs.forEach(r=>r.unregister()))` + `caches.keys().then(keys=>keys.forEach(k=>caches.delete(k)))` 後重新載入

TG遠端遙控

v1 上線

人在外面，電腦自己跑

aKim_amesoeur_botbot · 線上

出貨 06/0414:32

收到，整理出貨清單中…14:32

出貨清單好了
區間訂單 8｜全現貨可出 3
amesoeur-ops-report.pages.dev ↗14:33

這個東西的起點很簡單：我不想每次都要坐在電腦前才能查出貨清單。

有時候正在外面，想確認一下今天有幾張訂單可以出，或是跟廠商訂貨前先看一下預購數量，一定要回家開電腦才能看，這件事一直讓我覺得很麻煩。

更根本的問題是：那些腳本不能跑在雲端。因為 Cyberbiz 後台的 session 是綁 IP 的，用雲端 IP 去打就會被擋。所以它一定要在我自己的電腦上跑，才能撈到後台的數據。

所以需要的，其實不是把腳本搬到雲端——而是讓我在外面，也能叫家裡的電腦去跑。

想了一下，Telegram bot 剛好可以解這件事：bot 可以讓本機的 Python 直接用 long-poll 的方式監聽訊息，不用架公開伺服器、不用 webhook。只要電腦開著、腳本在跑，我在外面打一句話，它就會動。

怎麼辦到的

telegram_bridge.py 在本機常駐，用 Telegram Bot API 的 long-poll 模式等我發訊息。

收到訊息之後，它做三件事：

確認身分：只回應白名單 chat id（第一次綁定自動寫進 .env，之後就只認這個 id）。
比對指令：用 regex 驗過日期格式之後，把指令分派給對應腳本。白名單是：出貨 → ops_shipping_list.py、訂貨 → ops_order_list.py、週報 → weekly_report.py。不在清單裡的不接受，防止注入。
回傳結果：從腳本的 stdout 抓 LINK: 開頭的那行（pages.dev 連結）＋含「｜」的統計摘要，回給我手機。

安全設計：bot token 存在本機 .env（已 git ignore），腳本用 PYTHONUNBUFFERED=1 讓輸出即時顯示，start_telegram_bridge.bat 雙擊啟動。

v1 三個指令（出貨/訂貨/週報）目前都是唯讀，所以還沒有 gate。之後如果加入「真的標記出貨」這種不可逆動作，會在同一個 Telegram 對話回問「這步要確認，回確認放行」——她回「確認/好」才執行。技術上 v1 就做得到，只需要多一個「待確認動作」狀態。

v2 方向：接 Claude API，讓它變成「手機上的我」，可以自然對話、看圖、想 Reels 腳本，不用背指令。

讓它開機自己上線

v1 上線之後，有一個問題：每次要用，都要先手動開腳本。我不在電腦前的時候，傳了指令但橋沒在跑——訊息就消失在 Telegram 佇列裡了。

這件事本身是個很好的教訓：「電腦開著」跟「服務在跑」不是同一件事。

所以下一步就是讓它開機自動啟動。聽起來簡單，但踩了四個坑才搞定：

坑一：python 根本跑不動。Windows 商店版 python 是一個「別名」（應用程式執行別名），在非互動的情境（工作排程器、開機腳本）根本叫不起來。解法是改用真實路徑，直接指向 pythoncore-3.14-64 資料夾裡的 python.exe（路徑升級後記得更新）。

坑二：工作排程器要管理員。試了 schtasks /create 設定使用者登入時執行，結果非互動情境下提權被系統拒絕。改成用「開機啟動資料夾」放捷徑，這個不需要任何額外權限、Windows 原生支援。

坑三：VBScript 無法直接跑 .bat。WScript.Shell.Run 是走 CreateProcess，不認識 .bat 這種關聯格式，要用 cmd /c 包起來。試了一圈之後，乾脆跳過 .bat 這層，直接用 pythonw.exe（無視窗的版本）跑 python 腳本。

坑四：從 Git Bash 巢狀測 Windows 啟動是假象。在 Git Bash 裡用 cscript / wscript / start 這些東西行為很不一樣，測起來「壞了」，但實際上是測試情境的問題，不是設定本身錯。把驗證方式貼近真實情境——直接重開機、看 bridge.log 有沒有 [boot] 那行——才算真的測到了。

最終加進腳本的改動很小：開頭幾行把 sys.stdout 和 sys.stderr 都導到 bridge.log（pythonw.exe 底下 print 不會有地方輸出，不接 log 就完全無從診斷），用開機資料夾的捷徑啟動，設工作目錄在 scripts。這樣電腦一開機，橋就在跑，不需要我動任何東西。

還有一個小問題待確認：她第一次測試的日期範圍指令被處理成單日，懷疑她打的破折號是全形或特殊字元（程式只認半形 - 和 /），等她再傳一次、對著 log 確認實際收到的字串再說。

PythonTelegram Bot APIrequests.env

本機工具

âme soeur 穿搭誌

審視期

每週一篇穿搭知識文章，累積到同一個空間，Kim 看了再決定怎麼編輯

這個 app 的起點，其實是一個更小的問題：我需要每週一篇穿搭知識文章，給我拍知識教學型 Reel。

最初做成每週部署的靜態 HTML（amesoeur-styling.pages.dev），能看、不能改。

加入 POPEYE 雜誌參考

後來 Kim 給了三張日本雜誌 POPEYE 的版面當參考。那種感覺很具體：照片格狀卡、手寫感標題、英文 script 小標、密實小字，整頁有呼吸感又資訊量足。

做了 POPEYE 風範例（用後台真實商品照），Kim 很喜歡。基準檔就是 amesoeur-analyst/reports/styling/2026-W23-材質誌-POPEYE風.html。

嘗試 Canva 路線，走到死路

想試試看 Canva 能不能讓 Kim 直接在裡面改：用 import-design-from-url 支援 HTML/PDF 匯入。

結果：

HTML 抓取失敗（Canva 沒讀到任何內容）
PDF 匯入進去，版面看起來還可以——但文字被壓平成圖層，根本改不了，而且只有 1 頁

用 get-design-content API 驗證：richtexts 欄位抓不到，確認不可編。Canva 路線放棄。

Kim 補充

確立方向：自建部落格 app

Kim 說的很清楚：「我要的是一個自己能改文字、換照片的網頁。」

不用 Notion（要保留 POPEYE 版面），拍板自建。技術決策是沿用 reels app 那套（Next.js + Supabase），重用既有 Supabase 專案，新開資料夾 ame-soeur-journal。

這也讓它跟 amesoeur-marketing-agent 成為一組：agent 每週一產草稿入庫，Kim 進後台微調發佈。

怎麼辦到的

公開頁走 POPEYE 排版：PostView.tsx 吃資料庫的 styling_posts 表，組成格狀照片卡、手寫感大標題、英文 script 小標、段落正文的版面。SVG 線稿組件 Illustration.tsx 提供三種抽象插圖（texture/fiber/layering）當裝飾元素，隨文章主題搭配。

資料存 Supabase：styling_posts 資料表（Kim 在後台跑 SQL 自己建成功）、圖片桶 journal-photos（程式建）。

首頁列文章卡、/p/[slug] 單篇頁，npm run build 已通過。

為什麼可靠：

Supabase 同一個專案：reels app 已驗過，連線穩定，不用新開帳號
TypeScript 型別嚴謹：lib/types.ts 定型、build 時就抓錯，不用跑了才發現欄位對不上
靜態生成 + ISR：公開頁快、不額外燒費用

編輯後台（2026-06-07）

Kim 說的很清楚：「我要的是自己能改文字、換照片的。」

後台做成單一密碼擋（EDIT_PASSWORD env var，httpOnly cookie 維持登入），不串第三方帳號系統，Kim 記一個密碼就夠。/edit 清單頁可新增文章、切換發佈／草稿、刪除；/edit/[id] 單篇表單有所有欄位（標題、英文小標、各段落文字）和照片上傳（Supabase Storage journal-photos bucket，程式建）。照片上傳走 API route 用 service role key 直接寫 Storage，不需要額外設 RLS。

端到端驗過：登入 → 新增 → 填欄位 → 上傳照片 → 發佈 → 公開頁看到新文章，整條通。

第一篇入庫（2026-06-07）

scripts/seed-w23.mjs 把 W23「夏の素材手帖」草稿寫進 Supabase，6 張商品照上傳 Storage，部署 Vercel。公開站 https://ame-soeur-journal.vercel.app 上線，首頁、登入、RLS 讀寫、照片顯示全部 200 驗過。

每週流程走 scripts/insert-draft.mjs（JSON → 上傳照片 → 草稿 upsert → 回 /edit 連結），行銷 agent 每週一產草稿 JSON，Kim 進後台微調再按發佈，agent 不代發。

W23 文章目前是草稿，Kim 潤飾＋換照片後自己按發佈。

編輯方向轉向（2026-06-07 深夜）

表單式後台做完的同一天，Kim 看了另一個「自由拖拉畫布」的 demo，決定不要表單路線——把整包表單編輯後台移到 .trash（可復原），app 公開頁維持上線，但編輯機制待定。

自由畫布若要繼續做，建議避開 RWD 坑，直接以手機直式介面為主要設計尺寸。

試 Cyberbiz 官網部落格，走到死路

表單後台轉向的同時，也試了另一條路：把含自訂樣式的 HTML 貼進 Cyberbiz 的「部落格管理→HTML 編輯器」，看能不能在官網網域直接發 POPEYE 風文章。

結果：存檔之後抓前台原始碼，所有 <style>、字型連結、class、行內 style 全部被平台清光，只剩純文字和圖片。

結論：Cyberbiz 站內無法保留日雜風排版，這條路不可行。

子網域架構可行，Kim 先擱著

查了一下 amesoeur.co 的 DNS 架構：

DNS 管理在 GoDaddy
www CNAME 指向 Cyberbiz（不能動）
子網域（如 style.amesoeur.co）可以單獨加 CNAME 指向 Vercel

請教三方 AI（GPT/Gemini/我）對子網域 vs 官網同域的 SEO 影響：三方共識是子網域影響小、app 是真正 HTML 結構反而好讓 Google 爬。

Kim 的決定：先擱著，實際看幾週成品、覺得有必要再設子網域。在那之前就用 Vercel 預設網址（ame-soeur-journal.vercel.app）繼續累積文章。

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

原本每週用新的 HTML 部署、蓋掉上一篇。調整成累積到同一審視空間：insert-draft.mjs 每週把草稿 upsert 進 app（app 首頁列出所有文章），Kim 在 app 裡看了再決定要不要發佈。W23 第一篇已用這個流程發進空間。

同時修了兩個 TG 推播 bug：

新品判斷邏輯修正：原本只抓「已上架+9折」，改成「最新排序前幾個且有9折」，不再卡上架狀態，確保真的是當週剛上的新品。
網址被全形括號吃進去的 bug：TG 推播格式改成網址各自獨立一行、結尾不接符號，這樣 Telegram 的連結解析才不會把括號吃進去變成壞連結。

每篇插圖升級成 AI 生圖（2026-06-15）

起點是 Kim 的一句：「看起來跟上週一樣。」

原本每篇知識段落的插圖都是 Illustration.tsx 裡寫死的三種 SVG 線稿（texture / fiber / layering），畫法固定、週週一樣。Kim 不滿意：「你美學的技能不只這樣吧」「你生成圖的極限只能到這裡嗎」。

先把 SVG 線稿重畫成日雜編輯風；Kim 要「每篇專屬」；架構要能讓每篇帶自己的插圖——改 lib/types.ts 的 Section 加 illo_svg 欄位，PostView.tsx 優先用 dangerouslySetInnerHTML 渲染，illo_key 退成備用；insert-draft.mjs 把 sections 原樣帶進 Supabase，illo_svg 自然跟著存。

Kim 還要真．生成圖，於是找免費的路：cf_imagegen.py 用 wrangler 既有 OAuth Token 直打 Cloudflare Workers AI（@cf/black-forest-labs/flux-1-schnell）REST API，免部署 Worker、免子網域、免另產金鑰，只要 wrangler 已登入就能跑，免費額度內 $0。

每段知識點寫英文 prompt、呼叫一次生圖、存 PNG 上傳 Supabase Storage 取公開 URL，再把 <img> 標籤填進 illo_svg。W25「互相穿成套」三個知識段落全是這樣生出來的。

踩到的坑：

flux prompt 有長度上限約 230 字，超過回 400 Bad Request，要精煉 prompt。
先試在 Cloudflare 部署一個 Worker 中繼，但 workers.dev 子網域要 email 驗證、headless 模式走不了 → 放棄 Worker，改直打 REST，簡單得多。
免費 flux 框框不穩：會生出「無頭模特」或「衣服平攤無人」。解法是 prompt 寫死 full body, standing, editorial fashion illustration，遇到問題直接重生。
一篇三張插圖，畫風要統一。Kim 偏好全身站姿、乾淨平塗、優雅比例，prompt 統一這個描述語。

Next.js 16TypeScriptTailwindSupabaseVercel

開啟穿搭誌 →

評論信任感工程

上線中

Cyberbiz 反映一年沒結果、今天一天自建完成的商品評論呈現系統

這件事的起點是一個很具體的挫折。

我在店裡累積了近兩百筆顧客評論，大多數是我親手把顧客在訂單留言說的話搬進去的。但顧客在商品列表頁完全看不到這些評論——每張商品卡沒有星等、沒有評論數。

跟 Cyberbiz 反映超過一年。沒有結果。

今天決定自己做。

先搞清楚資料

動手前先查了評論總數。後台管理介面預設顯示第一頁，看到 6 筆——差點就設計了一套給「只有 6 筆評論的店」用的系統。繼續翻頁才發現：199 筆、140 件商品。

這個錯誤如果沒發現，後面全部都是空中樓閣。

三件呈現工程

商品頁做了三樣東西：商品名稱旁加了星級徽章（版型已有掛載點，補一個 div 就渲染）；購買區下方加了「顧客評價」精選卡（做了三輪：widget 搬位→Kim 沒感覺→原生 widget 手機醜→Kim 提案自製極簡卡，定案）；整條邏輯可逆，版型備份六份。

列表頁的星等是另一套工程：打通 board.cyberbiz.co 評論 API（走子系統，不是一般後台），每天 11:20 排程自動撈 199 筆評論計算平均星等，結果寫進佈景片段，collection、category、search 三個版型都 include 進去。金色 #f0a500，Kim 要求要顯眼。

邀評自動化

目前 172/199 筆評論是 Kim 親手搬的。要讓評論自己長出來，需要主動邀評。

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

預購店最大的坑：不能照購買日加幾天就發（貨還沒到）。Kim 定案：超商等確認取貨後 7 天、郵寄出貨後 10 天，從訂單歷程抓精確取貨日期，三種格式各自解析。

防呆齊全：退貨中不發、對話還開著不發、每單一次、同顧客 120 天冷卻。

PythonLiquidCyberbiz board APIsync_review_stats.pyreview_invite.py

看完整故事 →

DeskMemo 桌面便利貼

上線中

便條紙永遠釘在螢幕最上層，關電腦想落跑會被警示音擋住

這個東西的起點，是我同事的一個老毛病：東西放眼前也忘。

代辦事項貼在螢幕邊框的那張紙，隔天就不見。手機備忘錄開了也不看。Line 自己傳自己，十分鐘後忘記查。

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

設計核心

兩件事：便條紙要永遠在視窗最上層（不管切到哪個應用程式），關電腦時要主動攔住她、提醒沒看完的事。

用 Electron 做，一份程式碼 Windows 和 Mac 都能跑，GitHub Actions 幫 Mac 版在雲端打包（我沒有 Mac）。

怎麼辦到的

置頂用 Electron 原生的 setAlwaysOnTop(true, 'screen-saver')，用最高層級。視窗設 transparent: true，紙張真正浮在桌面上——落影和微歪邊都是 CSS box-shadow，不是貼著視窗邊框的矩形方塊。

關機攔截監聽 before-quit 和 suspend 兩個事件，有未處理事項時播警示音並彈確認視窗。

一天內的版本演進（v0.1 → v0.9.1）

一天從 v0.1 做到 v0.9.1。中間 Kim 連續幾輪退稿：圖示太科幻退回（Electron 預設原子圖），楷體太復古退回，邊界線不要退回，最後傳來五張 MUJI 實物照說「就這個感覺」。整個產品的審美是她用退稿退出來的。

v0.5 是最大轉向：象牙白/純白/霧灰/灰綠/牛皮五色、細灰橫線、刻印小標籤，新增週記（MONTH＋週一到週日）、月記（月曆格翻月）、單字卡（3D 翻面）三種紙。

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

最後一役（v0.9.1）：Kim 回報「列表的方框到底在哪」，切換到列表就卡死。查出是 v0.7 富文字升級時兩行舊邏輯沒清乾淨，殘留在初始化路徑——用 --remote-debugging-port 加 playwright CDP 直連 Kim 螢幕上正在跑的那個 Electron 視窗，在她真機上復現、定位、修復。比看截圖猜一百次有用。

技術硬仗

Windows 11「智慧型應用程式控制」（SAC）三度作妖：擋打包工具、擋新安裝檔、擋未簽章程式（連視窗都不開，靜悄悄什麼都沒發生）。每次都要繞開執行檔這個敏感點。

exe 圖示嵌入連環坑：electron-builder 26 winCodeSign 炸 → 降版本 24 → icon.ico 放 build/ 又炸 → 最後用 rcedit 加 afterPack hook 自嵌，繞過整個流程才過。

第二天：真的有人用了之後（v0.9.3 → v0.10.1）

同事的 Intel MacBook 打不開——查打包 log 發現 Mac 版完全沒簽章，Apple 晶片直接拒跑。v0.9.3 在 GitHub Actions 打包流程裡補了 ad-hoc 簽章。

Kim 問「他闔上螢幕怎麼沒提醒」——這是作業系統的底線：任何程式都攔不住闔蓋瞬間。v0.10.0 改用更早的訊號補位：下班鬧鈴（預設 18:00，還有未完成事項就響、可貪睡）＋鎖定螢幕時先嗶一聲、解鎖回來立刻補警示。

Kim 問「memo 沒按掉會留到下次開機嗎」——內容本來就會留（每個動作即時存檔），但 app 預設不會開機自動啟動，等於重開機後便利貼「在，但看不到」。給健忘的人用，這個預設不對。v0.10.1 改成裝好第一次啟動就自動設定開機自啟，系統列可關。

這三版的共同點：功能都不難，難的是「使用者以為的行為」和「程式實際的行為」之間的縫，要靠真實使用者的問題才照得出來。

ElectronHTML/CSS/JSGitHub Actionselectron-builderrcedit

公開 repo →使用說明書 →

âme soeur Agent 團隊

開發中

一群正在學著幫我工作的數位同事

今天的 agent 狀態

訂貨專員工作中

出貨小幫手工作中

數據分析專家當機中

上架專員學習中

行銷企劃上線中

行銷小編睡著了

日誌官記錄中

TG遠端遙控上線中

最近開始很認真地想：我到底有多少時間，是花在重複工作上？答案有點可怕。

所以我開始把一些營運流程慢慢 Agent 化。目前有訂貨、出貨、analyst、listing、content editor 五個。

它們不是什麼超大型 AI 系統，更像是一群正在學著幫我工作的數位同事。狀況好的時候很省時間，狀況差的時候還是會很笨，甚至突然壞掉。

但它們確實開始幫我接住一些重複工作：

訂貨／出貨從 30 分鐘變成 5 分鐘
四源數據週報自動生成
商品上架少很多重複操作
有個默默幫我記錄這一切的小幫手

原本每天都在消耗人的小事情，開始慢慢被轉移，也讓我能把時間放回更重要的事情上。

Claude CodePlaywrightCyberbizGA4 / META APICloudflare

看每個 agent ↗

âme soeur 穿搭誌

一個 Kim 自己能改字、換照片的穿搭知識部落格。長 POPEYE 雜誌風，每週一篇。建置中。

âme soeur 穿搭誌

審視期

每週一篇穿搭知識文章，累積到同一個空間，Kim 看了再決定怎麼編輯

這個 app 的起點，其實是一個更小的問題：我需要每週一篇穿搭知識文章，給我拍知識教學型 Reel。

最初做成每週部署的靜態 HTML（amesoeur-styling.pages.dev），能看、不能改。

加入 POPEYE 雜誌參考

後來 Kim 給了三張日本雜誌 POPEYE 的版面當參考。那種感覺很具體：照片格狀卡、手寫感標題、英文 script 小標、密實小字，整頁有呼吸感又資訊量足。

做了 POPEYE 風範例（用後台真實商品照），Kim 很喜歡。基準檔就是 amesoeur-analyst/reports/styling/2026-W23-材質誌-POPEYE風.html。

嘗試 Canva 路線，走到死路

想試試看 Canva 能不能讓 Kim 直接在裡面改：用 import-design-from-url 支援 HTML/PDF 匯入。

結果：

HTML 抓取失敗（Canva 沒讀到任何內容）
PDF 匯入進去，版面看起來還可以——但文字被壓平成圖層，根本改不了，而且只有 1 頁

用 get-design-content API 驗證：richtexts 欄位抓不到，確認不可編。Canva 路線放棄。

Kim 補充

確立方向：自建部落格 app

Kim 說的很清楚：「我要的是一個自己能改文字、換照片的網頁。」

不用 Notion（要保留 POPEYE 版面），拍板自建。技術決策是沿用 reels app 那套（Next.js + Supabase），重用既有 Supabase 專案，新開資料夾 ame-soeur-journal。

這也讓它跟 amesoeur-marketing-agent 成為一組：agent 每週一產草稿入庫，Kim 進後台微調發佈。

怎麼辦到的

資料存 Supabase：styling_posts 資料表（Kim 在後台跑 SQL 自己建成功）、圖片桶 journal-photos（程式建）。

首頁列文章卡、/p/[slug] 單篇頁，npm run build 已通過。

為什麼可靠：

Supabase 同一個專案：reels app 已驗過，連線穩定，不用新開帳號
TypeScript 型別嚴謹：lib/types.ts 定型、build 時就抓錯，不用跑了才發現欄位對不上
靜態生成 + ISR：公開頁快、不額外燒費用

編輯後台（2026-06-07）

Kim 說的很清楚：「我要的是自己能改文字、換照片的。」

端到端驗過：登入 → 新增 → 填欄位 → 上傳照片 → 發佈 → 公開頁看到新文章，整條通。

第一篇入庫（2026-06-07）

W23 文章目前是草稿，Kim 潤飾＋換照片後自己按發佈。

編輯方向轉向（2026-06-07 深夜）

自由畫布若要繼續做，建議避開 RWD 坑，直接以手機直式介面為主要設計尺寸。

試 Cyberbiz 官網部落格，走到死路

表單後台轉向的同時，也試了另一條路：把含自訂樣式的 HTML 貼進 Cyberbiz 的「部落格管理→HTML 編輯器」，看能不能在官網網域直接發 POPEYE 風文章。

結果：存檔之後抓前台原始碼，所有 <style>、字型連結、class、行內 style 全部被平台清光，只剩純文字和圖片。

結論：Cyberbiz 站內無法保留日雜風排版，這條路不可行。

子網域架構可行，Kim 先擱著

查了一下 amesoeur.co 的 DNS 架構：

DNS 管理在 GoDaddy
www CNAME 指向 Cyberbiz（不能動）
子網域（如 style.amesoeur.co）可以單獨加 CNAME 指向 Vercel

請教三方 AI（GPT/Gemini/我）對子網域 vs 官網同域的 SEO 影響：三方共識是子網域影響小、app 是真正 HTML 結構反而好讓 Google 爬。

Kim 的決定：先擱著，實際看幾週成品、覺得有必要再設子網域。在那之前就用 Vercel 預設網址（ame-soeur-journal.vercel.app）繼續累積文章。

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

同時修了兩個 TG 推播 bug：

新品判斷邏輯修正：原本只抓「已上架+9折」，改成「最新排序前幾個且有9折」，不再卡上架狀態，確保真的是當週剛上的新品。
網址被全形括號吃進去的 bug：TG 推播格式改成網址各自獨立一行、結尾不接符號，這樣 Telegram 的連結解析才不會把括號吃進去變成壞連結。

每篇插圖升級成 AI 生圖（2026-06-15）

起點是 Kim 的一句：「看起來跟上週一樣。」

踩到的坑：

flux prompt 有長度上限約 230 字，超過回 400 Bad Request，要精煉 prompt。
先試在 Cloudflare 部署一個 Worker 中繼，但 workers.dev 子網域要 email 驗證、headless 模式走不了 → 放棄 Worker，改直打 REST，簡單得多。
免費 flux 框框不穩：會生出「無頭模特」或「衣服平攤無人」。解法是 prompt 寫死 full body, standing, editorial fashion illustration，遇到問題直接重生。
一篇三張插圖，畫風要統一。Kim 偏好全身站姿、乾淨平塗、優雅比例，prompt 統一這個描述語。

Next.js 16TypeScriptTailwindSupabaseVercel

開啟穿搭誌 →

評論信任感工程

Cyberbiz 反映一年沒結果、今天一天自建完成的商品評論呈現系統。199 筆評論從埋著到讓顧客看見。

評論信任感工程

上線中

Cyberbiz 反映一年沒結果、今天一天自建完成的商品評論呈現系統

這件事的起點是一個很具體的挫折。

跟 Cyberbiz 反映超過一年。沒有結果。

今天決定自己做。

先搞清楚資料

這個錯誤如果沒發現，後面全部都是空中樓閣。

三件呈現工程

邀評自動化

目前 172/199 筆評論是 Kim 親手搬的。要讓評論自己長出來，需要主動邀評。

防呆齊全：退貨中不發、對話還開著不發、每單一次、同顧客 120 天冷卻。

PythonLiquidCyberbiz board APIsync_review_stats.pyreview_invite.py

看完整故事 →

評論信任感工程

一句話定位：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。

我學到什麼

做技術的事，最難的不是寫程式，是先把事實查清楚。「6 筆評論」和「199 筆評論」是完全不同的設計前提。還有：量使用者的感知，不能只看 DOM 結構。

規格小檔　建立：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 桌面便利貼

便條紙永遠釘在螢幕最上層，關電腦想落跑會被警示音擋住。Electron 跨平台，一天從 v0.1 做到 v0.9.1。

DeskMemo 桌面便利貼

上線中

便條紙永遠釘在螢幕最上層，關電腦想落跑會被警示音擋住

這個東西的起點，是我同事的一個老毛病：東西放眼前也忘。

代辦事項貼在螢幕邊框的那張紙，隔天就不見。手機備忘錄開了也不看。Line 自己傳自己，十分鐘後忘記查。

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

設計核心

兩件事：便條紙要永遠在視窗最上層（不管切到哪個應用程式），關電腦時要主動攔住她、提醒沒看完的事。

用 Electron 做，一份程式碼 Windows 和 Mac 都能跑，GitHub Actions 幫 Mac 版在雲端打包（我沒有 Mac）。

怎麼辦到的

關機攔截監聽 before-quit 和 suspend 兩個事件，有未處理事項時播警示音並彈確認視窗。

一天內的版本演進（v0.1 → v0.9.1）

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

技術硬仗

exe 圖示嵌入連環坑：electron-builder 26 winCodeSign 炸 → 降版本 24 → icon.ico 放 build/ 又炸 → 最後用 rcedit 加 afterPack hook 自嵌，繞過整個流程才過。

第二天：真的有人用了之後（v0.9.3 → v0.10.1）

同事的 Intel MacBook 打不開——查打包 log 發現 Mac 版完全沒簽章，Apple 晶片直接拒跑。v0.9.3 在 GitHub Actions 打包流程裡補了 ad-hoc 簽章。

這三版的共同點：功能都不難，難的是「使用者以為的行為」和「程式實際的行為」之間的縫，要靠真實使用者的問題才照得出來。

ElectronHTML/CSS/JSGitHub Actionselectron-builderrcedit

公開 repo →使用說明書 →

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 補充

0.11.1：月記字級＋視窗縮放把手（2026-06-15）

Kim 回報兩個使用問題：月記的文字沒辦法調大小、整個外框很難拉（不知道從哪裡調整視窗大小）。

月記字級：工具列的 A＋/A− 在週記上有效，月記上按了沒反應。查了原始碼找到根因：月格文字 .mtext 的字級在 CSS 裡寫死 9px，沒有吃 --note-fs 這個字級變數——週記是接這個變數的，月記漏接。改成 calc(var(--note-fs) * .55)，讓它跟週記一樣走同一套字級控制。無頭瀏覽器實測：A＋兩下，9.35px 升到 11.55px，動了。

視窗縮放把手：Electron 的 frameless + transparent 視窗，OS 那層超細又透明的縮放邊框幾乎抓不到。加了一個看得到的縮放把手 #szgrip 在右下角（折角那邊）——鼠標滑過變深、游標換 nwse-resize，拖它即時發送 resize-note IPC，main.js 收到後呼叫 setBounds 改尺寸、debounce 存大小。工程點：透明 frameless 視窗的縮放邏輯完全要自己做，-webkit-app-region: drag 是管拖移用的，管不到縮放，兩件事要分開處理。

發版流程：版本從 0.11.0 bump 到 0.11.1，commit push 後 electron-builder 出 Windows 安裝檔，gh release create v0.11.1 建 release，觸發 build-mac.yml workflow 補 Mac arm64/x64 dmg（1分4秒跑完）。三個資產齊全：https://github.com/hsukim-cpu/deskmemo/releases/tag/v0.11.1

本機驗裝：taskkill 停掉舊版，跑 0.11.1 安裝檔 oneClick 自動裝＋重開 DeskMemo，grep app.asar 確認兩個修正真的進去了（.mtext 那行找到 calc(var(--note-fs)、#szgrip 找到 nwse-resize）。便利貼資料存在 %APPDATA%/deskmemo，更新後完整保留。

Kim 補充

我學到什麼

CDP 直連真機比截圖猜一百次有用。測試路徑要包含「切換動作」，不只是驗靜態狀態——「demo 便條從不測切換」這個盲點，讓 v0.7 的殘留一路潛伏到 v0.9.1 才炸。

透明 frameless 視窗的縮放要自己實作把手，不能靠 OS 邊框；驗裝用 grep app.asar 確認修正真的進安裝包，比跑完安裝後盲目點點看更可靠。

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

訂貨專員

運作流程

說「訂貨 6/3」→撈訂單 · 免 OTP→篩出預購品→加總數量→回傳分享連結

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

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

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

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

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

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

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

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

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

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

為什麼數量不會錯。

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

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

成果

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

我學到什麼

先用最省、已經能動的那條路，不要一開始就硬幹最貴的方法。很多時候卡住不是因為事情難，是因為一開始選錯了路。

它的實際產出（示意）

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

示意 · 數據為示範

âme soeur 訂貨清單

只統計含「(預購)」的品項＝要跟廠商訂的量

區間訂單

含預購

需訂品項

總件數

#	商品名稱	顏色	尺寸	數量
1	涼感速乾短袖 tee｜24ss-tee-44	白	M	8
2	亞麻長袖襯衫｜26ss-shirt-09	黑	XL	6
3	直筒丹寧褲｜26ss-pants-20	藍	M	5

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

這個 agent 的開發日誌

06/03

頁面補上「怎麼辦到的」專業說明：怎麼撈、怎麼加總、為什麼數量不會錯

06/03

加了報表首頁：每天的訂貨清單列成一張表，點開就看，新的在最上面
超過 30 天的舊清單會自動清掉，不會越積越多
每張清單頁加「← 返回首頁」，從哪個連結進來都回得去

06/02

訂貨清單一條龍完成，自動部署成分享連結
6/1 驗收：20 品項、21 件，現貨自動排除

05/30

打通免 OTP 的 get_list 端點，不用再一直 key 驗證碼

還想幫它做的

自動判斷哪些品項該多訂一點（抓熱賣趨勢）
訂貨單直接整理成廠商要的表格格式

看它的實際設定檔（agent md）amesoeur-ops-agent.md

---
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」→撈訂單→分現貨／預購→給可出清單確認→唯讀列印明細

一句話定位：我說「出貨 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 補充

成果

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

我學到什麼

會動到真實資料的操作，一定要留一道「我來確認」的關卡，agent 只做唯讀的部分。方便跟安全之間，我選安全。還有一個踩到的教訓：我說「列印不見了」的時候，它一開始急著撇清、把原因推給別人；正解是先去查清楚、把該有的功能做成固定每次都在，而不是辯解。

它的實際產出（示意）

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

示意 · 數據為示範

âme soeur 出貨確認清單

整單一起出、不拆單｜有預購→整單待等｜已出貨已排除

區間訂單

全現貨可出

含預購待等

已出貨排除

#	訂單編號	訂購商品	付款／出貨狀態
1	#A001	刺繡布章老帽 ×1	已付款｜未出貨
2	#A002	航海平簷帽 ×1	已付款｜未出貨
3	#A003	棉質短襪 ×2	已付款｜未出貨

規格小檔　狀態：上線中｜唯讀、不誤觸後台｜整單出貨不拆單（全現貨才出、含預購整單待等）｜列印鈕固定在清單頁｜「列印全部可出」自動補空白背面（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

這個 agent 的開發日誌

06/12

「換貨差額」單修正：後台用 1 元商品 ×N 收差額（如 #4389 換貨差額 ×1290＝收 1290 元），標籤生成把它當實體商品展開成 1290 張、出貨清單也顯示成像要揀 1290 件。修法：ops_labels.py 加 is_physical()（品名含差額/運費/折抵/手續費＝非實體），三個標籤入口（日期模式、指定訂單、出貨連動）都跳過；出貨清單頁該品項改顯示「金額調整項 N 元，非實體、免揀貨」。6/10–6/11 出貨清單實測：標籤 1291→1 張

06/11

外箱品名標（box-labels）上線：Kim 要「像標籤4×5但橫向、不連後台、純手打」貼外箱用的品名標。做成常駐靜態頁（ops pages.dev/box-labels）：橫式 5×4cm 版面、品名自動縮字、小字列可留空、可複製/刪除/全部清空、內容存 localStorage 下次開還在；列印是把橫式內容用 canvas 轉 90° 組成 40×50mm PDF，印到同一捲芯樺 4×5cm 直式標籤紙上，印表機設定完全不用改。Kim 校正一次：第一版只給「下載 PDF」，她說「我不用下載pdf」→ 改成一顆「列印」鍵，頁內組好 PDF 後走 blob 隱藏 iframe 直接跳列印視窗，零下載步驟。踩坑：html2canvas 在 clone 階段就把 ::before 偽元素實體化，onclone 裡再改 CSS 砍 placeholder 來不及（灰色提示字被印進 PDF）；解法是產出前在原頁 body 加 .pdfing class 先藏掉、印完移除。另外 ops 站 30 天自動清舊檔會誤刪常駐工具頁，prune_old 加 KEEP_FILES 豁免，ops 首頁加常駐工具入口

06/10

雙面列印跨訂單問題修法：Kim 發現「列印全部可出」一次印多筆時，A 訂單印正面、B 訂單印背面落在同一張紙——不是程式沒分頁（印成 PDF 驗證 page-break-before:always 有效、3筆=3頁），而是「整批一個列印工作」造成跨訂單。試過 CSS break-before:right/recto 但 Chrome 不認（不會補空白、頁數一樣），最後改用 playwright 無頭量每筆訂單實際頁數，奇數頁就在後面補一張空白背面湊偶數，這樣雙面時每筆都落在正面。關鍵：量頁時要用跟最終合併頁相同的 @page A4 邊界，否則頁數對不上。保險：playwright 沒跑成就不補空白、照原樣輸出並提醒改用逐筆列印鈕。實測 06-09：三筆各1頁→補3張空白→共6頁，訂單落在第1/3/5頁（全正面）

06/10

郵局標籤接上 Telegram 手機觸發：手機傳「郵局標籤 4384 4383」或「郵局標籤 06-10」→ 橋跑 ops_post_labels.py 回連結。踩坑：「郵局標籤」含「標籤」兩字，會被既有商品標籤邏輯搶先攔截去跑 ops_labels.py；解法是把郵局標籤判斷排在商品標籤之前（更長詞先判斷），改 telegram_bridge.py 重啟橋生效
非郵寄單三層提醒：Kim 問「給的訂單號不是郵局單會不會提醒」→ 補強成：① TG 回覆摘要多一句「非郵寄(疑超商) N 張：#xxxx」 ② 標籤頁頂端紅字列出哪幾單、提醒地址欄是門市資訊 ③ 該卡片右上角小⚠標記（只顯示螢幕、不印出）。判斷依據：郵遞區號開頭 vs 門市名稱開頭。日期模式維持直接略過超商單，不提醒。改 ops_post_labels.py，不用重啟橋

06/10

郵局標籤系統（ops_post_labels.py）上線：針對宅配/郵寄訂單，產國內郵寄包裹 4×6"（101.6×152.4mm）格式的寄件標籤。指定訂單號或指定日期兩用，超商取貨訂單自動略過。直接從訂單 shipping_address 帶出收件人郵遞區號/地址/姓名/電話，不用一張張手動開訂單查。踩坑一：後台會把縣市區重複前綴塞進地址欄（客人打完整地址、後台又補縣市區 → 重複），regex 修掉。踩坑二：logo base64 嵌 CSS、flex column 容器裡未給明確寬度 → div 塌成寬度 0 看不到，補固定寬度解決。標籤頁內建品牌 logo 和固定寄件人資訊（可改），每張可改字/刪除，底部「下載列印 PDF（4×6"）」

06/10

出貨邏輯再校正（Kim 定案）：âme soeur 整單一起出、不拆單。砍掉「部分可出」這個中間分類，只剩兩類：全現貨→可出（ship_all），訂單含任何預購品→整單待等（wait）。商品標籤連動修正：只吃 ship_all 訂單的品項，wait 單不印、避免貼錯。標籤頁 slug 改 labels-ship-<date>，頁首說明改「只含可出貨商品（全現貨訂單；待等單不印）」。影響範圍：ops_shipping_list.classify() 邏輯、列印頁、標籤頁三處同步

06/08

商品標籤系統（ops_labels.py）上線：出貨前印吊牌標籤，支援兩種模式——①指定日期（當日所有訂單品項、依數量展開，買×3印3張）②指定訂單號（帶不帶#皆可，查無編號標「查無訂單」）。標籤頁是獨立網頁（部署 ops pages.dev）：每欄可點字改、「×」刪除、「新增空白標籤」、「套用固定資訊到所有標籤」、底部「下載列印 PDF（40×50mm）」用 html2canvas+jsPDF 轉正好 40×50mm 一頁 PDF。出貨清單頁（ops_shipping_list.py）跑完自動帶當日標籤頁連結、出貨清單上多「商品標籤」鈕
最大踩坑：標籤印出來一直失敗——內容溢出、左右被切、一張標籤跨到兩張實體紙。逐步排查真因：XP-420B 驅動預設紙張是交貨便 100×150，縮放設「依紙張大小自動調整」→ 把 40×50 的 PDF 放大去填滿 100×150、連進紙長度都算錯。修法三步：①縮放改「預設/實際大小100%」②驅動「列印喜好設定→頁面設定→股票→新增」一個 40×50 stock（模切標籤、左右襯紙各2mm）③換小標籤卷後做進紙校正（關機→按住進紙鍵→開機吐定位）。關鍵取捨：不改驅動預設（交貨便仍需 100×150），只「新增」40×50 並存，印標籤那次手動選。瀏覽器直印會印出頁首頁尾的日期/網址，改走 PDF 解決。Kim 最後要求標籤頁當獨立網頁（拿掉返回出貨清單連結與下單區間顯示）

06/03

頁面補上「怎麼分辨現貨／預購」的設計過程說明（逐項讀(預購)標記分三類）
頁尾附上它的實際設定檔（agent md），可折疊查看

06/03

把列印鈕直接做進出貨清單頁：每筆一顆＋最上面「列印全部可出」，固定每次都在
不再依賴後台那顆時有時無的列印按鈕
同上報表首頁＋30 天自動清理＋返回首頁鈕
把這套出貨工具去品牌化、打包成可分享版，給也用 Cyberbiz 的朋友用

06/02

出貨清單分三類（全現貨／部分可出／全預購）＋唯讀列印完成
6/1 驗收：2 張現貨可出（帽子）

還想幫它做的

串超商託運單一起列印
我確認後一鍵標記已出貨

看它的實際設定檔（agent md）amesoeur-ops-agent.md

---
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 指定的會員看呈現，她說看完再說要不要啟用。排程還沒掛，一筆都不會自己發。

成果

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

我學到什麼

分析的價值不是貼數字，是把幾個來源串成「到底發生了什麼事」。也學到：先把既有的規範載進來再動手，比急著生出東西重要。

它的實際產出（示意）

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

示意 · 數據為示範

âme soeur 整合週報

四源整合（Cyberbiz＋GA4＋META＋IG）

工作階段

3,280

轉換率

2.1%

廣告點擊

1,540

Reels 觀看

1.2 秒

流量來源	工作階段	佔比
自然搜尋	1,180	36%
IG / Reels	690	21%
META 廣告	910	28%
直接進站	500	15%

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

這個 agent 的開發日誌

06/15

W24 週報 AI 層首次自動排程（週一 12:00）實跑：四源數據真實——營收 NT$146,439（+11.3%）、訂單 74（+12.1%）、ROAS 5.0→7.62x（廣告效率拉回）、轉換率 0.96%（前週 0.89%）。我的診斷：回升幾乎全靠廣告效率，META 佔站內 91% 依賴度升高；進站→下單 <1% 結構未解；建議端午 6/19 前全館滿額折（符合促銷鐵則不做單品9折）。外在因素查證：梅雨期利網購、端午未到確認。首跑抓到 bug：12:00 自動版 IG 5 支 Reels 數字是 AI 憑空編的（違反自己 prompt 的「IG 沒數據就標待補、禁編」鐵則），已記進 memory，修法是加硬關卡——無 IG 來源 JSON 檔就只能印固定待補字串。這份（手動跑的校正版）IG 區正確標「待 Kim 傳截圖」，未編造。部署 https://amesoeur-weekly-report.pages.dev/2026-W24-ai.html

06/11

訂貨本瘦身完成：管理表2.0 刪掉 2021–2026營運＋工作表30 共 7 個分頁（歷年損益已搬進統整表、整檔 xlsx 備份），只剩純訂貨分頁。失效連結清理：非 1688 的 36 條（15 條舊 Shopline、4 條 superdelivery 失效）已紅底＋註解標進表。1688 的 1,054 條碰上 x5 防爬蟲硬牆：requests 被丟滑塊、playwright 真瀏覽器也被指紋偵測（Kim 親手拉滑塊都不放行）。解法＝點滴式掃描：失效商品就算被擋也會回 404 重導向，於是用 20–40 秒/條的低頻 requests＋被擋自動休 15–30 分，排程每 2 小時補跑直到掃完。教訓：對陣防爬蟲先找「不設防的訊號」（重導向）而不是硬剛渲染頁

06/11

庫存表改造上線：12 個品類分頁全部重建成「新版_{品類}」（366 列/722 件）。Kim 拍板規則＝庫存先帶後台現貨數（之後實際盤點改 E 欄、差異自動紅字）、後台為 0 或對不到的列直接刪、成本欄不標幣別。比對邏輯沿用 T恤樣品（正規化品名→現貨變體優先），每列埋隱藏變體 ID 欄，sync_inventory_tabs.py 每日 11:35 排程只更新後台庫存欄、絕不碰盤點數。踩坑：products/search 的庫存欄位是 inventory_quantity 不是 qty，第一版全抓成 0，跑樣品比對（67列/96件）才驗出來

06/11

評論信任感工程——列表頁星等模組上線：Cyberbiz 一年沒做的「商品列表頁顯示星等」，Kim 授權自建（不影響官網、可回復為前提）。重大更正在先：原本報告說「全站僅 6 筆評論」是錯的，留言板列表有分頁，只看了第一頁；實際是 199 筆已審核評論/140 商品。資料管線：評論 admin API（/admin/board_comments/token → board.cyberbiz.co）撈資料，sync_review_stats.py 每日 11:20 排程算每商品平均星等、寫進佈景片段 snippets/_as_review_stars.liquid，include 在 collection/category/search 三版型。實測 denim-pants 頁顯示正確。順帶打通樣板編輯器自動化手法（ACE 編輯器、同意視窗、新增片段流程），等於以後可以程式化改版型
評論呈現三件全上線（商品頁部分）：① 商品名稱旁星級徽章（版型預留掛載點 #board-comments-rating-badge，JS 插 div 就渲染；有評論顯示星等，零評論顯示「發表評論」引導）② 購買區下方自製「顧客評價」精選卡（三輪迭代定案：v1 widget 搬位手機沒感、v2 原生 widget 手機紅藍按鈕醜、v3 Kim 提案自製卡—細線極簡米白底、JS 即時從 widget 抓星等與一句評論、零評論自動隱藏）③ 版型備份六份（backups/）可隨時回復。真正重要的洞察：Cyberbiz 評論呈現是收費客製項目——平台沒留掛載點，但今天用防禦性 JS 自己插進去了

06/11

邀評自動化建好（review_invite.py），Kim 說先不啟用：查證 Cyberbiz 沒有內建邀評信；AUTOMATION 擴充的會員分群只認購買日、沒有「已取貨」條件，預購 7-20 工作天會打到還沒收到貨的人 → 平台路線棄用。改走破解訂單對話 API（POST /admin/message_posts，role=admin＝顧客通訊）自建邀評。發送時機 Kim 定案：超商取貨日+7天（七天鑑賞期後）、郵寄出貨日+10天；取貨日從訂單 histories 抓（7-11 和全家格式不同已兼容）。防呆：退貨中不發、對話進行中不發、每單一次、同顧客 120 天冷卻。測試發一筆給 Kim 指定會員驗收。Kim 明確說先不要發送 → 排程未掛，等她驗收後啟用

06/11

CRM 設定盤點（只查不動）：Cyberbiz 後台三處真實數值全部查清。紅利點數：無全館消費回饋率，bonus_collections 空（0筆），只有第三級潛艇堡會員消費滿 $2,500 送 100 點；會員等級：三級（甜甜圈 $2,000 升/可頌累積 $5,000/潛艇堡累積 $10,000），折扣只有二三級（97折/9折），生日禮各 $100/$150/$300；LINE：全部事件觸發型，無時間觸發（購買後 N 天自動推播），LINE OA 廣播需先完成 Messaging API 設定才能用。截圖三張推 TG。踩坑：新版 Cyberbiz admin 是完整 SPA，headless Playwright 所有直接 URL 都 redirect /admin；需 headed 模式＋先從 admin HTML 提取真實路由 hrefs，再 goto 正確路由。VIP 設定可用 /admin/vip_groups.json 直接取完整 JSON（cookie 即可，不需 Bearer token）

06/10

留存診斷與留客計畫：Cyberbiz 全年訂單 API 撈 3,251 筆，真實計算回購率（21.9%）、新客30天回購率（9.1%）、中位回購間隔（34天）、回購客營收佔比（46.8%）。最大發現：2026年新客月份回購率連五個月下滑（1月18%→5月6%），首購後流失問題在惡化，而非老客跑掉。提出5個留客方案（首購購物金回饋、30天LINE再行銷、加購補免運缺口、回購優惠碼、會員等級盤點），全部基於 Cyberbiz 現有功能。教訓：後台設定頁（購物金回饋率/會員等級門檻）API 查不到設定值，需要 Kim 登入確認；通知模板全開不等於回饋機制有設。部署：https://amesoeur-special-reports.pages.dev/20260610-retention-plan.html

06/10

活動設定查證＋CVR 診斷報告修訂：Kim 指出原報告「活動空窗造成 CVR 波動」錯誤——當初用訂單折扣金額反推活動日期，系統性漏掉了 GiftCollections 滿額贈（不產生折扣金額）。補查 Cyberbiz 後台 admin/special_collections.json（12筆）+ admin/gift_collections.json（12筆），確認 2026-W01–W23 每週都有促銷活動（SC 任選折與 GC 滿額贈交替覆蓋），從不空窗。教訓：活動設定要查後台設定檔，不能從訂單行為反推。修訂報告：承認錯誤、加入逐週行事曆表、改結論為「活動類型轉換力道差異（待週層級 CVR 對比驗證）」。部署：https://amesoeur-special-reports.pages.dev/20260610-cvr-diagnosis.html

06/10

六月業績診斷（6/1–6/10）：Kim 問「六月業績平平是為什麼」，直接跑 Cyberbiz BI / GA4 / META API 抓三源真實數據、交叉比對。核心發現：流量比五月同期多 25%，但轉換率從 1.21% 跌到 0.84%（跌 30%），AOV 從 $2,281 跌到 $1,866（跌 18%）——根本問題不是流量不夠，是「進站後沒買」。免運券 AOV $1,188 是最大 AOV 拖累項；五月有週末活動兩次（AOV $2,260–$2,760），六月前十天只有 6/6–6/7 兩天。報告三大行動：① 本週五起設全館滿 $2,000 折 $150（端午前）；② 限縮免運券主動推播；③ 請廣告專員查 ROAS 下滑原因再動廣告。部署至 https://amesoeur-special-reports.pages.dev/20260610-june-perf.html

06/10

週報 AI 分析層上線＋cookie 續登驗收＋腳本重構三件事。① AI 分析層：weekly_report.py 加 --dump-json（只抓四源數據存 JSON、不觸發規則版 email），新 run_weekly_report.py 無頭 claude 親自分析（prompt 寫死鐵則：四源交叉診斷、外在因素查證後才用、禁編因果、IG 沒數據標待補不准編），產 HTML→部署→推 TG，schtasks 每週一 12:00、首跑 6/15；穿搭文章排程挪 13:00 避免兩個無頭 claude 互搶。② cookie 續登：排程 6/9、6/10 其實都沒跑——schtasks 建任務預設「電池供電不啟動」（錯誤碼 0x800710E0），Set-ScheduledTask 改電池可跑＋錯過補跑＋可喚醒，腳本加 log 和 gh 完整路徑保險，實跑驗證 secret updated_at 刷新。③ 重構：81 個一次性勘查檔搬 .trash（_sku_* 依先前決定保留）、tg 推播抽成共用 notify.py（原本重複貼三份）、補 scripts/README.md 盤點表，全腳本 import 掃描確認沒有誰依賴被搬走的檔

06/08

W23 週報 Cyberbiz 分區補完：Kim 登入後台讓 Playwright headed 視窗攔截 Bearer JWT，補抓行銷活動 BI API（折扣三層、活動排名）。真實數據：66 筆訂單 / NT$131,344 / AOV $1,990；6/6~6/7 指定商品任選兩件9折帶出最高 AOV $3,082；6月免運券 AOV 只 $1,152 是效率最低活動。踩坑：user/sign_in 登入取到的 cookies 打 get_list 會 401，需進 /admin 後再導 BI 頁攔截 JWT。API 活動名稱 stdout 顯示亂碼（stdout=cp950），用 json.dumps(ensure_ascii=True) 取 Unicode escape 或直接寫 HTML 均正確。四源現在全部齊備，交叉診斷補上 Cyberbiz 真實數字串完整漏斗故事。部署：https://dc82c5dc.amesoeur-weekly-report.pages.dev

06/08

W23 四源整合週報（真正分析師版）：GA4 + META 直接 API 抓，Cyberbiz session 過期標明未取得（不冒充）。核心診斷：META ROAS 從 7.93x 跌到 5.00x 是舊活動（2604/2026常態）週期到期，新 2606 首週 ROAS 8.43–10.94x 強；九分褲全站瀏覽 6,912 + IG 珍藏 12 次三週最高，但加購率只 1.16%——典型換季觀望；GA4 conversions 陷阱（ame_瀏覽時間60秒被誤設為 conversion，要用 purchase=66 才是真數字）。報告含購物漏斗拆解、活動層 ROAS 明細、IG 跨源比對、組合優惠 mockup、鉤子 storyboard 三版。部署：https://amesoeur-weekly-report.pages.dev

06/08

W23 IG Reels 追蹤表補齊 ⑫⑬⑭⑮ 並完成整週分析。核心校準：⑮ 新版 UI 有官方均看 3 秒＋略過率 78.3%，作為前四支粗估值嚴重低估的參照基準——不再用「觀眾只看 0.3 秒」當確定結論。整週五支用互動率＋珍藏率＋非粉觸及三維排名，⑬ 水波紋直紋襯衫是本週最佳新品支（三指標平衡），⑭ 九分褲珍藏 12 是三週追蹤最高（社會認同型鉤子效果強）。⑮ 活動片 FB 62%高佔比：事實查不到直接原因，分三種推測並標明無法確認。導購效率：⑮ 連結點按 13 是本週唯一量化導流，但新粉 0，兩個目標需要不同的片。部署：https://amesoeur-reels-tracker.pages.dev

06/07

Kim 今天才發現現行 weekly_report.py 的判斷句是純規則 if/else、零 AI（已查證，無 anthropic/gemini 呼叫）。她很不滿：「我要分析師等級的解讀，一點都不需要制式化的產物」「要確保真的都是經由你去分析思考過然後做出來的」。確定方向：數據層繼續用腳本實抓（GA4/META/Cyberbiz），判斷/洞察由 Claude 親自分析寫——四源跨源診斷、外在因素（天氣/連假/趨勢/季節）查證後納入解釋為什麼。目標每週一 12:00 自動發 TG，06/08 週一起實作

06/10

全年轉換率結構性診斷：GA4 API + META API 查 2026-01–06-10 逐月數據。CVR 不是線性下滑，是活動依賴型波動（有活動週 1.18%、無活動週 0.7–0.9%）。根因三層：① IG 有機流量佔 71–81% sessions，CVR 只有 0.54–0.74%（高量低意圖）；② 新客 CVR 從未超過 0.65%，首購轉換從未被結構性解決；③ 站內漏斗本身沒壞（加購率 5–7%，付款率 11–13%）。對策：首購誘因結構（AddBuyCollection＋棄單碼）＋固定每月兩次活動節奏＋廣告目標分工診斷。報告：https://amesoeur-special-reports.pages.dev/20260610-cvr-diagnosis.html

06/03

兩日業績診斷踩坑＋抽絲剝繭：先編了「無新品檔期回落」被 Kim 退（官網明寫週一新品9折），改用 GA4 逐層拆—鎖定「社群新客的加購→結帳」崩(31% vs 74-83%)、轉換砍半，預購是常數非主因，待 IG 洞察確認 Reel 痛點。教訓：因果要有來源、兩天不成趨勢

06/03

頁面補上「怎麼辦到的」專業說明：數據怎麼來、怎麼判讀、為什麼結論站得住

06/01

週報排程改可靠：冷門時段 cron＋保險 cron＋週次去重

05/31

修好 Cyberbiz 沒資料時會崩潰的 ZeroDivisionError

05/30

加 GitHub Actions 週報自動化排程

還想幫它做的

把 Reels 真實成效數據灌進來一起分析
自動標記哪支 Reel 有下廣告

看它的實際設定檔（agent md）amesoeur-analyst-agent.md

---
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`

上架專員

運作流程

新品資料→對應後台欄位→描述交文案 agent 把關→填寫＋ SEO→存「未公開」→截圖給我確認

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

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

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

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

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

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

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

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

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

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

為什麼不會出包。

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

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

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

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

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

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

安全一樣是設計出來的：

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

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

成果

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

我學到什麼

對外發布的東西，一定要留「我確認」這一關。agent 負責繁瑣的部分，決定權留給我。

還有一個收穫：很多看起來只能「手動點」的後台操作，其實有更省力的路——找到那條路，重複的工就能交出去。但越省力的工具越要配上「先確認、先試一件」的剎車，快和穩才能同時要。

它的實際產出（示意）

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

示意 · 數據為示範

Cyberbiz 商品上架

新品後台欄位（狀態：未公開）

後台欄位	自動填入內容
商品名稱	涼感速乾．每日好感短袖 tee
售價 / 定價	NT$ 690 / 880
商品描述	親膚涼感、吸濕快乾，日常百搭…
SEO 標題	涼感短袖 tee｜âme soeur

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

這個 agent 的開發日誌

06/04

解鎖「不開瀏覽器、直接用 API 改後台商品」：PUT /admin/products/{id}.json＋帶頁面 meta 的 CSRF token，一次改整件多個 variant。比一格一格點瀏覽器快很多，之後上架批次改欄位／事後修都用得到
實戰是全站 SKU 整理：把跨商品撞號的收進 ZZ0001–ZZ0424、同色多碼併一，並學到條碼型商品(日貨 EAN)每尺寸各自一碼、不可硬併

06/03

頁面補上「怎麼辦到的」專業說明：資料怎麼對、怎麼填、為什麼不會出包
寫清楚商品描述會與文案 agent 協作把關（本來就這樣設定）

06/01

上架 agent 誕生：把 Cyberbiz 新品後台填寫流程交給它
定下鐵律——一律先設「未公開」、每個儲存節點截圖給 Kim 確認

還想幫它做的

商品上架 workflow 全自動化
SEO 標題／關鍵字自動產生

看它的實際設定檔（agent md）amesoeur-listing-agent.md

---
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`

行銷小編

運作流程

看數據選題 · 問分析 agent→讀品牌語氣規則→產文案／改寫→檢查清單把關→回成稿

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

起點：語氣常常跑掉

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

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

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

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

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

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

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

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

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

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

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

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

為什麼語氣會穩定。

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

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

成果

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

我學到什麼

品牌語氣不是靠感覺，是可以寫成規則交給工具的。把「不能說什麼」講清楚，有時候比「要說什麼」更重要。

它的實際產出（示意）

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

示意 · 數據為示範

文案改寫（品牌語氣）

草稿 → âme soeur 溫柔、不推銷的語氣

原始草稿	改寫後
限時搶購！必買款！	為日常選的一件，慢慢挑也沒關係
超顯瘦一定要收	俐落的版型，穿起來剛剛好
手刀下單衝一波	想入手的話，這裡可以慢慢看

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

這個 agent 的開發日誌

06/07

重做腳本生成器核心產出邏輯（最關鍵改動）：Kim 連退兩次——先嫌「跟自己拍沒差」（型錄展示），再嫌「POV 有了但沒在學範例」。撈 30 筆 is_recommended 高績效腳本，找出致勝 DNA＝每支都有觀眾能帶走的「價值爆點」（可複製技巧/Before-After/冷知識/破解常見錯誤）。真因：referencedScriptsContext 只餵了 hook＋主題，三個精華欄位沒進 prompt。修法：concept 強制包含價值爆點，整包精華餵進去並要求「學手法、不抄內容」，明文反例「穿上轉一圈說好舒服」；輸出加 concept 欄顯示在生成頁＋分享頁；品類防呆（曾把長褲講成襯衫）；溫度 0.7→0.8
改寫腳本生成器語氣規則（`prompts.ts`）：先查 2026 IG 演算法訊號排序（Sends > Watch time > Saves > Likes）＋ Meta 官方 engagement bait 降觸及聲明，再對照品牌語氣規則，刪喊單文字（剁手/不買不行/限時9折）、emoji 大幅減量、hook 改三型（共情痛點/數字定位/好奇缺口）、CTA 改分享＋儲存軟邀請且禁 engagement bait（不 gate 連結）。BRAND_VOICE / scriptStyleDescriptions / JSON 欄位三處同步改。editor-notes 補「2026 IG 演算法訊號排序」整章
依 Kim 指示區分自然流量片與廣告素材片：廣告素材片可直接講優惠、導連結、CTA 轉換型，但仍保留品牌底線（不用超殺/爆款/必買/剁手）。AD_CREATIVE_OVERRIDE 寫進 prompts.ts，依 mode 欄位分流

06/03

頁面補上「怎麼辦到的」專業說明：依據哪裡來、怎麼檢查、為什麼語氣穩定
補記完整角色＝品牌小編：不只改語氣，也照節奏產文案、且跟分析 agent 看數據選題

06/02

文案 agent 誕生：把 âme soeur 品牌語氣寫成可檢查的規則
改寫直接給成稿，並列「原文 → 改寫版」，不只給建議

還想幫它做的

多平台語氣切換（Threads／IG／EDM）
自動套用品牌金句

看它的實際設定檔（agent md）content-editor.md

---
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

行銷企劃

運作流程

說「穿搭文章」→撈當週新品（前6件已上架＋9折判斷）→蒐集趨勢資料→親自寫文章＋Reel骨架→部署 pages.dev＋推 Telegram

一句話定位：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：網址被全形括號吃進變壞連結，改成網址各自獨立一行

我學到什麼

「全自動」聽起來很理想，但有三個前提它無法同時滿足：雲端排程、碰後台真實資料、我親自寫。選哪個組合才是對的，要看真實限制說話——這次答案是本機半自動，不是為了省事，是因為其他選項不成立。

Kim 補充

它的實際產出（示意）

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

示意 · 數據為示範

每週穿搭文章示意

知識教學型——綁本週新品、衝儲存＋分享

元素	內容
本週主題	梅雨悶熱季，小隻怎麼穿不黏不悶又有型
知識點一	透氣材質優先：水波紋紋理＝空氣感設計
知識點二	下半身的比例魔法：五分短褲拉長視覺腿長
Reel hook	「小個子穿夏天最怕這件事——悶到忘記自己有打扮」

規格小檔　建立：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

這個 agent 的開發日誌

06/15

穿搭誌視覺大升級：串好免費 AI 生圖管線（cf_imagegen.py）。起點是 Kim 說「每篇知識插圖看起來跟上週一樣」「你美學的技能不只這樣吧」——原本 Illustration.tsx 三種線稿寫死在程式裡，無法每篇客製。升級路線：先重畫 SVG 線稿成日雜編輯風格，Kim 仍要「每篇專屬」；再改架構讓 Section 帶 illo_svg 欄位（PostView 用 dangerouslySetInnerHTML 渲染），優先於舊 illo_key；最後 Kim 還要真生成圖。解法：cf_imagegen.py 用 wrangler 既有 OAuth 直打 Cloudflare Workers AI（Flux-1-schnell）REST，**免部署 Worker、免子網域、免另產金鑰、免費額度 $0**。每段知識點依主題生一張全身編輯插畫→上傳 Supabase Storage→嵌 section。W25「互相穿成套」三段全是 AI 圖。四個踩坑：① flux prompt 有長度上限約 230 字（超過回 400 Bad Request）② 先試部署 Worker 但 workers.dev 子網域走 headless 無法完成 email 驗證 → 改 REST 直打才通 ③ 免費 flux 框框不穩，生出無頭半身或無人衣服平拍 → 寫死 full body 並重生 ④ 一篇多張畫風要齊，Kim 偏好全身站姿、乾淨平塗、優雅比例

06/10

穿搭誌五套日雜版型深化上線：原本五套主題只是換色＋小調整，這次每套做出結構性編排個性——FUDGE＝法系編輯頁（置中襯線、細雙線框、首件商品放大跨欄、引文式 pick 框）、POPEYE＝city boy 剪貼簿（色塊刊頭、卡片微旋轉＋陰影、紅圓徽章編號、虛線 memo 框）、2nd＝型錄規格頁（黑底刊頭欄、左色條 kicker、品名價格規格行）、MONO＝黑白字體誌（照片整篇灰階、超大描邊章節數字、黑底反白 pick 框）、OLIVE＝夏日手帖（pill 框手寫 kicker、圓角貼紙感、價格 pill）。純 CSS 層改造不動內容結構，vercel 部署後線上 CSS 驗證＋playwright 五套截圖逐一驗收。預覽連結 ?theme=t-fudge|t-popeye|t-2nd|t-mono|t-olive。待辦：theme ledger 記每期用過的色票防重複

06/07

每週流程微調：新品判斷改「最新+有9折」不分上架狀態（Kim 指正：舊規則靠上架狀態判定，會漏抓真的剛上的新品）；TG 推播整合（每週文章發進 app 後自動推連結到 Kim 手機）；修 TG 推播 bug（網址被全形括號吃進變壞連結，改成網址各自獨立行）。每週文章流程改成「累積到 app 首頁審視空間、Kim 看了再發佈」，W23 第一篇已用這個流程發進空間
穿搭誌編輯方向轉向：表單式後台做完後 Kim 看了自由畫布 demo 決定不走表單路線，整包移 .trash（可復原）。同天實測 Cyberbiz 部落格 HTML 編輯器——貼含樣式的 HTML 存檔後所有自訂樣式被平台清光，Cyberbiz 站內無法保留日雜風，這條路確認死路。查 DNS 架構：子網域 style.amesoeur.co 可行，Kim 先看幾週再決定。目前 app 公開頁維持上線，編輯機制待定

06/07

行銷企劃 agent 誕生：建立 `.claude/agents/amesoeur-marketing-agent.md`、`.claude/memory/marketing-notes.md`、command `weekly-styling.md`、腳本 `fetch_new_arrivals.py`（撈新品）＋`publish_styling.py`（部署+推Telegram）。判新品鐵則：後台 /admin/products/search 前 6 件已上架＋compare_at_price>price 判9折
踩坑：判新品一度誤用 special_collection_id（pm0606 混舊品 154 件）→ Kim 指正改掉。publish_styling.py 原本部署失敗吞錯推假連結 → 修成 Cloudflare Pages 專案不存在自動建、真失敗回 None 不推
首篇 demo W23「梅雨悶熱季，小隻怎麼穿不黏不悶又有型」上線 amesoeur-styling.pages.dev，綁 6 件新品，4 個知識點各綁一件，知識教學型 Reel 分鏡表產出，已推 Telegram

還想幫它做的

讀 Supabase reels_script_library 穿搭類卡片當 IG 靈感來源（接「讀靈感」管線）
穿搭圖配色建議自動化
將文章截圖做成可發 IG 的知識卡片

看它的實際設定檔（agent md）amesoeur-marketing-agent.md

---
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 決定。

日誌官

運作流程

說「記一筆」→讀 git／memory 真實進度→更新對應 .md 或資料→重建 HTML→部署 Cloudflare Pages→回 pages.dev 連結

一句話定位：這本「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遠端遙控、開發設計演進紀錄、指令速查表，以及這頁本身。

我學到什麼

「漏掉」本身就是好的紀錄點。把它寫進來、讓它成為故事的一部分，比遮掩或補救更有價值。

它的實際產出（示意）

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

示意 · 這就是這個作品集本身

Kim 的工作桌

AGENT 團隊

概覽

訂貨專員

出貨小幫手

數據分析專家

上架專員

行銷企劃

行銷小編

日誌官

穿搭誌

DeskMemo

Kim 的工作桌

它的產出就是你正在看的這個作品集本身——重建一次＝一個可分享的新版本

Reels Script Generator上線中

Payment Boy v2上線中

TG遠端遙控v1 上線

âme soeur Agent 團隊開發中

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

這個 agent 的開發日誌

06/15

記錄 DeskMemo 0.11.1 使用者回報→修→全平台發版→本機驗裝：deskmemo.md 補「0.11.1：月記字級＋視窗縮放把手」段落（起因、兩個修法說明、工程點、發版流程、本機驗裝方式、✍️ Kim 補充欄）；首頁 LOGS 加 06/15 里程碑，規格小檔日期改 2026-06-15；重建部署作品集

06/15

記錄 TG遠端遙控客服留言自動通知上線：telegram slug logs 加 06/15 詳細條目（資料源設計決策、敏感欄位處理、Kim 兩個後續校調），telegram-remote-bridge.md 補新段落，首頁 LOGS 加里程碑，重建部署作品集

06/15

記錄穿搭誌視覺升級（AI 生圖管線）＋W24 白話週報：marketing slug 加 cf_imagegen.py 管線踩坑記錄，analyst slug 加 W24 AI 層首跑診斷及抓到編造 bug，首頁 LOGS 加兩條 06/15 里程碑，重建部署作品集

06/11

為 DeskMemo 桌面便利貼新建作品集獨立分頁：新建 deskmemo.md 故事頁（故事型：為什麼做、一天版本演進 v0.1→v0.9.1、三大卡關與突破、Kim 設計總監角色、怎麼辦到的技術說明、✍️ Kim 補充欄）；NAV 加「DeskMemo」分頁；PRODUCTS 加條目（Electron/GitHub Actions/rcedit）；build() 加 view-deskmemo section；首頁 LOGS 加 06/11 DeskMemo 里程碑

06/11

把「評論信任感工程」升格為作品集獨立分頁：新建 review-trust-system.md 故事頁（四件事完整敘述、三輪迭代過程、預購店邀評兩個關鍵修正、為什麼走訂單留言而不走 email）；NAV 加「評論系統」分頁；PRODUCTS 加獨立條目；build() 加 view-reviews section；首頁 LOGS 更新 06/11 那條加分頁連結。Kim 說「他解決了最困擾我的事」

06/10

補記 ops 線（出貨/標籤）最近真實進展：首頁 LOGS 加 06/10 出貨標籤精準化里程碑，shipping slug logs 加 06/10 詳細條目（generate_shippable 新增、slug 改 labels-ship-<date>、動機說清楚）。照 git log + ops-notes 確認真實進度後才下筆

06/07

記錄穿搭誌這條線今天（跨 06/08 凌晨）的轉折：穿搭誌狀態從「上線中」改為「審視期」，PRODUCTS story 補四個新段落（編輯方向轉向 / Cyberbiz 死路 / 子網域可行但擱著 / 每週流程細節修正），marketing slug logs 加新條目，首頁 LOGS 最上面加里程碑。同時記錄週報升級需求（Kim 明確要分析師等級解讀＋外在因素、不要 if/else 套句，明天 06/08 週一起實作）

06/07

記錄 Reels app 本次大翻修（七大更新）：重生格機制＋定稿存檔分享頁＋挖出 JSON-mode 額度真因＋修 503 誤報成每日用完＋模型自動切換＋重做腳本產出邏輯（prompt 兩次退稿→找到價值爆點 DNA）＋品類防呆。穿搭誌 app #1–#7 全完成。首頁 LOGS 加里程碑，PRODUCTS story 補七個段落，content slug logs 加重做 prompt 紀錄

06/07

新增「穿搭誌」分頁進作品集，記錄 app 從靜態 HTML → Canva 死路 → 自建部落格 app 的完整轉折過程。PRODUCTS 加穿搭誌條目，NAV 加獨立分頁，首頁 LOGS 加 06/07 里程碑（穿搭誌啟動）。照實寫：狀態是建置中，#5 後台、#6 部署、#7 行銷 agent 接入都還沒做，誠實標

06/07

記錄今天行銷企劃 agent 誕生：新增 marketing slug 進作品集、建 amesoeur-marketing-agent.md 故事頁（設計決策：半自動 vs 全自動的取捨、Kim 親自寫不外包 Gemini、判新品鐵則定案、踩坑誤用 special_collection_id、publish_styling.py 吞錯假連結修復）。首頁 LOGS 加 06/07 里程碑，marketing slug 開發日誌補誕生條目，AGENT_STATUS 加行銷企劃。重建部署

06/07

記錄腳本生成器今天兩件事：① 語氣全面校正（依 2026 IG 演算法，由 content-editor 改寫 prompts.ts，刪喊單、hook 改三型、CTA 改軟邀請，已 commit）② 新增自然流量片 / 廣告素材片雙模式（types.ts + prompts.ts + GenerateForm.tsx，已 commit）。首頁 LOGS 加這筆里程碑，content slug logs 加詳細紀錄，腳本生成器 story 補兩段。重建部署

06/07

記錄今天兩件事：① 讀靈感 bug 修復（兩個疊在一起的 bug：模型過載無重試＋思考 token 截斷 JSON，分別加指數退避重試＋關 thinkingBudget）—— Kim 以為是扣打問題，查證後排除，4 支卡多天的影片全部匯入。② 新增「清除」逃生門指令（搬到備份夾不刪檔）。telegram-remote-bridge.md 補版本歷程段落＋更新目前狀態＋規格小檔，telegram slug logs 記詳細踩坑，首頁 LOGS 加里程碑

06/05

記錄今天兩件 Gemini 免費額度引發的事：① 腳本生成器「餘額不足」查清是 fallback 文案寫不準，/api/usage + Supabase + 燈號 + gemini.ts 拆兩種退模板原因，產品 story 補完整說明段落。② Telegram 讀靈感撞 quota 後失敗影片回傳機制——直接把失敗影片 sendVideo 送回手機附白話原因，今天 4 支實測回傳成功。兩件事根因同一把 key 被多流程共用，Gemini 免費版沒有即時查剩餘 API，只能自記次數。首頁 LOGS 加「失敗影片回傳」里程碑，telegram slug logs 加詳細紀錄，telegram-remote-bridge.md 補版本歷程段落

06/05

記錄腳本生成器用量儀表板＋fallback 修正：/api/usage + Supabase generation_usage 表、頁面頂常駐用量燈號、gemini.ts 拆 quota 用完 vs 暫時塞車兩種原因。首頁 LOGS 加這筆里程碑，產品頁 story 補「用量計數與 fallback 修正」段落

06/05

Kim 看了作品集後，補齊腳本生成器和 payment boy 兩個產品頁：各補了細節說明段落（腳本生成器加「可以吃影片當養分」＋「做成可安裝 App」兩段；payment boy 補 GBA 像素風的設計思路）、各加可折疊的 skill md 連結（仿照 agent 頁規格）。新增腳本生成器 PWA app 化里程碑進首頁 LOGS

06/04

記錄 TG遠端遙控「開機自動啟動＋一次故障排除」：Kim 在外傳指令沒回應，查是 bridge 沒在跑（不是壞），先把她要的清單補跑出來，再做開機自啟。最終解＝開機資料夾捷徑用 pythonw.exe 跑腳本（無視窗），腳本開頭把 stdout/stderr 導到 bridge.log。排坑四個：① WindowsApps python 別名非互動跑不動 → 用真實路徑；② schtasks 要管理員被拒 → 改開機資料夾（免權限）；③ WScript.Shell.Run 不能直接跑 .bat → cmd /c；④ 在 Git Bash 巢狀測 Windows 啟動是假象，要貼近真實情境才準。殘留 vbs/bat 可清。未解：日期破折號字元疑似非半形，待 Kim 重測

06/04

記錄了今天這件事本身：Kim 嫌 agent 一直問確認很煩，一起定出整套「可逆就直接做、不可逆才 gate」規章；起點是「查閱動作也要問 proceed」，終點是四類 gate＋一句話測試，進 safety.md。踩到的兩個教訓也一起記：「事後給 diff」≠「事前問准不准」、信 Kim 講的事實別覆核她

06/04

Kim 替六個夥伴取正式稱呼：訂貨專員／出貨小幫手／數據分析專家／上架專員／行銷小編／日誌官；整站名字從功能性 slug 改成有人格的稱呼

06/04

被 Kim 點出「記錄 agent 也該有自己的分頁」，補上第六個 agent 頁面
把「漏掉自己」這件事本身寫成起點故事的一部分，正式立為 journal-agent

06/03

正式立成第六個 agent（.claude/agents/journal-agent.md）
速查表整合進作品集時，把它漏掉了——這個「漏掉」後來變成故事的一部分

06/02

作品集 v4→v5：從開發日誌升格成以產品為主軸的 Founder Notebook
建立 build_journal.py：零依賴生成 HTML→部署 Cloudflare Pages 一條龍

還想幫它做的

主動偵測「有實質動作」就自動提醒記一筆
作品集版本快照：每次大改前存一版可比較的歷史

看它的實際設定檔（agent md）journal-agent.md

---
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 指令→橋比對白名單→叫本機腳本跑→抓 pages.dev 連結→回傳手機

一句話定位：人在外面，電腦自己跑——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-15）

Kim 的需求很具體：「後台有顧客在訂單留言或詢問時，自動推我 Telegram，不要讓我一直進後台翻。」

資料源選擇是這次最關鍵的設計決定。

第一直覺是「一張訂單打一次 API，輪詢全部訂單的留言」——但 Cyberbiz 訂單動輒幾百張，這樣做每 30 分鐘就要打幾百次請求，成本高、也容易被鎖。查了一下，發現 GET /admin/message_posts/get_list 這個全站訊息中心端點：一個請求就能拿到所有近期更新的對話串，每串已內含完整 comments 陣列，完全不用 per-order 輪詢。

踩點：這個端點的回傳帶有 OTP secret、token 等敏感欄位。 設計上只抽需要的四個欄位（訂單號、顧客名、留言內容、時間），不存原始 payload，也不 log 到 bridge.log。

留言分流的判斷邏輯：

Cyberbiz 訂單留言混了兩種東西——真的是顧客說話的（role 以 customer 開頭），以及後台操作產生的備註（admin_note_<email> 格式，出貨/訂貨自動留的「出」字記錄就是這個）。只有前者才推，後者全部忽略，不然後台一跑出貨清單就狂響。

首跑 seed 機制： 第一次啟動時，自動把現有的 35 筆顧客留言標成「已讀」，避免上線第一秒就把幾個月的歷史留言一口氣全推出去。之後靠 comment id 做 dedupe。

Kim 後續兩個校調（當天）：

只推「未回覆」的（status != replied）——她已經在後台回覆過的留言不需要再推，否則等於每回一次就再收到一次通知。
輪詢間隔 30 分鐘（POLL_SECONDS=1800）——每 5 分鐘太頻繁，她說 30 分鐘夠了，不急的事。

整合方式： 新增 cs_notify.py（state 存 _cs_notify_state.json），在 telegram_bridge.py 啟動時起一個背景 daemon thread 跑 cs_notify.run_loop()，不另建排程器。改了 cs_notify.py 的程式碼，要重啟 bridge 才會換新碼生效。同時在 HELP 加了「客服區」說明，新增 客服 on-demand 指令（手機打「客服」→ 立刻撈一次有沒有新留言，不用等輪詢）。

端到端驗證：--summary 模式實撈到真實顧客留言、測試訊息成功送達 Kim 手機、bridge 重啟後 log 顯示「CS notify loop started, polling every 1800s」。

### 讀靈感匯入失敗 + 清除指令（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 手機驗收。
後台客服留言自動通知（2026-06-15 完成）：cs_notify.py 每 30 分鐘輪詢全站訊息中心，顧客新留言推 TG 通知（admin_note 內部備註過濾掉，只有真顧客說話才響）；客服 on-demand 指令隨時觸發；首跑 seed 35 筆已讀避免歷史全推；端到端驗證通過。

v2 方向

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

它的實際產出（示意）

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

示意 · 實際指令互動

aKim_amesoeur_botbot · 線上

出貨 06/0414:32

收到，整理出貨清單中…14:32

出貨清單好了
區間訂單 8｜全現貨可出 3
amesoeur-ops-report.pages.dev ↗14:33

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

這個 agent 的開發日誌

06/15

客服留言自動通知上線：新增 cs_notify.py，每 30 分鐘輪詢 Cyberbiz 全站訊息中心端點 GET /admin/message_posts/get_list，有顧客新留言就推 Telegram 通知。資料源設計是關鍵——這個端點一次返回所有對話串含 comments，不用一張訂單打一次 API，省掉大量請求。只推 role 以 customer 開頭的留言，後台大量 admin_note 備註（出貨/訂貨用的「出」字記錄）全部忽略。首跑自動 seed 現有 35 筆已讀，避免歷史留言一口氣全推；dedupe 用 comment id。Kim 兩個後續校調：① 只推「未回覆」的（status != replied，她已回過的不煩她）② 輪詢 30 分鐘（POLL_SECONDS=1800）。跑在常駐 bridge 背景執行緒，不另開排程，改碼要重啟橋。端到端驗證：--summary 實撈到真實顧客留言、測試訊息送達手機、bridge 重啟後 log 顯示輪詢已啟動。踩點：端點回傳含 OTP secret 等敏感欄位，只抽訂單號/顧客名/內容/時間，不存原始 payload

06/08

新增「標籤」指令（LABEL_WORDS 路由）：手機打「標籤 06-08」或「標籤 4368 4367」→ 橋在本機跑 ops_labels.py → 生出標籤頁部署到 ops pages.dev → 連結回手機。支援日期模式（當日所有訂單品項展開）和訂單號模式（指定幾張單只生那幾張）兩種呼叫方式

06/07

修好「讀靈感」匯入影片失敗（`process_inbox.py`）。Kim 原本以為「一天只能匯入一次」，查證後否定（免費層 250–1500 RPD、同次有成功匯入），真因是兩個 bug：① 撞模型過載「This model is currently experiencing high demand」，原程式單次就放棄→ 加指數退避重試最多 5 次（3/6/12/24 秒，認 high demand/overloaded/503/429/network）；② 撞 JSON 截斷（Unterminated string）→ 2.5-flash 思考 token 吃光 maxOutputTokens → 修法：thinkingBudget=0＋maxOutputTokens 4096→8192。卡多天的 4 支 inbox 影片全部成功匯入，inbox 清空，手機「讀靈感」連帶修好
新增「清除」指令（逃生門）：手機打「清除／清空／清掉／清靈感」→ `clear_inbox()` 把收集夾裡還沒匯入的影片搬到 reels_inbox/cleared/ 備份（不刪檔），回報清了幾支。判斷排在「靈感」之前避免「清靈感」誤觸讀靈感。HELP 已加說明。bridge 重啟（2026-06-07 15:50 boot、連上 @Kim_amesoeur_bot），待 Kim 手機實打驗收

06/05

「Reels 靈感收集 → 腦本生成器」功能完成，Kim 手機實測通過：螢幕錄影 Reel → 傳 bot → 打「讀靈感」→ 電腦 Gemini 2.5 Flash 分析（抓口白+字卡+分鏡）→ 腳本卡寫入 Supabase → 手機回 IMPORT REPORT。腳本庫 26→27 筆，端到端整條通。零封號風險：完全不碰 IG API/登入/爬蟲，影片統一螢幕錄影後轉寄。
解決 Gemini 金鑰卡關：原本 .env.local 的 GEMINI_API_KEY 是佔位字。Kim 從 Google AI Studio 拿到真 key（免費 tier），貼進 .env.local，實測 generateContent 回 200 OK。
用真實 Reel 端到端驗證：Kim 手機螢幕錄影包包 Reel（3.1MB）→ 傳 bot → bridge 收檔存進 reels_inbox/，回「OK saved to inbox」。電腦跑 process_inbox.py：Gemini 真的「看完影片」，抓出 9 場分鏡＋口白＋字卡（含示範雙開口設計、側袋放洗手液、限時優惠$981）→ 品牌判讀、情緒設計、CTA、可複製重點、改寫成 âme soeur 版腳本、建議商品、參考價值4★、自動標 is_recommended。這是這次最大突破：caption 根本抓不到「過程腳本」，Gemini 多模態把影片裡的口白+字卡+分鏡全抽出來了。
手機觸發「讀靈感」指令（INSPIRE_WORDS + run_inbox()）：手機打「讀靈感」→ 橋在電腦跑 process_inbox.py → 把 IMPORT REPORT 回傳手機。Kim 實測「讀靈感」→ 回「Inbox empty: 0 videos」，整條手機→電腦→回報的迴路通了。現在全部可手機操作，電腦開著即可。
修小瑕疵：rewritten_version 有時被 Gemini 回成巢狀 JSON、存成帶 \u 編碼的醜字串 → 加 as_text() 用 ensure_ascii=False 轉乾淨中文。已知既有一筆舊卡片的該欄是舊醜版，待清，誠實標。
bridge 重啟兩次：第一次因 bash 吃掉 $(Get-Location) 短暫斷線幾秒，第二次加「讀靈感」後重啟。最終乾淨一個 pythonw 在跑，連上 bot，開機自啟不受影響。回報一律英文（避中文 pipe 編碼坑）。

06/05

讀靈感失敗影片回傳：今天實際撞 quota——5 支進 1 成功（Gemini 200 OK），3 支「exceeded quota/billing」，1 支 JSON 格式壞掉（Expecting value）。原本 Kim 手機收到的失敗報告只有一串時間戳檔名，認不出是哪支影片、也不知道為什麼壞。修法：bridge 把「跑 process_inbox 後還留在 reels_inbox/ 沒被搬走的影片」（成功才搬到 done/）逐一用 sendVideo 傳回 Telegram，附白話原因（quota 用完＝明天再試；JSON 壞掉＝格式問題）。今天那 4 支實測回傳成功。根因：同一把免費 Gemini key 被 web app＋讀靈感＋本機測試三個流程共用，比預期更快撞每日上限；Gemini 免費版不提供即時查剩餘額度的 API（header 無 ratelimit 欄位），只能靠 app 端自記次數估。

06/04

修 bot 回報中文亂碼（Kim 手機收到「2026-06-04█U█w█e█L 1 … LBP161/LBP162」）：列印其實有成功，亂的只是回報文字——子腳本在 Windows 用 cp950 吐中文、橋用 utf-8 讀，對不上。判別：英數正常、中文+｜+→+emoji 全變 █。修法：跑子程序帶 PYTHONIOENCODING=utf-8，一處修、所有指令通用。結論：維持中文不退英文（退英文只治標還難讀）

06/04

Kim 手機列印「還沒印就關起來」三坑全修，本機端到端驗過（故意把預設切到離線 Xprinter → 跑腳本 → 自動搶回 Canon → 印出 → 佇列清空）。待 Kim 從手機實打「列印」做最終驗收
坑一「還原網站泡泡」：每次 kill Chrome 留 Crashed 旗標 → 下次跳還原視窗搶焦點、window.print 打不到 → 修法：啟動前清 crash 旗標 + --hide-crash-restore-bubble
坑二「遠端圖片卡列印」：列印頁有 4 張 Cyberbiz CDN 圖，綁 load 事件才印 → 圖慢時 load 不觸發 → 修法：改成「load 完成或最多 3.5 秒就印」+ 盯印表機佇列確認工作真的 spool 進去才關 Chrome
坑三「預設印表機亂跳」：Windows 自動管理預設印表機 → Canon 雷射機 ↔ 離線 Xprinter 標籤機間跳，跳到 Xprinter 就悄悄失敗 → 修法：每次列印前用 WScript.Network COM 鎖定 Canon LBP161/LBP162，關掉自動管理

06/04

開機自動啟動裝好：pythonw.exe + 開機資料夾捷徑，電腦開機橋就跑。排了四坑：WindowsApps python 別名 → 真實路徑；schtasks 要管理員 → 開機資料夾；WScript 不能直接跑 .bat → pythonw 直跑；Git Bash 巢狀測 Windows 是假象 → 直接重開機看 bridge.log

06/04

v1 上線：Kim 在外打 Telegram 指令 → 本機跑出貨/訂貨/週報腳本 → 連結回手機。long-poll 不需架伺服器；白名單 chat id 第一次自動綁定；日期參數 regex 驗過才執行，防注入

06/04

加上「列印」指令：手機打「列印 6/4」→ ops_auto_print.py 判斷可出訂單 → Chrome --kiosk-printing 靜默送印。Edge 同樣參數不送印，最後改用 Chrome 才通

還想幫它做的

v2 接 Claude API：自然對話、看圖、想 Reels 腳本，不用背指令格式
加入「確認 gate」：列印、標記出貨等不可逆動作回問一次再執行

← 回出貨小幫手

商品標籤

一句話定位：出貨前要貼的吊牌標籤——我說「標籤 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

紀錄筆記

做這些工具時的一些紀錄——包含這個網站自己一版一版改過來的過程。

純文字

像說明書、字牆。

數據帶

有重點與結構。

我

書本排版

襯線、落款大字。

產品主軸

產品 showcase。

Workdesk

個人工作桌儀表板。

這個作品集自己的誕生

一句話定位：你正在看的這頁，本身也是一個「從草稿改到成品」的作品——它從一份開發日誌，長成一個以產品為主軸的 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

指令速查表

不用記指令，看到對的情境照念例句就會自動跑。釘在書籤、忘記時回來看。

① 口語快捷指令

不用打 /，也不用指名 agent。直接用自然口語就好 —— 看到關鍵字會自動派對的角色、讀對的 memory、跑對的流程。所有產出都回可分享連結，不丟本機路徑。

你想做的事	直接說（任選）	誰會接
產週報Cyberbiz＋GA4＋META＋IG 四源整合，只跟你要 IG 截圖	「幫我產這週週報」「weekly report」	analyst-agent
產月報整月訂單／折扣三層／AOV／新品成效	「產 5 月月報」「monthly report」	analyst-agent
訂貨／補貨清單撈範圍內所有「(預購)」品加總，給日期就好	「訂貨 6/3」「訂貨 6/1 到 6/3」	ops-agent · 一條龍
出貨／可出清單分全現貨可出／部分／全預購，你確認後才產列印連結	「出貨 6/3」	ops-agent · 一條龍
上架新品讀表單→生文案→填後台，先設未公開、每步截圖確認	「上架新品，表單最新那筆」「上新品」	listing-agent
本週文案包Threads＋IG Caption＋Reels 參數	「產這週的文案包」「weekly content」	weekly-content
改文案／潤稿／寫腳本直接給成稿，不只給建議	「這段幫我潤一下：……」「改稿」	content-editor
檢查文案／品牌檢查禁用詞、性別預設、節奏	「這篇幫我做品牌檢查」「brand check」	brand-check
保存進度存當前狀態到 memory，不結束任務	「checkpoint」「記一下」「儲存一下」	我自動寫
接續上次讀 current-task.md 繼續做	「繼續上次」「resume」「接著做」	我接續
更新作品集／記一筆日誌刷新日誌與各 agent 開發紀錄→重建部署	「更新一下作品集」「這件事記一筆」	journal-agent

② 六個專職 agent

其實不用指名，描述你要做的事就好，我會自己派對角色。這張表只是讓你忘記時對得上號。

Agent	管什麼	照念例句
amesoeur-analyst-agent數據分析	週報月報、訂單／折扣／AOV、GA4 流量、META 廣告 ROAS、IG 洞察、轉換率異常診斷。會做四源交叉診斷、建議附範例。	「這週轉換率怎麼掉的，幫我看 GA4 漏斗」
amesoeur-ops-agent營運出貨	訂貨（撈預購加總成補貨清單）、出貨（判斷現貨可出、產列印清單）。只檢視不改設定，最後動作交你確認。	「這批預購現貨混在一起，幫我理出哪幾張能先出」
amesoeur-listing-agent商品上架	把新品完整上架 Cyberbiz：填資訊、寫描述、SEO、表單對應欄位。先設未公開、每步截圖。缺資料會停下來問。	「把表單最新這筆新品上架到後台」
content-editor內容改寫	改寫／整合 Threads、IG Caption、產品文案、郵件，並檢查品牌語氣。並列「原文→改寫版」。寫文案前自己抓官網真數據。	「這三段 Threads 幫我潤成可發版本」
journal-agent持續記錄	維護「AI 產品作品集／Kim 的工作桌」這本 Founder Notebook：把問題、卡關、里程碑、決策持續記成日誌，重建並部署。看到好的紀錄點會主動記。	「這件事記一筆到日誌」「更新一下作品集」

③ 系統斜線指令

①② 是「叫我做事」；這裡是「控制對話本身」—— 像壓縮、清空、看花費。直接打 / 會跳出選單。最常用：/compact（對話太長變慢時壓縮）、/clear（要做不相干的新事時清空）。

指令	用途	什麼時候用
/compact	把長對話壓成摘要，釋放記憶體又保留重點（不會丟掉進度）	對話很長、開始變慢或變貴時
/clear	清空對話、開全新一輪	要做完全不相干的新任務時
/context	看目前 context 用了多少、還剩多少空間	想知道是不是快爆了
/cost	看這次 session 花了多少 token	想抓花費
/model	切換模型（Opus／Sonnet／Haiku）	想更快或更省時
/fast	開關 Fast 模式（Opus 加速輸出，不會降級成小模型）	想要回應更快
/agents	檢視／管理 subagent	想看或調整那 5 個 agent
/memory	直接編輯 memory／CLAUDE.md（我記住的設定）	想自己改我記得的東西
/config	開設定（主題、模型等偏好）	想調介面或預設
/help	列出所有可用指令	忘記有哪些指令時