跳到主要內容

DS 202 · 模組 1

AI 協作分析:從問題到可執行程式

從一份服務支援分析資料包出發,練習判斷 AI 在資料科學工作中能做什麼、不能做什麼,提供足夠的資料 context,寫出可驗證的分析 prompt,並在執行 AI 生成的程式碼前先讀懂它。

開始第一節
已完成 0 / 5
同步我的進度加入梯次後,進度可跨裝置保存,講師也能看到

資訊

加入後,你已完成的模組編號會連同「學員代碼」傳送給講師,講師可以看到你的進度。請使用講師提供的代碼,不要輸入姓名、公司機密或其他個資。進度資料與該梯次的其他資料一起保存。

學習目標

  • 理解 AI 可協助 framing、code、debug、解讀、文件,但責任仍在人
  • 提供 schema、grain、units、限制與禁止假設,避免 AI 猜欄位
  • 以 task/context/requirements/output/verification 結構撰寫分析 prompt
  • 執行前檢查 imports、columns、filters、joins、formula、副作用與預期輸出
  • 讓 AI 提案並實作分析,再獨立驗證每個關鍵步驟

AI 在 Data Science 中能做什麼、不能做什麼

35 分鐘

AI 在 Data Science 中能做什麼、不能做什麼

學習目標:理解 AI 可協助 framing、code、debug、解讀、文件,但責任仍在人。

你把一份「服務支援分析資料包」丟給 AI 助理,問它:「幫我看看哪個服務組別最需要增加人力。」AI 很快回了一段程式碼、一張圖表,還有一段結論:「B 組的案件量最高,建議優先增援。」這個回答看起來很完整,但它背後隱藏了好幾個沒有被檢查的假設:AI 怎麼知道 value 欄位這次代表的是案件量、而不是平均處理時數?它有沒有排除掉 status 為草稿、之後會被覆蓋的列?如果沒有人去檢查,這個看似合理的結論很可能只是一個寫得很流暢的錯誤。

把 AI 的輸出當作答案

「AI 說某組案件量最高」直接被引用進報告,沒有人確認 value 欄位這次對應的是哪一個指標,也沒有人檢查是否混用了 draft、superseded 與 validated 三種狀態的資料。

把 AI 的輸出當作提案,人來驗證

AI 能做什麼
快速列出候選分析角度、草擬程式碼、指出可能的資料問題、把統計結果轉成白話說明、整理成文件草稿。
AI 不能做什麼
不能確認欄位的業務定義是否正確、不能保證程式碼真的讀懂資料的 grain、也不能替代人對最終結論負責。
人要做什麼
確認資料 context、逐行檢查關鍵程式碼、驗證結論是否真的來自資料,並在交付前做出「這個結果可以信任」的判斷。
本課程的資料集(先看 schema,再談分析結論)
import pandas as pd

# clean:服務支援分析資料包,一列代表某個服務組別在某個期間的一筆量能記錄
df = pd.read_csv("DS202_Analysis_Package_Clean.csv", parse_dates=["period"])
df.shape
df.dtypes
df[["record_id", "period", "group", "value", "unit", "status"]].head()

# 先問:這次的 value 欄位,單位(unit)是什麼?status 有幾種?
df["unit"].unique()
df["status"].unique()
AI 在分析流程中的合理定位
角色AI 適合做的事仍需要人確認的事
Framing列出候選預測問題或分析角度哪一個角度真的對應到業務決策
Code草擬讀取、清理、彙總程式碼欄位定義、單位與 grain 是否正確被使用
Debug指出可能的錯誤或不一致這個錯誤修正後,結論是否需要重新檢查
解讀把統計結果轉成白話摘要摘要有沒有比實際數據更樂觀或武斷
文件整理 prompt、程式碼與結論成文件草稿文件是否誠實反映限制與未驗證之處
案例:同一個 value,兩種完全不同的故事

同一個分析群組在某個月份的 value 是 58.4。若這代表案件量(unit=count),58.4 件是偏低的工作量;若這代表平均回應時數(unit=hours),58.4 小時卻是嚴重超時的警訊。AI 給出的結論「58.4,數值偏高」,若沒有先確認 unit 代表哪一個指標,這句話往哪個方向解讀都說得通,卻只有一個是對的。

  • 先確認 value 這次代表哪一個 unit(指標),再談數字高低
  • 確認是否已排除 status 為 draft 或 superseded 的列
  • 確認是否已排除 sensitive_flag 為真、不應流入一般分析的列
  • 確認彙總的 group、period 範圍,是否真的對應你想回答的問題

注意

資料安全提醒:本課程所有練習都使用課程提供的合成資料。除非獲得授權,切勿將機密的機構資料、客戶個人資料或未經授權的敏感資訊貼入 AI 工具或練習環境。

