工作導入AI，卻常常做一半沒下文？104資深協理：別先想「AI能做什麼」
做了一堆AI工具，卻沒多久就晾在那裡？該如何真正用AI解決工作問題？104資深協理李明倫分享3個實際案例、5類提示詞與7步驟實作法，教非技術職從「非做不可」的工作開始，把工作拆成角色交給不同的AI，打造你的「AI營運團隊」。
文／《104職場力》整理
本文目錄（點擊可快速前往）
公司導入AI後，興沖沖用AI做了一堆工具、Dashboard與Skill，卻過沒多久就晾在那裡，或者做一做就沒有下文……這可能是許多工作者近期的共同經驗和痛點，到底該如何和AI分工協作、真正用AI提升工作效率？
104人力銀行資深協理李明倫（Will Lee）觀察，生成式AI的出現，讓「先做一個工具看看」變得很容易，而他認為，AI應用能否落地，關鍵不在工具本身，而在一開始挑的問題。因此他認為，導入AI的第一個問題，不是先想「AI可以做什麼」，應該從「我現在最想解決什麼問題？」開始。因為持續存在的問題會帶來足夠的改善動力，團隊才會願意反覆測試、修正，最後把AI放進日常工作。
本文整理自104人力銀行資深協理李明倫於104「AI煙火小聚」分享的主題「如何打造你的AI營運團隊」，他並非技術職主管，過去兩年卻與團隊透過生成式AI、自動化及AI輔助開發（Vibe Coding），逐步改善資料整理、客服追蹤與工作流程，本次分享他與AI的協作心法。以下節錄精華內容。
【開始前的提醒】操作前應確認AI工具權限與資安規範
本次分享中，李明倫使用公司提供的Claude企業版來協助盤點工作問題。實務上，工作資料能否提供給AI，仍應依照各公司核准的工具、權限與資安規範來判斷。建議操作前需確認哪些資料可以上傳、哪些內容應先去識別化。
新需求不斷增加、系統卻跟不上，工作卡在人工怎麼辦？
在成長期的單位，常見的工作狀況是：新的客戶、新的服務與新的流程持續出現，連帶增加新的名單、資料、報表、分析及管理需求；即使工作量倍數成長，但人力卻沒倍數成長，系統建置速度也不一定能跟上，因此耗費大量時間在人工整理資料。
「最好的方法還是系統。」李明倫說：「可是新的單位、新的服務很多流程還不確定，不可能直接建到CRM。」尤其是新服務剛開始運作時，流程與規格可能仍在調整。若此時投入大量工程資源建正式系統，一旦作業方式改變，系統都得跟著改。他形容，這階段急著要求PM與工程建系統，「其實只是在丟另外一個炸彈給他們」。
這種情況下，許多團隊會先用Excel試算表來因應過渡期。「結果就是我很會用Excel，包括寫各式函數。」他說，資料不多時，這種方式快速又有彈性；但隨著檔案、函數與使用者增加，Excel的極限逐漸浮現，例如檔案跑不動、多人共用時可能誤改、資料散落在不同檔案，或是主管需待人工彙整才能掌握進度，都是可能發生的問題。
而本次分享的AI輔助開發工具，李明倫將它定位為「過渡方案」。它不取代正式後台，也沒有直接串接所有系統；用途是讓尚未定型的流程先被實際使用、驗證和修正。等規格逐漸穩定，團隊再把真正需要的功能移入正式系統。這段過渡期也像一場低成本的使用者測試，幫助更快確認規格與使用方式。
如何選題：第一個AI專案，不要挑最大的問題
首先要注意的是，不是所有工作都值得投入時間打造工具，李明倫建議，優先挑「高頻、重複、可標準化、成效可驗證」的問題：
- 高頻：經常或定期發生。
- 重複：大量步驟相同，人工反覆複製、整理或確認。
- 可標準化：狀態、判斷條件、處理順序或截止時間能說清楚。
- 可驗證：能用時間、錯誤率、處理量、採用率或其他KPI比較改善前後。
選定之後，他建議先問5個問題，把答案寫下來當作「改善前」的基準：這件事多久做一次？每次花多少時間？有幾個人參與？哪裡最容易出錯？成功後要看哪個KPI？
另外，第一個專案不必挑全公司最大的痛點。規模越大，利害關係人、資料來源與例外情況通常越多。從最常重複、最容易驗證價值的工作著手，更容易做出第一個真的有人使用的版本。
讓AI進入工作流程：3個案例看人與AI重新分工
案例1：客服案件量大，進度仍靠Excel管理
把Excel搬上網頁只是表面，真正的改變是工作方式
某個客服團隊每天要處理大量資料，一筆筆聯絡、確認、做紀錄。曾經客服為了不掉球，發展出「把資料複製到Excel」的整理方式，記下當天聯絡狀況與下次聯絡日期，也方便主管查看進度及數據。
為了改善工作流程，團隊起初嘗試增加試算表的函數和提醒，檔案卻隨資料累積變得更龐大、跑不動。李明倫接著把工作群組中的大量溝通訊息、現有流程規則、團隊成員口頭反映的問題彙整，交給AI協助標出流程中明確與仍在變動的部分，以及可能的斷點。
關鍵在於，AI蒸餾出可能的問題之後，還要跟現場同仁確認。「AI畢竟不在這個單位裡面，整理完以後我們還是會跟同事討論，哪些是大家認同的、哪些是AI想像的。與實際狀況不符合的，就剔除掉。」
問題收斂後，他們以Vibe Coding建立網頁工具來快速驗證。客服仍然處理同一批案件，但操作方式改變了：
- 所有案件集中處理，減少在不同資訊之間來回切換
- 網頁化操作，多人可同時查詢及填寫，資料不會互相覆蓋
- 可依案件屬性、時間與處理狀態等條件搜尋及排序
- 優先顯示當天必須處理案件，急件也能調整優先序
- 主管可直接查看處理量及相關數據，省去另行整理
這項工具的重點不只是幫忙整理資料，還改變了客服每天如何工作。客服能把注意力放在聯絡與服務，資料搜尋、排序、提醒與統計則交由工具承接。流程還在變動時，團隊也可以快速修改規則，持續確認哪些功能值得進入正式後台。
他分享，工具導入後，即使曾有人力較吃緊的時期，團隊單人每日處理量仍能較過去平均提升一倍以上，工作量的波動也有所下降。不過他也補充，還有各種因素可能影響成果，因此不能將改善幅度完全歸因於工具。
案例2：開發名單持續增加，需在多份Excel不斷切換
從「整理排序」到「開發優先順序建議」
另一個團隊會接到多種來源的開發名單，例如講座名單、不同月份的專案名單、AI推薦名單，每種檔案格式、欄位和產生時間不同，累積一段時間後，客服可能需要在多份試算表之間切換與比對；多人共用時，同樣可能不小心覆蓋資料。
為了改善工作模式，本例也以AI輔助開發製作管理工具，將不同批次的名單集中到同一個工具，客服可依人員、批次或開發狀態篩選，主管也能看到整體進度。同時，工具內不會直接顯示敏感的聯絡資訊，沿用內部原有的權限控管。
這個案例不同之處，是「名單整理排序」還多了一道AI與人工的來回協作：以AI參考過去成功案例的特徵，提出新名單的開發優先順序建議，並交由人工審查註記。人工複核被安排在關鍵判斷和防呆節點，大量整理與初步排序則交給AI。
案例三：公用客服信箱大量來信，回覆、紀錄、管理都費時
Power Automate與AI接力分類處理
公用信箱的回覆與管理也是許多團隊的痛點。信件數量少時，大家可以直接分工處理；但隨著業務成長，短時間內累積數百封來信，便可能出現重複處理、漏回或無法掌握處理進度等問題。
團隊原本把每封信登記到Excel試算表，再手動註記分類及處理狀態，管理雖有改善，行政負擔卻很重。
李明倫和AI討論解決方案，說明來信量、人工步驟與管理困難，最後決定採用Power Automate自動化工具，將Outlook收到的郵件定期匯入試算表，不必再花時間備份，收到即同步；再由AI協助分類，最後上傳至前例開發的客服處理工具，集中查看信件類別與處理進度。另外，Power Automate是AI提出的第2個建議。原先想的解法不可行，討論來回幾次才定案。
共通點：沒有預設解法、讓AI從工具變營運夥伴
3個案例看下來，第一個共通點是都沒有預設既定解法。他們把團隊工作現況與遇到的困難交給AI盤點、討論，再從幾個解決方案裡比較選擇、來回修正，最後採用的做法有時可能與最初想像相差很遠。這些工具也都由團隊共同討論、實際使用並調整修正。
第二個共通點，是工作被重新拆解過。李明倫用「AI營運團隊」來形容，核心主張是把工作重新解構，拆解能力、角色，再看哪些可以交給AI。以名單案例為例，一套流程內其實有好幾種職責，例如整理與比對資料（助理、分析）、釐清規格與流程（PM）、開發工具（工程）、產出主管要看的數字（Dashboard管理），最後才是實際聯絡客戶的客服。現在其中好幾段交給AI，角色之間會互相接力，人只留在需要判斷的節點。讓AI從工具，真正變成「共同營運夥伴」。
非技術職如何和AI協作？把AI當「第一天上班的聰明新人」
「AI不是通靈。即便他非常聰明，你沒有跟他講清楚，他的回答當然不會精準。」
李明倫把AI視為第一天上班、能力很強的新同事。不過，AI能快速分析與建立原型，卻不了解部門情境，也不會讀心。若提供的背景越模糊，來回修正的次數通常越多。
因此盤點型提示詞可以包含5類資訊：
- 背景現況（Existing）：工作現狀、流程如何運作
- 規則與判斷邏輯（Rules）：工作實務上的詳細規則，包括決策規則、狀態定義、操作模式
- 佐證資料（Evidence）：實際工作檔案、畫面與案例說明
- 問題與落差（Problem）：目前看到的問題，哪裡耗時、容易出錯、缺少SOP
- 明確任務要求（Ask）：希望AI最後產出什麼、給誰用，例如建立SOP、待確認資訊、問題及建議
他也分享，「盤點型」和「工具型」的prompt不太一樣：盤點型要把問題和資料給足，和AI討論出卡點；而工具型比較單純，就是把功能講清楚。
AI「專業新人」交辦模板
想請AI先協助盤點問題，可以使用以下格式：
我目前要處理的工作是＿＿。
現在由＿＿負責，使用＿＿工具。
這件事大約每＿＿執行一次，每次花費＿＿。
目前最耗時或容易出錯的環節是＿＿。
現有資料包括＿＿。
必須遵守的規則是＿＿。
我希望改善的結果是＿＿。
請先幫我整理目前的工作流程、主要痛點與可能解法，暫時不製作工具。請同時標出適合由AI協助的步驟，以及仍應由人判斷的步驟；如果資訊不足，請先向我提問。
實作心得1：一次只加一個功能，做完立刻驗證
直言自己並非技術職，李明倫打造工具時，會先和AI討論方案是否可行，確認後再逐步增加功能。他曾一次要求多項調整，結果自己和AI都容易混亂；後來改成一次處理一個小功能，完成後立刻驗證。此外，正式讓同事使用工具後，後續修改則要區分測試版與正式版（Staging／Production），避免調整功能時讓現場工具直接停擺。
實作心得2：AI說「很簡單」，不代表真能做出來
AI提出可行方案後仍要實測。李明倫坦言，有些AI口中的「很簡單」，最後仍可能做不出來；第一版範圍越小，團隊越能及早發現限制。遇到看不懂的技術問題時，他也會直接請AI換一種方式解釋，確認自己理解後再做選擇，避免盲目操作讓後續修改變得更複雜。
實作心得3：把專案知識建立在MD檔
每個主要專案也會建立MD檔，記錄規則、步驟與使用方式，避免重要脈絡散落在長對話中。至於是否進一步做成可重複調用的Skill，則要看流程的共通性。李明倫提到，許多工具的規則非常細，只適用特定單位；若跨團隊無法直接套用，保留成專案MD檔更實際。
實作心得4：文字講不清楚，就截圖給AI看
李明倫提到，和AI來回修正時，他大量使用截圖：把畫面截下來、圈起要改的地方，比打一長串文字精準得多。若要說明幾份檔案之間的關聯，他甚至會用PowerPoint畫成一頁示意圖。部署失敗時也是同樣做法：平台上會顯示錯誤訊息，截圖給AI就會自行修正，讓錯誤不再是障礙。
從問題到落地：非技術職也能採用的7步驟
想從0開始一個AI專案，必須涵蓋選題、盤點、測試與持續營運。綜合李明倫分享的實務做法，整理為以下7個步驟：
- Choose 選題：選一個值得解決的問題，優先挑「高頻、重複、可標準化、成效可驗證」。寫下發生頻率、每次花費時間、參與人數、常見錯誤與成功指標。
- Define 定義：用EPSP梳理現況（Existing）、問題（Problem）、AI解法（Solution）、標準流程（SOP）與預期影響（Business Impact）。
- Discover 盤點：蒐集現有試算表、文件、SOP、工作討論、操作畫面，訪談真正執行工作的人（使用者痛點），再請AI整理流程、痛點與可能機會。整理完務必回到實務現場逐項確認。
- Prototype 原型：只解決一條核心流程，第一版先求能用、能測，不急著做成完整系統。
- Test 實測：找一位真實使用者放入真資料，實際使用一段時間（一天／一週），記錄錯誤與新需求，反覆修正。
- Standardize 標準化：把有效做法整理成固定輸入、固定流程與固定輸出，並定義負責人、更新頻率、SOP及檢核標準。
- Review 檢討：定期檢查時間、品質、KPI、使用率與可擴充性；若規則或現場需求改變，再回到下一輪選題與定義。
李明倫認為，真正可複製的不是Prompt，而是「Problem → Solution → SOP → Review」的方法，重新拆解工作，讓工作流程持續進化。
從最想解決的問題開始，打造你的AI營運團隊
而在工具導入後，李明倫建議AI專案的成效不要只看「做出幾個工具」，應追蹤使用者是否持續使用、人工時間是否下降、錯誤或遺漏是否減少、工作品質和核心指標是否改善，以及這套流程能否被交接與持續調整等。
他也強調，雖然本次分享是使用Claude，但不同AI工具都能協助盤點流程與建立原型，介面設計、功能穩定度和使用習慣可能各有差異，選擇自己和團隊用得順手的工具即可。真正決定專案能否落地的，仍是問題是否值得解、規則是否講得清楚，以及使用者是否參與驗證。
從「非做不可」的工作開始，AI才會進入每天與每週的真實流程。當團隊持續經歷「發現問題、建立解法、形成SOP、檢視成效、再修正」的循環，累積下來的成果會超過零散的提示詞或單一工具，逐漸形成一套可運作、可交接、可改進的人機協作系統。
測你的AI素養
