業務需求轉數據規格：指標沒定義前，不要急著寫 SQL

01解決的工作問題

業務主管提出「我要看活躍度」「我要看流失」「我要看轉換率」這類需求時，聽起來像一句話就講完的任務，其實藏著至少八個沒講出口的假設：指標怎麼定義、分子是什麼、分母是什麼、用哪一種時間基準、對象範圍是誰、要排除哪些帳號、資料從哪張表來、多久更新一次。這些假設不同人腦中的答案往往不一樣——主管以為的「活躍」是有付費行為，分析師以為是有登入紀錄，兩邊都合理，但兜出來的數字會差很多。AI 最容易犯的錯，是看到「活躍度」三個字就自己選一種常見定義，直接生出一段語法正確、看起來很專業的 SQL。這段 SQL 能跑、有結果、圖表也畫得出來，但那是 AI 幫你決定的定義，不是主管真正想看的那個數字。等到報表上線、主管拿著數字去做決策，才發現「活躍」的算法跟他心裡想的不一樣，這時候要回頭改的不只是 SQL，還有已經根據錯誤數字做出的判斷。這個方法要處理的，就是在 AI動手寫 SQL之前，先把八個關鍵條件問清楚、寫下來、讓業務主管拍板，讓「怎麼算」這件事有一份大家都認的規格書可查，而不是活在某一個人的腦子裡或某一段 SQL 的邏輯裡。

02什麼時候用、什麼時候別用

什麼情況下該用這一套

• {'t': '業務主管的需求用詞是名詞而非定義', 'd': '「活躍度」「流失」「轉換率」這種詞本身不是定義，是需要拆解的入口。'}
• {'t': '這份數字之後要拿去做決策或對外報告', 'd': '口徑一旦錯了，後面根據這個數字做的判斷都要重新檢視，越早釐清成本越低。'}
• {'t': '有唯讀權限可以查資料庫的欄位與型態', 'd': '規格書裡寫的資料來源要能實際核對，不能只憑欄位名稱猜。'}
• {'t': '多個報表或多個人會用到同一個指標', 'd': '只要有第二個人或第二張報表引用同一個詞，口徑不一致的風險就存在，值得先寫規格書。'}

什麼情況下別用

已經有明確口徑文件的既有指標

公司已經定義過、大家都在用的指標不需要重新走一次，除非要新增排除條件或改時間基準。

純粹的探索性資料查看

分析師自己想先摸一下資料長什麼樣，不涉及要交付的正式指標，不需要走完整規格書流程，直接用唯讀查詢看看即可。

業務主管明確要求「先給我一個粗略版本就好」

如果主管已經知情並接受粗略版本可能不準，這是主管的決定，但要在交付時明確標註「未定稿口徑」，不能悄悄升級成正式數字。

指標定義涉及法規或財務認列標準

營收認列、法定合規指標等有既定會計或法規標準時，定義權不在業務主管，要先確認是否有法遵或財務規範要遵守。

誰會用到

數據分析

你是最常被要求「先給我看一下數字」的人，也最容易在還沒問清楚之前就先跑一版出來交差。先跑的那一版會變成事實上的定義，之後很難改。

PM

你常常是業務主管與分析師之間的翻譯，待確認清單就是你最好用的翻譯工具——拿著八個問題去跟主管對，比自己猜一個版本回去問「這樣對嗎」有效率。

主管

你要做的不是自己去定義指標，而是在拍板那一步真的把每一項看過、確認過。含糊帶過「差不多這樣」是這個方法最容易失敗的地方。

所屬工作情境

04完整步驟圖的文字版，逐步展開

一句話版（快速回顧）

1. 先把主管的原話記下來，不要自己詮釋成「活躍度就是 DAU」這種結論。
2. 請 AI 依原話整理出「待確認清單」：指標定義、分子、分母、時間基準、對象、排除條件、資料來源、更新頻率的候選選項，明確標示這只是選項不是決定，此步驟不准產出 SQL。
3. 拿著待確認清單回去跟主管與相關人逐項核對拍板，寫成正式定義。
4. 核對候選的資料來源在實際資料庫裡是否存在、型態是否相符，型態或欄位對不上要退回重新定義。
5. 所有條件都確認後，才請 AI 生成正式的 Data Requirement Spec 與對應的 SQL 草稿，SQL 每個條件都要能對回規格書的某一條。
6. 由主管與資料負責人共同簽核規格書定稿與 SQL 邏輯，才能上線變成正式報表。

