部落格列表

2026.11.06

AI流程自動化如何串接系統並創造可量化效益

AI流程自動化的真正價值，不在於讓聊天機器人多回答幾個問題，而在於讓訂單、發票、客服案件、庫存預警與主管決策能跨系統流動，並在適當位置保留人工判斷。許多企業已購買 AI 工具，卻仍靠人員複製貼上、查詢 ERP、寄信催辦；問題通常不是模型不夠強，而是流程、資料權限與例外處理沒有被設計好。

對傳統產業而言，導入 AI 最常見的風險是直接從大型系統開發開始，卻尚未確認資料品質、現場接受度與財務效益。McKinsey 調查顯示，2024 年有 72% 的組織採用了 AI，65% 的組織採用了生成式 AI；但同時有 43% 的企業不知道該先做哪個 AI 專案，且超過80%的組織尚未將成果轉化為企業層級的 EBIT 影響。

本篇會從定義、架構、工具、AI Agent 導入與治理五個面向，說明如何建立可驗收的 AI工作流程；也會以文件與營運場景示範 Trigger、Action、信心分數、人工覆核及錯誤回滾。讀完後，您可選出適合 PoC 的流程，定義 AI POC 成功指標，並規劃從試點走向正式營運所需的技術與內控制度。

AI流程自動化是什麼：從規則執行走向情境決策

企業團隊檢視 AI流程自動化與文件處理流程圖

先釐清定義：AI 不是單純的流程按鈕

AI流程自動化是把事件觸發、資料擷取、模型判讀、商業規則、跨系統動作與人工覆核串成閉環的設計。傳統自動化通常依固定欄位與 if／then 條件執行；AI 則能讀取電子郵件、PDF、圖片與客服對話等非結構化資料，提出分類、摘要、預測或下一步建議，再由流程引擎決定是否寫回系統。

以採購發票為例，流程不應只停在 OCR 擷取金額。更完整的設計是：收到檔案後辨識供應商與品項、比對採購單及收貨紀錄、計算信心分數、將低風險案件送入 AI ERP 草稿、高風險案件建立覆核任務，最後留下來源檔、模型版本與核准紀錄。這才是可稽核的自動化。

企業應將流程視為可衡量的營運產品，而非一次性腳本。輸入資料格式、Prompt 版本、輸出 Schema、例外碼、重試次數與人工處理結果，都必須可追蹤。若只追求「看起來會回答」，很難在發票、報價、庫存或客訴等高頻作業中穩定擴大，更無法向管理階層證明投資價值。

  • 核心組成：Trigger、資料處理、模型推論、決策節點、Action 與稽核軌跡。
  • 核心目標：降低人工搬運資訊，而不是取消所有人的判斷。
  • 核心原則：讓每一個 AI 輸出都有可接受、可覆核、可回滾的路徑。

AI工作流程、RPA 與 AI Agent 的差異

AI工作流程最適合處理步驟相對固定、但內容需要理解的任務，例如讀取請款信、擷取附件欄位、查找合約條款與建立工單。它會預先定義輸入、輸出、Prompt、判斷門檻與責任人，因此可預測性通常高於完全開放式的代理人操作，也較容易納入既有內控。

RPA 擅長模擬人在畫面上的重複操作，例如登入舊系統、下載報表或搬移欄位；缺點是畫面變動就可能失效。AI Agent 則具備規劃、使用工具與多步推理能力，能根據目標選擇下一個動作。實務上最穩健的做法不是三選一，而是以 Workflow 管理骨幹，在需要理解時呼叫 AI，在缺乏 API 時保守使用 RPA。

模型呼叫通常需要數百毫秒到數秒的回應時間，因此不宜把每個微小動作都交給模型判斷。對於折扣上限、付款帳期、庫存安全量等明確規則，應由規則引擎直接決策；對於品項描述歸類、文件摘要、異常原因說明等模糊工作，才交給模型。這種分工可降低延遲、成本與不一致輸出。

  • 固定規則與穩定介面：優先採用 API 或規則式流程。
  • 需閱讀、分類、摘要或判斷語意：加入生成式 AI 或模型服務。
  • 需跨工具自主規劃：在明確權限與護欄下使用 AI Agent。

以信心分數與人工覆核，避免自動化放大錯誤