資訊

Human, AI, Human:人負責定義分析問題與判斷範圍,AI 可以協助草擬程式碼與說明;人負責逐項驗證資料、程式與結論,並對最終交付的結果負責。
自我檢測

AI 助理針對服務支援資料給出一段流暢的分析結論,且程式碼能順利執行、沒有出現任何錯誤訊息。這代表什麼?

AI 助理針對服務支援資料給出一段流暢的分析結論,且程式碼能順利執行、沒有出現任何錯誤訊息。這代表什麼?

重點: 能完成步驟不代表結果可信;本節的能力必須能被驗證、重做並清楚說明。

Context for Data:Schema、Definitions、Constraints

40 分鐘

Context for Data:Schema、Definitions、Constraints

學習目標:提供 schema、grain、units、限制與禁止假設,避免 AI 猜欄位。

同事把資料檔案路徑丟給 AI,只說「幫我算每個組別的平均值」,沒有說明 unit 欄位其實同時扮演「量測單位」與「指標識別」兩個角色(unit 是 count 代表案件量,是 hours 就代表平均回應時數),也沒有說明 status 欄位有 validated、draft、superseded 三種狀態,並非所有列都能直接拿來分析。AI 為了完成任務,會自己「猜」出一套假設,例如假設整個 value 欄位代表同一種指標、假設每一列都是已核可的資料。這些假設很少被說出來,但足以讓整個分析從一開始就是錯的。

提供資料 context 時應該說明的五件事
項目這份資料包的答案
Schemarecord_id, period, group, value, unit, status, sensitive_flag, source_version
Grain(一列代表什麼)一個 group(分析群組)在一個 period(月份)下、某一個 unit(指標)的一筆分析數值
Units(單位)unit 同時是單位也是指標識別:count=案件量、hours=平均回應時數、percent=滿意度、cases=待處理案件數、usd=每案成本,不能假設全部同一種指標
允許的操作可以依 group、period、unit 分組彙總;跨 unit 彙總沒有意義,因為那代表混合了不同指標
禁止的假設不可以假設 status 都是 validated;分析前必須先篩掉 draft 與 superseded 的列
在 prompt 之前,先自己確認這些 context
import pandas as pd

df = pd.read_csv("DS202_Analysis_Package_Clean.csv", parse_dates=["period"])

# grain 檢查:同一個 group + period + unit 是否唯一?
df.groupby(["group", "period", "unit"]).size().max()

# unit 有哪些值?它同時決定了這一列是哪一種指標
df["unit"].unique()

# status 分布:是否存在還不能拿來分析的 draft 或 superseded 列?
df["status"].value_counts()
  1. 寫出 schema 與型態
    列出每個欄位的名稱、型態與允許值,不要假設 AI 已經知道。
  2. 定義 grain
    清楚說明一列資料代表什麼,是否可能有重複或版本關係。
  3. 標出單位與換算規則
    如果同一欄位在不同列有不同單位,必須明確告知,並說明換算或分組規則。
  4. 列出禁止假設
    明確寫出「不可以假設……」,例如不可以假設所有列的 status 都已經是 validated。
提供 context 前後,AI 給出的答案差多少

沒有提供 context:「B 組平均值是 58.4,是所有組別中最高的。」提供完整 schema、grain 與禁止假設後:「只計算 unit=count、status=validated 的列,B 組平均案件量是 112 件;原本的 58.4 其實混用了 count 與 usd 兩種指標,還包含 3 筆尚未核可的 draft 列。」

  • 欄位名稱、型態與允許值是否都已列出?
  • 一列資料代表什麼、是否存在重複或版本關係,是否已說明?
  • 同一欄位若有不同單位,換算或分組規則是否已講清楚?
  • 「不可以假設……」的禁止清單,是否比允許清單更明確?

注意

沒有提供 schema 與 grain 時,AI 不會告訴你它正在猜測,它會直接產出一個看起來很完整的答案。猜錯欄位語意造成的錯誤,通常比程式語法錯誤更難被發現。
自我檢測

你請 AI 「計算每個分析群組的平均 value」,但沒有說明 unit 欄位同時決定了這一列屬於哪一種指標(例如 count 是案件量、hours 是平均回應時數)。最可能發生什麼問題?

你請 AI 「計算每個分析群組的平均 value」,但沒有說明 unit 欄位同時決定了這一列屬於哪一種指標(例如 count 是案件量、hours 是平均回應時數)。最可能發生什麼問題?

重點: 能完成步驟不代表結果可信;本節的能力必須能被驗證、重做並清楚說明。

從分析需求到可驗證 Prompt

40 分鐘

從分析需求到可驗證 Prompt

學習目標:以 task/context/requirements/output/verification 結構撰寫分析 prompt。