完整版（每一步誰做、產出什麼）

05開始前要準備什麼標「必要」的沒備齊就先別開始

業務主管的原話必要

一字不改記下來，不要自己先翻譯成「他應該是要 DAU」，翻譯這件事該由待確認清單完成，不是由你腦補完成。

資料庫或資料表的唯讀存取權限必要

沒有辦法查欄位是否存在、型態是否相符，規格書就只能停在「假設」層級。

既有相關報表或指標的清單（如果有）可選

避免同一件事又定義出第二種口徑，先看看公司裡有沒有已經在用的類似指標。

可以核對的關鍵人清單必要

業務主管本人、可能還有財務或營運部門，指標若跨部門使用要一起拍板，不能只問發起需求的那個人。

存放規格書與版本紀錄的位置必要

共用試算表或知識庫，決定好位置規格書才有機會被後續的人找到、沿用、更新。

餵進去的東西要長這樣

業務主管的模糊需求原話 ＋ 逐項核對拍板後的八項定義 ＋ 資料庫欄位唯讀核對結果。

• 原話要一字不改記錄，不要先自行翻譯成技術定義。
• 八項定義要全部核對過才能往下一步，缺一項就停在待確認清單階段。
• 資料來源要附唯讀查詢核對結果，包含表名、欄位名、型態、時區。
• 跨部門會用到的指標，八項定義要讓相關部門一起確認，不能只問需求提出人。
• 涉及財務認列或法規標準的指標，先確認是否有既定規範要遵守，不能由業務主管單方面拍板。

【原話】「我想在下週的會議上看到我們 App 的使用者活躍度，最近好像掉了，我想知道是不是真的在流失。」

【已拍板八項定義】
1. 指標定義：活躍＝當日完成至少一次核心操作（上課、下單、發文）。
2. 分子：event_log 中 action_type='core_action' 的不重複 user_id。
3. 分母：（暫無，本次為絕對人數指標）。
4. 時間基準：自然日，UTC+8。
5. 對象：全部註冊使用者。
6. 排除條件：account_type IN ('test','internal')；deleted_at 不為 NULL 的帳號。
7. 資料來源：event_log 表、users 表。
8. 更新頻率：每日凌晨 2 點跑前一天資料。

【唯讀核對結果】
event_log 表：user_id (varchar)、action_type (varchar)、created_at (timestamp, UTC) —— 已確認存在。
users 表：account_type (varchar)、deleted_at (timestamp, nullable) —— 已確認存在。

06Prompt（快速／完整／進階）

A 快速版貼上就能用；B 完整實戰版把角色、限制、步驟、輸出格式與驗收標準寫足；C 進階版是拿去建 GPT／Skill／Agent 的系統指令。三種都附可替換變數、使用範例、預期輸出與人工確認點。

我是{職稱}，主管提出以下模糊的數據需求：「{原話}」。我還不知道正確的指標定義、分子分母、時間基準、對象、排除條件、資料來源與更新頻率。請不要現在就寫 SQL 或假設一套定義，先幫我列出一份「待確認清單」：
1. 這個詞在業務上可能對應哪幾種常見定義？逐一列出，每個定義要說明分子與分母各是什麼。
2. 每種定義各自需要哪些時間基準的選項（例如自然日、滾動 7 天、當月）？
3. 「對象」有哪些可能範圍（例如全部使用者／付費使用者／特定產品線）？
4. 有哪些常見的排除條件應該考慮（測試帳號、內部帳號、已刪除或停用帳號等）？
5. 這個指標通常會從哪幾種資料來源取得（登入紀錄、行為事件、訂單紀錄等），各有什麼限制？
6. 建議的更新頻率是什麼，為什麼？
請用清單列出所有候選項，每項候選都要標明「待確認」，不要幫我下結論、不要輸出任何 SQL。

