# 王董 Growth Hacker.md
> 閱江湖、看路徑、寫筆記
Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts.
Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`).
## Pages
### About this site
URL: https://growthhackers.tw/about/
Last updated: 2026-04-13T16:02:34.000Z
王董WANGDON is an independent publication launched in April 2026 by Lewis wang. If you subscribe today, you'll get full access to the website as well as email newsletters about new content when it's available. Your subscription makes this site possible, and allows 王董WANGDON to continue to exist. Thank you!
### Access all areas
By signing up, you'll get access to the full archive of everything that's been published before and everything that's still to come. Your very own private library.
### Fresh content, delivered
Stay up to date with new content sent straight to your inbox! No more worrying about whether you missed something because of a pesky algorithm or news feed.
### Meet people like you
Join a community of other subscribers who share the same interests.
---
### Start your own thing
Enjoying the experience? Get started for free and set up your very own subscription business using [Ghost](https://ghost.org/?ref=growthhackers.tw), the same platform that powers this website.
### 搜尋王董，幫助你數位行銷搞懂
URL: https://growthhackers.tw/wangdon/
Last updated: 2021-06-26T09:38:37.000Z
# 雨傘男孩的王董
愛讀冊，愛台語
## 最新網路行銷、學習文章
如果喜歡我的文章，歡迎訂閱我的電子報
### Blog
URL: https://growthhackers.tw/blog/
Last updated: 2019-10-08T18:48:28.000Z
## Blog
對很多東西總是充滿好奇和興趣，很開心和你分享我的學習紀錄，也希望透過我的文章能夠幫助到你。
如果喜歡我的文章
歡迎訂閱我的電子報
有最新文章，我會寄送給你
### CMX Taiwan 給社群經理的社群讀書會
URL: https://growthhackers.tw/cmx-taiwan-study/
Last updated: 2021-03-27T07:11:50.000Z
CMX Taiwan 給社群經理的社群讀書會的活動，一季為一個梯次，每月會由大家票選一本書籍，挑出一天的晚上來分享，會請大家各自攜帶一道菜一起晚餐，並會邀請適合該主題領域的夥伴來幫大家導讀，並且會有夥伴們來介紹自己的閱讀心得，以及自己經驗分享，往往都還會有特殊來賓的參與，更是收穫滿滿。
CMX 每個月會舉辦 [CMX 給社群經理的社群大聚](http://growthhackers.tw/blog/category/cmx/)活動，過往的活動可以參考我們的心得文章。
申請加入 CMX 讀書會：*https://lihi1.com/mJiSz*
## 讀書會夥伴們的滿滿心得分享
[在 Facebook 上查看](https://www.facebook.com/berlin.yeh.7/posts/2547578041965523)
[在 Facebook 上查看](https://www.facebook.com/ikuseilee/posts/10211757673137336)
[在 Facebook 上查看](https://www.facebook.com/ju.chu.75/posts/2708145115862427)
[在 Facebook 上查看](https://www.facebook.com/xup6g/posts/2703653489645241)
### 數位行銷情報局
URL: https://growthhackers.tw/mia/
Last updated: 2021-01-24T16:37:03.000Z
### 數位行銷最前線
定期分享國內外等媒體最新的數位行銷知識
### 學習筆記
分享筆者參與的活動｜講座｜閱讀書籍的相關學習筆記與心得
### SEO 自然搜索
SEO 相關的知識與操作方法，讓內容帶來高自然流量
### 電子商務
電子商務的相關操作方法與知識文章探討
### 社群行銷
社群媒體操作、線上線下實體社群活動經營等知識行文章
### 成長駭客
如何透過成長駭客讓自身的商業快速發展｜運用到產品上
## 本站宗旨
- 數位行銷日星月異，時常有變化，因此本站的宗旨是希望透過定期分享國內外數位行銷新知識，用深入淺出的方式，除了讓數位行銷人員能更掌控數位新知以外，更可以讓一般大眾，或是剛入門的新手更了解數位行銷的相關知識
### 王董
傳產轉生數位行銷人
[**觀看介紹**](https://growthhackers.tw/wangdon)
### Rae
跨境電商｜數位行銷
[**觀看文章**](https://growthhackers.tw/rae)
###
####
一鍵訂閱
## Posts
### subagent vs skills 怎麼選？Anthropic 電商 agent 藍圖：一個領域一個 subagent 是錯的
URL: https://growthhackers.tw/blog/skills-vs-subagents-commerce-agent-architecture/
Last updated: 2026-09-07T13:00:00.000Z
九月二號，Anthropic 開源了一份 commerce agent（電商代理）藍圖，裡面有兩隻做好的 agent：一隻 shopping agent 裝在你的網站或 App 裡面對客人，一隻 merchant agent 給後台同事用來顧店。同一天還丟了一篇工程深度文，作者是 Matthew Koen 跟 Ali Shazal。
十一則客戶證言，Visa、Mastercard、Accenture、Priceline、Intuit、Shopify、Klaviyo、Wix、Zomato、Square 等都在裡面。Wix 說他們工程師十五分鐘內就跑起一隻會接 prompt 的 commerce agent。
大家都在看那十一則證言。
如果你問我，這份藍圖最值錢的東西不在證言，在那篇工程文的第一段。因為它直接否定了現在多數台灣團隊規劃 AI agent 的方式。
## 你正在照組織圖拆 agent，而那是錯的
你要做電商 AI 助理，開會第一件事通常是拆分工：客服 agent 管退換貨、選品 agent 管推薦、定價 agent 管促銷、庫存 agent 管補貨。畫成一張圖，漂亮、模組化、每個 agent 各司其職，看起來就像一張組織圖。
很直覺對不對？我們做管理的腦袋本來就是這樣長的。
Anthropic 在 [A guide to the anatomy of effective commerce agents](https://claude.com/blog/the-anatomy-of-effective-commerce-agents?ref=growthhackers.tw) 裡面說，這樣做在實務上是次佳解。理由很硬：一段購物對話是**一個緊密耦合的 session**，橫跨很多意圖、很多回合，需要大量共享脈絡。
在 subagent（子代理）架構下，orchestrator（總調度）手上握著購物車、暫存的變更、客人的偏好、整段對話歷史。而每一次交接給 subagent，都是一次 **state-lossy（會掉狀態）的操作**。
原文講得很白：每次交接常常拉低 subagent 回覆的品質，接著拖累整體回覆，而且可能多花數倍的 token、多出好幾秒的延遲。
三種稅。狀態遺失稅、token 稅、延遲稅。每交接一次收一次。
交接稅：購物車在 agent 之間交接的瞬間，狀態、token 與延遲同時流失
更麻煩的是，領域根本切不乾淨。
台灣電商最好的例子就是超商取貨退貨。客人在 LINE 上面問「我上禮拜那雙鞋想退」，這一句話同時要碰訂單系統、物流系統、金流系統、庫存系統，還要判斷有沒有超過七天猶豫期、退貨要不要扣運費、超商退回來的貨要不要立刻回補到可售庫存。
你要怎麼叫一隻「退貨 agent」自己處理完？它手上沒有購物車、沒有商品目錄、沒有客人剛剛講過的話。
要嘛你把這些存取權在每一隻 subagent 都複製一份，要嘛你在任務做到一半的時候交接出去。兩條路都難看。
一筆退貨請求同時觸及訂單、購物車、商品目錄三個系統，切不成一個領域一隻 agent
## Anthropic 沒有打臉自己，是業界抄錯了作業
這裡要幫 Anthropic 講一句公道話，因為我看到不少人把這件事解讀成「Anthropic 推翻自己的 multi-agent 主張」。
不是這樣。
Anthropic 2025 年那篇《How we built our multi-agent research system》講的是 orchestrator 加三到五隻並行 subagent，在**研究任務**上贏過單一 Opus 4 達 90.2%，但吃掉大約 15 倍的 token，而 token 用量本身就解釋了 80% 的表現差異。
請注意那兩個數字的適用範圍：90.2% 跟 15 倍都是**研究任務**測出來的，不是電商場景的數字。
15 倍不能直接外推到電商，但它呼應了深度文提醒的那筆 token 稅。
所以這兩篇文章根本不衝突。同一家公司，先給了一個「深度研究這樣做很讚」的實驗結果，現在把界線畫出來：**對話型任務用 skills，只有狹窄、自成一體、值得給它獨立脈絡視窗的任務才用 subagent。**
出問題的是中間那段。業界把一個為深度研究量身測出來的結論，誤植成所有 agent 的預設架構。
那 subagent 什麼時候才對？原文只留兩種場合。
第一種，orchestrator 把它當一個 tool 來呼叫的狹窄、自成一體任務，值得有自己的脈絡視窗。典型就是 deep research subagent：搜尋、讀文件、跑程式、撞死路，全部在裡面發生，最後只有一個精簡答案回到主線。
第二種，那個領域本來就有自己專屬的 agent 跟合規面，例如藥局或金融服務。這時候正解是**真正的 hand-off**，讓那隻 agent 直接對客人、用自己的迴圈把任務做完。
差別在「對話的所有權」。hand-off 是把客人交出去，那隻 agent 變成客人的對話對象；delegation 則是總調度留著所有權，把領域 agent 在同一個回合裡拉進來又推出去，每交換一次就衰減一次。
## 那不用 subagent 用什麼？用 skills
Skills 給你很接近的 per-domain 模組化跟脈絡控制，但沒有交接稅。
你知道為什麼嗎？因為 skill 的指令是**直接載入那隻已經握有全部歷史的主 agent**。沒有人被交接出去，購物車一直在手上。
這就像從「把客人在部門之間轉來轉去」進化到「同一個櫃哥，需要哪本作業手冊就翻哪本」。我以前在百貨做專櫃的時候最怕的就是把客人交給別櫃，一轉手，客人剛剛講的尺寸、預算、要送誰，全部要重講一次，成交率當場掉一截。AI agent 的交接，掉的東西一模一樣。
Anthropic 說在多個企業部署的比較裡，單一 agent 加 skills 在品質上一貫勝過「一個 prompt 包全部」跟 subagent 兩種設計，而且往往每個任務的成本跟延遲還更低。
那要怎麼決定一段指令放 system prompt 還是放 skill？原文給了一條很好用的起點：**佔三分之一以上流量的功能放 prompt，其餘放 skill**。因為載入一個 skill 要花掉一個 model turn。
安全規則、法務規則、品牌限制、關鍵客人事實（例如過敏），一律放 system prompt，不准放 skill。
照這條規則，商品搜尋會放在 prompt 裡，因為幾乎每個 session 都會用到；而退貨客服、活動企劃這種長尾功能就各自打包成 skill。merchant agent 那邊是一個營運領域一包，銷售分析、庫存、定價促銷各自獨立。
看到這裡如果你覺得「skill 聽起來很好，那我多加幾包」，先等一下。我之前寫過[為什麼 skill 越加越多、AI 反而越不聽話](https://growthhackers.tw/blog/writing-great-agent-skills/)，那個坑是真的。還不清楚 skill 到底是什麼的，可以先看這篇 [Agent Skills 入門整理](https://growthhackers.tw/blog/agent-skills-andrew-ng-course/)。
我自己就在踩這個坑。這個部落格的寫作產線就是用 Claude Code 搭的，裡面同時有 skills 也有 subagent。什麼時候該讓 subagent 去跑、什麼時候該讓主線自己拿著 skill 做完，我試錯過很多次。體感非常一致：只要任務需要「記得前面講過什麼」，交接出去就會掉東西，回來的東西你還得再對一次。
## 順便戳破一個省錢的迷思
講到成本，多數老闆的直覺是「換一隻便宜的模型」。
原文這段的判斷剛好相反。
第一，在 agentic 介面上，真正推動留存、互動、客單的是**結果品質**，也就是答案切不切題、任務有沒有真的完成。這件事比省下那零點幾秒的延遲重要得多。
第二，成本要算**每個完成任務的成本**，不是每次呼叫的成本。
你知道為什麼嗎？一隻比較笨的模型，可能要多跑好幾個回合才做得完同一件事，或者乾脆失敗讓客人重問一次。單次呼叫便宜，總帳更貴。原文甚至指出，更聰明的配置有時候連延遲都贏，因為它把 tool call 規劃得更好、需要的輪次更少。
所以選模型要用整套 eval 掃過去（原文建議 merchant agent 從 Opus 起跳，面對消費者的 agent 從 Sonnet 起跳），拿數字決定，不要拿感覺決定。
## 上線之後真正會燒到錢的那條
架構決定一次就好。真正會讓你半夜接到電話的是第三段。
原文的核心主張一句話：**prompt 是安全行為的起點，但在電商不能是安全的執行點。**
因為電商的失誤是財務性的、而且常常不可逆。一條 prompt 規則距離被繞過，只差一次注入攻擊或一個壞樣本。
所以藍圖的做法是：**模型只能提案，執行由人或政策決定。**
下單、付款、退款、改價、活動上線，全部收束到 harness（外框程式）控制的動作。消費者端做得很絕：checkout tool 只負責把購物車跟一顆下單按鈕渲染出來，而 agent 呼叫的那個後端介面**根本沒有扣款方法**。它想扣也扣不了。
商家端每個寫入 tool 都只產出一筆暫存變更，要有人在真實介面按下核准才會生效。而且護欄是在核准的**當下**拿最新的限制重查一次，不是沿用暫存當時的限制。
翻成台灣電商聽得懂的話：這就是你本來就在跑的「行銷提案，主管核准」。藍圖只是把這個 maker-checker 流程從 Google 表單搬進程式碼裡。
模型只能提案，只有人能按下執行：maker-checker 閘門
還有兩條，我認為對台灣電商特別重要。
一條是**寫入跟渲染只認 server 真的發過的 ID**。harness 會記錄這個 session 內 server 交給模型的每一個 ID，那是唯一被接受的鑰匙。幻覺生出來的、客人自己貼上的、埋在商品評論裡的 ID，在碰到後端之前就被擋掉。
另一條是**受規管的文案由 server 逐字提供**。模型只能選要揭露哪個商品，每一個字都從核准過的文案來，而且 eval 會逐位元組比對渲染出來的字串。運費、超商取貨手續費、七天猶豫期，這些東西不能讓模型自己改寫。標錯價在台灣電商是會上新聞的，改價幅度、折扣深度、活動預算的上限，全都要當成護欄寫死。
memory 那段也值得一看：Anthropic 建議**非同步寫入**，在每個回合結束後（長對話則每幾個回合）由另一個 thread 讀對話存事實。這樣做在他們內部的 commerce memory eval 上，事實召回率比讓 agent 即時存**高出 13%**，而且完全不佔用客人等待的時間。想多了解 agent 記憶怎麼運作，可以看我之前解碼的[兩個記憶原語](https://growthhackers.tw/blog/anthropic-agent-memory-dreaming/)。
## 台灣中小電商該怎麼動
先講一件很多人會忽略的事：這份藍圖**不附任何 MCP connector**，你得自己透過 backend interface 去接你的系統。
意思是，如果你是 91APP、Shopline、Cyberbiz 上面的品牌，這份東西不是你今天下載就能用的。你多半會是等平台把這層做進來。但看懂它，你才知道該去問平台什麼問題。
順帶釐清一個定位，免得跟前陣子的新聞搞混：[Shopify 的 UCP](https://growthhackers.tw/blog/shopify-ucp-cli-agent-commerce/) 是跨平台的「協定」層，處理不同家的 agent 怎麼跟不同家的店溝通；Anthropic 這份是單一供應商的「架構實作」層，處理你自己那隻 agent 內部怎麼蓋。兩件事互補，不衝突。
► **第一：先把「agent 能不能自己執行」這題答完，再談模型選哪個。** 開會第一個問題不該是用 Opus 還是 Sonnet，而是「下單、改價、發折扣碼這三件事，有沒有寫在程式碼裡擋住？」寫在 prompt 裡不算。
► **第二：從小開始，而且是真的很小。** 藍圖自己建議 shopping pilot 只實作搜尋跟商品詳情、其餘全部先擺著；merchant pilot 只實作八個唯讀方法，寫入一律拒絕。翻成白話：先讓 agent 會查商品、查訂單、查物流、查庫存、查活動報表，但一筆資料都不准改。報表跟每日摘要照樣能跑。先讓它「會看不會動」。
► **第三：把 LINE 官方帳號當第一個落地點，但先做唯讀。** 查訂單、查物流、查退貨政策，這三件事就能吃掉大量客服工單，而且完全不碰寫入，出事的上限很低。
► **第四：prompt caching 這題要去問，不要自己猜。** 快取讀取只要新 token 的十分之一，最好的部署跑在 90 到 99% 的 cache hit rate。最常見的錯誤是把時間戳記或當前頁面放在 system prompt 最前面，那會讓快取每一個請求都無聲失效。自建團隊照 Global、Session、Volatile 的順序排；用平台的就直接問平台商一句：「你們的 cache hit rate 多少，有沒有報表可以看？」這一題直接決定你的 AI 帳單。
同樣的內容換一個順序，就是溫熱快取與整條失效的差別
► **第五：檔期凍結要把 agent 算進去。** 雙 11、週年慶、母親節，你本來就會凍結系統上線。agent 是**一個部署單位**，一個壞改動會一次打到所有客人。自建就先滾 canary；用平台的就要求兩件事：檔期前兩週凍結話術與技能變更，以及提供一個不用重新部署就能單獨關掉某個功能的開關。
## 最後
工程文結尾那句話我很喜歡：這裡面大部分東西都跟模型無關。tool 呼叫的是你已經在跑的系統，skill 編碼的是你已經在遵循的流程，eval 是你的產品需求文件寫成測試。
以前我們評估一個 AI 專案，第一個問題是「模型夠不夠聰明」。現在真正決定成敗的是「你的系統邊界劃在哪裡」。
而且這套東西的射程比聊天視窗遠。再往後看，你店裡的流量會有一部分來自**替客人購物的外部 agent**。到時候，讓你自己的 agent 守規矩的那套暫存與核准規則，剛好就是你敢把 tool 開放給外面 agent 的底氣。
想清楚前台要解什麼任務，可以搭配看[AI 購物助理該解的三種任務](https://growthhackers.tw/blog/retailer-ai-assistant-jobs-to-be-done/)。那篇談客人要什麼，這篇談後面怎麼蓋。
藍圖在 [anthropics/commerce-agents](https://github.com/anthropics/commerce-agents?ref=growthhackers.tw)，四個垂直範例（零售、旅遊、電信、票務）全部用虛構品牌 ACME，不會真的下單也不會扣款，可以放心跑。官方發布稿在 [Building Commerce Agents with Claude](https://claude.com/blog/claude-for-commerce-agents?ref=growthhackers.tw)。
**協作聲明與免責**
這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。
內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。
### Claudeforce 解碼：Salesforce 財報證明 AI 沒殺死 SaaS，但介面已經不是它的了
URL: https://growthhackers.tw/blog/salesforce-claudeforce-fy27-q2-decode/
Last updated: 2026-09-07T01:00:00.000Z
Salesforce 在 8 月 26 日交出 FY27 第二季財報，隔天股價大漲 22.6%，是 2020 年以來最好的單日表現。
漂亮的數字有一整排：Agentforce ARR（年度經常性收入）衝破 15 億美元、年增超過 240%；自由現金流 11 億美元、年增 81%；全年營收指引上修到 461 億至 464 億美元。執行長 Marc Benioff 在法說會上直接點名「SaaSpocalypse」（SaaS 末日）這個說法，認為它被過度渲染了。
財報數字都是真的，我一個一個對過官方新聞稿。
但我想先跟你講一件比數字更重要的事：
這一季，Salesforce 換了兩把尺。
## 第一把尺：15 億美元，是用新算法量出來的
Agentforce ARR 破 15 億、年增 240%，這個數字你在各大媒體都會看到。
你在媒體上通常不會看到的，是 Salesforce 自己在新聞稿裡寫的那行小字：
> 「Effective Q2 FY27, Agentforce ARR includes our AI offerings, Slackbot and Headless 360.」
> （自 FY27 第二季起，Agentforce ARR 納入我們的 AI 產品、Slackbot 與 Headless 360。）
翻成白話：這一季開始，Slackbot 跟 Headless 360 的收入被算進 Agentforce 了。上一季不是這樣算的。
我在雨傘產業待了七年，工廠業務、品牌定位、產品開發都做過，其中一段是在百貨公司站專櫃當櫃哥。那段日子教會我一件事：報表的口徑一改，故事就整個換掉。
週年慶結算的時候，去年只算專櫃現場刷卡，今年把線上訂單、電子禮券、跨櫃滿額券全部併進來，然後宣布「成長 240%」。
數字沒有造假。尺換了而已。
我不是說 Salesforce 騙人，他們有揭露，白紙黑字寫在新聞稿裡。我是說，**大部分轉述這個數字的人，沒把那行小字一起轉述給你。**
## 第二把尺：11% 的成長，有多少是買來的
第二個數字是總營收 113 億美元，年增 11%。
一樣，新聞稿自己揭露了：這裡面有 4.56 億美元來自 Informatica 的併購貢獻。
那把併購拿掉呢？官方沒給這個數字，我用他們自己的數字算一次：
Salesforce FY26 第二季營收是 102 億美元。這季 113 億扣掉 Informatica 的 4.56 億，剩下大約 108.4 億。
108.4 除以 102，成長大約 6%。
不是 11%。是 6% 左右。
這是我用官方兩份新聞稿換算的，不是官方口徑，你可以自己驗一次。
## 另一個角度：合作夥伴那邊的數字沒有跟著漂亮
到這裡都還只是「數字怎麼讀」。有另一份資料值得放在旁邊一起看。
投資機構 TD Cowen 在 Agentforce 上市滿兩年時做了一份合作夥伴調查，結果是：**0%** 的受訪夥伴把 Agentforce 列為新簽單的主要成長動能。只有 33% 的夥伴達成當季目標，前一次是 43%。KeyBanc 的調查結論類似，問題卡在資料太碎、產品還不夠熟。
一邊是原廠財報上 240% 的 ARR 成長，一邊是通路端 0% 的簽單動能。
這兩件事可以同時成立，而且成立的路徑不只一條。一個解讀是大型企業的 AI 預算往往是「先買再說」的擴約，錢先付了，agent 還沒上線幹活；另一個解讀是原廠自己簽下的大單，本來就不會反映在合作夥伴的簽單動能上。哪一個占多數，公開資料判不出來，所以這份調查我把它擺在旁邊當另一面看，不拿它下結論。
股價那邊也是一樣的道理。22.6% 的漲幅不必全記在 Agentforce 頭上，自由現金流年增 81%、全年指引上修、Benioff 親自出來反駁「SaaSpocalypse」，都發生在同一天。
這對台灣電商的意義很直接：**原廠財報漂亮，不等於你導入就會成功，這兩件事要分開看。**
## Claudeforce 才是這場財報真正的重點
同一天還有另一個公告，我認為它比所有數字都重要。
Salesforce 跟 Anthropic 宣布了 **Claudeforce**。（順帶一提，它是一個字，不是「Claude force」，很多轉述都寫錯。）
它不是 Salesforce 推出的新產品。它是一個合作關係，而首發交付的東西叫做「Salesforce in Claude」：一個裝在 Claude 裡面的外掛，內含 37 個預建的業務技能（meeting prep、deal health review、pipeline review 之類），2026 年 9 月開放公測。
看懂了嗎？
以前你要用 Salesforce，你得登入 Salesforce。
現在你在 Claude 裡面，Salesforce 是那 37 個功能。
Benioff 自己在公告裡講了一句話，我覺得是這次最誠實的一句：「the UI is the AI」（介面就是 AI）。
這就像從「自己開一間店」，改成「進百貨設專櫃」。
我當過櫃哥，很清楚這中間的差別。專櫃再會賣，客人也不是你的客人，是百貨的客人。你負責供貨、負責專業、負責結帳不出錯，但人流、動線、被誰攔截，都不是你決定的。
而市場給了這份財報 22.6% 的漲幅。
**但看清楚方向：Salesforce 選的是走下去當底層，不是守住介面。**
## 我要修正我六月的判斷
六月底我寫過一篇[Salesforce 把整個平台變成 AI agent 的基礎設施](https://growthhackers.tw/blog/salesforce-platform-agent-infrastructure/)，結論是：「把內場顧好。外場的裝潢，會越來越不值錢。」
這季財報印證了前半句，但我要修正後半句。
內場當然還是關鍵。Salesforce 有資格走進 Claude，正是因為它握著 system of record（權威紀錄系統）：誰買了什麼、什麼條件、誰有權限看。這些模型自己生不出來，我在[第一方資料護城河](https://growthhackers.tw/blog/ai-agent-first-party-data-moat/)那篇講的就是這件事，這次算是被財報蓋章。
連 Headless 360 這種「刻意不做介面」的產品，這季都被算進 AI 收入（[Headless 360 怎麼把 CRM 拆開](https://growthhackers.tw/blog/salesforce-headless-360-ai-agent-enterprise/)）。
但我當時說「外場裝潢不值錢」，講得太輕鬆了。
正確的說法是：外場很值錢，只是那個外場已經不歸你管了。你不能因為介面被降級，就假裝介面不重要。你要做的是主動把內場送進別人的介面裡，而不是留在原地等人來敲門。
## 台灣電商，你的官網正在走同一條路
把場景換到台灣。
你的官網、App、LINE OA，現在還是消費者找你的入口。但當人開始在 ChatGPT、Claude、Gemini 裡面問「幫我找一把耐風的自動傘，預算八百以內」，你的官網就從入口變成後台了。
跟 Salesforce 遇到的是同一道題。差別只在它做了決定，多數台灣品牌還沒。
不是我說，你在 momo、蝦皮上架的時候就練習過這件事了：進了平台，客人是平台的客人，你只剩商品力跟出貨速度。AI 助理只是下一個、而且更強勢的平台。
具體該做什麼？
► **第一，盤點你的「權威資料源」。** 商品規格、庫存、會員分級、退換貨規則，哪一件還躺在某個老員工的腦袋裡或某張 Excel 裡？那就是 agent 呼叫不到的部分。不管你用 91APP、Shopline 還是 Cyberbiz，先問後台廠商一句：這些資料有沒有乾淨的 API 或 MCP 可以被外部 agent 讀？
► **第二，把「換口徑」列進你的成效檢查表。** 下次看 AI 客服、AI 選品的成效報告，先問：分母跟上一期一樣嗎？有沒有把原本就有的功能併進 AI 成效？基期是哪一期？我看過太多報表，成長不是做出來的，是併出來的。
► **第三，挑一個高頻、規則明確的場景先做。** 查訂單、查物流、退換貨資格判定，規則清楚、量大、答錯代價低。先把一個場景做到能被外部 agent 安全呼叫，比買一整套 agent 平台實在。
► **第四，寫一頁「外部 agent 存取規則」。** 哪些商品資料可以公開？哪些會員資料只能查本人？哪些欄位絕對不能出站？先把邊界寫清楚，你才有資格談要不要接進 ChatGPT 或 Claude。
## 最後，我的判斷
Salesforce 這份財報，同時證明了兩件看起來矛盾的事。
SaaS 沒有死。企業軟體不但沒被 AI 吃掉，還因為 agent 需要乾淨的資料跟權限而變得更重要。
但介面已經不是它的了。而且它是自己交出去的，同一天還拿到 2020 年以來最好的股價表現。
如果你問我，這份財報最值得台灣電商帶走的，不是那 15 億美元。是那行沒人轉述的小字。
以前看數字，我們問「成長多少」。
現在該先問：「這一季，尺換了沒有？」
介面會一直換。今天是 Claude，明天可能是別的。但你的商品、庫存、會員、規則，不會因為換一個介面就重來一次。
把那個顧好。然後主動走進別人的店裡設專櫃。
## 常見問題 FAQ
**Q1：Claudeforce 是什麼？跟 Agentforce 差在哪？**
Claudeforce 是 Salesforce 與 Anthropic 在 2026 年 8 月宣布的合作關係，首發交付物叫「Salesforce in Claude」，是一個裝在 Claude 裡的外掛，內含 37 個預建業務技能，2026 年 9 月開放公測。Agentforce 則是 Salesforce 自家平台上的 AI agent 產品。簡單說：Agentforce 是「Salesforce 裡的 AI」，Claudeforce 是「Claude 裡的 Salesforce」。方向剛好相反。
**Q2：Agentforce ARR 15 億美元是真的嗎？**
是真的，官方新聞稿寫得很清楚，年增超過 240%。但同一份新聞稿也註明，自 FY27 第二季起，這個數字納入了 Slackbot 與 Headless 360，跟上一季的算法不同。要跟前期比較時，要記得這件事。
**Q3：那「AI 會殺死 SaaS」到底成不成立？**
從這份財報看，短期內不成立。營收、現金流、簽約金額都在成長，Benioff 也提到客戶流失率接近歷史低點（法說會口頭說法，新聞稿沒列數字）。但 TD Cowen 的合作夥伴調查顯示 0% 的夥伴把 Agentforce 當成主要簽單動能。比較準確的說法是：軟體本身沒被殺死，但軟體「作為使用者介面」的角色正在被取代。
**Q4：我是台灣中小電商，這跟我有什麼關係？**
關係在於角色定位。當消費者開始透過 AI 助理購物，你的官網跟 App 會從「入口」降級成「後台」。你要提早決定：是繼續投資介面，還是把資源放在讓自己的商品、庫存、會員資料成為 AI 查得到、信得過的來源。後者的投資報酬率，我認為會高很多。
**Q5：怎麼判斷自家 AI 成效數字有沒有灌水？**
問三個問題：分母跟上一期一樣嗎？有沒有把原本就存在的功能（例如舊的自動回覆）併進「AI 成效」？基期是不是挑了最低的那一期？Salesforce 這種等級的公司都會換口徑，你的供應商當然也會。
---
### 本文參考來源
- [Salesforce Delivers Record Second Quarter Fiscal 2027 Results（投資人關係新聞稿，2026-08-26）](https://investor.salesforce.com/news/news-details/2026/Salesforce-Delivers-Record-Second-Quarter-Fiscal-2027-Results/default.aspx?ref=growthhackers.tw)
- [Salesforce and Anthropic Announce Claudeforce（2026-08-26）](https://investor.salesforce.com/news/news-details/2026/Salesforce-and-Anthropic-Announce-Claudeforce-The-1-AI-Meets-the-1-AI-CRM/default.aspx?ref=growthhackers.tw)
- [Salesforce Reports Record Second Quarter Fiscal 2026 Results（2025-09-03，用於計算有機成長基期）](https://investor.salesforce.com/news/news-details/2025/Salesforce-Reports-Record-Second-Quarter-Fiscal-2026-Results/default.aspx?ref=growthhackers.tw)
- [Salesforce Partners Report Zero Revenue Boost from Agentforce Two Years After Launch（Techstrong.ai 報導 TD Cowen 調查）](https://techstrong.ai/articles/salesforce-partners-report-zero-revenue-boost-from-agentforce-two-years-after-launch-study/?ref=growthhackers.tw)
- [Salesforce and Anthropic Announce Claudeforce in Q2 '27 Earnings（Salesforce Ben）](https://www.salesforceben.com/salesforce-and-anthropic-announce-claudeforce-in-q2-27-earnings/?ref=growthhackers.tw)
- [Salesforce Shares Surge 23%（The Motley Fool，2026-08-29）](https://www.fool.com/investing/2026/08/29/salesforce-shares-surge-23-this-is-why-the-stock/?ref=growthhackers.tw)
- 原始素材：Salesforce FY27 Q2 法說會影片（YouTube）之自動摘要與逐字稿。財報數字均已回查官方新聞稿；股價、合作夥伴調查與法說會口頭說法依上列各來源；未能取得一手佐證的口頭數據不予採用。
---
**協作聲明與免責**
這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。
內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。
### 你的 Claude Skill 為什麼沒被叫出來？解碼 Anthropic 官方 33 頁指南：勝負在 description 那一行
URL: https://growthhackers.tw/blog/claude-skills-description-trigger-test/
Last updated: 2026-09-06T13:00:00.000Z
Anthropic 出了一份 33 頁的官方指南，《The Complete Guide to Building Skills for Claude》，把 Agent Skills（代理技能）怎麼做講了一輪。
我讀完的第一個動作不是抄重點，是去翻它的日期。
內文寫著「Current distribution model (January 2026)」。這份東西是今年一月的狀態。我拿八月的[現行官方文件](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices?ref=growthhackers.tw)逐條對過一遍，有四條已經不一樣了。
大家拿到官方指南的預設動作是「照抄」。但照抄有兩個洞：一來是格式規則有保存期限，二來是幾乎所有人都跳過了最該讀的那一章。
那一章叫 Testing and iteration，講的不是怎麼寫 skill，是怎麼驗收 skill。
漸進式揭露三層：YAML frontmatter 永遠載入系統提示，SKILL.md 本文相關時才載入，references/ 需要時才讀
## 只有一行字是「永遠」被讀到的
指南裡最關鍵的機制叫 progressive disclosure（漸進式揭露），分三層：
★ 第一層 YAML frontmatter（檔案開頭的設定區塊）：**永遠**載入 Claude 的系統提示 ★ 第二層 SKILL.md 本文：Claude 判斷這件事跟你的 skill 有關，才會載入 ★ 第三層 references/ 裡的檔案：真的需要時才去讀
看懂這三層，你就會發現一件很不舒服的事。
你在 SKILL.md 裡寫得再用力、規則列得再細，全都躺在第二層。第一層只有兩個欄位：`name` 和 `description`。而 description 上限 1,024 個字元。
換句話說，你的 skill 會不會被叫出來，跟你寫得多好完全無關，只跟那一行 description 有關。
這就像投廣告。SKILL.md 是素材，description 是投放設定。素材做到得獎等級，投放沒設對，曝光是零。觸發率是曝光，內容品質是轉換率，順序不能顛倒。
指南說 description 必須同時包含兩件事：**做什麼**，以及**什麼時候用**。失敗的案例，大多只寫了前半段。
想像你把公司的退換貨話術做成一個 skill，description 寫「處理客服訊息」。
這只交代了做什麼。什麼時候用？沒寫。於是客服同事在後台問「這張單客人說鞋子穿了兩天要退，怎麼回」，Claude 根本不知道該把你那份話術叫出來，就自己掰了一段。
指南裡還藏了一招除錯神技，我覺得比任何檢查清單都好用：
**直接問 Claude：「你什麼時候會用 \[skill 名稱\] 這個 skill？」**
它會把 description 背回來給你。它漏掉的、講不出來的，就是你該補的。
看兩種病：
► **不觸發（undertriggering）**：該用卻沒載入、你得手動叫它。解法是補細節跟關鍵字，特別是使用者實際會講的詞。 ► **觸發太頻繁（overtriggering）**：不相關的問題它也跳出來。解法是加負面觸發詞，明白寫「不要用在什麼情況」，並且界定範圍。
技能不是越多越強，這件事我在[之前談 Matt Pocock「技能地獄」那篇](https://growthhackers.tw/blog/writing-great-agent-skills/)講過。但那是品味問題，今天這個是機制問題。
觸發診斷兩種病：不觸發要補關鍵字與細節，觸發太頻繁要加負面觸發詞並界定範圍
## 官方自己承認：現在還有一部分是憑感覺
指南第 9 頁有一段話，我相信 99% 的人讀過就滑掉了。
Anthropic 在講「怎麼定義 skill 成功」的時候，自己補了一句：這些只是 aspirational targets（理想目標）和 rough benchmarks（粗略基準）。
原文寫「aim for rigor but accept that there will be an element of vibes-based assessment」：要求嚴謹，但要接受評估帶有憑感覺的成分。他們當時說，更嚴謹的量測工具正在開發。
官方蓋章：現在判斷一個 skill 好不好，還有一部分靠感覺。
那它給的可量測標準是什麼？
**skill 應該在 90% 的相關查詢上被觸發。**（注意，這是指南自己說的理想目標，不是保證，也不是官方 SLA。）
量法很土炮，但有效：跑 10 到 20 個「應該觸發」的查詢，記得放幾句換句話說的版本，數它自動載入幾次、幾次要你手動叫。再補一組「不應該觸發」的不相關問題，看它會不會亂跳。
再來是對照組。同一個任務跑兩次，一次開 skill、一次關 skill，比四個數字：來回幾次、呼叫幾次工具、失敗幾次、總共吃掉多少 token。
指南裡舉的例子是 12,000 token 降到 6,000。這是說明概念的示意數字，不是實測基準，別拿去當簡報效益。Anthropic 的工程部落格全文沒有任何量化數據。
然後是這篇的重點查證。
那句「正在開發量測工具」，八個月後兌現了嗎？我在 2026 年 8 月底去翻現行官方文件，上面仍然寫著：目前沒有內建的方式執行這些評測，使用者可以自建評測系統。
工具還沒到。所以你想量，只能自己土炮。
還有一件很容易誤判的事。一個 skill 裝在那裡，卻從來沒被叫出來過，第一時間通常會被當成內容寫得不夠好。
零使用率不是內容爛，是觸發失敗。這跟公司裡那份四十頁沒人照做的客服 SOP，是同一種死法。
對照組要比的四個數字：來回次數、工具呼叫次數、失敗次數、總 token。此為概念示意，非實測基準
## 對照 Anthropic 現行文件，有四條已經變了
這四條在 PDF 裡要不是完全沒寫，就是寫得不一樣，是我對照八月官方文件抓出來的：
**1\. description 必須用第三人稱。** 官方原文警告：description 會被注入系統提示，人稱不一致會造成 discovery（發現）問題。好的寫法是「Processes Excel files and generates reports」，要避免的是「I can help you...」跟「You can use this to...」。順著中文語感寫成「我可以幫你…」的都該改掉。
**2\. SKILL.md 本文控制在 500 行以內。** PDF 寫的是 5,000 words（英文字數）。單位跟數字都不一樣，我不打算幫它們換算，以現行官方文件為準就好。
**3\. 你打算用哪幾個模型，就要每個都測一遍。** Haiku 會不會覺得不夠明確、Sonnet 讀起來清不清楚、Opus 會不會嫌你過度解釋。PDF 完全沒提模型差異。
**4\. 先寫評測，再寫文件。** 這條最狠：先不帶 skill 跑一次代表性任務、記下它爛在哪，接著建三個測試情境，量出沒有 skill 的基準線，然後只寫剛好夠用的指令，最後跑評測跟基準線比。
以前大家的做法是「寫完 skill 再想怎麼測」。現在官方把順序倒過來：先建評測、先量基準線，再寫文件。講白一點就是，沒有基準線就不要動筆。
## 這週先測你的 description 觸發率
台灣電商團隊先別急著重寫整包 skill。手上那三份文件：客服應對 SOP、上架文案規範、檔期活動 checklist，拿來當觸發測試的素材就夠了（SOP 怎麼變技能，[Andrew Ng 課程那篇](https://growthhackers.tw/blog/agent-skills-andrew-ng-course/)談過）。每一份都重複、都有規則、都常常沒人照做。
但動手前，先做那件所有人都跳過的事：
► **先跑基準線。** 不帶 skill，讓 AI 做一次上架文案，把爛結果原封不動存下來。這就是你的對照組。這跟做促銷檔期一樣，台灣電商最常見的錯就是看到營收漲就當有效，沒留對照組，永遠不知道是折扣有效還是節慶有效。 ► **description 寫兩段。** 前半寫做什麼，後半寫「當使用者提到退貨、上架文案、檔期 checklist 時使用」。把你團隊真的會講的詞塞進去。寫完問 Claude 一句「你什麼時候會用它」，看它背得出來嗎。 ► **列 10 個測試句。** 5 句該觸發（其中 2 句故意換句話說），5 句不該觸發。跑一輪，數命中率。沒到九成就回去改 description，不要改 SKILL.md。
想再進一步的，可以把驗證流程本身也寫成 skill，我在[Claude Code skill 驗證迴圈那篇](https://growthhackers.tw/blog/claude-code-skill-verification-loop/)拆過做法。另外，skill 裝多了會撞到天花板，[Stripe 內部 AI 助理那篇](https://growthhackers.tw/blog/stripe-kai-agent-platform-governance/)有實測數字可參考。
如果你問我，這份 33 頁指南最有價值的不是那些格式規則。
格式會過期，我對照八個月就抓到四條。
但「先量基準線、再寫東西」這個順序不會過期。它在 A/B 測試是這樣，在廣告投放是這樣，在 skill 也是這樣。
## 常見問題 FAQ
### Q1：SKILL.md 的 description 到底該寫什麼？
兩件事缺一不可：這個 skill 做什麼，以及什麼時候該用它（觸發條件）。上限 1,024 字元，用第三人稱寫，把使用者實際會講的詞放進去，有涉及特定檔案類型也要寫明。
### Q2：為什麼我的 skill 從來不會自動觸發？
這叫 undertriggering（觸發不足）。八成是 description 太籠統，或只寫了「做什麼」沒寫「什麼時候用」。除錯方法：問 Claude「你什麼時候會用這個 skill」，看它背回來缺什麼，就補什麼。特別是技術名詞跟你團隊的慣用語，一定要寫進去。
### Q3：skill 觸發太頻繁怎麼辦？
這叫 overtriggering（過度觸發），解法是加 negative trigger（負面觸發詞）。在 description 裡明白寫出不該用它的情境，例如「不要用於單純的資料瀏覽」。同時把描述寫得更具體、界定清楚適用範圍。
### Q4：SKILL.md 該寫多長？
Anthropic 現行文件建議 SKILL.md 本文控制在 500 行以內。超過就把細節拆到 references/ 資料夾，讓 Claude 需要時才去讀。這正是漸進式揭露的用意。
### Q5：怎麼知道我的 skill 到底有沒有用？
先測觸發率：跑 10 到 20 個查詢，指南的理想目標是命中 90%。再跑對照組，同一任務開關 skill 各做一次，比四個數字：來回次數、工具呼叫次數、失敗次數、總 token。Anthropic 目前沒有提供內建的評測執行工具，這套流程要自己搭。
---
**協作聲明與免責**
這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。
內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。
### WebMCP 是什麼？跟 MCP 差在哪？台灣電商先別急著動工
URL: https://growthhackers.tw/blog/webmcp-vs-mcp-browser-agent-tools/
Last updated: 2026-09-06T01:00:00.000Z
我最近在看一個 [WebMCP 的官方示範網站](https://webmcp-demo-sdras.netlify.app/?ref=growthhackers.tw)，一個線上預約的 demo，程式碼寫得很乾淨。我順手把它的程式碼，跟 [W3C 的規格原文](https://github.com/webmachinelearning/webmcp?ref=growthhackers.tw)擺在一起對照。
然後就對不上了。
demo 裡註冊工具的入口寫的是 `navigator.modelContext.registerTool()`，規格現在寫的卻是 `document.modelContext.registerTool()`。這不是誰手滑打錯字。規格自己把入口從 `navigator` 搬到了 `document`，而 Chrome 150 已經把舊的那個標記成 deprecated（即將淘汰），未來版本會直接移除。
一個 2025 年 8 月才首次發布的草案，幾個月內改掉了自己的名字。
所以你現在 Google 得到的 WebMCP 教學，不少還在教一個已經被改掉的寫法。
## 先別急著問「要不要接」
我知道你看到這裡在想什麼：「所以我是不是又落後了？要不要叫工程師趕快接一下？」
如果你問我，這是錯的問題。
看一下這份規格現在的體檢報告：狀態標示是 experimental（實驗性），截至 2026 年 8 月底，倉庫裡躺著大約 108 個 open issues（未解決的討論），Chrome 從 149 版開始才開放 origin trial（來源試用），本機想測還得手動去開 `chrome://flags/#enable-webmcp-testing` 這個旗標。規格文件自己開宗明義寫著：這是 Draft Community Group Report，不是 W3C 標準，也還沒進標準軌道。推手是微軟和 Google，掛在 Web Machine Learning 社群組底下。
翻成白話：**WebMCP 還不是瀏覽器預設就能用的功能。** 現階段它適合拿去 origin trial 或測試站踩踩看，不適合當成正式環境的依賴。
做過百貨專櫃的都知道，櫃位一改陳列，熟客就找不到原本那排貨。這幾年看規格草案，我養成一個習慣：先看它改過幾次名字。改名字代表底層的想法還在動，而底層還在動的東西，你花錢接上去，改的成本是你自己吸收。
錯的問題會讓你把預算丟進一個還在改的規格。對的問題只有一個：**這件事裡面，哪一部分不會變？我現在只投那一塊。**
## WebMCP 是什麼？
用一句話講：WebMCP 是一個瀏覽器端的標準草案，讓網頁主動把「我這頁能做哪些事」宣告成結構化的工具，AI agent 直接呼叫，不用再去猜你的畫面。
以前 agent 要幫你在一個網頁上訂位，它得截圖、讀 DOM（網頁的元素結構）、猜哪個輸入框是日期、猜哪顆按鈕才是真的送出。現在網頁直接給它一份契約：這個工具叫 `bookSlot`，需要日期、時間、姓名、email，格式長這樣，跑完會回你什麼。
每個工具有名稱、說明、JSON Schema 定義的參數、annotations（標註，例如 `readOnlyHint` 告訴 agent 這個動作只讀不寫），還有實際執行的函式。這個描述形狀刻意貼著 server 端的 MCP 工具長，但它不是把 MCP 直接搬進瀏覽器：執行位置、生命週期、協定層都不一樣。
寫法有兩種。一種是用 JavaScript 呼叫 `registerTool()`。另一種更簡單，直接在 HTML 的 `