「幫我分析一下這份資料」是一個任務,但不是一個可驗證的 prompt。可驗證的 prompt 必須讓你事後能檢查「AI 到底有沒有做到我要的事」。把 prompt 拆成五個部分:task(要做什麼)、context(資料是什麼)、requirements(限制與規則)、output(輸出格式)、verification(要附上什麼讓人可以驗證),能大幅降低 AI 自己補假設的空間。

模糊的 prompt

「幫我看看哪個組別案件量最高,畫個圖。」沒有說明 value 在這裡代表哪一個指標、要不要排除還沒核可的列、輸出要包含什麼佐證。

結構化、可驗證的 prompt

Task
計算 2026 年每個分析群組「案件量」(unit 為 count 的列,即 request_volume 這個指標)的月平均,並找出最高的群組。
Context
資料欄位為 record_id, period, group, value, unit, status, sensitive_flag, source_version;unit 同時決定這一列是哪一種指標,status 有 validated、draft、superseded 三種。
Requirements
只使用 status 為 validated 的列;unit 必須等於 count;排除 sensitive_flag 為真的列。
Output
一張依群組排序的表格,附上使用的列數與排除的列數;圖表需標註單位與資料期間。
Verification
附上你使用的篩選條件程式碼,以及篩選前後的列數,讓我可以重新執行並核對。
把上面的 prompt 拆解對應到的程式碼
mask = (df["unit"] == "count") & (df["status"] == "validated") & (~df["sensitive_flag"])
filtered = df[mask]

print("篩選前列數:", len(df), "篩選後列數:", len(filtered))

monthly = filtered.groupby(["group", filtered["period"].dt.to_period("M")])["value"].mean()
monthly.sort_values(ascending=False).head()
可驗證 prompt 的五個部分
部分要回答的問題
Task具體要完成什麼,用什麼欄位、什麼指標?
Context資料 schema、grain 與版本關係是什麼?
Requirements有哪些篩選條件、單位限制或禁止的操作?
Output輸出格式、要包含哪些佐證資訊?
Verification要附上什麼,讓別人可以重新執行並核對?
同一個任務,缺 verification 和有 verification 的差別

缺少 verification 的 prompt 只換來一句「B 組案件量最高,平均 112 件」,沒有人知道這個數字怎麼來的。加上 verification 要求後,收到的是「篩選前 480 列、篩選後 365 列,程式碼如下」,讓你可以重新執行同一段篩選條件,核對 112 這個數字是否真的成立。

  • Task 是否寫清楚用哪個欄位、哪個指標?
  • Context 是否涵蓋 schema、grain 與版本關係?
  • Requirements 是否寫出篩選條件與禁止的操作?
  • Verification 是否要求附上程式碼與篩選前後列數?

注意

如果 prompt 沒有 verification 部分,你收到的通常只有結論和圖表,沒有可以重新執行的篩選條件與列數,事後很難判斷這個結果是不是可信。
自我檢測

下列哪一個 prompt 修改,最能提高分析結果的可驗證性?

下列哪一個 prompt 修改,最能提高分析結果的可驗證性?

重點: 能完成步驟不代表結果可信;本節的能力必須能被驗證、重做並清楚說明。

AI 生成 Python:Read Before Run

40 分鐘

AI 生成 Python:Read Before Run

學習目標:執行前檢查 imports、columns、filters、joins、formula、副作用與預期輸出。

同事收到 AI 生成的一段程式碼,看起來很專業,就直接按下執行。程式跑完沒有出現任何錯誤訊息,於是他直接把輸出貼進報告。三天後才發現,那段程式碼裡有一個 join 用錯了 key,導致部分組別的資料被重複計算了兩次。Read before run 的意思是:在按下執行之前,先用清單逐項檢查程式碼要做什麼,而不是等結果出來才回頭找問題。

範例:一段看起來沒問題、但藏著風險的 AI 生成程式碼
import pandas as pd

df = pd.read_csv("DS202_Analysis_Package_Clean.csv")
volume = df[df["unit"] == "count"][["group", "period", "value"]].rename(columns={"value": "volume"})
cost = df[df["unit"] == "usd"][["group", "period", "value"]].rename(columns={"value": "cost"})

# 這個 join 只用 group 當 key,忘了同時比對 period,
# 導致同一個 group 在不同月份的列互相配對,列數被大量放大
merged = volume.merge(cost, on="group")