我是資料分析師，主管提出以下模糊的數據需求：「我想在下週的會議上看到我們 App 的使用者活躍度，最近好像掉了，我想知道是不是真的在流失。」我還不知道正確的指標定義、分子分母、時間基準、對象、排除條件、資料來源與更新頻率。請不要現在就寫 SQL 或假設一套定義，先幫我列出一份待確認清單。（照母提示詞六條）

【待確認清單】

一、指標定義候選
(A) 活躍 = 當日有登入。
(B) 活躍 = 當日有登入「且」完成至少一次核心操作（例如上課、下單、發文，依產品而定）。
(C) 活躍 = 當日有任何被記錄的行為事件（含被動的頁面瀏覽）。
【待確認：主管想看的「活躍」比較接近哪一種？如果是想知道「流失」，通常對應到 B 或 C，因為單純登入不代表真的在用。】

二、分子與分母
若選 DAU/MAU 這種比率型指標：
分子候選：符合上面活躍定義的不重複使用者數。
分母候選：(a) 當月累計註冊使用者數 (b) 當月曾登入過至少一次的使用者數。
【待確認：分母要不要排除「從沒登入過」的帳號？兩種算出來的比率差異可能很大。】

三、時間基準候選
(A) 自然日（每天 00:00–23:59，依哪個時區？）
(B) 過去 7 天滾動平均
(C) 當月累計
【待確認：「最近好像掉了」是跟上週比、上月比、還是跟去年同期比？】

四、對象範圍候選
(A) 全部註冊使用者 (B) 付費使用者 (C) 特定產品線或特定地區使用者
【待確認：如果只有付費使用者在流失，跟全體使用者流失，處理方式完全不同。】

五、排除條件候選
測試帳號、內部員工帳號、客服測試帳號、已申請刪除但尚未清除的帳號。
【待確認：目前系統裡這些帳號有沒有一個明確的標記欄位可以排除？】

六、資料來源候選
(A) 登入紀錄表 (B) 行為事件記錄表（event log）(C) 訂單或交易表
【待確認：這幾張表各自的記錄範圍與更新時間可能不同，需要實際查過才能確認能不能用。】

七、更新頻率候選
(A) 每日一次（隔日更新前一天資料）(B) 每小時 (C) 即時
【待確認：下週會議要看的是「到會議前一天」的資料，每日更新應該就夠，除非有即時監控的需求。】

八、下一步
以上八項全部標【待確認】，尚未產出任何 SQL 或查詢語法。建議帶著這份清單去跟主管當面核對，特別是第一項（活躍的定義）與第三項（時間基準），這兩項對最終數字的影響最大。

以下是已經跟業務主管核對拍板的八項定義，以及資料庫實際欄位核對結果。請完成兩件事：

1.【生成 Data Requirement Spec】用固定格式輸出完整規格書，包含：指標名稱、業務背景（一段話說明為什麼要這個指標）、指標定義（文字敘述）、分子定義（含篩選條件）、分母定義（含篩選條件）、時間基準、對象範圍、排除條件清單、資料來源（含表名、欄位、確認過的型態）、更新頻率、負責人與拍板日期、已知限制或假設。
2.【生成 SQL 草稿】依規格書寫出對應的 SQL 查詢，並在每個 WHERE、JOIN、GROUP BY 子句旁用註解標明它對應規格書的哪一條。

規則：
- 規格書與 SQL 只能使用我提供的八項已拍板定義與已驗證欄位，不得自行補充或替換成其他常見算法。
- 如果我提供的資訊有任一項仍是【待確認】或欄位未經驗證，不要生成 SQL，改為列出還缺什麼、需要回去確認什麼。
- SQL 裡出現的每一個篩選條件都要能在規格書裡找到對應文字，找不到對應的條件視為你自行加入，不允許出現。

已拍板的八項定義：{貼上}｜資料庫欄位核對結果：{貼上}

