把各部門對同一KPI的名稱、定義、公式、來源、時間窗、排除條件、Owner攤開來比，找出誰在用哪一種算法，產出定義對照表與衝突清單。
先確認這一篇解的是不是你的問題。看完這兩節如果覺得不像，就不用再往下讀——省下的時間比讀完更值錢。
每個月的營運會議上最容易吵起來的，往往不是數字本身，而是同一個名字底下藏了好幾種算法。行銷部說『活躍用戶』本月成長一成二，產品部卻說掉了半成，兩邊都沒有算錯，只是行銷數的是打開過App的人、產品數的是完成過至少一個核心動作的人，時間窗一個明確是rolling 30天、一個沒寫清楚是不是rolling。轉換率也一樣，業務部的分母是報價單、行銷部的分母是廣告點擊，同一個詞彙背後根本不是同一件事。這種分歧平常不會被發現——各部門各自產各自的報表，數字第一次對到一起，通常是在跨部門會議或董事會報告上，而那時候已經沒時間查為什麼對不起來，只能各說各話、互相懷疑對方算錯。真正的問題不是誰的算法比較對，而是從來沒有人把每個部門「這個KPI到底怎麼算」寫下來、攤開來比對過。人工去比對這些定義既枯燥、跨部門溝通成本又高，於是永遠排不進待辦，直到出大問題才臨時補救。
以下都是具名機構的公開案例，每個來源都經過連結實測。數字只寫來源講得出來的；來源沒講的，這裡就寫未公開。
Airbnb發現Data Science與Finance兩部門對同一個簡單問題（如「上週哪個城市訂房最多」）常給出不同答案——因為兩邊用不同的資料表、指標定義與商業邏輯去算「同一個」數字，因此建立Minerva：指標只定義一次、到處都能用的中央化指標倉庫。
成效官方部落格數字：Minerva累計超過12,000個指標與4,000個維度，逾200個跨職能的資料生產者（Data、Product Management、Finance、Engineering等）共用同一套定義。
不能照抄的理由這篇文章發表於2021年，早於AI輔助生成查詢的時代——它證明的是「跨部門指標口徑對齊」這個治理紀律本身，不是「AI檢查KPI口徑」的直接案例，引用時不要宣稱這是AI輔助的成果。
先用一張圖抓全貌，再看逐步展開。圖看不懂沒關係，下一節會把每一步實際在做什麼、誰做，一條一條講清楚。
這張圖是整篇的骨架：輸入 → 步驟 → 困難點 → AI／Agent／Tool 介入 → 人工檢查 → 產出。紅框是最常出事的位置，綠框是不能下放的人工檢查點，粗框是中止條件。後面每一節都是在展開圖上的某一格。
| 序 | 類型／角色 | 流程步驟 | 這一步的困難點／中止條件 |
|---|---|---|---|
| 1 | Human | 各部門對同一KPI的定義文件／報表截圖／口頭說明 每份標明部門來源 | — |
| 2 | Human | 人蒐集整理成可讀文字，標明部門 | — |
| 3 | AI | AI拆解七要素：名稱／商業定義／公式／來源／時間窗／排除條件／Owner 缺項標【未提供】，不可自行補 | 困難點／風險AI自行腦補公式，補一個「業界常見算法」而非部門實際用法 |
| 4 | AI | AI逐要素比對，分四類並附原文佐證 一致／部分一致／名稱同定義不同／名稱不同疑似同一件事 | 困難點／風險把同名異義誤判成真衝突，硬要合併成同一個定義 |
| 5 | Checkpoint | 人找owner核對衝突清單，判斷同名異義或真衝突 | 困難點／風險衝突清單做完沒人裁定，下次月報又各吵各的 失敗與中止條件發現疑似資料來源本身抓錯資料表時，轉去做資料品質稽核，不併入口徑比對 |
| 6 | Human | 人針對每條真衝突裁定算法或拆分名稱 | — |
| 7 | Tool | 定稿存進共用試算表／資料字典 | — |
| 8 | Output | KPI定義對照表＋衝突清單＋裁定結果 | — |
回流線：各部門對同一KPI的定義文件／報表截圖／口頭說明 → 人蒐集整理成可讀文字，標明部門（退回）；人蒐集整理成可讀文字，標明部門 → AI拆解七要素：名稱／商業定義／公式／來源／時間窗／排除條件／Owner（退回）；AI拆解七要素：名稱／商業定義／公式／來源／時間窗／排除條件／Owner → AI逐要素比對，分四類並附原文佐證（退回）；AI逐要素比對，分四類並附原文佐證 → 人找owner核對衝突清單，判斷同名異義或真衝突（退回）；人找owner核對衝突清單，判斷同名異義或真衝突 → 人針對每條真衝突裁定算法或拆分名稱（退回）；人找owner核對衝突清單，判斷同名異義或真衝突 → 人蒐集整理成可讀文字，標明部門（文件有缺漏，退回重新蒐集）；人針對每條真衝突裁定算法或拆分名稱 → 定稿存進共用試算表／資料字典（退回）；定稿存進共用試算表／資料字典 → KPI定義對照表＋衝突清單＋裁定結果（退回）
flowchart TD
in1(["<b>Human</b><br/>各部門對同一KPI的定義文件／報表截圖／口頭說明<br/><small>每份標明部門來源</small>"])
s1["<b>Human</b><br/>人蒐集整理成可讀文字，標明部門"]
a1[/"<b>AI</b><br/>AI拆解七要素：名稱／商業定義／公式／來源／時間窗／排除條件／Owner<br/><small>缺項標【未提供】，不可自行補</small>"/]
a2[/"<b>AI</b><br/>AI逐要素比對，分四類並附原文佐證<br/><small>一致／部分一致／名稱同定義不同／名稱不同疑似同一件事</small>"/]
c1{{"<b>Checkpoint</b><br/>人找owner核對衝突清單，判斷同名異義或真衝突"}}
s2["<b>Human</b><br/>人針對每條真衝突裁定算法或拆分名稱"]
t1[("<b>Tool</b><br/>定稿存進共用試算表／資料字典")]
o1(["<b>Output</b><br/>KPI定義對照表＋衝突清單＋裁定結果"])
r1>"<b>Risk</b><br/>AI自行腦補公式，補一個「業界常見算法」而非部門實際用法"]
r2>"<b>Risk</b><br/>把同名異義誤判成真衝突，硬要合併成同一個定義"]
r3>"<b>Risk</b><br/>衝突清單做完沒人裁定，下次月報又各吵各的"]
st1[/"<b>Stop</b><br/>發現疑似資料來源本身抓錯資料表時，轉去做資料品質稽核，不併入口徑比對"\]
in1 --> s1
s1 --> a1
a1 --> a2
a2 --> c1
c1 --> s2
s2 --> t1
t1 --> o1
a1 -.->|風險| r1
a2 -.->|風險| r2
c1 -.->|風險| r3
c1 ==>|中止| st1
in1 -.->|退回| s1
s1 -.->|退回| a1
a1 -.->|退回| a2
a2 -.->|退回| c1
c1 -.->|退回| s2
c1 -.->|文件有缺漏，退回重新蒐集| s1
s2 -.->|退回| t1
t1 -.->|退回| o1
classDef clsIn fill:#FFFFFF,stroke:#2C4459,stroke-width:2px,color:#141E2B
classDef clsHuman fill:#FBFCFD,stroke:#7A8CA0,stroke-width:2px,color:#141E2B
classDef clsAI fill:#FFF6EA,stroke:#DE9A45,stroke-width:2px,color:#141E2B
classDef clsAgent fill:#FDEBD2,stroke:#B87A2E,stroke-width:2px,color:#141E2B
classDef clsTool fill:#EDF2F6,stroke:#2C4459,stroke-width:2px,color:#141E2B
classDef clsCheck fill:#E8F2EC,stroke:#3F7A5A,stroke-width:2px,color:#123024
classDef clsOut fill:#141E2B,stroke:#141E2B,stroke-width:2px,color:#F2F6F9
classDef clsRisk fill:#FCEFEA,stroke:#C0552F,stroke-width:2px,color:#5E2110
classDef clsStop fill:#F7E1DB,stroke:#8E2F17,stroke-width:3px,color:#5E2110
class in1 clsIn;
class s1 clsHuman;
class a1 clsAI;
class a2 clsAI;
class c1 clsCheck;
class s2 clsHuman;
class t1 clsTool;
class o1 clsOut;
class r1 clsRisk;
class r2 clsRisk;
class r3 clsRisk;
class st1 clsStop;| 序 | 誰做 | 步驟與說明 |
|---|---|---|
| 1 | Human | 蒐集定義文件 跟各部門要這個KPI的定義文件、報表截圖或至少一段口頭說明，標明部門來源。→ 已標記部門的定義文件集 |
| 2 | AI | 拆解七要素 把每份文件拆成指標名稱、商業定義、計算公式、資料來源、時間窗、排除條件、Owner七項，缺哪一項就標【未提供】，不要幫忙補。→ 各部門的七要素拆解表 |
| 3 | AI | 逐要素比對 比對所有部門的七要素版本，標出完全一致、部分一致（哪幾項不同）、名稱相同定義不同、名稱不同但疑似同一件事四種情況，每條附原文佐證。→ KPI定義對照表與衝突清單草稿 |
| 4 | Human | 找owner核對 拿著衝突清單去問對應的owner，確認是不是真的衝突，還是本來就是兩個不同的東西。→ 已核對的衝突清單 |
| 5 | Human | 裁定算法 針對每條真衝突，決定採用哪一種算法為公司標準，或乾脆拆成兩個不同名稱的指標各自定義。→ 裁定結果 |
| 6 | Human | 定稿並公告 把裁定結果寫進KPI定義對照表定稿，公告給所有用到這個指標的人，並標明版本與日期。→ KPI定義對照表定稿 |
| 7 | Human | 確認報表更新 列出所有引用這個指標的報表／dashboard，逐一確認已改用新口徑，不是只改了文件沒改報表。→ 已更新報表清單 |
這一區是真的動手：先備料、再貼指令、然後對照產出應該長什麼樣。手上是哪一支 AI 都做得完，差別寫在最後的工具那一節。
各部門對同一KPI的定義文件（含七要素，或至少原始說明文字）＋ 既有的資料字典或治理規範（如有）。
【行銷部】KPI：月活躍用戶。定義：過去30天內開啟過App的不重複使用者。公式：distinct device_id。資料來源：GA4事件記錄。時間窗：rolling 30天。排除條件：排除內部測試帳號。Owner：行銷部數據分析師。 【產品部】KPI：活躍用戶。定義：過去30天內完成至少一次核心動作（瀏覽商品／加入購物車／下單）的使用者。公式：distinct user_id where event_type in (...)。資料來源：後端事件Log。時間窗：30天。排除條件：（未提供）。Owner：產品部PM。 【財務部】KPI：活躍會員。定義：過去30天內至少一筆訂單的會員。公式：distinct member_id from orders。資料來源：ERP訂單系統。時間窗：自然月。排除條件：排除全額退款訂單。Owner：財務部。
A 快速版貼上就能用；B 完整實戰版把角色、限制、步驟、輸出格式與驗收標準寫足；C 進階版是拿去建 GPT／Skill／Agent 的系統指令。三種都附可替換變數、使用範例、預期輸出與人工確認點。
手上有兩三個部門對同一個KPI的定義文件或報表截圖，想先拿到一份拆解與初步比對結果。
以下是各部門對「{KPI名稱}」這個指標各自的定義文件（或報表輸出、口頭說明）。請幫我拆解並比對：
1. 針對每份文件，各自列出七個要素：指標名稱、商業定義（在說明什麼）、計算公式、資料來源（系統／資料表）、時間窗、排除條件、負責Owner。缺哪一項就標【未提供】，不要幫我補。
2. 逐要素比對所有部門的版本，標出：完全一致／部分一致（哪幾項不同）／名稱相同但定義不同／名稱不同但疑似同一件事。
3. 產出一份「KPI定義對照表」與一份「衝突清單」，衝突清單每一條都要附上是哪個部門的哪一句話造成的分歧。
4. 不要替我判斷哪個部門的算法才是對的，那是我們要開會裁定的事。
各部門定義文件：{貼上}| 變數 | 要換成什麼 |
|---|---|
{KPI名稱} | 要比對的指標名稱，例如「月活躍用戶」「轉換率」。 |
{貼上} | 各部門對這個指標的定義文件、報表截圖文字或口頭說明，逐份貼上並標明部門。 |
以下是各部門對「月活躍用戶」這個指標各自的定義文件，請幫我拆解並比對。（照母提示詞規則） 【行銷部】 定義：過去30天內開啟過App的不重複使用者。 公式：distinct device_id 資料來源：GA4事件記錄 時間窗：rolling 30天 排除條件：排除內部測試帳號 Owner：行銷部數據分析師 【產品部】 定義：過去30天內完成至少一次「核心動作」（瀏覽商品／加入購物車／下單，符合其中一項即算）的使用者。 公式：distinct user_id where event_type in (view_item, add_to_cart, checkout) 資料來源：後端事件Log（自建） 時間窗：30天（未寫明是否為rolling） 排除條件：未提及 Owner：產品部PM 【財務部】 名稱：活躍會員（月報上常被拿來跟「月活躍用戶」放在同一張表比較） 定義：過去30天內至少一筆訂單的會員 公式：distinct member_id from orders 資料來源：ERP訂單系統 時間窗：自然月（非rolling 30天） 排除條件：排除全額退款訂單 Owner：財務部
【七要素拆解表】 ｜要素｜行銷部｜產品部｜財務部｜ ｜指標名稱｜月活躍用戶(MAU)｜活躍用戶｜活躍會員｜ ｜商業定義｜30天內開啟過App的人｜30天內完成至少一次核心動作的人｜30天內有下單的會員｜ ｜公式｜distinct device_id｜distinct user_id (view/cart/checkout其一)｜distinct member_id from orders｜ ｜資料來源｜GA4事件記錄｜後端事件Log(自建)｜ERP訂單系統｜ ｜時間窗｜rolling 30天｜30天（【未提供】是否rolling）｜自然月（非rolling）｜ ｜排除條件｜排除內部測試帳號｜【未提供】｜排除全額退款訂單｜ ｜Owner｜行銷部數據分析師｜產品部PM｜財務部｜ 【比對結果】 一、名稱相同、定義不同——真衝突 行銷部與產品部都在報「活躍用戶」，但行銷算的是「打開過App」，產品算的是「做過至少一個核心動作」。同一個名字底下是兩件不同的事，數字自然對不上。 二、時間窗寫法不一致，無法確認是否可比 行銷部明確是rolling 30天，產品部的定義只寫「30天」，沒說是不是rolling——這一項標【未提供】，需要回頭問產品部PM才能判斷這兩個30天是不是同一種算法。 三、名稱不同，疑似同一件事但資料來源完全不同 財務部的「活躍會員」常被放進同一張月報表跟「月活躍用戶」並列比較，但財務部算的是ERP裡有下單的會員，跟前兩者的行為型活躍完全是兩件事——建議在報表上明確拆開，不要放同一欄。 四、排除條件缺口 產品部的定義沒有寫排除條件，不確定測試帳號有沒有被算進去。這一項若不確認，產品部的數字可能偏高。 【KPI衝突清單】 1.〔真衝突〕「活躍用戶」名稱相同，行銷部＝開啟App、產品部＝完成核心動作。佐證：行銷部「開啟過App的不重複使用者」vs 產品部「完成至少一次核心動作的使用者」。 2.〔待確認〕產品部時間窗是否為rolling 30天。佐證：產品部文件僅寫「30天」，未註明rolling。 3.〔混用風險〕財務部「活躍會員」與前兩者常被同表比較，但資料來源與定義完全不同。佐證：財務部「ERP訂單系統」「至少一筆訂單」。 4.〔缺口〕產品部未提供排除條件。佐證：產品部欄位【未提供】。 這份清單只列出分歧與佐證，哪一種算法要當公司標準、「活躍會員」要不要改名以免混淆，需要你們找對應owner開會裁定。
沒有額外的，看上面「三種版本共通的紅線」那一段就好。
定義文件裡沒寫清楚時間窗或排除條件是最常見的缺口，這種缺口要標【未提供】回頭問owner，不能讓AI用常見算法幫你補，那樣比對結果就失去意義。
沒有額外的，看上面「三種版本共通的紅線」那一段就好。
拆解表跟初步比對有了，要正式產出KPI定義對照表與衝突清單，並讓每條衝突都能回頭核對佐證，還要往前追業務原因。
以下是{部門數量}個部門對「{KPI名稱}」這個指標的定義文件（含拆解後的七要素，如果還沒拆解就直接貼原始文件）。請做正式的KPI口徑比對：
1.【七要素比對表】用表格列出每個部門在指標名稱、商業定義、計算公式、資料來源、時間窗、排除條件、Owner七項各自怎麼寫。缺哪一項就標【未提供】，不要幫忙補。
2.【分類】把所有指標對，分成四類並各自列出：（a）完全一致（b）部分一致，並具體指出哪幾項不同（c）名稱相同、定義不同——真衝突（d）名稱不同，但疑似指向同一件事，需要人判斷是不是同名異義。
3.【衝突清單】每一條衝突都要附上是哪個部門的哪一句話造成的分歧，格式：〔分類〕衝突描述。佐證：部門A「原文」vs 部門B「原文」。
4.【追根究底】針對每條真衝突，推測可能的業務原因（例如財務要月結所以用自然月、產品要看短期趨勢所以用rolling），並註明這是推測，需要人跟對應部門確認。
5.【不要做的事】不要替我判斷哪個部門的算法才是公司標準，那是我們要開會裁定的事；不要把「名稱不同疑似同一件事」直接判定為衝突，那需要人確認業務語意是否真的相同。
各部門定義文件：{貼上}| 變數 | 要換成什麼 |
|---|---|
{部門數量} | 參與比對的部門數量。 |
{KPI名稱} | 要比對的指標名稱。 |
{貼上} | 各部門的定義文件或前一步的七要素拆解表，逐份貼上並標明部門。 |
（貼上三個部門「月活躍用戶／活躍用戶／活躍會員」的完整定義文件，部門數量填3、KPI名稱填「活躍用戶／活躍會員」）
【七要素比對表】 （同前步驟，略） 【分類】 (a) 完全一致：無。 (b) 部分一致：行銷部與產品部的時間窗都寫「30天」，但rolling與否不確定是否一致。 (c) 真衝突：行銷部「開啟App」vs 產品部「完成核心動作」，同名不同定義。 (d) 疑似同一件事需人判斷：財務部「活躍會員」與前兩者的「活躍用戶」，需要業務端確認這三個是不是同一個概念的三種切法，還是本來就該是三個獨立指標。 【衝突清單】 1.〔真衝突〕行銷部與產品部的「活躍用戶」定義不同。佐證：行銷部「過去30天內開啟過App的不重複使用者」vs 產品部「過去30天內完成至少一次核心動作的使用者」。 2.〔待確認〕產品部時間窗是否為rolling。佐證：產品部僅寫「30天」，未註明。 3.〔需人判斷〕財務部「活躍會員」是否與MAU同屬一個概念體系。佐證：財務部「過去30天內至少一筆訂單的會員」，資料來源為ERP，跟前兩者的行為型定義完全不同。 【追根究底（推測，待人確認）】 - 行銷部用rolling 30天：常見於行銷需要即時看成效，滾動視窗能反映近期趨勢，推測與行銷活動的檢視頻率有關。 - 財務部用自然月非rolling：常見於財務需要跟月結、月報對齊，推測是配合會計月結週期，不是隨意選的。 - 產品部核心動作定義較寬（瀏覽即算）：推測是產品端希望及早看到用戶engagement的訊號，不想等到下單才算活躍。 以上三點都是推測，實際原因要跟對應部門確認後才能寫進正式的KPI定義對照表備註欄。 【提醒】 財務部的「活躍會員」建議不要跟MAU放在同一張比較表，除非業務端確認這兩者本來就該是同一個概念的兩種算法——目前看起來比較像是兩個不同維度（行為活躍 vs 交易活躍），硬要比反而製造混淆。
沒有額外的，看上面「三種版本共通的紅線」那一段就好。
如果只給AI兩個部門的定義，比對出來的『疑似同一件事』類別容易漏掉——像財務部的活躍會員這種第三方視角，通常要三個以上部門的資料放在一起才會被注意到。盡量一次把所有相關部門的定義都收齊再比對。
沒有額外的，看上面「三種版本共通的紅線」那一段就好。
KPI定義對照表定稿了，要讓之後新增或修改的指標定義都自動先比對一次現有口徑表，而不是等到又對不上才發現。
請把以下定稿的KPI定義對照表，寫成一份可以直接用來建立常駐口徑比對助手的系統指令。
【系統指令要包含】
1. 角色與任務：只做口徑比對，不判斷哪個算法才是對的，也不修改任何一方的原始文件內容。
2. 現有的KPI定義對照表全文（照我提供的，不得增刪）。
3. 比對流程：使用者貼進新的指標定義或報表截圖時，先判斷這個指標名稱是否已存在於現有表裡；存在就逐要素比對，找出跟現有定稿不一致的地方；不存在就先確認是不是既有指標的同義詞（用商業定義而非名稱去判斷），再決定要新增還是合併。
4. 缺項處理：任何一項（名稱／商業定義／公式／資料來源／時間窗／排除條件／Owner）沒寫清楚就標【未提供】，不得依常見業界算法自行補上。
5. 輸出格式：一致性結論（一致／不一致，列出哪幾項不同）＋ 是否為新指標的判斷與理由 ＋ 需要人確認的地方。
6. 硬限制——以下情況一律停下來回報，不自行判斷：
- 新定義與現有定稿的差異涉及計算邏輯的實質改變（不只是措辭不同）
- 無法判斷是同一指標的新版本，還是應該視為獨立的新指標
- 使用者要求『直接用新的取代舊的』——取代與否是治理決策，不是這個助手能做的事
【另外請給我】
(a) 一份「使用說明」，寫給第一次用的同事看，含兩個好例子與兩個壞例子。
(b) 一份「維護說明」：KPI定義對照表要更新時該改哪裡、多久回頭盤點一次、誰是最終裁定人。
KPI定義對照表定稿：{貼上}| 變數 | 要換成什麼 |
|---|---|
{貼上} | 已裁定完成、正式定稿的KPI定義對照表全文。 |
（貼上定稿的KPI定義對照表：MAU沿用行銷部rolling 30天開啟App算法為公司標準，產品部改名為「參與活躍用戶(EAU)」獨立追蹤，財務部維持「活躍會員」但正式改名避免與MAU混用）
【常駐口徑比對助手 系統指令】 一、你的角色 你是本公司的KPI口徑比對助手。你只做口徑一致性比對，不判斷哪個算法才是公司標準，也不修改任何一方提供的原始定義。 二、現有的KPI定義對照表 （照錄定稿全文：MAU／EAU／活躍會員三項的七要素） 三、比對流程 1. 使用者貼進新的指標定義時，先比對指標名稱是否已存在於現有表。 2. 名稱已存在：逐要素比對，列出跟定稿不一致的地方，並標明是「措辭不同但邏輯相同」還是「實質計算邏輯不同」。 3. 名稱不存在：先用商業定義（不是名稱）去判斷是否為既有指標的同義詞。判斷不出來時，先問使用者，不要自行假設。 四、缺項處理 七要素任何一項沒寫清楚，一律標【未提供】，不得依常見業界算法自行補齊。 五、一律停下來回報、不自行判斷的情況 1. 新定義與定稿的差異涉及計算邏輯實質改變（例如把rolling 30天改成自然月）。 2. 無法判斷是既有指標的新版本，還是應該視為獨立的新指標。 3. 使用者要求『直接用新的取代舊的』——這是治理決策，一律回報請使用者找裁定人處理。 六、輸出格式 【一致性結論】一致 / 不一致（列出哪幾項不同） 【是否為新指標】是/否，理由 【需要你確認的地方】沒有就寫「無」 ────────── 【使用說明（給第一次用的同事）】 這個助手做什麼：新的指標定義丟進來，先幫你查有沒有跟現有的KPI定義對照表打架。 這個助手不做什麼：幫你決定新算法該不該取代舊的、幫你寫新指標的商業意義。 好例子： 1. 貼上一份新的「客單價」定義草稿，問「這個跟現有表裡的東西有沒有衝突」。 2. 貼上財務部新報表裡出現的「留存率」定義，問「這是不是我們EAU的另一種算法」。 壞例子： 1.「幫我把這個新算法直接更新進定案表」——取代與否要走裁定流程，這個助手只負責比對不負責更新。 2.「這兩個名字很像，你幫我決定要不要合併」——業務語意是否相同要人判斷，助手只能提示疑似同一件事。 【維護說明】 - KPI定義對照表更新時，先走裁定流程定稿，再回來更新助手的第二節內容。 - 每季盤點一次：抽查近期新增的報表或dashboard，看有沒有繞過助手直接產出未比對過的口徑。 - 最終裁定人：〔填寫〕。更新後在共用位置註明版本與日期。
沒有額外的，看上面「三種版本共通的紅線」那一段就好。
如果沒有先把KPI定義對照表定稿放進系統指令，這個助手比對的基準就是空的，等於每次都要重新從頭比對，失去『常駐』的意義。
沒有額外的，看上面「三種版本共通的紅線」那一段就好。
兩份產出：KPI定義對照表（各部門七要素並列）與衝突清單（分類＋佐證＋待確認事項）。
【沒有要求附佐證】 AI產出（節錄）： 「三個部門對『活躍用戶』的定義大致相近，主要差異在於統計口徑略有不同，建議後續統一採用行業慣用的『月活躍用戶』標準定義，即過去30天內有登入行為的不重複使用者。」 → 讀起來很像結論，問題是： → 「大致相近」掩蓋了行銷部與產品部其實是兩種完全不同的行為定義（開啟App vs 完成核心動作）。 → 「行業慣用的標準定義」是AI自己補的通用說法，不是這三個部門任何一份文件裡寫的東西，也沒人裁定要採用它。 → 財務部的「活躍會員」直接被忽略，因為它跟另外兩個「不太像」，但這正是最該被單獨拉出來討論的一項。 【強制每條附原文佐證】 AI產出（節錄）： 「1.〔真衝突〕行銷部『過去30天內開啟過App的不重複使用者』vs 產品部『過去30天內完成至少一次核心動作的使用者』——兩者名稱相同，但定義的行為完全不同。 2.〔需人判斷〕財務部『過去30天內至少一筆訂單的會員』，資料來源為ERP訂單系統，跟前兩者的GA4／事件Log完全不同體系，建議先確認業務端是否真的把這三者視為同一概念。」 → 每一條都指出是哪份文件的哪句話造成分歧，回頭找owner核對時不用再重新翻文件。 → 沒有直接建議『統一採用某個標準定義』，因為那是裁定人要做的事，AI只負責把分歧攤開來。 → 財務部這一項被單獨標出來，而不是因為『看起來不太像』就被略過。 【差別在哪】 第一種在幫你下結論，第二種在幫你把材料準備齊全讓你自己下結論。KPI口徑這種事，結論被誰下、根據什麼下，比結論本身更重要。
【KPI定義對照表】 ｜要素｜行銷部｜產品部｜財務部｜ ｜指標名稱｜月活躍用戶(MAU)｜活躍用戶｜活躍會員｜ ｜商業定義｜30天內開啟過App的人｜30天內完成至少一次核心動作的人｜30天內有下單的會員｜ ｜公式｜distinct device_id｜distinct user_id(核心動作其一)｜distinct member_id from orders｜ ｜資料來源｜GA4事件記錄｜後端事件Log｜ERP訂單系統｜ ｜時間窗｜rolling 30天｜30天（未提供是否rolling）｜自然月｜ ｜排除條件｜排除測試帳號｜未提供｜排除全額退款訂單｜ ｜Owner｜行銷部數據分析師｜產品部PM｜財務部｜ 【衝突清單】 1.〔真衝突〕行銷部與產品部「活躍用戶」定義不同：開啟App vs 完成核心動作。佐證：兩部門原文定義。 2.〔待確認〕產品部時間窗是否為rolling。佐證：僅寫「30天」未註明。 3.〔需人判斷〕財務部「活躍會員」與前兩者常被同表比較，但資料來源與定義完全不同，是否該視為同一體系需業務端確認。 4.〔缺口〕產品部未提供排除條件。
這幾支都做得到——差別在你手上有哪一支、資料能不能外流。標「起手」的是不知道從哪支開始時的建議，不是限定。
| 工具 | 什麼時候用 | 為什麼 | 注意 |
|---|---|---|---|
| Claude ↗起手 一次讀完多份報表定義文件 | 部門多、定義文件量大，要一次讀完所有部門的定義稿 | 長輸入穩定，適合一次貼進所有部門的定義文件逐一拆解比對，不會中途遺漏某個部門。 | 文件沒寫清楚的地方仍要標【未提供】回頭問人，不能讓AI自己猜公式。 |
| ChatGPT ↗ 部門少、文件短時快速跑一輪比對 | 部門少、定義文件短，想快速跑一輪初步比對 | 拆解與比對速度快，適合先抓出明顯的名稱相同定義不同的衝突。 | 同樣要求每條衝突附文件出處，不然回頭沒辦法核對是誰說的。 |
| 試算表 定稿後長期維護KPI定義對照表 | KPI定義對照表定稿後要長期維護 | 把定案表做成共用試算表，各部門認領各自欄位，之後改版有紀錄可查。 | 試算表只是存放的地方，實際計算公式仍要以各部門系統為準，不要只信手動填的欄位內容。 |
這一區是踩過的坑與該守的線。標「不下放」的步驟請不要交給 AI 決定；Checklist 是拿來驗收的，不是拿來勾好看的。
AI會依常見業界算法猜一個公式，那不是這個部門實際使用的，比對結果會失真。
怎麼修缺項一律標【未提供】，回頭問對應部門，不要讓AI補。
名稱一樣但業務意圖完全不同（例如活躍用戶vs活躍會員），勉強合併成一個定義只會製造新的混亂。
怎麼修先判斷是不是同一件事，不是的話拆成兩個不同名稱各自定義。
光說A用7天、B用30天不夠，沒人知道該聽誰的，開會時容易變成互相指責。
怎麼修請AI在衝突清單附上各自的原文出處與推測的業務原因，開會時直接對著文件討論。
列出來但沒人拍板，下次月報又是各吵各的，比對等於白做。
怎麼修裁定完要有正式定稿與公告日期，不是留在會議紀錄裡。
口徑表定了，但各部門的BI dashboard、SQL、Excel公式沒有真的改，數字還是照舊。
怎麼修定稿後列出所有用到這個指標的報表清單，逐一確認是否已更新。
如果某部門根本抓錯資料表，那是資料品質問題，不是口徑分歧，混在一起查會查不完。
怎麼修先確認各部門的資料來源本身沒有問題，再進入口徑比對。
| 流程位置 | 誰 | 做什麼／怎麼做 |
|---|---|---|
| 拆解階段 | AI | 把每份定義文件拆成七要素 逐項填入標準格式，缺哪一項就標【未提供】，不可以用一般業界常見算法幫忙補。 |
| 比對階段 | AI | 逐要素比對各部門版本 分四類列出：完全一致／部分一致（列出哪幾項不同）／名稱相同定義不同／名稱不同但疑似同一件事。 |
| 產出階段 | AI | 生成KPI定義對照表與衝突清單 每條衝突附上各部門原文出處，方便人回頭核對，不主動下結論說哪個部門算得對。 |
| 使用階段 | Agent | 做成常駐的口徑比對助手 之後新報表或新定義文件丟進來，自動比對現有的KPI定義對照表，及早抓到新的分歧，而不是等到月報才發現。 |
看看別人實際做過的樣子，再決定下一步往哪走。沒有找到可查證案例的方法，這裡會直說沒有，不拿相似的案例充數。
三個部門都沒算錯，只是沒人把三份定義攤開來比過
當時的狀況：一家中小型電商的行銷、產品、財務三個部門，月報上都各自報「活躍用戶／活躍會員」的數字。某次董事會報告時，行銷說本月活躍用戶成長，產品的報表卻顯示下滑，兩份數字擺在同一張投影片上，被董事會當場質疑是不是有人算錯。
結果：董事會報告不再出現同名指標打架的狀況，因為MAU、EAU、活躍會員已經是三個各自獨立、有清楚定義的指標，不會再被放進同一欄比較。三個部門的owner也第一次看到彼此的完整算法，發現產品部原本連排除條件都沒定義——這個缺口在比對之前沒人注意到。
待補資料：本站不提供這次改名與裁定之後，三部門下一次月報數字是否真的完全對齊的量化驗證數據。建議做法：定稿後的下一次月報週期，請三個部門各自依新口徑產出數字，由沒有參與這次比對的人核對三份報表是否還有名稱或定義混用的情況，作為驗收依據。
口徑統一之後，下一步是把它變成dashboard或報表的正式資料規格，讓開發或BI工具照著做。
口徑對齊只是起點，數字本身還會有突然暴增暴跌等異常，需要另外的機制盯著。
KPI定義對照表之後會被複製、修改，要定期跟最新版比對有沒有偷偷改了口徑。
KPI定義對照表要跟其他治理文件放在同一個找得到的地方，不是躺在某次會議紀錄裡。
這個方法的模板與 Checklist 下載包整理中——訂閱更新，上架後第一時間通知你。
之後會不定期整理：新方法、指令包（Prompt Pack）、Checklist 與模板。免費、無廣告；送出後會收到一封確認信，點了連結才算訂閱成功，之後每封信都附一鍵退訂。
送出即表示你同意本站的 隱私權說明：我們只儲存 Email 與同意版本，不會把 Email 和你的閱讀紀錄綁在一起。沒有點確認信就不會收到任何內容，之後也隨時可以一鍵退訂。
免責聲明：本站內容為個人實作筆記與工具，僅供參考，不構成法律、財務、稅務、醫療或任何專業意見。照方法操作所得的 AI 產出可能有錯誤或過時，請務必自行查證後再使用；因採用本站內容所生之任何結果，作者不負擔責任。
工具與商標：站內免費工具以「現狀」提供，不保證持續可用或無錯誤。ChatGPT、Claude、Copilot、Gemini 等名稱與商標均歸各該權利人所有；本站與各該公司無隸屬或合作關係，外部連結內容不代表本站立場。
著作權：© 2026 Ridgeline · by Lucas。站內文章、指令與工具開放免費使用與學習，但保留所有權利（非開源授權），未經同意請勿重製、散布或作商業用途。