WHAT_IS
AI 流程自動化到底在做什麼？
把公司裡「每天重複、規則固定」的那幾段工作，交給程式跑完，人只負責需要判斷的部分。不換掉任何一套現有系統。
- 現在是這樣有人每天從 A 系統匯出、整理成 B 系統要的格式、再貼回去。月底還要打開三個地方才湊得出一張報表。
- 做完之後資料自己搬、報表自己產、對不起來的時候主動通知人。
- 判斷還是留給人核價、議價、人事這類決定不交給模型。程式只負責把資料整理好放到人面前。
WHAT_WE_DID
n8n 導入與 RPA 流程自動化做得出什麼？
四塊承接範圍。前兩塊的交付物在平台後台，後兩塊有程式碼可以佐證。
- 一、n8n 導入與自架維運。 節點圖與觸發條件設計、憑證與環境變數管理、錯誤分支與重試策略、流程版本備份。自架（Docker，開在你的雲端專案）或雲端版都可以，差別在資料落點與維運責任由誰扛。
- 二、Dify 企業導入與知識庫問答。 知識庫的切分與更新方式、提示詞版本管理、可回答與不可回答的邊界、回覆附引用來源、API 金鑰與用量控管。
- 三、RPA 流程自動化：沒有 API 的系統也接得起來。 我們長期用 Playwright 與 Puppeteer 在寫，其中多視窗網頁自動化排程系統是我們自己的工具，Docker 部署、失敗自動重試並列出失敗清單。任務分派到多個相互獨立的瀏覽器情境並發執行，各自持有自己的 cookie，一個任務失敗不會拖垮其他任務。
- 四、報表自動化與流程異常通知。 報表定時產出、對帳規則設計，以及通知要推給誰、推到哪、什麼情況要升級。完成與失敗分開列、失敗原因可追。異常要推到人每天會看的地方，LINE 端的推播與權限作法見 LINE 串接系統開發。
- 讓 AI 唯讀查公司資料。 MCP 串接內部資料是我們自己一直在用的東西。AI 不生成 SQL，只能呼叫伺服器端寫死的查詢工具，資料範圍與可回傳欄位都固定；查詢走唯讀 VIEW 讀唯讀副庫，ERP 主庫全程零接觸，每一次查詢留稽核紀錄。架構取捨寫在案例頁 讓員工用 ChatGPT 安全查詢 ERP。
判斷標準只有一條：能用條件判斷解決的，不放 LLM。模型只用在非結構化的地方——讀信件內容、分類客訴、整理自由文字。
PRICING
費用怎麼算？
- 分兩階段報價。 初步判讀不收費；第一階段是顧問諮詢，單列：盤點流程、挑出適合交給 AI 的步驟、試算效益，交付的流程文件與需求單歸你所有，不往下做也是你的。第二階段才報導入價：不按人頭算月費，一條流程一個價，做完看得到結果再談下一條。實際金額依需求評估。
- 最大的變因是對方系統有沒有 API。 有 API 就是串接；沒有 API 要走瀏覽器自動化，對方畫面改版還得維護。
其他影響價格的因素：
- 步驟數與分支五個步驟走一條路，跟五個步驟每步都有例外，是兩件事
- 例外處理的嚴格程度允許失敗後整批重跑，跟必須每一筆核對，工差很多
- AI 用在哪裡純條件判斷最省，需要讀非結構化內容才動用 LLM，這部分上線後還有持續的 API 用量成本
- 跑在哪裡自架 n8n 要主機與更新維護，雲端版省維運但有訂閱
- 要不要長期維運上線後誰看失敗通知、誰處理平台改版
平台費用（n8n 雲端版、LLM API、Google Cloud）直接開在你的帳號，我們不經手、不加成。
不報價的兩種情況：需求只有一句「想導入 AI」，或希望我們先承諾能省下多少工時。
PROCESS
怎麼進行？要多久？
一次只做一條流程，跑得起來再擴大。
- 流程盤點與效益試算（顧問諮詢）講清楚這條流程現在誰做、一天做幾次、資料從哪來到哪去、哪一步最常出錯；挑出適合交給 AI 的步驟、試算效益，流程沒講清楚的先陪你寫成 SOP。
- 定成功條件什麼叫跑成功、什麼叫失敗、失敗要通知誰。例外狀況在這一步列完，不留到上線才處理。
- 建流程串接、寫腳本或設定節點，全部開在你的帳號下。
- 雙軌比對自動化與人工同時跑一段時間，逐筆比對結果。差異都解釋得出來，才停掉人工。
- 上線與移交節點圖、環境變數、錯誤處理邏輯與操作說明一起交，人員換手時看得懂。
時程取決於三件事：對方系統有沒有 API、例外狀況有幾種、結果要不要人工覆核。正式時程等盤點完成才給得準，我們會連同流程圖一起給，你再決定要不要做。
WHO_FITS
誰適合做 AI 流程自動化？
符合任一條就可以先試跑一條流程。
- 有人每天在兩套系統之間搬資料的公司從 A 匯出、整理成 B 要的格式、再貼回去。步驟固定、每天重複。
- 報表靠人工拼出來的團隊月底對帳、日報表、庫存異動彙整，資料都在系統裡，但要有人打開三個地方才湊得出一張表。報表自動化通常是最好的起點。
- 異常事後才發現的企業訂單卡住、庫存低於水位、對帳金額不符。流程異常通知要做的就是把這件事提前。
- 已經在 Google Workspace 上跑流程的公司表單、試算表、雲端硬碟、Gmail 之間的串接接得起來，不必再買一套工具。
前提是講得出每一步在做什麼；講不出來的，先在顧問諮詢寫成 SOP——直接自動化只會讓混亂跑得更快。
NOT_FOR_YOU
誰不適合？
這幾種情況我們會直接說不做，或建議你先做別的事。
OWNERSHIP
帳號與資料歸誰？
全部開在你的帳號下，結案移交，不留在我們手上。我們自己的存取權限在結案後撤掉，你也可以隨時撤。
| 項目 | 開在誰的帳號 |
|---|---|
| n8n 主機或雲端版 | 你的雲端專案／你的帳號 |
| Dify 專案與知識庫 | 你的帳號 |
| LLM API 金鑰 | 你的帳號，用量帳單你自己看得到 |
| Google Cloud／Google Workspace | 你的組織 |
| 自動化腳本與流程設定原始碼 | 交付給你，含 Git 紀錄 |
資料面三條紅線：AI 查詢一律唯讀（需要寫入的動作走人工確認）、每一次查詢留稽核（誰在什麼時候問了什麼，查得到）、權限最小化（白名單決定誰能用、視圖決定看得到哪些欄位）。網路層的控管作法見企業雲端建置與資安防護。
START
要從哪裡開始？
先做一件你今天就做得到的事：挑一條你覺得最煩的流程，把現在的做法錄一段螢幕、或拍幾張截圖給我們，順便講一天做幾次。
我們會回你一份判讀：這條流程值不值得自動化、卡在哪一步、需要先補什麼、大概分成幾個階段。這一步不收費，也不需要你先整理好規格；往下做才進入顧問諮詢。
EVIDENCE
這一頁的說法，去哪裡查證？
- MCP 是公開協定，不是我們發明的名詞規格由 Model Context Protocol 維護，目前版本為 2026-07-28。規格本身就寫明「工具等同任意程式執行，必須謹慎對待」——我們把查詢工具的範圍寫死在伺服器端，依據在這裡。
- 權限設計為什麼排第一OWASP 的 Top 10:2025（範圍是網頁應用程式，不是 AI 專屬清單）把權限控制失效列為第一名。自動化流程拿到的憑證通常權限過大，所以我們把「這條流程需要哪些權限」當成設計題，不是設定題。
- n8n 與 Dify 的能力邊界看官方文件節點與觸發器見 n8n 文件，知識庫與應用編排見 Dify 文件。我們承接的是設計與維運，不是重寫這兩套工具。