（貼上已拍板的八項定義：活躍＝當日有登入且完成至少一次核心操作；分母＝當月曾登入過至少一次的使用者；時間基準＝自然日，UTC+8；對象＝全部註冊使用者但排除測試與內部帳號；排除條件＝account_type IN ('test','internal')；資料來源＝event_log 表的 action_type='core_action'；更新頻率＝每日凌晨 2 點跑前一天資料。並附上唯讀查詢核對結果：event_log 表確有 user_id、action_type、created_at 三欄，created_at 為 UTC 時間戳，account_type 欄位存在於 users 表。）

【Data Requirement Spec｜使用者日活躍度】

指標名稱：日活躍使用者數（DAU，核心操作版）
業務背景：主管觀察到近期使用量可能下滑，需要每日追蹤活躍使用者數，及早發現流失徵兆。
指標定義：當日完成至少一次核心操作（上課、下單、發文等，依 event_log 的 action_type='core_action' 判定）的不重複使用者數。
分子定義：當日 event_log 中 action_type='core_action' 的不重複 user_id 數，且該 user_id 對應的 users.account_type 不在 ('test','internal') 之列。
分母定義：（此指標為絕對人數，暫無分母；若後續要換算比率，分母定義為當月曾登入過至少一次的使用者數，需另行拍板。）
時間基準：自然日，時區 UTC+8，以 created_at 換算後的日期為準（原始時間戳為 UTC，需 +8 小時換算）。
對象範圍：全部註冊使用者。
排除條件：account_type IN ('test','internal')；已申請刪除且 deleted_at 不為 NULL 的帳號。
資料來源：event_log 表（欄位：user_id, action_type, created_at）＋ users 表（欄位：account_type, deleted_at）。已用唯讀查詢核對，兩張表欄位與型態均存在且相符。
更新頻率：每日凌晨 2 點（UTC+8）跑前一天 00:00–23:59 的資料。
負責人與拍板日期：{待填}／{待填}
已知限制或假設：event_log 的 action_type 分類目前只到產品端定義的「核心操作」，若產品後續新增其他被視為核心的動作類型，需要回頭更新本規格書，不會自動涵蓋。

【SQL 草稿】
```sql
SELECT
  DATE(CONVERT_TZ(e.created_at, '+00:00', '+08:00')) AS active_date, -- 對應「時間基準：自然日 UTC+8」
  COUNT(DISTINCT e.user_id) AS dau
FROM event_log e
JOIN users u ON u.user_id = e.user_id
WHERE e.action_type = 'core_action' -- 對應「指標定義：完成至少一次核心操作」
  AND u.account_type NOT IN ('test', 'internal') -- 對應「排除條件」
  AND u.deleted_at IS NULL -- 對應「排除條件：已刪除帳號」
  AND DATE(CONVERT_TZ(e.created_at, '+00:00', '+08:00')) = CURDATE() - INTERVAL 1 DAY
GROUP BY active_date;
```
這份草稿的每個條件都對回規格書的對應項目，沒有規格書之外自行加入的邏輯。若要換算成比率型的「活躍度」，需要先補上分母定義那一項的拍板，目前暫不產出比率版本的 SQL。

請把「業務需求轉數據規格」這套流程，寫成一份可以直接用來建立共用受理助手的系統指令。

【系統指令要包含】
1. 角色與任務：接收任何模糊的數據需求，先做需求釐清，不主動生成 SQL 或查詢語法。
2. 開場動作：無論使用者說什麼，第一步永遠是拆解出「指標定義、分子、分母、時間基準、對象、排除條件、資料來源、更新頻率」八項候選清單，逐項標【待確認】。
3. 硬性限制——以下情況一律不產出 SQL，直接回報缺什麼：
   - 八項條件中有任何一項仍標【待確認】。
   - 使用者提供的資料來源沒有附上唯讀查詢核對結果（欄位存在、型態相符）。
   - 使用者要求「先給我抓個大概」——這時要求對方明確承認這是「未定稿口徑」並在輸出上標註，而不是默默升級成正式數字。
