Claude Code 管廣告一個月花多少錢？MCP 電商生態深度解讀
寫在前面
上一篇《讓 AI 接管你的亞馬遜廣告》發出後，收到了不少賣家的回饋。留言區兩個問題出現頻率最高：
- 「用了多少 token？」 — 也就是說，這套方案一個月到底花多少錢？
- 「能用於多個帳號嗎？」 — 多店鋪場景下 API 怎麼設定？
今天先解決第一個問題。不只是算一筆帳，而是把 MCP 在全球電商領域的生態現狀一起講清楚 — 你會看到，成本只是入場券，真正的價值在趨勢判斷。
一、直接上結論：Claude Code 管廣告要花多少錢
固定成本
| 項目 | 費用 | 說明 |
|---|---|---|
| Claude Pro 訂閱 | $20/月 | 最低門檻，包含 Claude Code + MCP 支援 |
| Claude Max 訂閱 | $100/月 | 重度使用者，token 上限大幅提升 |
| Amazon Ads API | 免費 | 官方不收費，Direct Advertiser 免審核費 |
| MCP 協議 | 免費 | 開源，不收費 |
| 伺服器 | $0 | 本地執行，不需要雲端伺服器 |
一句話：最低 $20/月，推薦 $100/月。
Token 消耗：基於真實 Session 資料
以下資料來自我們 10 天內 4 個實際操作 Session 的統計，不是估算，是回溯分析。
首先要理解一件事：token 消耗的大頭不是 API 呼叫本身，而是 AI 的分析和決策過程 — 讀取歷史資料、對比趨勢、判斷策略、生成操作方案。真正調 API 可能只占 10-15%，剩下 85% 是「思考」。
一次性成本（初始建置）
| 操作 | Token 消耗 | 說明 |
|---|---|---|
| 全店 Campaign 掃描 + 止血策略制定 | ~15K | 掃描 48 campaigns，制定暫停/降 bid/負面詞策略 |
| API 註冊指導 + 驗證 | ~15K | Amazon Developer 註冊 + LwA + 申請流程 |
| API 全鏈路調試 + 工具開發 | ~30K | 調試 MCP Server、封裝 shell 工具、驗證全部操作 |
| 一次性小計 | ~60K | 花一次就夠了，後續不再重複 |
日常營運成本（週度循環）
實際操作模式是一週一次集中 Session，一次完成所有操作：
| 週度 Session 內容 | 實測 Token |
|---|---|
| 拉 Campaign 效能報告（API） | ~3K |
| 拉搜尋詞報告 + 全量分析 | ~10-15K |
| 策略判斷（對比上週、診斷異常） | ~8-10K |
| 執行操作（調 bid + 加負面詞 + 恢復/暫停） | ~8-10K |
| 資料存檔 + 更新 Session Handoff | ~3-5K |
| 單次週度 Session 合計 | ~35K tokens |
我們實測的 Session 6（3/27，純日常營運）：42,310 output tokens，包含拉取 2 份報告、分析 53 個搜尋詞、回調 39 個關鍵詞 bid、新增 39 條負面詞、恢復 1 個 campaign、存檔 4 個檔案。
月度預估
| 使用模式 | 月消耗 | 適合 |
|---|---|---|
| 每週一次集中操作（推薦） | ~140K tokens | 大多數賣家 |
| 每週一次 + 偶發異常排查 | ~180K tokens | 需要更細粒度監控 |
| 每日快速檢查 + 每週深度操作 | ~250K tokens | 多站點/大量 campaigns |
Pro 訂閱（$20/月）足夠覆蓋「每週一次」模式。如果你管理 3 個以上站點，或需要每日監控，建議升級 Max（$100/月）。
注：以上 token 數為 output tokens。Claude Code 的計費中，大量 context 透過快取機制處理（我們 4 個 Session 總計處理了約 5,600 萬 tokens 的上下文，但其中 99% 是快取讀取，不額外計費）。實際體感：Pro 訂閱跑一個站點綽綽有餘。
隱性成本：時間
別忘了算這筆帳：
| 項目 | 耗時 |
|---|---|
| API 申請（Amazon Developer 註冊 + 審批） | 約 3 天 |
| 環境建置（Claude Code 安裝 + MCP 設定） | 半天 |
| 學習命令列基礎（如果完全沒接觸過） | 1-2 天 |
| 跑通第一個完整流程 | 1 天 |
總投入：約一週。 之後就是日常操作了，邊用邊熟練。
二、和替代方案比，貴不貴？
| 方案 | 月費 | 能做什麼 | 不能做什麼 |
|---|---|---|---|
| Claude Code + API | $20-100 | 全鏈路：拉資料、分析、調 bid、加詞、生成報告 | 需要基本命令列能力 |
| Helium 10 | $79-229 | 關鍵詞研究、Listing 最佳化、市場分析 | 不能自動執行廣告操作 |
| Perpetua | 廣告花費 10-15% | 自動競價、自動規則 | 黑盒，你不知道它做了什麼 |
| Pacvue / Skai | $500+/月 | 企業級廣告管理平台 | 貴，適合大賣 |
| 請營運 | ¥6,000+/月 | 人工判斷，靈活 | 一個人看不了太多 campaign |
Claude Code 的優勢不是「便宜」（雖然確實便宜），而是透明 + 可控 + 可擴充：
- 透明：每一步操作你都能看到，不是黑盒
- 可控：AI 給出建議，你決定是否執行
- 可擴充：今天管 Amazon 廣告，明天可以接 Shopify、Stripe、物流 API — 用同一套方法論
三、多帳號會不會關聯？技術層面完整解析
這是留言區和後台私訊問得最多的問題。直接上結論，然後拆解原理。
結論
透過 API 管理多個 Amazon 帳號的關聯風險極低。 但用瀏覽器登入多個 Seller Central 後台的關聯風險極高。兩者是完全不同的技術模型。
先理解：Amazon 靠什麼判定帳號關聯？
Amazon 的關聯偵測系統基於多因素綜合判斷，不是單一指標。按權重排列：
| 權重 | 訊號 | 來源 |
|---|---|---|
| 極高 | 瀏覽器指紋（Canvas/WebGL/字體/外掛） | 瀏覽器登入 |
| 極高 | Cookies / localStorage 共享 | 瀏覽器登入 |
| 高 | 相同營業執照/收款銀行/信用卡 | 註冊資訊 |
| 中 | 相同 IP 位址 | 瀏覽器 + API 都有 |
| 中 | 相同商品圖片/Listing 文案 | 後台內容 |
| 低 | 操作時間模式相似 | 行為分析 |
注意：IP 位址單獨不足以觸發關聯。 跨境賣家社群（知無不言、創藍論壇）的共識是：「僅憑 IP 不會封號，因為 Amazon 的關聯技術是多因素綜合判斷。」咖啡廳、共享辦公室的人天天用同一個 IP 登不同帳號。
瀏覽器 vs API：訊號暴露對比
這是整個問題的核心。看完這張表你就懂了：
| 訊號 | 瀏覽器登入 Seller Central | API 呼叫（curl / Python） |
|---|---|---|
| IP 位址 | 暴露 | 暴露 |
| Cookies | 暴露（持久化，跨 Session） | 不存在 |
| Canvas 指紋 | 暴露 | 不存在 |
| WebGL 指紋 | 暴露 | 不存在 |
| 螢幕解析度 | 暴露 | 不存在 |
| 安裝字體 | 暴露 | 不存在 |
| 瀏覽器外掛 | 暴露 | 不存在 |
| User-Agent | 暴露（每個瀏覽器唯一） | 通用值（如 python-requests/2.31） |
| WebRTC 本地 IP | 暴露 | 不存在 |
| 滑鼠/鍵盤行為 | 暴露 | 不存在 |
| TLS 指紋 | 暴露（瀏覽器特有） | 通用（和百萬個 Python 腳本一樣） |
| OAuth Token | Session 內 | Header 攜帶 |
瀏覽器暴露 15+ 種可識別訊號。API 暴露 2 種（IP + TLS），且都是通用的、無法區分個體的。
這就是為什麼中國賣家要花錢買指紋瀏覽器（AdsPower、Multilogin 等） — 它們解決的是瀏覽器指紋問題。如果你只用 API，根本不需要指紋瀏覽器，因為那些指紋訊號在 API 呼叫中壓根不存在。
Claude Code + API 的實際通訊鏈路
你用 Claude Code 管廣告時，實際發生了什麼：
Claude Code（本地終端機）
→ curl / Python 腳本（本地執行）
→ HTTPS 請求到 advertising-api.amazon.com
請求標頭:
Authorization: Bearer eyJ...（帳號 A 的 Token）
Amazon-Advertising-API-ClientId: amzn1.xxx（App 的 Client ID）
Amazon-Advertising-API-Scope: 123456（Profile ID）
Content-Type: application/jsonAmazon 的 API 伺服器看到的就是：一個標準 HTTPS 請求，攜帶了正確的認證資訊。沒有瀏覽器，沒有指紋，沒有 Cookies。 這個請求和全世界任何一個 ERP 系統、SaaS 工具發出的請求沒有任何區別。
Amazon 官方怎麼說？
Amazon Ads API 文件明確支援一個應用程式管理多個廣告帳號：
"API access is limited to one client application per company, but there is no limit to the number of advertising accounts that can be managed by a single client application."
也就是說：一個 App 管理多個帳號是官方設計的使用方式。 不只是「不禁止」，而是「就是這麼用的」。API 的三種接入角色（廣告服務商 / 代理商 / 直接廣告主）都支援多帳號管理。
中國的亞馬遜 ERP 產業（積加、易倉、賽盒等）每天用 API 管理成千上萬個賣家帳號，共用相同的伺服器基礎設施，從未因此觸發關聯。
風險矩陣
| 場景 | 關聯風險 | 說明 |
|---|---|---|
| 同一台電腦 + 不同 API 憑證 + 不同 LwA Profile | 低 | 官方設計用法，無瀏覽器指紋 |
| 同一台電腦 + 瀏覽器登入多個 Seller Central | 極高 | 指紋重疊，這就是被封的主要原因 |
| 同一台電腦 + API 管廣告 + 瀏覽器只登一個帳號 | 低 | API 和瀏覽器的資料通道完全獨立 |
| 不同電腦 + 各自 API 憑證 | 最低 | IP 都不同了 |
如果你真的要多帳號操作，建議
- 廣告管理全走 API — 就是我們這套 Claude Code + Amazon Ads API 方案，關聯風險最低
- Seller Central 瀏覽器只登主帳號 — 需要手動操作的時候只開一個帳號
- 每個帳號用獨立的 LwA Security Profile — 獨立的 Client ID + Secret + Refresh Token，最大化隔離
- API 憑證分檔案存放 — 不要混在一個設定檔裡
- 註冊資訊才是關聯的核心 — 不同的營業執照、收款帳號、信用卡。技術手段再好，註冊資訊相同一樣關聯
- 如果非要用瀏覽器登多個帳號 — 那必須用指紋瀏覽器 + 獨立 IP，這不是 API 的問題，是瀏覽器的問題
一句話總結
指紋瀏覽器解決的是「瀏覽器指紋」問題。API 呼叫沒有瀏覽器指紋。
用 Claude Code + API 管多個帳號，技術上等同於用 ERP 管多個帳號 — 這是 Amazon 官方支援的使用方式。
四、MCP 全球生態：電商是最大的空白
什麼是 MCP？三句話回顧
MCP（Model Context Protocol）是讓 AI 連接外部工具的開放協議。上一篇講了原理，這裡不贅述。你只需要知道：MCP 讓 AI 從「只能聊天」變成「能操作真實系統」。
全球巨頭都在接入
MCP 的官方程式碼庫在 GitHub 上已經有 82,000+ stars，支援 8 種程式語言。看看誰在用：
| 公司 | MCP 伺服器數量 | 覆蓋範圍 |
|---|---|---|
| AWS（亞馬遜雲端） | 68 個 | 幾乎所有雲端服務 |
| 微軟 | Playwright（瀏覽器自動化）+ Azure | 開發者工具 |
| Chrome DevTools（32K stars） | 瀏覽器 | |
| GitHub | 28K stars | 程式碼管理 |
| Notion | 官方支援 | 知識管理 |
| Stripe | 官方支援 | 支付 |
| Grafana | 官方支援 | 監控 |
中國方面，字節跳動的火山引擎做了 80+ 個 MCP 伺服器，是中國布局最激進的公司。但需要注意：這 80 個伺服器幾乎全部是雲端基礎設施（伺服器管理、資料庫、CDN），面向的是 DevOps 工程師，不是電商賣家。
電商領域：全球範圍內幾乎空白
這是我們深度調研後最重要的發現：
| 電商場景 | MCP 現狀 |
|---|---|
| Amazon Ads API | 能用，但沒有現成的 MCP 封裝（我們是手動對接） |
| Shopify | 官方出了，但功能很初階 |
| Stripe（收款） | 官方有，可用 |
| 淘寶/天貓（直通車、萬相台） | API 存在，MCP 封裝 = 0 |
| 京東（京東快車） | API 存在，MCP 封裝 = 0 |
| 抖音（巨量千川） | API 存在，MCP 封裝 = 0 |
| 拼多多 | API 有限，MCP = 0 |
| 聚水潭、店小二等 ERP | 未接入 MCP |
為什麼空白？
幾個原因疊加：
- MCP 生態仍處早期 — 全球開發者的注意力集中在雲端服務和開發者工具，電商營運還沒被覆蓋到
- 各平台的資料策略較為保守 — 尤其是中國平台，廣告系統的 API 雖然存在，但開放程度和文件品質參差不齊
- 賣家群體的技術門檻 — 大多數電商賣家不具備命令列和 API 對接能力，工具開發者看不到足夠的市場需求
- 各地區資料合規要求不同 — 跨平台資料流動需要考慮不同的合規框架
這意味著什麼？你現在學會 MCP + 電商 API 這套方法論，在全球範圍內都是極少數人。
五、為什麼跨境賣家是 MCP 的最佳切入點
1. 海外平台的 API 生態更成熟
Amazon Ads API 的文件完整、審批流程清晰（上篇文章已經帶你走了一遍）、不需要額外付費。Shopify、Stripe 等平台同樣如此。這不是評判好壞，而是客觀現實：跨境賣家面對的 API 基礎設施更適合 MCP 接入。
2. 跨境天然是多平台協同
一個典型的跨境賣家可能同時管理：
- Amazon 北美站（US/CA/MX）廣告
- Shopify 獨立站
- Stripe / PayPal 收款
- 物流追蹤（ShipStation / 4PX）
每個平台都有 API，而 MCP 的核心價值就是讓 AI 同時連接多個系統。你不需要在五個後台之間來回切換 — AI 幫你統一處理。
3. 迭代速度是核心競爭力
上一篇文章講過：廣告最佳化本質上是一個回饋迴圈。手動操作是週級循環，MCP 讓你做到日級甚至小時級。
同樣的起跑線，一年後：
- 手動賣家迭代了 52 次
- MCP 賣家迭代了 365 次
這個差距是複利的。每一次迭代都讓下一次更精準。
4. 方法論可遷移
今天你用 Claude Code 管 Amazon Ads，學會的不只是「怎麼調 API」，而是：
- 如何讓 AI 理解業務邏輯
- 如何用 session 檔案保持上下文連續性
- 如何設計人機協作的工作流程
這些能力遷移到 Shopify、TikTok Shop、甚至中國的千川投流，邏輯是完全一樣的。平台會變，方法論不變。
六、MCP 生態的未來：不止亞馬遜廣告
已經可以接入的場景
| 場景 | 工具/API | 對賣家的價值 |
|---|---|---|
| 廣告管理 | Amazon Ads API | 自動分析、調 bid、加負面詞 |
| 獨立站 | Shopify MCP | 管理產品、訂單 |
| 收款對帳 | Stripe MCP | 自動核對帳單 |
| 瀏覽器自動化 | Playwright MCP | 補齊沒有 API 的平台（萬能後備） |
| 資料分析 | Google Sheets / Notion MCP | 自動生成報告和看板 |
| 郵件處理 | Gmail MCP | 處理買家郵件、供應商溝通 |
未來 6-12 個月可能出現的
- TikTok Shop MCP — TikTok 在北美成長快，API 生態在建置中
- 物流 MCP — ShipStation、雲途等物流平台的 API 封裝
- ERP MCP — 把聚水潭等 ERP 的資料接入 AI
- 跨平台儀表板 — AI 同時連接 Amazon + Shopify + Stripe，一句話生成全通路週報
誰先掌握這套能力，誰就在這波 AI 工具革命中占據先發優勢。
七、決策樹：我該不該入場？
你目前的廣告月花費是多少？
│
├── < $500/月
│ └── 暫時不需要。手動管理夠了，先把產品和 Listing 做好。
│
├── $500 - $5,000/月
│ ├── 有基本命令列能力 → Claude Pro ($20/月)，跟著上篇教學走
│ └── 完全沒碰過終端機 → 先花 1-2 天學基礎，或者找人幫你設定環境
│
├── $5,000+/月 或多站點
│ └── 強烈建議 Claude Max ($100/月)。
│ 多站點 + 高頻報告需要更大的 token 額度。
│
└── 用過 Helium 10 / Perpetua / Pacvue
└── 不衝突。Claude Code 補的是「執行層」— 那些工具給你看資料，
Claude Code 幫你根據資料直接操作。可以共存。八、總結
| 問題 | 答案 |
|---|---|
| 一個月多少錢？ | $20 起，推薦 $100 |
| 比 Helium 10 貴嗎？ | 便宜 3-10 倍，而且能做更多 |
| 需要會程式設計嗎？ | 不需要，但需要基本命令列能力 |
| 電商 MCP 生態成熟嗎？ | 早期，全球範圍內幾乎空白 |
| 值得現在學嗎？ | 值得。正因為早期，先學會的人有先發優勢 |
| 下一步看什麼？ | 關注本系列，下一篇講多帳號安全設定 |
系列回顧
- 第一篇：讓 AI 接管你的亞馬遜廣告：Claude Code + Amazon Ads API 實戰指南
- 第二篇：本文 — 成本核算 + MCP 生態深度解讀
- 第三篇（預告）：多店鋪 API 安全設定 — 帳號關聯風險分析
本文基於 2026 年 3 月實際專案經驗和公開資料。定價、token 額度和 API 政策可能隨時變化，請以官方文件為準。