可靠流程的直接答案是：不要把 AI 結果直接當成事實。每次文件擷取、分類或比對都應產生信心分數、引用來源與驗證狀態。例如發票總額與採購單完全吻合、供應商名稱已在主檔、稅額格式合理時，可走自動建單；任一條件不符，就應送入待處理佇列。

人工覆核不代表自動化失敗，而是風險控制的一部分。建議將案件區分為「自動完成」「抽樣覆核」「必須覆核」三個層級，並量測每層的正確率、人工介入率與處理時間。若某家供應商格式經常出錯，可將回饋轉為文件模板、規則或 Prompt 改版，而不是讓人員永久補洞。

企業尤其需要防範幻覺與錯誤引用。調查指出，57% 的企業遇到幻覺問題；因此模型若無法找到合格來源，系統應輸出「無法判定」而非自行補寫。對外寄信、調整付款、刪除資料或下採購單等不可逆操作，還要加入雙人覆核、金額門檻或主管核准，避免錯誤被流程高速放大。

  • 將信心分數與商業風險分開設定，不能只看模型自評。
  • 保留原始文件、擷取結果、規則命中與人工修正紀錄。
  • 所有高風險 Action 都應提供停止、回滾與升級處理機制。

設計可落地的 AI工作流程與 PoC 驗收標準

從高頻痛點挑選第一個驗證流程

第一個 AI POC 不該選最複雜的專案，而應選量大、規則可說明、結果可量測的流程。理想案例包括每日處理數百或數千筆相似請求的文件分類、發票驗證、客服分流或報價單比對。這類場景有足夠樣本檢驗準確度，也能清楚計算人工分鐘數、錯誤成本與例外比例。

流程盤點時，請訪談實際執行者而非只詢問主管。畫出從 Trigger 到結案的每一步，標示資料來源、目前花費時間、系統登入點、例外情形與誰有核准權。常見情況是同一筆資料在 Excel、Email、ERP 與群組訊息間重複輸入；這些轉接點往往比「做一個聊天機器人」更具改善價值。

建議先核准3至5項流程，再以商業價值、資料可用性、導入難度與風險四項評分排序。每一項都要設定基準線，例如每筆處理分鐘數、一次做對率、人工轉交率與逾期率。沒有基準線，PoC 就只能展示功能，無法回答模型的預測準確度是否真正改善了營運結果。

  • 優先選擇：高頻、可重複、可取得歷史資料且有明確責任人的流程。
  • 暫緩選擇：跨太多部門、流程本身尚未標準化或結果無法驗收的案件。
  • 驗證目標應連結業務成果，例如縮短結帳時間或降低缺貨，而非只看模型展示效果。

把流程規格寫成可測試的契約

可上線的流程必須先寫清楚「何時開始、讀什麼、如何判斷、要做什麼、失敗怎麼辦」。例如收到特定信箱的 PDF 即觸發；系統擷取發票號碼、總額與供應商；若比對成功且信心分數達門檻則建立草稿，否則建立人工任務。這份規格就是業務、工程與稽核人員共同檢查的契約。

Prompt 也必須版本化。建議固定角色、任務、可使用資料、禁止行為與 JSON 輸出格式，並要求模型列出引用欄位。若要摘要合約，輸出可限制為500 字以內，且分開呈現義務、期限、違約風險與原文位置。這會比只要求「請幫我摘要」更容易做自動測試與後續維護。

除了正常測試案例，也要刻意準備錯誤檔案、缺欄位、重複上傳、語言混雜、供應商改版格式與 API 逾時等案例。測試結果要記錄準確率、引用正確性、幻覺率、端到端延遲、吞吐量、每筆成本與人工介入率；這些才是 AI POC 成功指標，而非單一模型分數。

  • 輸入契約：來源、允許格式、必要欄位、個資遮罩規則。
  • 輸出契約：JSON Schema、必填欄位、引用來源、錯誤代碼。
  • 失敗契約：重試間隔、最大次數、人工佇列與回滾條件。

用短週期 PoC 建立 Go／No-Go 證據

AI PoC 的目的不是承諾一定做成，而是在正式開發前，以最小範圍驗證可行性與效益。實務上可先設定兩到四週完成資料盤點、原型與初測，再依資料量與系統串接複雜度安排後續驗證。若涉及多個既有系統、權限或正式介接，8 週完成 POC 是較務實的規劃方式。