4. 條件齊全後的動作：生成正式 Data Requirement Spec（固定格式：指標名稱、業務背景、指標定義、分子、分母、時間基準、對象範圍、排除條件、資料來源、更新頻率、負責人與日期、已知限制）＋ 對應 SQL 草稿，SQL 每個條件都要標註對應規格書條款。
5. 版本紀錄：規格書修改時要記錄修了哪一項、誰同意的、日期。

【另外請給我】
(a) 一份「使用說明」，寫給第一次用的同事看，含三個好例子與三個壞例子。
(b) 一份「維護說明」：規格書要更新時該改哪裡、誰負責核對資料來源、多久回頭檢查一次既有指標是否還適用。

（不需要額外變數，直接把上面的 body 貼給 AI 即可取得完整系統指令）

【共用受理助手 系統指令】

一、你的角色
你是本單位的數據需求受理助手。任何人丟給你模糊的數據需求（例如「我要看活躍度」「我要看流失」），你的任務是先把它拆解清楚，不是直接生成 SQL。

二、開場動作
收到需求後，第一步永遠是列出八項候選清單：指標定義、分子、分母、時間基準、對象、排除條件、資料來源、更新頻率，逐項標【待確認】，並提示使用者「請帶著這份清單去跟需求提出人核對」。

三、不產出 SQL 的情況
1. 八項條件任一項仍為【待確認】——回報「還缺哪幾項」，不生成查詢語法。
2. 資料來源沒有附唯讀查詢核對結果——回報「請先核對欄位是否存在、型態是否相符」。
3. 使用者要求「先抓個大概」——同意提供粗略版本，但輸出最上方必須標註【未定稿口徑，僅供參考，不得作為正式報表依據】。

四、條件齊全後
生成 Data Requirement Spec（固定十一欄格式）＋ SQL 草稿，SQL 每一行篩選條件旁加註解對應規格書條款編號。

五、版本紀錄
每次規格書修改，記錄【修改項目】【修改前】【修改後】【核准人】【日期】，附加在規格書最下方，不覆蓋舊版本。

──────────

【使用說明（給第一次用的同事）】
這個助手做什麼：把模糊的數據需求拆解成可以核對的具體條件，並在條件齊全後生成規格書與 SQL 草稿。
這個助手不做什麼：不會自己決定「活躍」該怎麼算，不會在條件不全時先給你一個能跑的 SQL 讓你「先用著」。

好例子：
1. 貼上「我想看轉換率，從瀏覽到下單」，讓助手先列候選清單。
2. 八項都跟需求提出人核對完，貼回來要求生成正式規格書與 SQL。
3. 資料來源有兩個候選表，先各自查過欄位再回來讓助手比較哪個更合適。

壞例子：
1.「先幫我用最常見的算法寫一版 SQL，之後再調」——這正是要避免的事，最常見的算法很可能不是主管要的那個。
2. 把候選清單裡的【待確認】自己隨便選一個就當作已核對——助手擋不住這種自欺，需要人誠實面對還沒問過的事。
3. 資料來源核對只看欄位名稱像不像，沒有真的查過型態與時區。

【維護說明】
- 系統指令的「八項候選清單」定義每季檢視一次，依公司實際常見指標更新候選選項的內容。
- 資料來源核對由熟悉資料庫結構的人負責，助手本身不能執行查詢，只能引導使用者去查。
- 既有規格書每半年抽查一次，確認資料表結構是否變動、指標定義是否仍適用。
- 負責人：〔填寫〕。更新後在共用位置註明版本與日期。

07產出應該長什麼樣拿到的東西要長這樣

Data Requirement Spec 固定十一欄格式 ＋ 對應的 SQL 草稿，SQL 每個條件都標註對應規格書條款。

完成品：同一句「我要看活躍度」，兩種處理方式的落差

【沒有先問清楚，AI 直接生成】
使用者輸入：「幫我寫一段 SQL，算出我們 App 每天的活躍使用者數。」
AI 產出（節錄）：
```sql
SELECT DATE(created_at) AS day, COUNT(DISTINCT user_id) AS dau
FROM login_log
GROUP BY day;
```
附帶說明：「這段 SQL 統計每天登入過的不重複使用者數，也就是常見的 DAU 定義。」

