hi, I'm Kim.

訂貨 agent

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

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

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

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

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

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

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

成果

現在我只要說「訂貨 6/3」，大概一分鐘就拿到一張可以直接傳給廠商的清單，現貨會自動排除，連結打開就能看。

我學到什麼

它的實際產出（示意）

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

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

出貨 agent

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

起點：分不清哪一張能出

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

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

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

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

成果

出貨判斷從一張張看，變成一份已經分好類的清單，我只要勾要出哪幾張就好。

我學到什麼

它的實際產出（示意）

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

規格小檔　狀態：上線中｜唯讀、不誤觸後台｜輸出：可出清單＋列印頁｜工具：Claude Code＋Playwright＋Cyberbiz｜最後更新：2026-06-02

分析 agent

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

起點：數據散在四個地方

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

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

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

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

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

成果

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

我學到什麼

它的實際產出（示意）

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

規格小檔　狀態：上線中｜四源整合（Cyberbiz＋GA4＋META＋IG）｜輸出：週報＋分享連結｜工具：Claude Code＋GA4／META API｜最後更新：2026-06-02

上架 agent

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

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

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

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

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

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

成果

上架從一格一格手填，變成它先填好、我看過再公開。

我學到什麼

它的實際產出（示意）

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

規格小檔　狀態：開發中｜先存未公開、節點截圖確認｜工具：Claude Code＋Cyberbiz 後台｜最後更新：2026-06-02

文案 agent

一句話定位：我說「改文案」，它就把零散草稿改成 âme soeur 的語氣——溫柔、不推銷。

起點：語氣常常跑掉

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

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

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

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

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

成果

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

我學到什麼

它的實際產出（示意）

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

規格小檔　狀態：開發中｜品牌語氣改寫／檢查｜模型：輕量、省成本｜最後更新：2026-06-02

這個作品集自己的誕生

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

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

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

過程：一版一版調

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

卡關與突破

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

成果：從草稿到成品

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

我學到什麼

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