merged.to_csv("output_summary.csv")  # 有副作用:會覆寫既有檔案
print(len(volume), len(cost), len(merged))  # merged 的列數遠大於 volume 與 cost 各自的列數
執行前的檢查清單
檢查項目要問的問題
Imports匯入的套件是否合理?有沒有意外連到網路或未知來源?
Columns用到的欄位名稱是否存在、型態是否正確?
Filters篩選條件是否符合分析需求(例如排除 draft、sensitive_flag)?
Joinsjoin 用的 key 是否真的唯一或符合預期的對應關係?會不會造成資料重複?
Formula彙總或計算公式是否符合定義(例如平均是否跨了不同單位)?
副作用程式是否會寫入、覆蓋或刪除既有檔案?是否符合預期?
預期輸出執行前,你能不能先猜出大概的輸出範圍,事後用來核對?
把檢查清單套用在上面那段程式碼

套用檢查清單後會發現:join 只用 group 當 key,沒有同時比對 period,造成一個 group 的每個月都互相配對;程式還有副作用,會覆寫 output_summary.csv。這兩項都不會讓 Python 報錯,卻足以讓整份分析失去意義。

  • 這段程式碼用到的每個欄位,名稱與型態是否都存在、正確?
  • 篩選條件是否真的對應到你要的業務規則?
  • join 的 key 在來源資料中是否唯一?會不會造成資料重複?
  • 程式是否會寫入或覆蓋既有檔案?這是否是你預期的?

注意

「沒有跳出錯誤訊息」不代表程式碼做的是你要的事。join key 不唯一、篩選條件遺漏、單位混用,這些都不會讓 Python 報錯,卻會讓結果整個錯掉。
自我檢測

執行前檢查清單中,「join 是否會造成資料重複」屬於下列哪一個檢查項目?

執行前檢查清單中,「join 是否會造成資料重複」屬於下列哪一個檢查項目?

重點: 能完成步驟不代表結果可信;本節的能力必須能被驗證、重做並清楚說明。

Guided Lab:AI Pair Analyst

55 分鐘

Guided Lab:AI Pair Analyst

學習目標:在教師引導下,讓 AI 提案並實作分析,再獨立驗證每個關鍵步驟。

資訊

實作問題:如果 AI 幫你提案並寫好了整段分析程式碼,你會用哪些步驟證明這段分析是可信的,而不是只看結論就相信?
  1. 提供資料 context
    把 schema、grain、unit 規則與禁止假設寫給 AI,作為它提案的依據。
  2. 請 AI 提案並產生程式碼
    用 task/context/requirements/output/verification 結構寫出 prompt,請 AI 提出分析方法並實作。
  3. Read before run
    執行前逐項檢查 imports、columns、filters、joins、formula 與副作用。
  4. 獨立驗證關鍵步驟
    自己重新計算至少一個關鍵數字(例如篩選後的列數或其中一組的平均值),確認與 AI 的輸出一致。
  5. 記錄仍需要人工判斷的項目
    列出這次分析中,哪些判斷(例如要不要納入 draft 列)仍需要業務端確認,而不是程式能自動決定的。
Guided Lab 應包含的最少內容(請填入你自己的輸出結果)
項目要回報的內容
Prompt你實際使用的 task/context/requirements/output/verification prompt
Read-before-run 檢查至少三項你在執行前檢查出的潛在問題
獨立驗證你重新算過、與 AI 輸出一致的至少一個數字
仍待人工判斷的項目至少一項需要業務端確認的假設或決策
一個常見的 Lab 失誤

某位學員在 Guided Lab 中,AI 提案的程式碼看起來跑得很順,彙總出的平均值也「看起來合理」。但他沒有重新算過任何一個數字,直到助教問「你怎麼知道這個平均值是對的」才發現,篩選條件少了排除 draft 列這一步,整個結果都需要重算。

  • 只看結論合不合理,沒有重新算過任何一個關鍵數字
  • 忘了把 sensitive_flag 為真的列排除在分析之外
  • prompt 沒有要求附上篩選前後的列數,事後無法核對
  • 把 AI 生成的程式碼直接執行,沒有先逐項檢查 join 與 filter

注意

「AI 寫的程式碼順利跑完」不等於「這個分析可信」。每一個關鍵數字都應該能被你自己重新算出一次,且篩選條件與假設都要清楚寫下來。

完成

如果 AI 協助撰寫分析程式碼,請自己逐項檢查:資料 context 是否完整提供、程式碼是否依你的 requirements 執行、關鍵數字是否被獨立驗證過。AI 可以加快撰寫速度;驗證與結論仍是人的責任。
自我檢測

你完成了 Guided Lab,AI 產出的分析結論看起來合理,但你發現 requirements 中「排除 sensitive_flag 為真的列」這個條件並沒有真的被套用到程式碼裡。這時最適當的做法是什麼?

你完成了 Guided Lab,AI 產出的分析結論看起來合理,但你發現 requirements 中「排除 sensitive_flag 為真的列」這個條件並沒有真的被套用到程式碼裡。這時最適當的做法是什麼?

重點: 能完成步驟不代表結果可信;本節的能力必須能被驗證、重做並清楚說明。

接下來做什麼?