單人操作者以三面螢幕跑 13 個並行 Claude Code session：LG ultrawide 排 3×2 六視窗，直立螢幕再排 3×2，MacBook 跑第十三個。 十三個代理同時組建 Shopify 商店，各自一個 context，各自負責商店的一層。 每間商店售價 $800，每日 API 總花費不超過 $80，無固定人力成本。
整個運作由一人主導：LG ultrawide 掛牆，排第一組 3×2 的 Claude Code 視窗陣列；旁邊螢幕轉直立，排第二組 3×2；MacBook 跑第十三個視窗。 螢幕以支架鎖牆，無辦公室。
計費方式為按 token 計費的 API，非訂閱方案。成本結構決定商業模式： 十三個同步代理，第一間完工商店的收入即足以覆蓋當日全部 API 費用。每間商店售價 $800，十三個視窗全天運行成本不超過 $80。
每個視窗都是一個獨立的 Claude Code session，跑在自己的工作目錄裡，有自己的
CLAUDE.md、自己連的 MCP、和自己能動的檔案範圍。各 session 互不干擾，
因為它們不共用 context window。統籌靠的是檔案系統、Shopify Admin API、和操作者的人工審核。
你是我新請的 founder-engineer。
常見的代理 prompt 採詢問語氣，如 「可以幫我做⋯⋯嗎」、「你覺得⋯⋯怎麼樣」， 每一次澄清都會產生等待成本。此操作者在第一個視窗的 system prompt 中直接重新定義角色關係：
# /CLAUDE.md — Window 01 (Orchestrator) You are my new founder-engineer. You don't hint. You don't advise. You don't supplement. You own the result. The store ships, or it doesn't — and that is on you. # Working directory /projects/client-{{client_id}}/ # Authority - Read/write all files in this project. - Call the Shopify Admin API via the MCP server already configured. - Spawn sub-tasks in worktrees W02–W13 by writing briefs to /briefs/. - Mark a brief done by moving it to /briefs/_done/. # Definition of done A live, working store at https://{{slug}}.myshopify.com with: 80 products, payment + shipping live, 30 email flows armed, homepage + 50 banners shipped, GA4 + pixels firing, QA report green. No half-finished stores leave the floor.
founder-engineer 定位直接告訴模型遇到模糊地帶時的預設行為：判斷、記錄、往下走，不要停下來等確認。這對輸出效率的影響比大多數 prompt 技巧更直接。
每個代理只負責商店的一個切面，工作範圍緊縮成一個明確的交付物。統籌者（W01）是唯一會跟操作者對話的。 其他人各自讀 brief、執行、寫檔案、簽核。以下是完整名單。
section.liquid 或 Shopify 2.0 JSON 模板組起來。
settings_data.json，讓整間店繼承同一套。
同時生成一張單頁品牌指南交給客戶。
robots.txt.liquid。送 Google Search Console。
新的代發業者把一份 brief 丟進佇列：利基、目標國家、偏好供應商、幾個參考店。 操作者把這份貼進 W01（統籌者）。整天為這個客戶手動打字的時間，就到此為止。
約 5 分鐘 · 操作者主導
統籌者把專案目錄搭起來，寫出 12 份 brief 放進
/briefs/，下游每個視窗一份。每份 brief 包含：
客戶利基、品牌語氣、交付物、檔案路徑、截止點。
操作者把每個下游視窗開起來，打一句「讀你的 brief 然後執行」就走人。 W02（商品目錄）和 W05（品牌系統）先跑，因為下游全部都靠它們。 W03、W04、W06–W10 一旦依賴解除就開工。 W08（橫幅）等 W02 的商品圖和 W05 的 tokens。
約 90 分鐘 · 11 個代理同步跑等首頁和 PDP 穩定後，W11 才裝所有 pixel、開第一個 A/B 實驗。 刻意排在後段。版型還在修改時安裝 pixel，會產生大量無效事件。
約 15 分鐘 · 排在 W04 之後W13 是門口的保鑣。它在三個配送區下實際測試訂單、跑一輪完整 Lighthouse、走過每一條連結、 觸發每一封信。綠燈 → W01 整包好交件。紅燈 → 附修正清單退回對應視窗。
約 20 分鐘 · 只動 W13W01 寫好交付信，包含商店網址、管理員轉移說明、品牌指南附檔、30 天上手清單。 操作者掃過一遍，按送出。$800 帳款入帳。視窗 01 立刻從佇列拉下一個客戶。
約 10 分鐘 · 操作者確認以每天 6 間、每週 6 天、每年 50 週計算，數字可以自行推算。 關鍵在於 Shopify 建站的成本結構已經改變：過去需要 $3,500 的建站工作，現在可以 $800 交付，對應的 token 成本約 $12。
# 建一份每個新客戶都會複製過去的 template。 mkdir -p ~/factory/_template cd ~/factory/_template # 頂層目錄結構 mkdir -p briefs briefs/_done decisions assets/identity assets/banners \ catalog config sections templates qa # 每個視窗的 CLAUDE.md — 一個代理一份 for n in $(seq -w 01 13); do mkdir -p windows/W$n touch windows/W$n/CLAUDE.md done # 共用 MCP 設定 mkdir -p .mcp touch .mcp/shopify.json .mcp/klaviyo.json .mcp/supplier.json
每個新客戶就是 cp -R _template client-{slug}。
視窗 prompt、檔案路徑、MCP 串接都從同一份 template 繼承。
修改一次，所有後續商店同步更新。
以下是三個代表性 prompt。其他十個遵循相同格式：一個角色、明確的工作範圍、 以交付物形式定義的 definition-of-done。（完整 13 個放在 template repo 裡。）
You are my new founder-engineer. You don't hint. You don't advise. You own the result. # Working directory /factory/client-{{slug}}/ # Authority Read/write all files. Call Shopify Admin via MCP. # Your only job 1. Read /intake.md (the client brief). 2. Decide niche, brand voice, regions, payment, shipping. Write decisions to /decisions/01-foundation.md. 3. Generate 12 briefs in /briefs/W02..W13.md. Each brief contains: - GOAL (one sentence) - INPUTS (paths or URLs to read) - OUTPUTS (exact file paths the agent must produce) - DEFINITION OF DONE (the test that must pass) 4. Wait. When all 12 briefs are in /briefs/_done/, run the final QA review and write /delivery.md (client email + handoff). Never ask me a clarifying question. Make the call, log it, move.
You build the product catalog. 80 products. No more, no fewer. # Read /briefs/W02.md, /decisions/01-foundation.md # Tools MCP: supplier (CJ/AliExpress/Spocket), Shopify Admin # Write /catalog/products.json, then push to Shopify via API # Quality bar - 80 SKUs, deduped by image-hash + title-similarity. - Price = supplier_cost × markup_table[niche]. - Variants normalized (size XS–XXL, color names canonicalized). - Tags from the niche taxonomy in /decisions/01-foundation.md. - Every product must have ≥3 images and a non-empty body_html. Body_html is a placeholder — W03 (Copy Rewrite) will replace it. Done = 80 products visible in Shopify Admin AND /catalog/products.json snapshot committed.
You are the bouncer. No half-finished store ships. # Read /briefs/W13.md, all /briefs/_done/*.md # Tools MCP: Shopify Admin, headless browser (Playwright), Lighthouse # Run, in order 1. Test orders in 3 shipping zones (default + 2 international). Verify each completes through to confirmation page. 2. Walk every page (homepage, all collections, 5 random PDPs, cart, checkout, account, search, 404, policy pages) on desktop + mobile breakpoints. 3. Lighthouse on homepage + 1 PDP. Performance > 70 mobile. 4. Verify every email flow fires by triggering each event. 5. Validate JSON-LD schema, sitemap, robots, canonical tags. # Output /qa/report.md with: pass/fail per check, screenshots of failures, and — if any fail — a /qa/fixes-for-W{nn}.md addressed to the responsible window. Do not mark done if any check is red.
用官方的 Shopify Dev MCP server，或自己包一個包住 Admin GraphQL API 的版本。 W02、W03、W04、W06、W10、W11、W12、W13 都會用到。Token 必須按商店區隔， 每個客戶使用獨立的 API token。
包一層 CJ Dropshipping、Spocket、或 AliExpress，供 W02 使用。每天本地快取一次資料。 供應商 API 有速率限制且回應慢，每個代理重複抓取同一批 SKU 會造成嚴重延遲。
自己包 Klaviyo REST API 的 server。W07 用它推 30 封生命週期信。寫一次就好， 把 flow JSON 模板按利基做版控。
W08（橫幅）和 W09（logo）需要圖像生成（Higgsfield / Nano Banana 2 / Soul）和去背服務。 W08 跑那 50 張橫幅，是一天裡最大宗的非 Anthropic 成本項。
第 200 間商店輸出品質與第 1 間一致，原因是每一個重複出現的決策都被編寫成了一個 Skill。 Skills 是這套體系的持久知識層。Claude Code 依描述比對，自動載入對應的 markdown 檔案。 以下是這個工廠所需的最小 Skill 組合。
settings_data.json 結構之間的對應關係。
沒有這個 Skill，W05 每次都需要重新推斷哪個 setting key 對應哪個 CSS 變數，浪費 token。
--- name: shopify-product-loader description: Use when bulk-creating Shopify products via the Admin GraphQL API. Triggers on phrases like "load 80 products", "push catalog to Shopify", "bulk product create". Handles variants, images, tags, metafields, rate-limiting, and retries. Required for W02 (Catalog Builder). --- # When to use - W02 building a fresh catalog from supplier feed - Any agent that needs to write products to Shopify # Inputs you must have - A products.json with the canonical schema (see below) - A valid Shopify Admin API token in env var SHOPIFY_ADMIN_TOKEN # Steps 1. Validate products.json against schema in /skills/.../schema.json 2. Chunk products in batches of 25 for GraphQL `productSet` mutation 3. Call mutation; on rate-limit (429), exponential backoff 4. For each successful product, upload images via stagedUploads 5. Verify each product is visible in Admin (GET productByHandle) # Output - All 80 products live in store - /catalog/_loaded.json with Shopify product GIDs # Failure handling - If < 80 products land: write /catalog/_failed.json with reason per SKU - Never mark "done" with partial load. Hand back to W01.
這個案例的架構是可複製的。在投入 API 費用之前，以下六個限制條件需要先確認。
大量橫幅生成、每個視窗跑 Opus、長 context、無 prompt 快取，同一組設備一天可達 $400。 $80 這個數字的前提是明確的模型路由策略：樣板任務用低成本模型，必要時才升級， 並搭配積極的快取策略。
一天 6 間的速度下，除非利基差異夠大，第 200 間會跟第 5 間長得很像。 付 $800 的代發業者通常看不出來；想建長線品牌的客戶會看得出來。 模型最後出貨的長相，只取決於 QA 代理（W13）和操作者的眼睛放行了什麼。
自動生成的商店、自動生成的文案，可能會帶出商標侵權、管制商品 （保健食品、化妝品、電子產品）的錯誤、或不實宣稱。W13 的 QA 要加上合規檢查， 跨區域操作（廣告法、商品法各地不同）時尤其重要。
供應商 feed 中斷、Shopify Admin API 限速、Klaviyo 對新帳號限流，13 個代理會同步受影響。 每個 MCP server 都要內建佇列＋重試，本地一定要有快取， 這樣一次 30 分鐘的中斷不會斷掉整天的產能。
$800 的交付物是可運作的開站套裝，不是客製品牌系統。進件 brief 必須明確說明範圍。 能將此模式規模化的操作者，銷售的是「一間週一即可上線的功能性商店」， 而非長期品牌建設服務。
「每天只做兩個決策」是簡化的說法。實際上操作者需要掃過每一份 QA 報告、處理 W01 升上來的邊界情況、 應對供應商斷線，以及回覆客戶。每日主動注意力約 5 小時以內，但不為零。
可遷移的是架構： 十三個窄域代理，各負責一層，靠檔案系統協調，由一個人審核每一個閘門。 這個模式適用於任何交付物可以拆成獨立層的產線。Shopify 商店是其中一個應用場景， 房地產物件上架、SaaS 著陸頁等結構類似的產出同樣適用。
「Founder-engineer」定位也可遷移。不暗示、不建議、負責結果這個角色設定， 適用於任何需要代理自主判斷的場景。將目前設定為「助手」的代理改寫 system prompt， 觀察輸出行為的變化。