→ 看起來完全正確，能跑、有結果。問題是：
→ 用的是 login_log（登入紀錄），沒有人確認過主管要的「活躍」是不是「有登入就算」，還是要有實際操作行為。
→ created_at 沒有處理時區，「每天」的切法可能跟業務認知的一天對不上。
→ 沒有排除測試帳號與內部帳號，這兩種帳號通常登入頻率很高，會把活躍度墊高。
→ 這份 SQL 沒有任何文件說明它的假設，三個月後換人維護，沒人知道當初為什麼這樣寫。

【先列待確認清單，逐項核對後才生成】
AI 產出（節錄，條件確認後）：
「【Data Requirement Spec｜使用者日活躍度】
指標定義：當日完成至少一次核心操作的不重複使用者數。
資料來源：event_log 表（action_type='core_action'），已用唯讀查詢核對欄位存在、型態相符。
時間基準：自然日，UTC+8，已處理時區轉換。
排除條件：account_type IN ('test','internal')；deleted_at 不為 NULL。

【SQL】
SELECT DATE(CONVERT_TZ(e.created_at,'+00:00','+08:00')) AS active_date,
  COUNT(DISTINCT e.user_id) AS dau
FROM event_log e JOIN users u ON u.user_id=e.user_id
WHERE e.action_type='core_action'
  AND u.account_type NOT IN ('test','internal')
  AND u.deleted_at IS NULL
GROUP BY active_date;」

→ 每一行都能回答「為什麼這樣算」，時區與排除條件都處理過，三個月後換人維護，規格書就是交接文件。

【差別在哪】
第一種問「能不能跑出結果」，第二種問「這個結果是不是主管真正想看的那個定義」。SQL 語法本身可能一樣簡單，差別全部發生在動筆之前那八個問題有沒有問過。

指標名稱：日活躍使用者數（DAU，核心操作版）
業務背景：主管觀察到近期使用量可能下滑，需要每日追蹤活躍使用者數。
指標定義：當日完成至少一次核心操作的不重複使用者數。
分子定義：event_log 中 action_type='core_action' 的不重複 user_id，且排除 test/internal 帳號。
分母定義：暫無，本次為絕對人數指標。
時間基準：自然日，UTC+8。
對象範圍：全部註冊使用者。
排除條件：account_type IN ('test','internal')；deleted_at 不為 NULL。
資料來源：event_log 表（已驗證）、users 表（已驗證）。
更新頻率：每日凌晨 2 點（UTC+8）跑前一天資料。
負責人與拍板日期：王經理／2026-08-20。
已知限制或假設：core_action 分類目前僅涵蓋既定的三種操作，產品新增操作類型時需回頭更新本規格書。

SQL：
SELECT DATE(CONVERT_TZ(e.created_at,'+00:00','+08:00')) AS active_date, -- 對應時間基準
  COUNT(DISTINCT e.user_id) AS dau
FROM event_log e JOIN users u ON u.user_id=e.user_id
WHERE e.action_type='core_action' -- 對應指標定義
  AND u.account_type NOT IN ('test','internal') -- 對應排除條件
  AND u.deleted_at IS NULL -- 對應排除條件
GROUP BY active_date;

08工具怎麼挑

這幾支都做得到——差別在你手上有哪一支、資料能不能外流。標「起手」的是不知道從哪支開始時的建議，不是限定。

09會卡住與會做錯的地方

會卡住的地方（流程困難點）

AI 自己選一種常見定義就動手寫 SQL

「活躍」「流失」都有好幾種業界常見算法，AI 選了其中一種、語法正確、看起來很專業，但那不是主管腦中的那個定義。

分子分母各自表述

同一份報表裡，活躍度用「登入天數」當分子，流失率卻用「最後下單日」當基準，兩個指標看似互補，其實根本不是同一群人。

時間基準被悄悄選定

「自然日」「過去 7 天滾動」「當月累計」算出來的數字差異很大，AI 沒問清楚就會選一個預設值，而預設值往往不是主管要的。

排除條件被忽略