驗收會議應同時看三種證據：第一是模型品質，例如關鍵欄位正確率與錯誤類型；第二是營運品質，例如人工分鐘數、處理量與例外率；第三是採用品質，例如現場人員是否願意使用、覆核介面是否能快速修正。只因模型答對幾題就通過，通常會在正式營運時失敗。

有些 PoC 最有價值的結論是暫不投資。若歷史資料缺漏、流程規則仍爭議很大、預期節省時間不足以支付維運成本，應明確提出 No-Go 或重新定義範圍。以實際資料與實際環境驗證，並保留架構、測試集與程式碼，能讓後續正式開發不必從零開始，也降低決策者承擔的風險。

  • Go：品質與效益達標，且資料、權限與責任邊界可支持上線。
  • Iterate：有商業價值，但需改善資料、介面或例外處理。
  • No-Go：效益不足、風險過高或前提未成熟，應停止擴大投資。

AI 系統整合與 AI ERP：讓資料在正確位置流動

以分層架構整合 ERP、CRM 與企業知識

AI 系統整合的關鍵不是把所有資料搬到模型裡，而是讓模型在被授權的範圍內取得必要資訊，並將結果安全寫回正確系統。建議採用資料層、整合層、智慧層、流程層與應用層的分層架構：資料層保存主檔與文件，整合層處理 API 與事件，智慧層提供 RAG 與模型，流程層負責編排與審核。

在企業知識庫聊天機器人情境中，RAG Engine 應依使用者部門與文件權限檢索內容，再把核准的片段交給模型回答。這比把所有檔案直接丟進對話工具安全，也能要求答案附上文件來源。若使用者無權看某份採購合約或人資規章，系統應拒絕檢索，而不是僅在前端隱藏按鈕。

AI ERP 的定位是讓 AI 協助讀取、預測、建議與建立草稿，不是讓模型自行改寫總帳或主資料。舉例來說，需求預測模型可用過往銷售與庫存資料比較多個模型，再把預測結果送入補貨建議；實際下單量、核准權限與會計分錄仍應由 ERP 既有控制機制管理。

  • 資料層：ERP、CRM、文件庫、資料庫與事件紀錄。
  • 智慧層：OCR、RAG、分類模型、生成式模型與 Model Router。
  • 流程層：Workflow Engine、規則、核准、通知與錯誤處理。

API、事件與函數呼叫開發的實務分工

函數呼叫開發是讓模型以受控方式要求系統執行查詢或動作的技術，例如查詢庫存、建立客服工單或取得客戶信用狀態。模型不應直接生成 SQL 或任意 API 請求；工程團隊應提供名稱明確、輸入 Schema 嚴格、權限受限的函數，並由後端再次驗證資料型別、範圍與使用者身分。

整合層通常需要 API Gateway 統一管理身分驗證、流量限制、版本與稽核。同步 API 適合使用者等待結果的查詢；事件驅動則適合訂單成立、文件上傳、庫存變動等非同步工作。若付款系統暫時失敗，流程應使用具冪等性的交易識別碼，依規則重試，避免同一張發票被建立兩次。

新式 MCP協定可讓模型透過標準化介面發現並使用工具與資源，但它不是免治理的捷徑。企業仍要審查每個 MCP Server 可讀取的資料、可執行的動作與傳遞的身分資訊。尤其涉及 ERP 寫入、客戶個資或檔案下載時，應採最小權限、明確核准與完整紀錄。

  • 讀取類函數：可設定較高自動化程度，但仍須遮罩敏感欄位。
  • 寫入類函數：需做參數驗證、冪等控制、核准與回滾設計。
  • 高風險函數：付款、刪除、主檔異動應禁止模型直接執行。

選工具前先決定整合深度與維運責任

工具選擇的答案取決於流程成熟度，而不是哪一套平台最熱門。Make、Zapier、n8n 與 Power Automate 都可快速建立觸發與 Connector；若是跨部門、涉及 ERP、SSO、稽核、版本控管與高交易量的核心流程，則要評估企業平台或客製 Workflow Engine。低程式碼適合加速原型，但不會自動解決資料契約與治理問題。

