<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>案例研究 on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/%E6%A1%88%E4%BE%8B%E7%A0%94%E7%A9%B6/</link><description>Recent content in 案例研究 on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Thu, 06 Aug 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/%E6%A1%88%E4%BE%8B%E7%A0%94%E7%A9%B6/feed.xml" rel="self" type="application/rss+xml"/><item><title>AIO / GEO - Part 5 - 量測與案例篇：建立監測系統與六個月實戰復盤</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part5-measurement-case-study-zh/</link><pubDate>Sat, 01 Aug 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part5-measurement-case-study-zh/</guid><description>大多數人的做法：改完網站，等三個月，然後憑感覺說「好像有效」。 真正該做的事：在改之前先量基線，改之後每週量一次，把「哪一次改動讓哪一題上升」講清楚。
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，但它在報表上完全不存在。 結論：你必須主動去問模型，而不是被動等流量。這就是監測系統要做的事。</description></item><item><title>AIO / GEO - Part 6 - 實戰案例：大型企業官網（多語系 + AWS + 法遵）</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part6-case-enterprise-site-zh/</link><pubDate>Sun, 02 Aug 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part6-case-enterprise-site-zh/</guid><description>大企業做 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 完全相反。</description></item><item><title>AIO / GEO - Part 7 - 實戰案例：電商網站（12,000 SKU + 價格新鮮度）</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part7-case-ecommerce-zh/</link><pubDate>Mon, 03 Aug 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part7-case-ecommerce-zh/</guid><description>電商 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 個商品頁，一個都沒被引用過。</description></item><item><title>AIO / GEO - Part 8 - 實戰案例：單頁式 Landing Page（內容只有 800 字）</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part8-case-landing-page-zh/</link><pubDate>Tue, 04 Aug 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part8-case-landing-page-zh/</guid><description>一頁式網站做 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。這其實是好事——任何改動的效果都會很清楚。
二、先搞清楚：小網站的三個結構性劣勢 劣勢 影響 能不能繞過 ────────────────────────────────────────────────────────── 網域權威幾乎為零 同分時永遠輸 ✘ 不能，需要時間 內容量少 能命中的查詢少 ✔ 能，靠精準取代廣度 沒有第三方提及 實體不存在 ✔ 能，這是最快的一項 戰略推論：不要跟大公司比廣度。找出「他們沒有認真回答、而你能給出最好答案」的少數問題，全力攻下。</description></item><item><title>AIO / GEO - Part 9 - 實戰案例：線上課程平台（付費牆 + 影片內容）</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part9-case-course-platform-zh/</link><pubDate>Wed, 05 Aug 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part9-case-course-platform-zh/</guid><description>「我們的內容都在付費牆後面，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 上從來沒被任何人或機器讀過。</description></item><item><title>AIO / GEO - Part 10 - 實戰案例：私有 Repo 與內部知識庫（把 GEO 反過來用）</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part10-case-internal-rag-zh/</link><pubDate>Thu, 06 Aug 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/aio-geo-part10-case-internal-rag-zh/</guid><description>前九篇都在講怎麼讓外部引擎引用你。 這一篇反過來：你自己就是那個引擎。
有趣的地方在於——當你能看到檢索管線的每一層時， 會發現「內容不可引用」的原因，和公開網站一字不差。
一、情境 公司 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%」是同一個數字，也是同一類問題。</description></item></channel></rss>