分析脈絡
對應提問
如何用 Claude Code Skills 系統化地管理業務知識、加速數據分析、並將影響力從個人擴展到團隊？
拆解方式
- 盤點 6 個 Skills 的定位、職責邊界與協作關係
- 展示 business-glossary 的 Eval 評測數據（16 題，+45pp）
- 論述知識閉環機制與從個人→團隊的影響力擴展
資料來源與欄位
- Skills SKILL.md 定義檔 × 5
- business-glossary References × 18
- Eval grading.json × 32（16 題 × with/without）
- Hub 報告清單（8 份報告、52 個版本）
資料區間
2026 Q1 建構成果
數據分析 Agent 系統架構總覽
5 個 Skills 分三層運作：知識層提供業務定義與產業洞察、查詢層安全生成 SQL、產出層渲染分析報告。所有 Skill 共享 business-glossary 作為 SSOT。
Knowledge Layer
知識層
business-glossary
18 篇 Reference · SSOT
18 篇 Reference · SSOT
ads-analyst
OTA 廣告策略顧問 · 產業知識
OTA 廣告策略顧問 · 產業知識
knowledge-capture
知識回收 · 持續累積
知識回收 · 持續累積
confluence-search
Subagent
本地知識不足時啟動獨立子代理搜尋 Confluence，僅回傳摘要，不佔主 Agent context
Query Layer
查詢層
bigquery-data
Text2SQL · dry_run 安全機制
Text2SQL · dry_run 安全機制
信心門檻機制
表選擇
欄位語義
業務邏輯
JOIN 關係
篩選條件
任一項不通過 → 暫停產出，主動提問
安全防護
dry_run 預估
20 GB 上限
只允許 SELECT
Output Layer
產出層
data-analysis
Plotly 圖表 · HTML 報告 · Hub
Plotly 圖表 · HTML 報告 · Hub
Monochrome Design System
12 種 Plotly 圖表 · 互動篩選 · Jinja2 模板
迭代機制
腳本存檔 → 讀取前版 → 增量修改 → Hub 自動版本管理
知識循環
查閱
讀取 References
→
使用
釐清新知識
→
回收
寫回 References
⟳
Eval 驅動迭代
16 題業務知識評測（持續新增測試題），對比 with / without Skill
正確率 48.8% → 93.8% （+45pp）
正確率 48.8% → 93.8% （+45pp）
93.8%
Skills 詳細介紹
每個 Skill 有明確的職責邊界和觸發條件，CLAUDE.md 中定義的分工規則確保問題被路由到正確的 Skill。
business-glossary
核心
業務邏輯的 Single Source of Truth
18 篇 Reference 文件（DM 11 / DW 4 / General 3）
涵蓋：訂單會計、金額計算、客戶分群、市場分類、商品分類、資料表目錄
特色：所有 Skill 的知識基底，遇到不確定先查這裡
Eval：16 題評測平均 93.8%（無 Skill 僅 48.8%）
bigquery-data
查詢
安全、透明、可控的 SQL 生成與執行
兩種模式：SQL 模式（只產出）/ 查詢模式（dry_run → 確認 → 執行）
信心門檻：5 項自我檢查，任一不通過就暫停提問
安全機制：dry_run 預估掃描量、20 GB 上限自動阻擋
輸出：River Style SQL + Markdown 表格結果
data-analysis
產出
互動式 HTML 分析報告產出管線
工具鏈：BQClient + ChartBuilder (12 種圖表) + ReportRenderer + HubPublisher
設計系統：Monochrome Design System · Plotly 互動圖表
迭代機制：腳本存檔 → 下次讀取前版 → 在此基礎上修改
實績：8 份報告、累計 52 個版本迭代
ads-analyst
知識
OTA 產業經驗的廣告數據分析總監
角色：策略顧問，不只看數字，更理解數字背後的業務意涵
模式切換：討論模式（預設） / 開發模式（修改程式碼）
專精：歸因模型、預算配置、新客獲取 vs 利潤最大化
預建腳本：LTV、配速、Campaign 深潛、異常偵測
knowledge-capture
回收
讓每次對話都在增強系統知識
流程：掃描對話 → 辨識新知識 → 提議更新 → 確認後寫入
目標：主要寫回 business-glossary/references/
篩選：只記錄已驗證的知識，排除猜測和一次性數據
意義：從「用完就忘」到「用完就記住」
工作流程示例
一個典型分析需求如何在多個 Skills 之間流轉，展示 Skill 間的協作模式。
典型分析場景：「幫我分析上月各市場的新客 ROI」
data-analysis
步驟 0：列出現有報告，詢問要迭代還是新建
data-analysis
步驟 1：「新客定義用 retention_type_dd 還是 _mm？」
→ business-glossary
讀取
dm/customer-and-product.md → 確認新客定義→ bigquery-data 邏輯
信心門檻檢查 → 生成 SQL → dry_run 預估 → 安全查詢
data-analysis
Plotly 圖表 → HTML 報告 → 自動開啟瀏覽器 → Hub 發布
→ knowledge-capture
（可選）對話中發現的新知識寫回 references
整個流程中，每個 Skill 只做自己擅長的事，透過 CLAUDE.md 的分工規則自動路由到正確的 Skill。
總結：為什麼這件事值得做
解決的核心問題
- 業務知識散落 → 集中為 18 篇 SSOT Reference，任何人都能查到一致的定義
- AI 回答不可靠 → 透過 Eval 驗證，正確率從 48.8% 提升至 93.8%（+45pp）
- 分析從零開始 → 報告迭代機制讓每次分析都在前版基礎上累積
技術深度
- 設計了 SSOT + 信心門檻 + 知識閉環 + Eval 驅動的完整架構
- 開發了 5 個 Python 工具模組（BQClient、ChartBuilder、ReportRenderer、Interactive、HubPublisher）
- 建立了 16 題評測框架，用數據而非感覺驅動迭代
從個人到組織的影響力
這套系統的價值不只在於提升個人效率，更在於它是一個「知識資產化」的範本。透過 knowledge-capture 的閉環機制，每次使用都在增強系統——這意味著團隊中的每一位成員都能受益於所有人累積的知識，而不只是自己的經驗。這是從「個人能力」到「組織能力」的關鍵跨越。
知識管理閉環
business-glossary（查閱）→ knowledge-capture（回收）形成閉環，每次對話都在增強系統知識。Confluence Agent 作為外部知識的補充來源。
1
使用者提問
「retention_type_dd 和 _mm 差在哪？」
2
business-glossary 查閱 References
讀取 dm/customer-and-product.md → 提供權威答案
3
對話中發現新知識
「原來 _dd 只看最近 30 天，適合短期活動分析」
4
knowledge-capture 回收新知識
寫回 dm/customer-and-product.md → 下次所有人都能查到
5
知識累積 → 下一位使用者受益
SSOT 持續增長，回答品質越來越好
每次對話都在讓知識庫變得更完整 — 使用即維護，維護即使用
Reference 知識庫結構
18 篇 Reference 文件按資料架構層級組織（DM / DW / General），涵蓋 KKday 數據團隊日常工作的所有業務知識。
關鍵發現
DM 層 11 篇最多，因為日常分析 90% 以上都在 DM 層操作。DW 層 4 篇用於追根溯源，General 3 篇提供公司與市場背景。
Skill 評測：16 題業務知識問答
建立 16 個測試案例，涵蓋訂單會計、客戶分群、資料架構等核心議題。每題對比「有 business-glossary Skill」vs「純 LLM」的回答品質。
關鍵發現
With Skill 平均正確率 93.8%，Without Skill 僅 48.8%，提升 45 個百分點。最大改善在 tableau_order_all 篩選、retention_type 粒度、CID 渠道定義三題，從 0% 提升至 100%。
Skills 知識量與報告產出
6 個 Skills 共計 73 KB 的 SKILL.md 定義 + 18 篇 Reference 文件。data-analysis 已產出 8 份報告、52 個版本迭代。
關鍵發現
MTA 歸因分析報告迭代 35 次，顯示報告迭代機制的實用性 — 不需要每次從零開始，在前版基礎上持續優化。
從個人到團隊的影響力
Skills 系統不只是個人效率工具，更是知識資產的載體。從個人建構 → 小組標準化 → 組織規模化，三階段擴展影響力。
Before — 傳統方式
個人知識 = 個人瓶頸
業務定義散落在 Slack、Confluence、個人筆記
新人問一次、再問一次、每次都要教
SQL 寫錯欄位，跑出來的數字跟管報不一致
分析報告每次都從零開始做
After — Skills 系統
組織知識 = 團隊加速器
18 篇 Reference 統一維護，SSOT 隨時可查
AI 助手自動引用正確定義，一致性 93.8%
信心門檻機制，不確定就問，不亂給答案
報告可迭代，8 份報告累計 52 個版本
個人
建構 Skills & 知識庫
— 撰寫 5 個 Skill 定義
— 建立 18 篇 Reference
— 設計 Eval 評測框架
— 開發工具鏈 (5 modules)
→
小組
分享 & 標準化
— 團隊共用統一業務定義
— 降低 onboarding 門檻
— 報告格式與口徑一致化
— 減少「問人」的等待時間
→
組織
規模化影響力
— 可複製到其他 BU/Team
— AI-assisted 分析文化
— 數據治理自動化基礎
— 知識資產持續增值
關鍵技術決策
建構這套系統過程中的四個核心設計決策，每一個都直接影響系統的可用性和可擴展性。
SSOT 設計
所有業務知識集中在 business-glossary 的 18 篇 Reference 中。
其他 Skill 需要業務定義時不自行定義，而是查閱這個共享知識庫。
避免了「每個 Skill 各說各話」的問題。
信心門檻機制
bigquery-data 在生成 SQL 前強制自我檢查 5 個條件。
任一不通過就暫停產出，主動向使用者確認。
「寧可多問一次，也不要產出錯誤的 SQL」。
Eval 驅動迭代
建立 16 題評測工作區，對比「有 Skill」vs「無 Skill」的表現。
用數據驗證 Skill 的實際效果（+45pp），而非憑感覺調整。
評測結果反饋到 Reference 內容的持續改進。
報告迭代機制
每份報告同時保存 HTML + Python 腳本。
下次修改時讀取前版腳本，在此基礎上迭代。
Hub 自動版本管理，8 份報告累計 52 個版本。