例如某些自動化平台支援超過 7,000 種應用整合，對行銷、通知與一般 SaaS 串接很方便；但製造、財務或供應鏈流程常有私有 API、舊系統與複雜權限，仍需工程團隊建立 Connector 與監控。選型時應將月費之外的 API 用量、錯誤排查、帳號管理與供應商鎖定成本一併納入。

下表可協助決策者依流程風險與整合需求初步選擇方向。無論採哪一種工具，都應先做最小流程驗證，並將可觀測性、例外佇列與維運責任寫進上線條件；否則流程數量一增加，團隊很快會失去對資料流向與成本的掌握。

依流程複雜度與治理需求選擇自動化建置方式
項目 無程式碼平台 低程式碼／自架流程 企業級客製整合
適用場景 SaaS 通知與行銷 部門流程與 PoC ERP 核心與跨域流程
建置速度 最快 快 較長
客製整合 Connector 為主 API 與程式擴充 完整 API、事件與資料契約
治理能力 平台功能為主 可自行強化 可依內控深度設計
維運責任 業務與資訊共管 內部技術團隊 專責產品與維運團隊
實際選型仍需驗證 API 能力、資料所在地、身分整合與交易量。
  • 選型前確認：既有系統是否有 API、是否需要地端連線與是否支援企業身分管理。
  • 選型前確認：誰負責失敗告警、版本升級、Connector 異動與費用監控。
  • 選型前確認：流程是否可匯出、替換模型或遷移至其他平台。

AI Agent 導入與 AI代理人協作的安全邊界

先讓 AI Agent 做可逆、可監督的工作

AI Agent 導入應從「查詢、整理、建議」等可逆任務開始，而不是一開始就授權它自主下單或修改財務資料。適合的第一步包括彙整客服案件、查找 SOP、產生回覆草稿、整理異常報告，或根據庫存與交期提出補貨建議。這些任務可以讓人員快速確認品質，也容易回收資料來改善提示與規則。

成熟的 AI Agent 需要目標、工具清單、記憶範圍、停止條件與升級規則。若客服 Agent 無法從知識庫找到來源，應將案件轉交真人；若採購 Agent 的建議金額超過門檻，應建立審批而非直接發單。將自主範圍限制在明確的任務沙盒中，才可能逐步建立現場與稽核單位的信任。

調查顯示，82% of cross-industry operations executives expect that process automation and workflow reinvention will be more effective because of AI agents by 2027。這項期待不代表企業應跳過基礎工程；真正的前提是資料可用、工具權限可控、流程有例外處理，且每次 Agent 決策都能回答它用了哪些資料、呼叫了什麼工具與造成何種結果。

  • 從讀取、摘要、建議開始，再逐步開放建立草稿與提交核准。
  • 每個 Agent 都應有明確的工具白名單、預算上限與執行時間限制。
  • 對外發送、資金異動、資料刪除等行為必須設為人工核准。

建立 AI代理人協作，而非讓多個 Agent 任意對話

AI代理人協作的最佳實務是讓每個角色負責單一可驗收職責，並由 Workflow Engine 控制交接順序。例如文件 Agent 負責擷取欄位，政策 Agent 只負責檢索規章，審核 Agent 檢查資料完整性，最後由流程引擎根據規則建立案件或送人工覆核。這比讓多個模型自由討論更可預測且更容易除錯。

協作設計要避免「一個 Agent 的假設成為下一個 Agent 的事實」。每次交接都應傳遞結構化資料、來源連結、信心分數與處理狀態；接收者只能使用被授權的欄位。若擷取 Agent 回傳供應商名稱不確定，審核 Agent 應要求補件或轉人工，而不是自行猜測並將答案傳到付款流程。

管理者也需要觀察協作成本。多 Agent 架構雖可提升任務分工，但每次呼叫都增加延遲、Token 費用與失敗點。應量測每筆任務的工具呼叫數、成功率、人工轉交率及平均完成時間，並定期淘汰沒有帶來額外品質的 Agent 步驟，讓架構保持簡潔。

  • 角色分工：擷取、檢索、比對、決策建議與執行動作應彼此分離。
  • 資料交接：使用固定 Schema，不以自然語言長文作為唯一交接內容。
  • 流程控制：由編排層決定下一步，不讓 Agent 無限制自行擴張任務。

把 AI數位員工定位為受管理的營運角色