測試帳號、內部帳號、客服帳號沒被排除，活躍度或轉換率會被稀釋或灌水，數字失真但看起來完全正常。

資料來源只憑欄位名稱猜

欄位叫 last_login 不代表它真的記錄每次登入，也可能只在特定情境更新，沒有實際查過就當作事實使用。

會做錯的地方（常見失敗方式）

其他注意事項

• 讓 AI 直接把「活躍度」「流失」「轉換」翻成它認為合理的 SQL，其實是 AI 自己選了一種定義，主管很可能是別的意思。
• 分子分母定義混用，例如活躍用「登入天數」算但流失用「最後一次下單」算，兩張報表看起來像在講同一群人，其實口徑完全不同。
• 資料來源沒有實際核對過欄位與型態，規格書寫得很漂亮，SQL 一跑才發現那個欄位根本不存在或時區不對。

10人工把關與安全限制

AI／Agent／Tool 介入在哪幾步

這幾關不下放

八項條件的最終拍板

指標定義、分子、分母、時間基準、對象、排除條件、資料來源、更新頻率，每一項的最終選擇都由業務主管（跨部門則加上相關部門）拍板，AI 只能提供候選。

資料來源的實際核對

欄位是否存在、型態是否相符，要由人用唯讀查詢實際核對過，不能只看 AI 說的欄位名稱。

SQL 邏輯與規格書的對應

SQL 每個條件都要能指回規格書的具體條款，這一項由資料負責人核對，對不上要退回重寫。

規格書定稿簽核

業務主管與資料負責人都簽核過，規格書才能發布成為正式依據。

未定稿口徑的標註

若主管接受先用粗略版本，粗略版本要明確標示「未定稿口徑」，由人決定要不要在報表上這樣呈現。

安全與權限限制

唯讀權限的邊界

核對資料來源只能用唯讀存取查看結構與少量樣本資料，不得用來做任何寫入、修改或大量匯出。

規格書與 SQL 裡的敏感欄位

若涉及個資欄位（姓名、聯絡方式等），規格書與 SQL 草稿裡應以欄位名稱與型態描述為主，避免貼出實際個資範例。

共用位置的存取範圍

規格書存放位置的分享權限要設對，特別是包含資料表結構與商業指標定義的內容。

財務或法規認列指標的定義權

涉及營收認列、法定合規指標時，定義不能由業務主管單方面拍板，需先確認是否有既定規範。

SQL 不得包含未經確認的邏輯

任何規格書之外自行加入的篩選條件或運算，都可能悄悄改變數字的意義，一律視為不允許。

11Checklist 與驗收標準

做的時候逐項打勾

• 指標定義、分子、分母、時間基準、對象、排除條件、資料來源、更新頻率八項都已由業務主管拍板，沒有一項寫著「待確認」
• 候選清單提出時沒有夾帶 SQL 或儀表板草稿
• 資料來源欄位已用唯讀查詢實際核對過存在與型態，不是憑欄位名稱猜的
• 正式規格書的每一條 SQL 條件都能對回規格書裡的某一項定義
• 規格書已由業務主管與資料負責人共同簽核
• 規格書與 SQL 都有版本紀錄，改動要看得出改了哪裡、誰同意的

做完了才檢查：全部成立才算完成

1. 指標定義、分子、分母、時間基準、對象、排除條件、資料來源、更新頻率八項都已由業務主管（跨部門則含相關部門）拍板，沒有一項仍標【待確認】。
2. 候選清單提出階段沒有夾帶任何 SQL 或查詢語法。
3. 資料來源已用唯讀查詢實際核對欄位存在、型態相符，核對結果附在規格書裡。
4. 正式規格書具備十一欄固定格式，且「已知限制或假設」一欄非空。
5. SQL 草稿的每個條件都能對回規格書的具體條款，沒有規格書之外自行加入的邏輯。
6. 規格書已由業務主管與資料負責人共同簽核，並留有版本紀錄。
7. 若使用未定稿的粗略版本，已明確標註【未定稿口徑】。

12實際案例

13相關方法與下一步

可直接使用RELATED PROMPTS