https://yennj12.js.org/yennj12_blog_V4/tags/case-study/Recent content in Case Study on YennJ12 Engineering BlogHugo -- gohugo.ioen-usThu, 06 Aug 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part4-outsourcing-zh/Thu, 30 Apr 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part4-outsourcing-zh/情境設定 公司背景： TechBridge Studio，台灣台北，10 人軟體外包公司 主要業務： 承接中小企業的網站、APP、後台系統開發 每月詢問量： 約 40-60 個潛在客戶詢問 核心痛點： PM 每天要花 3-4 小時回覆詢問、估時、報價 需求不清楚的客戶佔 70%，常常來回溝通一週才能確定範圍 報價單格式不統一，常常漏掉風險評估 客戶問進度時 PM 要手動查詢 Jira，很耗時 目標： 用 AI Agent 團隊處理 80% 的初步詢問與報價流程，讓 PM 只需審核最終結果。 整體架構設計 客戶詢問（LINE / Email / 網頁表單） ↓ ① Intake Agent（需求釐清師） → 提問 10 個標準問題，整理結構化需求 ↓ ② Scope Agent（範圍評估師） → 拆解功能清單，標記模糊需求，評估風險 ↓ ③ Estimator Agent（報價估算師） → 根據功能清單估時、報價，套用公司價目表 ↓ ④ Proposal Agent（提案撰寫師） → 產出正式提案文件（含時程、里程碑、付款條件） ↓ ⑤ PM Review（人工審核） → PM 在 5 分鐘內審核並核可 ↓ ⑥ Follow-up Agent（追蹤師） → 3 天後自動詢問客戶是否有問題，追蹤成交 技術選型 本案例使用 Claude Code + AGENTS.https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part5-measurement-case-study-zh/Sat, 01 Aug 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part5-measurement-case-study-zh/大多數人的做法：改完網站，等三個月，然後憑感覺說「好像有效」。 真正該做的事：在改之前先量基線，改之後每週量一次，把「哪一次改動讓哪一題上升」講清楚。 GEO 最大的風險不是做錯，是做完不知道有沒有用， 於是第二季預算被砍掉。 一、為什麼傳統分析工具在這裡失效 你想知道的 GA4 能告訴你 GSC 能告訴你 ────────────────────────────────────────────────────────────────── ChatGPT 提到我幾次？ ✘ ✘ Perplexity 引用了我哪一頁？ 部分（有 referrer） ✘ AI Overview 有沒有引用我？ ✘ ✘（曝光混在一起） 模型怎麼描述我的產品？ ✘ ✘ 競品的引用份額是多少？ ✘ ✘ 核心問題：AI 引用大多不產生可歸因的流量。 使用者旅程的真實樣貌 Day 1 問 ChatGPT「台灣有哪些 OMS 系統」 → 答案中提到 OrderFlow，附連結 → 使用者沒有點連結，只是記住了名字 → GA4：無任何紀錄 Day 4 在 Perplexity 問「OrderFlow 好用嗎」 → 讀了摘要，點了一個連結 → GA4：referrer = perplexity.ai（唯一看得到的一次） Day 11 直接 Google 搜尋「OrderFlow 價格」 → 點進官網定價頁 → GA4：Organic Search，query = 品牌詞 Day 14 填表單 → GA4 歸因：Organic Search / 品牌詞 真正的第一因是 Day 1 的 ChatGPT，但它在報表上完全不存在。 結論：你必須主動去問模型，而不是被動等流量。這就是監測系統要做的事。https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part5-digital-marketing-zh/Thu, 30 Apr 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part5-digital-marketing-zh/情境設定 公司背景： PixelFlow Agency，台灣台中，8 人數位行銷公司 主要服務： 社群媒體管理、廣告投放（Meta / Google Ads）、SEO、內容行銷 服務客戶數： 同時服務 15-20 個品牌 核心痛點： 每個客戶每月需要 30-50 篇社群貼文，文案師產能跟不上 廣告成效報告每月要花 2 天手動彙整，格式各異 新客戶的「內容策略規劃」每次都要從頭寫，耗時 3-5 天 客戶問「我們這個月的廣告怎麼樣」時，帳號管理師要翻資料才能回答 目標： AI Agent 承擔 60% 的文案產出、100% 的報告彙整、80% 的策略草稿。 整體架構設計 定期觸發（每日/每週/每月）+ 客戶即時請求 ↓ ① Brand Agent（品牌守門員） → 載入品牌 DNA，確保所有輸出符合品牌調性 ↓ ┌────────────────────────────────┐ │ 並行執行（Parallel Execution） │ ├──────────────┬─────────────────┤ ② Content Agent ③ Ad Copy Agent （內容策略師） （廣告文案師） └──────────────┴─────────────────┘ ↓ ④ Analyst Agent（數據分析師） → 讀取廣告成效數據，產出洞察 ↓ ⑤ Report Agent（報告撰寫師） → 整合所有產出，製作月報/週報 ↓ ⑥ Presenter Agent（簡報師） → 把報告轉成客戶易讀的簡報格式 技術選型： 本案例使用 LangGraph + Claude API（路線 C）https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part6-case-enterprise-site-zh/Sun, 02 Aug 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part6-case-enterprise-site-zh/大企業做 GEO 的難點從來不是「不知道怎麼做」。 是「知道怎麼做，但要跑六個部門的簽核」。 這個案例的技術部分只花了 4 人天。 剩下五個月都在處理組織問題。 一、情境 公司 台灣製造業集團，3,000 人，年營收約 NT$210 億 產品 工業自動化零組件（B2B，客戶為系統整合商與 OEM） 網站 6 語系（繁中/簡中/英/日/德/越），約 1,800 頁 CMS Adobe Experience Manager（AEM） 部署 AWS：S3 + CloudFront + WAF，Route 53 多區域 團隊 IT 部門（不含前端）、行銷部（不懂技術）、法務（很有意見） 業務動機很具體：海外客戶的採購工程師開始用 ChatGPT 做初步選型。業務回報「客戶說 AI 推薦了三家，沒有我們」。 基線量測（40 題 × 3 引擎，2026-02） ──────────────────────────────────── 提及率 9% 引用率 2% 描述正確率 31% ← 模型講的是 2019 年被併購前的舊公司名 Engine Variance 3pp ← 各引擎一樣糟，所以不是單一引擎的技術問題 Coverage Gap 67% 注意 Engine Variance 只有 3pp：各引擎表現一致地差，代表不是 CDN 擋人這種局部問題，而是內容本身就不存在或不可用。這和 Part 5 案例 A 完全相反。https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part7-case-ecommerce-zh/Mon, 03 Aug 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part7-case-ecommerce-zh/電商 GEO 的核心矛盾： 你有 12,000 頁，但只有 40 頁值得為 GEO 手工優化。 剩下 11,960 頁要靠模板——而模板化內容天生就是薄內容。 解法不是「把每頁寫厚」， 是「讓資料本身變成內容」。 一、情境 公司 台灣戶外用品電商，35 人，年 GMV 約 NT$4.2 億 品項 登山、露營、單車裝備，12,000 SKU，420 個品牌 技術 Shopify（後台）+ Next.js App Router（前台，headless） 部署 Vercel（前台）、Shopify（結帳）、Algolia（站內搜尋） 內容 商品頁 12,000 / 分類頁 380 / 選購指南 64 篇 業務動機：客單價 NT$3,000-15,000 的裝備，購買前研究期長達 2-6 週。使用者開始用 AI 問「登山杖怎麼選」「XX 帳篷跟 YY 比哪個好」。 基線量測（45 題 × 3 引擎，2026-03） ────────────────────────────────────── 提及率 22% 引用率 9% 價格正確率 14% ← 幾乎全錯 Page Concentration 91% ← 引用幾乎全落在 3 篇選購指南 Coverage Gap 38% Page Concentration 91% 是這個案例的核心訊號：12,000 個商品頁，一個都沒被引用過。https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part8-case-landing-page-zh/Tue, 04 Aug 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part8-case-landing-page-zh/一頁式網站做 GEO，聽起來像沒有勝算。 但小團隊有一個大公司沒有的優勢：可以在一週內把整個網站重寫。 這個案例的重點不是技巧， 是「資源極少時，該把力氣放在哪」。 一、情境 產品 Webhook 除錯與重送工具（開發者工具） 團隊 3 人（2 工程 + 1 兼職行銷） 網站 Landing Page（1 頁，約 800 字）+ 文件站（12 頁）+ 部落格（3 篇） 技術 Astro（靜態）+ Cloudflare Pages 定價 Free / Pro $19 / Team $79 競品 5 家，其中 2 家是 YC 出身、內容量是他們的 50 倍 目標 被「webhook 除錯工具有哪些」這類問題引用 基線量測（30 題 × 3 引擎，2026-01） ────────────────────────────────── 提及率 0% 引用率 0% Coverage Gap 83% 乾淨的 0。這其實是好事——任何改動的效果都會很清楚。 二、先搞清楚：小網站的三個結構性劣勢 劣勢 影響 能不能繞過 ────────────────────────────────────────────────────────── 網域權威幾乎為零 同分時永遠輸 ✘ 不能，需要時間 內容量少 能命中的查詢少 ✔ 能，靠精準取代廣度 沒有第三方提及 實體不存在 ✔ 能，這是最快的一項 戰略推論：不要跟大公司比廣度。找出「他們沒有認真回答、而你能給出最好答案」的少數問題，全力攻下。https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part9-case-course-platform-zh/Wed, 05 Aug 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part9-case-course-platform-zh/「我們的內容都在付費牆後面，GEO 是不是做不了？」 這是最常見的問題，也是最常見的錯誤前提。 付費內容站要問的不是「開不開放」， 而是「開放哪一層，才能讓模型有東西引用、又不讓人不用付費」。 一、情境 平台 資料工程 / 後端開發線上課程，繁中為主 規模 8,000 名付費學員，18 門課，1,200 支影片，年營收約 NT$6,000 萬 內容 90% 是影片（平均 12 分鐘）+ 課後練習 + 討論區 技術 Next.js（前台）+ Django（後台）+ PostgreSQL 部署 GCP：Cloud Run（前後台）+ Cloud CDN + Cloud SQL + GCS（影片） 付費 單門課 NT$3,600-6,800，或年費 NT$14,800 全站通行 業務動機：學員來源高度依賴 FB 廣告與 KOL 合作，獲客成本連續兩年上升（CAC 從 NT$1,900 漲到 NT$3,400）。同時發現學員在課程討論區問的問題，很多人是先去問 AI——但 AI 從沒提過這個平台。 基線量測（35 題 × 3 引擎，2026-01） ────────────────────────────────── 提及率 6% 引用率 2% Coverage Gap 71% 可被 crawler 讀取的內容佔全站 3% ← 核心問題 二、真正的問題：內容存在，但不可見 內容資產盤點 ───────────────────────────────────────────────────── 1,200 支影片 付費牆後，且只有影片沒有文字 1,200 份自動字幕（VTT） 存在 GCS，從未公開 ↑ 這是被完全浪費的資產 340 篇課後練習與解答 付費牆後 2,800 則討論區問答 付費牆後 ← UGC，AI 最愛引用的類型 18 個課程介紹頁 公開，但都是行銷文案 0 篇部落格 — 可被 AI crawler 讀到的：18 個課程介紹頁 ≈ 全站內容的 3% 關鍵發現：字幕檔已經存在了。1,200 支影片 × 平均 1,800 字 = 約 216 萬字的技術內容，躺在 GCS 上從來沒被任何人或機器讀過。https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part10-case-internal-rag-zh/Thu, 06 Aug 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part10-case-internal-rag-zh/前九篇都在講怎麼讓外部引擎引用你。 這一篇反過來：你自己就是那個引擎。 有趣的地方在於——當你能看到檢索管線的每一層時， 會發現「內容不可引用」的原因，和公開網站一字不差。 一、情境 公司 B2B 金融科技，400 人（工程 180 人） 背景 2026 年初上線內部 AI 助手，接 Slack 資料源 GitHub Enterprise（86 個 private repo）、Confluence（4,200 頁）、 Notion（部分團隊）、Slack 歷史訊息、Jira、Google Drive 技術 GCP：Vertex AI Search（as RAG 檢索層）+ Gemini/Claude 生成 文件同步用 Cloud Run Job + Cloud Scheduler 使用者 全體員工，尖峰每日約 900 次查詢 問題：上線三個月後，工程團隊的使用率從第一週的 71% 掉到 12%。 內部滿意度調查（n=142） ────────────────────────────────────────────── 「答案正確」 23% 「答案有引用來源」 61% 「引用的來源是對的」 31% ← 關鍵 「比自己搜尋快」 34% 「我已經不用了」 58% 最常見的自由填答： 「它引用了一份 2022 年的舊 RFC，那個架構早就換掉了」 「它把 staging 的設定當成 production 講」 「它從一個廢棄的 repo 抓答案」 「引用連結點進去看不到它講的那句話」 「引用的來源是對的」只有 31% ——這和 Part 6 那家製造業的「描述正確率 31%」是同一個數字，也是同一類問題。