AI數位員工不是人力替代的宣傳名詞，而是具備明確職務說明、輸入範圍、KPI、權限與主管責任的數位角色。例如「應收帳款資料整理員」可讀取請款附件、建立草稿與提醒缺件，但不能修改客戶信用額度；其績效可用處理量、一次正確率、人工退件率與平均處理時間評估。

導入時要重新設計人的工作，而不是把原本流程原封不動塞給 AI。第一線人員可由重複搬資料轉為處理例外、驗證高風險案件、維護知識庫與優化規則；部門主管則要能判讀儀表板、核准流程變更並處理模型漂移。這也是企業從 PoC 走向正式營運時最容易被低估的能力缺口。

Agentforce Operations 的成熟度觀察顯示，隨著工作流程數位化，前60至90天可提升15–20%的效率；接下來60至180天內，由代理接手協調工作後，效率可提升40–60%；當 AI 優先的設計在一至兩年內逐步落實後，效率可提升70–95%。這些數字應視為設計方向，不應取代各企業以自身基準線驗證 ROI。

  • 為每個數位角色建立職務範圍、禁止行為、核准人與停用機制。
  • 將人員訓練聚焦在例外處理、資料品質、判讀 AI 證據與流程改善。
  • 績效衡量應兼顧效率、正確率、合規性與使用者信任。

從 PoC 到正式營運：治理、監控與持續優化

正式上線前補齊治理與內控能力

正式營運的直接答案是：模型之外，更要管理資料、權限與責任。企業應建立流程負責人、資料擁有者、模型負責人、資安審查者與最終業務核准者，避免發生錯誤時沒有人能決定停用、修正或對外說明。若跨部門共用流程，也要先定義資料誰能看、誰能修、誰對結果負責。

身分與權限應整合 SSO 與 RBAC，並遵守最小權限原則。使用者登入企業知識庫聊天機器人後，系統必須依其角色過濾文件與函數權限；服務帳號則應與人員帳號分離、定期輪替憑證。稽核紀錄至少要保留輸入來源、模型與 Prompt 版本、檢索文件、函數呼叫、輸出結果與人工覆核動作。

治理不是上線前的一次性審查。模型、文件內容、供應商格式與法規都會改變，因此應設置變更管理：任何 Prompt、模型、Connector 或權限異動，都要經測試、核准與可回復的發布流程。對涉及個資、財務或合約的流程，還要訂定保存期限、遮罩規則與事件通報機制。

  • 責任治理：明確指定流程 Owner、資料 Owner、技術 Owner 與核准人。
  • 存取治理：採 SSO、RBAC、服務帳號隔離與最小權限。
  • 變更治理：模型、Prompt、工具與資料來源改版均需測試與紀錄。

持續監測模型漂移、成本與流程品質

上線後最重要的工作是監測模型漂移。當供應商改用新的發票版型、產品名稱改碼、內部政策更新或客戶問法改變時，原本表現良好的流程可能逐漸失準。系統應持續抽樣比較 AI 結果與人工最終結果，並監控信心分數分布是否異常下降，而不是等到大量錯帳才發現問題。

營運儀表板至少應分成品質、速度、成本與風險四類指標。品質看關鍵欄位正確率、引用正確性與人工退件率；速度看端到端延遲與積壓案件；成本看每筆任務模型費用、工具呼叫與人工覆核分鐘數；風險看未授權存取、失敗重試與高風險 Action 被攔截的次數。

供應鏈場景可用結果證明價值：一家電子製造商將庫存滯留時間整整縮短一天；一家能源公司在單一發票驗證流程中，新增約40個由代理執行的步驟，每年節省數千萬的成本。這些案例提醒我們，效益來自端到端重設計與持續監測，而不是單純把一個模型接到既有畫面。

  • 設定品質警報：正確率下滑、人工退件上升或信心分數異常時自動通知。
  • 設定成本警報：單筆成本、呼叫次數或失敗重試超過預算時暫停擴張。
  • 設定風險警報：敏感資料存取、高風險工具呼叫與權限異動均須可追溯。

用分階段路線圖擴大，而不是一次全面替換

企業擴大 AI流程自動化時，應採「一個流程、一組證據、一個可複製模組」的方式前進。第一階段先完成文件或客服等單一流程 PoC；第二階段把已驗證的資料 Schema、審核元件、告警與權限模式重用到相鄰流程；第三階段才整合跨部門資料與 AI Agent 協作。這種路線可減少大型專案常見的範圍失控。

