驗收上線檢查清單流

🎯 這條流程解決什麼

網站上線前的驗收，最怕的不是「明顯壞掉」，而是「看起來都好、上線就出包」。漏設了 meta 描述、首頁圖片忘了壓縮導致載入慢、聯絡表單送出後沒接到通知信、手機版某個區塊跑版、內頁有幾條死連結——這些都不是大 bug，肉眼掃過去很容易放過，但只要其中一項在正式上線後被客戶或客戶的客戶撞見，第一時間就是一通抱怨電話，設計公司的專業形象瞬間打折。

問題在於，傳統的上線驗收高度依賴人工逐項點選一張 Excel 清單。一個有十幾個頁面的網站，QA 要手動跑 PageSpeed 看效能、一頁一頁檢查 title 與 meta、用工具掃死連結、開不同尺寸的手機模擬器看 RWD、再一個個測表單——整套做完扎實要花上半天到一天，而且越到專案後期、上線壓力越大，越容易為了趕時間而草草帶過。更糟的是，每個 QA 的檢查標準不一，這次記得測的項目，下次換人就漏了，品質完全看人。對承接多個案子的設計公司來說，這種「不穩定、靠人力、易漏項」的驗收，是上線翻車與客訴的主要來源之一。

這條流程要解決的，就是把「可程式化檢測」的部分自動化、標準化，讓人工專注在機器測不出來的地方。

導入後的改變

導入前，驗收是一場與時間賽跑的人工苦工：QA 對著清單一項項手測，做到後面眼睛都花了，效能數據、SEO 標籤、死連結、RWD 全靠手動，半天一天跑下來還不保證沒漏。每個專案的驗收品質，取決於當天負責的人累不累、細不細心。

導入後，專案狀態一切到「待驗收」就自動觸發：系統呼叫 Lighthouse 跑效能與 SEO、用連結檢測工具掃死連結、檢查行動裝置相容性，把結果對照標準清單標出未通過項目，再由 AI 彙整成一份易讀的驗收報告附上修正建議。原本要花半天的機械式檢測，幾分鐘內就有一份完整報告，QA 拿到的不是空白清單，而是「這幾項沒過、建議這樣修」的明確待辦。可重複、不漏項、標準一致，上線翻車的機率大幅下降，QA 的時間則挪去做機器做不到的視覺與文案複核。對接案密集的團隊來說，每個案子省下的驗收工時累積起來，等於多出可以接案的產能。

流程怎麼運作

對照上方節點，流程是這樣跑的：

第一步「待驗收觸發」，PM 在專案管理工具把狀態切到「待驗收」，流程自動帶入要檢測的網站網址與該案適用的檢查項目清單。

第二步「自動跑檢測」，系統呼叫 PageSpeed / Lighthouse API 取得效能分數、Core Web Vitals 與 SEO 基本項，用連結檢測工具爬出死連結與錯誤連結，並檢查行動裝置相容性，把客觀數據一次蒐齊。

第三步「比對清單」，把檢測結果對照公司的標準上線檢查清單，自動標記哪些通過、哪些未通過、哪些是待人工補確認的項目，一目了然。

第四步「AI 彙整報告」，AI 報告節點把一堆原始數據整理成 PM 與客戶都讀得懂的驗收報告，標出風險等級並給出具體修正建議，而不是丟一堆技術術語。

第五步「送 QA 複核」，報告寄給 PM 與 QA，由人工針對視覺、文案、敏感功能逐項複核，確認無誤後才安排正式上線。想理解這類「狀態觸發 + API 串接」的設定，可參考 自動化 的說明。

需要的工具與串接重點

平台用 n8n 或 Make。檢測核心是 PageSpeed / Lighthouse API（效能與 SEO）、連結檢測工具（死連結與 RWD）。Google Sheet 存放標準檢查清單與每次驗收的結果紀錄，方便橫向比較不同專案。AI 報告節點把數據翻成人話。Email 負責把報告送到 PM 與 QA 手上。

串接重點：一是標準清單要先定義清楚並版本化，自動檢測只是「對照清單」，清單訂得好不好決定品質；二是 Lighthouse 分數會有波動，建議跑多次取代表值，別被單次數字誤導；三是報告一定要分「自動已驗」與「待人工複核」兩區，讓 QA 清楚知道哪些還沒人看過。SEO 相關的待補項目，可搭配 SEO 檢查 配方逐項補強後再重跑。

常見錯誤與注意事項

最重要的一點：自動檢測只能涵蓋可程式化的項目，絕不等於驗收通過。視覺呈現對不對、文案有沒有錯字、品牌色與設計稿一不一致、金流串接能不能真的扣款、會員註冊與個資填寫流程是否正常，這些務必由 QA 與 PM 人工逐項複核確認無誤後，再安排正式上線。

特別是涉及金流與個資的環節，更不可僅憑自動測試就放行——一個沒測到的付款失敗或會員資料外洩，後果遠超過所有效能分數加總。自動化能幫你不漏掉機械性的項目，但上線把關的最終責任，永遠在人身上。

此外，檢測時要注意別在正式環境反覆壓測、影響到客戶現有流量；測試表單時也要避免真的觸發行銷信或寄到客戶真實名單。報告中若含客戶網址與內部資料，外送時要控管收件對象。

台灣中小企業情境案例

台南一間專做中小企業形象官網的「築點設計」，過去吃過上線翻車的虧：一個觀光工廠的案子上線當天，客戶發現手機版的預約表單按了沒反應，氣得在群組連發訊息，團隊熬夜搶修。痛定思痛後導入這條流程，把過往踩過的雷全寫進標準檢查清單。

之後接的一個餐廳訂位網站，狀態切到待驗收後，系統自動跑出報告：效能分數偏低（圖片未壓縮）、兩條死連結、行動版有一處 meta 缺漏。QA 拿到報告直接照著修，再人工測過訂位表單與付訂金流程，確認無誤才上線。這次上線零客訴，客戶還稱讚「你們很細」。團隊統計，導入後每個案子的驗收時間從近一天縮短到約兩小時（自動檢測幾分鐘，其餘為人工複核），上線後一週內的緊急修補工單也明顯減少。

延伸應用

這條流程的骨架是「狀態觸發 → 自動檢測 → 對照清單 → AI 報告 → 人工複核」，可以延伸出很多用法。可以把它從「上線前一次性驗收」擴充成「上線後定期健檢」，每月自動跑一次效能與死連結，主動發現客戶網站的退化，順勢帶出維護或優化提案。也能把報告結果回寫進專案系統，承接 工作流 裡的進度追蹤與交付環節，讓驗收狀態自動更新。長期累積的檢測數據，還能整理成公司的「上線品質基準」，新人也能照標準把關。把可量化的檢測交給機器、把需要判斷的留給人，整體交付品質會穩定許多。

流程圖

用到的工具

更多「專業服務」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →