重點摘要
- 2026 年 10 月 21 日 PHP 與 Node.js 同日爆出重大漏洞，影響視覺科技資安團隊在數小時內完成 25 個專案的升級與通報。能做到這件事，靠的不是某個 AI 工具，而是五個已經融入日常的 AI 工作流。
- 這五個工作流分別解決「漏接公告」「深夜驗證易漏」「通報耗時」「紀錄難留」與「AI 失控」五個真實痛點，每一個都是從找根因開始、小規模驗證、量化效益後才寫進流程。
- 本文說明這些工作流怎麼運作、怎麼長出來，以及我們接下來要補的五件事。給同樣想把 AI 落地到維運與資安工作的團隊參考。
為什麼是「工作流」而不是「工具」？
談 AI 落地，多數討論停在「用了哪個工具」。但工具只回答「怎麼做某件事」，工作流才回答「什麼時候、由誰、依什麼標準、做完交給誰」。
我們對 AI 工作流的定義是：一段有明確輸入、輸出、判斷標準與人工介入點的流程，AI 在其中負責一個或多個環節，流程本身可被量測、被檢討、被改進。 這個定義的重點在最後一句。工具買來就是那樣，工作流則會隨著團隊的痛點與需求持續演化。
這也是為什麼我們不在這篇文章列工具名稱。工具會換，而且不同團隊適合的工具不同。值得分享的是每個工作流解決了什麼問題、為什麼這樣設計、效益怎麼量。
引子：2026 年 10 月 21 日 PHP 與 Node.js 漏洞那一夜
那天晚上，PHP 官方發布兩個 CVSS 9.2 的遠端程式碼執行漏洞修補，Node.js 官方同日修補 10 個漏洞，其中 4 個為高風險。我們的團隊在當晚接獲通知，在 10 月 22 日清晨五點前完成 25 個專案的升級與驗證，上班時間依專案性質分級通報所有客戶，當天完成稽核格式的處理紀錄。完整過程記錄在〈PHP2Shell 與 Node.js 高風險漏洞同日爆發〉一文。
這篇文章要談的是：那個晚上之所以能這樣進行，前面幾年我們做了什麼。
五個已經落地的 AI 工作流
一、常態化漏洞監控：讓「第一時間」不靠運氣
痛點：資安公告來源多，官方郵件清單、安全公告頁、漏洞資料庫、資安媒體，每天的資訊量遠超過人工能逐一閱讀的程度。靠人盯，不是漏接就是延遲，而且會把精力耗在 90% 與自己無關的公告上。
流程：團隊訂閱多個官方與資安情報來源，由 AI 工作流自動讀取每一則新公告，分析其影響的軟體、版本範圍與嚴重程度，再與團隊維護的專案版本清單交叉比對。只有判定「與我們維運的專案相關」的公告才會推播給團隊，推播內容同時附上受影響專案的初步清單與建議修補版本。無關的公告則歸檔，不打擾任何人。
效益：團隊從「被動等人通知或隔天看新聞」變成「公告發布後不久就知道哪些專案中、多嚴重」。這次事件中，從官方公告到團隊開始盤點，中間沒有等待。
設計重點：分級與比對是這個工作流的核心，不是「轉發所有新聞」。推播太多等於沒有推播。
二、升級後自動驗證：讓「以為修好了」不再發生
痛點：升級後的驗證是最容易被省略的步驟，尤其在深夜、專案多、人疲倦的時候。而沒驗證的升級，等於把風險從「漏洞」換成「網站壞了而不知道」。
流程：每個專案都有一份固定的驗證清單：執行環境版本、服務重啟狀態、首頁與主要頁面、HTTPS、表單送出與郵件、檔案上傳、API 與第三方串接、排程程式、錯誤紀錄。其中可以自動化的項目由 AI 工作流在升級完成後立即執行並回報結果；涉及業務邏輯判斷的項目，例如後台特定功能、電商結帳，由負責工程師確認。
效益：每個專案都走過同一份清單，不因人、不因時段而有差異。工程師的精力集中在需要判斷的項目上。
設計重點：清單是固定的，但「哪些項目自動、哪些人工」會依專案性質調整。自動化不是為了取代人，而是讓人做人才能做的事。
三、客戶通報自動化：速度與語氣兼顧
痛點：事件處理完成後，通報客戶是另一個時間黑洞。不同客戶需要不同深度的資訊，逐一撰寫既耗時又容易漏掉重點，而通報延遲會直接影響客戶的安心程度。
流程：AI 工作流依專案的規模、性質與合約要求，從處理紀錄中產生差異化的通知初稿：規模較小的網站是一則簡潔的訊息，有合規需求的專案是結構完整的書面報告，重大專案則附上會議說明用的摘要。所有初稿都由負責的工程師審核、調整後才送出，確保內容正確、語氣合宜。
效益：上班時間一到，所有客戶都在同一個早上收到符合自身需求的通知，而不是依序等待。工程師把時間花在審核與回答客戶問題，而不是從空白頁開始寫。
設計重點：AI 產生初稿，人決定送出。對外溝通永遠有人負責。為什麼通報的設計這麼重要，我們在〈重大漏洞先修補再報告，錯了嗎？〉分享過一次被客戶質疑的經驗。
四、事後復盤自動化：讓知識留在組織裡
痛點：事件處理完，大家都累了，紀錄常常拖到幾天後才補，細節已經模糊。沒有紀錄，就沒有稽核佐證，也沒有下次改進的依據。
流程：AI 工作流從處置過程中的操作紀錄、版本變更、驗證結果與對話紀錄，自動整理成時間軸，並依 ISO/IEC 27001 要求的格式產出事件處理紀錄：事件說明、風險評估、處置措施、驗證項目、處理結果、後續追蹤、應留存的附件清單。工程師補充判斷依據與教訓後定稿。
效益：這次事件的處理紀錄在事件當天就完成，包含每個專案的升級前後版本、版本選擇的理由，以及其中一個專案因相容性暫升至 PHP 8.2 並需在該版本支援終止前再升級的追蹤事項。這份紀錄同時服務三個對象：客戶查核、內部稽核、下一次事件的參考。
設計重點：復盤的產出不只是「紀錄」，還包括「後續追蹤事項」。這讓事件的尾巴有人接。
五、治理原則：讓 AI 快，但不失控
痛點：AI 參與越多環節，「AI 做錯怎麼辦」的問題就越真實。沒有治理的自動化，風險不比沒有自動化小。
原則：我們為所有 AI 工作流訂了幾條不可妥協的規則：
- 人在迴路：所有對外溝通、所有正式環境變更，最後一步由人決定。AI 產生建議與初稿，不直接執行。
- 最小權限：AI 工作流只能存取完成任務所需的資源，密鑰與憑證不交給 AI。
- 關鍵節點人工核准：部署、對外發信、刪除或覆寫資料，必須有人核准。
- 稽核紀錄：所有 AI 的操作與產出都留存，可追溯是誰、在什麼時候、依什麼依據做了什麼。
- 正式環境不自動部署：AI 可以在測試環境驗證，但進正式環境永遠是人按下去的。
設計重點：這些原則與 ISO/IEC 27001 的存取控制、變更管理、紀錄保存要求是一致的。AI 工作流不是制度的例外，而是在制度之內運作。這也是我們的創辦人在〈人人都在談 AI 代理，我想說點冷靜的〉所說的：從出錯可逆的流程開始，人保留最後簽核。
這些 AI 工作流是怎麼長出來的？
這五個 AI 工作流沒有一個是一開始就設計好的。每一個都經過同樣的循環：
- 找到真實的痛點：不是「AI 可以做什麼」，而是「團隊什麼事情做得痛苦、做得慢、做得不穩」。
- 問根因：漏接公告的根因不是「人不夠努力」，而是「資訊量超過人工處理的極限」。深夜驗證遺漏的根因不是「工程師粗心」，而是「沒有固定清單與自動執行」。找到根因，解法才會對。
- 小規模試：先在少數專案或少數情境跑，看結果對不對、省了多少時間、有沒有副作用。
- 量化效益：能量的才留下來。通知的準確率、驗證的覆蓋率、通報的時間差、紀錄完成的時間。
- 寫進流程：驗證有效後，寫成標準流程，讓它不依賴某個人。
- 下一輪：流程跑一段時間後，新的痛點會浮現，回到第一步。
這個循環的本質是根據團隊自身的情況與實際需要，找出最根本的原因與解方，真正落地執行，並以實質效益檢驗。AI 是其中的手段，不是目的。我們相信這種彈性、持續調整、不斷成長的工作方式，比任何單一工具都更能決定一個團隊在關鍵時刻的表現。
下一步：資安 AI 工作流要補的五件事
這次事件能一夜完成，也讓我們看清楚 AI 工作流還缺什麼。
最值得談的是那十個停留在 PHP 7.4 的專案。它們不是被遺忘的：每一次盤點都看得到，每一次也都評估過，結論一直是「風險可接受，暫不升級」，理由是接手維護的系統以最小變更為原則、跨版本升級的成本在雙方優先序裡排不到「目前沒有問題」的系統前面、而且補償性控制一直都在。這些評估當時都站得住腳，但有一個沒被寫出來的前提：出事時會有補丁可打。EOL 版本正是這個前提不成立的情況。所以下一輪的工作流改進，重點是把「被迫漏夜升級」變成「排程內的例行升級」，讓前提過期時有人回頭重算。我們的創辦人在〈團隊一夜修完 25 個專案，我卻不想談速度〉一文中，對這個問題有更完整的說明。
- EOL 提前預警：對所有專案的執行環境、框架與主要套件追蹤支援終止日，在到期前數個月自動提醒並排入升級計畫。這一條直接回應本次的根因。
- 活的專案資產清單：把目前「人工維護、事件時確認補漏」的版本清單，升級為定期自動掃描所有程式庫與伺服器產生的清單（業界稱為 SBOM，軟體物料清單），讓盤點這個步驟從「確認」變成「查詢」。
- 重大版本升級的自動修補支援：單純的版本更新交給自動化處理；跨大版本的升級則由 AI 工作流先行執行相容性掃描與語法改寫、跑完測試後提出變更建議，工程師審核後才進入正式流程。
- 可執行的應變手冊：把目前文件形式的應變流程，改寫為 AI 工作流可以逐步執行、在關鍵節點暫停等候人工核准的形式，讓每一次事件的處置更一致。
- 可量化的指標：建立平均偵測時間（MTTD）、平均修復時間（MTTR）、修補覆蓋率、EOL 專案比例等指標並定期檢視。有數字，「持續精進」才不是口號。
這五件事會依照同樣的循環推進：找痛點、問根因、小規模試、量化、寫進流程。
給想導入 AI 工作流的團隊
如果你的團隊也在思考如何把 AI 落地到維運、資安或其他營運工作，我們的建議是：
- 從痛點開始，不從工具開始。 先列出團隊做得最慢、最累、最常出錯的三件事，再問 AI 能在其中哪個環節幫上忙。
- 先定治理原則，再放手自動化。 哪些事 AI 可以直接做、哪些事必須有人核准，在第一天就想清楚。事後補規則比事前訂規則難得多。
- 量化，否則無法改進。 每個工作流至少要有一個能量的指標，才知道它有沒有真的帶來效益。
- 與既有制度對齊，而不是繞過。 如果你的組織有 ISO/IEC 27001 或其他管理制度，AI 工作流應該在制度內運作，制度的要求反而是好的設計約束。
- 接受它會變。 工作流不是專案，沒有「完成」的一天。把它當成會長大的東西。
常見問題
AI 漏洞監控會不會誤判或漏報？ 會有誤差，所以設計上寧可多報一點相關公告，也不漏掉重大的；同時每則推播都附上比對依據，由工程師快速確認。監控結果會定期回顧，調整分級標準。
AI 工作流會不會自己動正式環境？ 不會。我們的治理原則明訂正式環境的變更與部署必須由人執行，AI 只負責在測試環境驗證並提出建議。
小團隊適合做 AI 工作流嗎？ 特別適合。小團隊的人力更有限，重複性工作佔比更高，AI 工作流釋放出來的時間比例反而更大。重點是從一個痛點開始，不要一次做五個。
AI 工作流和購買資安產品有什麼不同？ 資安產品解決的是通用問題，工作流解決的是你的團隊的具體問題。兩者不衝突，許多工作流會把產品的輸出當成輸入。差別在於工作流是依你的痛點設計、隨你的需求演化的。
ISO/IEC 27001 與 AI 工作流會衝突嗎？ 不會，前提是 AI 工作流依制度的存取控制、變更管理與紀錄保存要求設計。我們的經驗是，制度提供了好的設計約束，讓 AI 的應用從一開始就是可稽核、可追溯的。
想為自己的團隊設計 AI 工作流？
影響視覺科技的做法是「先診斷，再行動」：從團隊的實際流程、既有系統與真實痛點出發，找出根因，再決定 AI 該放在哪裡。如果你想了解自己的團隊可以從哪裡開始，歡迎免費品牌初診，由顧問與你進行初步諮詢，或直接預約諮詢。