每個月底，總部的權限管理人員會把系統匯出的 CSV 放進指定資料夾，再點兩下桌面的捷徑。

二十秒後，資料夾裡會多出一份 Access Review Excel。

它已經把停用帳號排除，也會標出九十天未登入、權限與職務不一致的帳號，並依部門拆好頁籤。CSV 少了必要欄位，Script 會直接報錯。

這支工具跑了兩年。規則不常變，使用者也只有總部那一個團隊。

其他區域同樣要做權限審查，只是各自用 Excel 整理。AI Platform Team 因此決定把 Script 包成公司共用的 Skill。

三週後，Portal 上多了一個新項目：

Access Review Preparation Skill

它有權限控管、執行紀錄、版本發布與統一入口。使用者不必再下載 Script，也不必知道原始檔案應放在哪裡。

第一次使用時，原作者看到五個欄位：

平台工程師的說法也沒有錯：其他團隊可能需要不同設定，所以這些不能全部寫死。

但她填完欄位、確認系統產生的資料摘要、再等待 Skill 呼叫原本的 Script 後，拿到的 Excel 和以前完全一樣。

下個月，她又點回舊捷徑。

平台化，先把原本被隱藏的前提攤開了

原 Script 的流程之所以只有一個按鈕，不是因為它少做了事。

固定的來源系統、帳號範圍、排除規則與輸出格式，早就寫在程式、設定檔或日常流程裡。使用者不需要每次重選，因為這些條件根本沒有變。

Skill 想要支援更多情境，就必須把這些固定前提打開，變成欄位與分支。

這是平台的正常工作。它要處理誰能執行、資料能否保存、版本出了問題怎麼回退，以及不同團隊的規則如何共存。

問題在於，這些成本不會因為名稱換成 Skill 就自動產生價值。

原使用者多了操作步驟；平台團隊多了 Portal、權限、文件、監控與支援工作。若最後仍只有同一個團隊、同一份資料、同一套規則在使用，這次包裝只是把原本穩定的工具改成更貴的入口。

「其他團隊也能用」要先被證明

後來 Platform Team 找了三個區域訪談。

他們都說自己有 Access Review，但實際流程不一樣。

• 一區沒有統一的員工編號。
• 一區把 Shared Account 和 Service Account 放在不同系統。
• 一區只做季度抽查，不做每月完整審查。

相同的是名稱，不是工作。

如果為了容納這些差異，把更多選項加進同一個 Skill，使用者只會繼續增加，維護分支也會越來越多。

真正可重用的，可能是 CSV 欄位檢查、帳號比對，或產出 Excel 的底層程式；不一定是整個 Access Review 流程，更不一定是同一個前台介面。

這是把 Script 包成 Skill 前最容易跳過的一步：先確認重複的是哪一段工作，而不是先假設整份工具都應該被共用。

多出來的成本，必須換到具體的東西

團隊後來沒有把 Skill 下架，但先縮回總部既有流程。

來源系統固定，帳號類型從 CSV 自動判斷，排除規則回到版本化設定檔。畫面只留下上傳檔案的入口。

這個版本比原 Script 慢一些，卻解決了一個原本沒有的問題：稽核時，團隊不必再人工找出「誰在何時用哪份資料跑過哪個版本」。

因此它有留下來的理由。

其他區域的需求則先各自記錄輸入、規則與輸出，跑過幾輪後再判斷是否存在可共用的底層能力。

Script 變成 Skill，不是升級儀式。

它代表工具開始承擔更多人、更多情境與更多治理責任。這些責任要成立，前提是它真的替組織減少了重複開發、風險或人工維護；否則，維持一支寫清楚說明、有人負責的 Script，反而是較好的選擇。