嗨 Reader：

以前做一份 Power BI 報表，清理資料、建立模型、寫 DAX、拉圖表、調整格式，都得自己一步步完成。做到一半發現需求不清楚，或是數字不合理，又得再回頭找原因。

最近我開始在工作中大量使用 AI 開發 Power BI 報表，讓我體驗了很不一樣的工作方式。

例如：最近一次的專案，手上已有使用者需求與資料。我把大部分模型、公式、報表畫面和文件的實作交給 AI，自己看成果、提出問題，再決定下一輪怎麼改。

最有感的變化，是我不用每一步都親手操作，可以先交代一輪工作，等結果回來，再集中處理需要「判斷」的地方。

過去累積的資料與報表經驗，這時候很有用！我要知道需求少了什麼、數字哪裡不合理，也要看得出一份畫面完整的報表，還有哪些地方不能放心交出去。

這篇就用這次的實作經過，整理我怎麼和 AI 一起把報表往前推進，以及過程中真正花心力的地方。

一、先想清楚，這份報表要幫誰做什麼決定？

讓 AI 開始做圖表以前，我得先把報表的任務講清楚。

例如：主管想知道各部門的業績有沒有跟上目標？

如果只交代「做一張各部門業績圖」，AI 可以做出圖，但使用者要怎麼「從這張圖決定下一步」？

我會再往前想：

• 第一眼要先看到整體達成狀況，還是落後最多的部門？
• 發現落後以後，要能往下查到哪個月份、哪一類業務？
• 切換條件後，哪些數字應該一起改變？

這些問題會影響資料、計算、版面和操作順序。先把想找的答案說清楚，才知道圖表應該放什麼。

還有，自己做報表時，有些條件可能早就放在心裡，操作時順手就做了。交給 AI，這些「我以為不用說」的條件，就得補進要求裡。

同樣一句「跟去年比較」，是全年跟全年比？還是今年 1–9 月，只和去年 1–9 月比？

這些都會影響公式怎麼寫，以及讀者會怎麼理解結果。

二、先確認資料與計算，再往畫面走

實作上我會先讓 AI 讀取模型，對照需求檢查資料表、欄位與關聯，再討論指標怎麼算。

過程中用到 Power BI Modeling MCP。你可以把它理解成讓 AI 和 Power BI 模型互動的工具：連上模型後，AI 可以查閱結構、執行 DAX 查詢，也能透過工具修改模型。這裡先用它查清楚現況，修改的範圍再另外交代。

資料有沒有、能不能算，得分開確認。

例如：資料只有部門、月份與業績。缺了目標，儘管能加總業績，卻算不出達成率。這時候我會先請 AI 列出缺少什麼，哪些部分可以繼續，哪些得等補件。

盤點完資料後，接著才是公式試算。

DAX 是 Power BI 用來寫計算公式的語法；AI 寫出一段 DAX 後，我仍需要知道該拿什麼答案核對。

以下用一組假設的單月資料說明，金額單位都是萬元：

只選 A 部門時，達成率預期是 80%；看全體時，則是（80＋20）÷（100＋100）＝50%。這兩個答案可以先算出來，後面拿到報表就有核對依據。

當然，真實專案還有日期、分類及空白資料等條件，要依實際需求檢查。先把幾個關鍵計算驗證過，再做進畫面，會比較知道下一輪該查哪裡。

三、用 HTML 先試版面和操作

計算方向確認後，我會請 AI 先做 HTML 互動原型，也就是一份可以在瀏覽器打開、實際點選的網頁。

先試篩選器、圖表位置、配色與工具提示。可以直接看：重要的數字有沒有放在容易找到的位置？切換條件後，使用者還看得懂現在在看什麼嗎？

例如：同樣是部門業績，光在文字裡說「要簡潔、專業」，很難知道彼此想的是不是同一種畫面？先有一版能操作的 HTML 原型，就能指出哪裡太擠、哪些資訊藏得太深、哪個操作應該放前面。

但原型裡試過的設計，進到 Power BI 以後還得重新確認。

我就遇過 HTML 原型轉進 Power BI 後，有些卡片與滑鼠移上去才出現的提示資訊，沒有完整保留原來的內容。原型方向可以沿用，實際呈現與互動仍要人為確認。

這也讓我更確定，每個階段都要說清楚這一輪要確認什麼。原型可以幫助我們討論操作與版面；正式報表裡的資料、公式及互動，還有各自要通過的檢查。

四、分批進 Power BI 實作，拿到一頁就檢查一頁

進入正式實作時，我把報表另存成 PBIP 專案。

PBIP 會將報表與資料模型保存為文字檔，讓程式或 AI 能處理這些專案內容。模型與公式透過對應工具處理，報表畫面則透過專案檔案修改，兩邊搭配完成。

我會保留原檔，在副本上分批實作。先做一頁，確認數字、篩選與畫面，再往下一頁走。

如果第一頁的比較方式或操作邏輯還沒確認，就一次做完整份，後面很可能整批都得改。把修改範圍縮小，也比較能看出這一輪究竟改了什麼。

整個流程仍然會與 AI 來回。有時是要求不夠清楚，有時是 AI 漏了條件，也有些問題，得實際打開報表操作才看得到。

五、驗證時，我會看數字，也會真的去操作

拿到成果後，我最不能省的工作就是檢查。

以剛剛的假設資料來說，全體達成率是 50%，選 A 部門後應該變成 80%。如果篩選器已經選了 A，卡片卻仍顯示 50%，就得回頭查公式、模型或視覺互動設定。

畫面上有數字，還需要進一步確認：它算的是誰、哪段時間，是否真的受到目前條件影響。

專案上也遇過：調整座標軸的做法會影響圖表之間的篩選互動。所以改完畫面後，要回去點選、切換條件，看看其他圖表有沒有跟著正確改變。

我也用到 Codex 的 Computer Use，讓 AI 協助操作報表、跑畫面上的檢查。但我自己的感受是，這類操作很吃 Token，會挑需要實際操作才能確認的地方使用。

有些數字可以請 AI 批次比對，有些使用上的問題，我得親自看過，才能決定這一版是否符合原本的需求。

後來回顧這段時間與 AI 的協作，我發現一件很有意思的事：大量時間都花在驗證與交付。

挑一個最近的專案來說，累計有 62.09 小時的 AI 任務處理時間，也就是把每次 AI 收到指令到完成回覆的時間加總，依每個回合的主要任務分類如下。

驗證修正與文件交付合計占 59.2%，接近六成。裡面也包含重做、修正與補說明的時間，反映的是這個案例實際走過的過程。

所以，我不會把 62.09 小時直接寫成自己省下的工時。要回答省了多少，還得比較相同成果原本需要的人工時間，以及這次我實際投入多少。

這次我能明確感受到的是，AI 接手了大量持續執行的工作，我把更多心力放在交代條件、判讀結果和決定下一步。

六、交付時，還要想下一個人怎麼接手

做完自己能開啟的報表，後面還有一段工作：讓接手的人也看得懂、用得起來。

除了可編輯報表與專案檔，我也會整理操作導覽、公式說明與設計規範，把報表的用途、資料來源、計算邏輯和已知限制留下來。

這些文件要回答很實際的問題：第一次打開，從哪裡開始看？資料來源換了，要改哪裡？遇到連線問題，要怎麼處理？哪些資料還缺、哪些結果暫時不能下結論？

以後同事要使用或修改報表，就能先從文件了解專案，不必每次都找原作者問。下一次換 AI 協助維護，也能讓它先讀文件，快速掌握需求、模型結構與注意事項，減少重新交代背景的時間。

因此我交代 AI 整理文件時，也得講清楚讀者是誰、已經懂什麼，以及需要哪一層的說明。文件整理好後，仍要確認接手環境能否正常開啟、更新與操作，才能完成正式驗收。

把這些說明留下來，不只是為了這次交付，也是讓之後的同事、AI，甚至隔一段時間再回來的自己，都能更快接著做。

七、想開始，可以先挑一件知道怎麼檢查的小任務

如果你也想試著把報表工作交給 AI，可以先挑一個範圍小、資料拿得到，而且你知道怎麼判斷對錯的任務。

例如：先做「單月各部門業績與達成率」這一頁。下面是一份給 AI 用的任務說明，可以依你的情境調整：

目的：讓主管查看各部門單月業績與目標達成率。

資料：部門、月份、業績、目標；先檢查欄位與月份是否齊全，缺少的資料列出來。

這一輪：先列計算方式、試算結果與待確認問題，暫時不要修改原始報表。

核對範例：同一月份，
A 部門業績 80 萬、目標 100 萬；
B 部門業績 20 萬、目標 100 萬。
只選 A 時達成率為 80%，看全體時為 50%。

下一步：等我確認資料與計算，再做一頁原型，確認後才進 Power BI 實作。

給 AI 任務時，把目的、資料、這次範圍與檢查方式一起說清楚，你拿回成果後也比較有方向。

但要把這些條件交代清楚，自己得先理解資料怎麼連、指標怎麼算，以及報表要回答什麼問題。這也是這幾次專案讓我最有感的地方：過去學的資料模型、DAX 和報表設計，不只用來親手做報表，也成了我交代 AI 任務、檢查成果的依據。

如果你也想讓 AI 幫忙做報表，卻還不知道怎麼描述需求、檢查數字，可以先從資料與報表的基本觀念開始。

你可以先建立看懂資料、計算與報表的基礎，再拿一件熟悉的小任務，練習和 AI 一起完成。

哪邊還能獲得更多資源呢？