流程擴張前，應成立跨部門的輕量治理小組或 CoE，負責優先順序、共用元件、資安審查與成效報告。這個團隊不需要壟斷所有開發，但應維護流程目錄、可用模型清單、核准函數、資料分類規則與評測標準，避免各部門各自購買工具後形成新的資訊孤島。

最後，請以可量化的營運成果決定投資，而不是以展示效果決定預算。若流程能縮短處理時間、降低錯誤、改善服務品質或提升資金與庫存周轉，就有擴大基礎；若成效不明，應回到流程與資料診斷。92% 的企業計畫在三年內加碼投資 AI，但能把投資轉化為成果的企業，會是那些先建立驗證與治理能力的團隊。

  • 第一階段：完成單一高價值流程的資料、模型與人工覆核驗證。
  • 第二階段：重用 Connector、Schema、權限與監控元件，擴展相鄰流程。
  • 第三階段：在治理成熟後再導入跨部門 Agent 協作與端到端最佳化。

總結

AI流程自動化的成功關鍵，是先把營運問題拆成可驗證的流程，再以 AI 處理語意理解與建議、以規則與人工覆核管理高風險決策。從 AI工作流程、AI ERP 串接到 AI Agent 導入，企業都應將資料契約、權限、例外處理、監控與 ROI 一起納入設計，而非在上線後才補救。

重點整理

  • 先選高頻、可量測、資料可用的單一流程做 PoC，避免一開始就全面改造。
  • 以信心分數、引用來源與人工覆核控制模型幻覺與高風險操作。
  • AI 系統整合應採分層架構，讓 API、RAG、Workflow Engine 與 ERP 各司其職。
  • AI Agent 與 AI數位員工必須有清楚的權限、停止條件、責任人與稽核紀錄。
  • 正式營運要持續追蹤模型漂移、每筆成本、人工介入率與端到端商業效益。

若您正評估文件處理、企業知識庫聊天機器人、AI ERP 或客服流程，建議先選定一個可在短期驗證的流程，盤點其資料來源、人工處理時間、錯誤類型與核准權限。將這些基準整理成 PoC 需求，再與業務、資訊、資安及財務共同定義 Go／No-Go 條件，才能讓 AI 投資從展示走向可持續的營運成果。

常見問題 FAQ

Q1. AI流程自動化一定要從 AI Agent 開始嗎？

不需要。大多數企業更適合先從有固定步驟的 AI工作流程開始，例如文件擷取、案件分類、知識檢索或草稿生成。當資料、權限、例外處理與監控機制穩定後，再讓 AI Agent 使用受限工具執行多步任務，成功率通常更高。

Q2. AI ERP 導入時，哪些工作不應直接交給模型？

付款、刪除資料、總帳過帳、主檔異動、信用額度調整及對外承諾等高風險動作，不應由模型直接執行。較安全的做法是讓 AI 擷取資料、提出建議或建立草稿，再透過 ERP 原有的權限、核准與稽核流程完成最終動作。

Q3. 如何判斷 AI PoC 是否成功？

請同時檢查模型品質、營運效益與使用者採用度。常用指標包括關鍵欄位正確率、人工介入率、端到端處理時間、每筆成本、錯誤率與現場覆核者的接受度。模型準確度是重要指標，但最終應判斷是否改善了實際營運成果。

Q4. MCP協定可以直接安全地連接企業內部系統嗎？

不可以直接假設安全。MCP協定能標準化模型存取工具與資源的方式，但企業仍需驗證每個 Server 的身分傳遞、資料範圍、函數權限、稽核紀錄與網路邊界。尤其涉及 ERP 寫入或個資時，仍須採最小權限與人工核准。

Q5. 可參考哪些可信來源來建立治理與導入策略？

可參考 McKinsey 的生成式 AI 調查與營運研究：https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai；NIST AI Risk Management Framework：https://www.nist.gov/itl/ai-risk-management-framework；OWASP 的 LLM 應用安全指引：https://owasp.org/www-project-top-10-for-large-language-model-applications/；以及 Salesforce 的 Agentforce 資源：https://www.salesforce.com/agentforce/。



返回部落格列表