學習路線圖 · AI 產品主線
階段 3 No/Low-code
把 AI 接進工作流程，做到自動產出、通知、歸檔與追蹤。
觀念教學
不寫程式也能把 AI 接進日常營運:這一階段 AI 產品人要用 No/Low-code 平台,讓流程自動產出、通知、歸檔、追蹤。
這一階段學什麼
- 自動化平台(Zapier/Make/n8n):用「觸發、條件、動作」組裝流程;例如 AI 判定客戶訊息是退費意圖、且金額超過門檻,就自動通知主管 — 靠的是條件判斷元件。
- Webhook:事件發生時,由來源系統主動推送資料到指定網址、對方即時回應 — 與定時輪詢相反,是事件驅動自動化的神經。
- 整合能力評估:選平台先看能不能串你的 ERP、倉儲、通知系統 — 標準 API 與連接器的完整度,比介面美觀重要得多。
- 供應商鎖定(Vendor Lock-in):資料用專有格式儲存、匯出受限、又沒有標準 API 的封閉平台,長期會讓轉換成本高到走不了。
為什麼是現在學
階段 2 的提示詞讓 AI 會做事,這一階段讓它「自動地做」:文件一進來就處理、結果自動歸檔通知。對資訊人力有限、不具自行開發能力的企業,這是導入 AI 最快的路 — 之後的 RAG 與 Agent,也都掛在這些流程上。
怎麼練(具體行動)
- 做一條自動文件處理流程:收到文件、AI 摘要分類、存雲端硬碟、通知群組。
- 加入條件分支:高金額或高風險案件,改走人工審核路線。
- 用 Webhook 串接兩個系統,體會「事件驅動」與「定時輪詢」的差別。
- 寫一頁平台選型筆記:整合能力、匯出自由度、鎖定風險。
完成標準
- 一條含 AI 步驟、條件分支與通知的自動化流程,穩定跑滿一週。
- 能依整合需求、人力與鎖定風險,替一個情境選出合理平台並說明理由。
⚠️ 常見誤區:只看功能酷炫、不看資料出得來出不去 — 被封閉平台鎖死才是最貴的成本。
iPAS 情境題常從這裡出:條件觸發元件、Webhook 的運作邏輯、封閉平台的長期風險與整合選型。
📝 本節掛載 6 題 iPAS 歷屆試題 — 讀完往下到「iPAS 考題練習」直接實戰。
里程碑
✓ 完成自動化流程
範例專題
自動文件處理流程
應用場景
iPAS 歷屆考題詳解(6 題)
先自行作答,再展開詳解。題目出處均為 iPAS AI 應用規劃師正式考題,著作權屬原主辦單位。
某客服主管希望在Low-Code 平台中設定自動化流程：當客戶訊息被AI 判定為「退費意圖」，且退費金額大於10,000 元時，即自動發送緊急通知給主管。此需求最可能透過下列哪一種元件實現？
- A條件分支（Branching / Router），依據多重條件判斷流程走向；
- B資料格式化（Formatter），用於整理與轉換流程中的資料格式；
- C迭代／迴圈（Iterator），逐筆處理多筆資料並依序執行流程；
- D陣列聚合器（Array Aggregator），將多筆資料整合後再進行後續處理
看正解與逐選項詳解
正解:A
正確答案:(A)
【正解解析】
題幹需求是「當客戶訊息被判定為退費意圖,且退費金額大於 10,000 元時,自動發送緊急通知」,這是典型的多重條件判斷與流程分流:兩個條件同時成立才走通知路徑,否則走其他路徑。在 Low-Code 自動化平台中,這正是條件分支(Branching / Router)元件的用途:依據條件運算的結果決定流程接下來執行哪一條路徑,故 (A) 正確。
【為何其他選項錯了?】
- (B):資料格式化(Formatter)用於整理與轉換資料格式,例如日期、文字、數字格式的處理,不具備依條件決定流程走向的功能。
- (C):迭代(Iterator)用於逐筆處理多筆資料,重點在對每筆資料重複執行相同步驟,不是條件判斷與路徑分流的元件。
- (D):陣列聚合器(Array Aggregator)把多筆資料整合為一組後再進行後續處理,屬資料彙整功能,與多重條件的流程判斷無關。
提示:題幹句型「當某些條件成立時,執行某動作」對應條件分支;格式化、迭代、聚合皆是資料處理元件。
一家連鎖零售業者使用某封閉式No-Code 平台多年，將客戶資料、訂單流程與內部作業高度整合於該平台。近期業者進行系統盤點時發現，該平台資料採專有格式儲存，匯出功能有限，且未提供標準API 支援。在此情境下，長期而言，該企業最可能面臨下列何種風險？
- A員工需具備撰寫進階程式語法的能力，才能持續使用該平台進行系統操作；
- B隨著系統使用時間增加，平台運算效能將逐漸下降，影響營運效率；
- C系統運作過程中較容易發生資安漏洞，導致資料外洩風險提高；
- D企業在未來更換系統時，將因資料與功能難以轉移而高度依賴原平台
看正解與逐選項詳解
正解:D
正確答案:(D)
【正解解析】
題幹的三個線索:資料採專有格式儲存、匯出功能有限、未提供標準 API。這代表資料與功能都難以搬移到其他系統,未來若要更換平台,將面臨資料轉出困難、流程重建成本高昂的處境,只能持續依賴原平台,即供應商鎖定(Vendor Lock-in)風險;長期而言,企業的議價能力下降、轉換成本持續累積,故 (D) 正確。
【為何其他選項錯了?】
- (A):No-Code 平台的定位就是降低程式撰寫門檻,持續使用該平台不需要進階程式能力;此敘述與 No-Code 的本質相反。
- (B):使用時間增加不必然導致平台運算效能下降;效能表現取決於平台架構與資源配置,題幹也沒有相關線索。
- (C):資安漏洞屬另一類風險議題;題幹描述的專有格式、匯出受限與缺乏 API,指向的是資料可攜性與轉移性問題,而非資安弱點。
提示:專有格式、匯出受限、無標準 API 三個線索同時出現,即指向供應商鎖定(Vendor Lock-in)。
某物流公司評估導入No-Code／Low-Code 平台，希望能與現有的ERP 系統、倉儲管理系統及客戶通知平台進行資料串接。若主要考量系統整合能力，而非介面美觀度或功能豐富性，下列哪一項平台特性最能滿足此整合需求？
- A平台是否提供強制將所有應用程式部署於地端伺服器的選項，以確保資料不外流；
- B平台是否具備豐富的API 介接能力、Webhooks 機制與開放式架構，能順暢串接既有系統；
- C平台是否內建將圖形化流程還原為原始程式碼的編譯工具，以便未來自行維護；
- D平台是否採用封閉式架構設計，以降低外部系統整合所帶來的安全風險
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
題幹的主要考量是系統整合能力:平台需與 ERP、倉儲管理系統及客戶通知平台進行資料串接。評估重點在平台是否具備豐富的 API 介接能力、Webhook 機制與開放式架構:API 讓平台能呼叫既有系統,也能被外部系統呼叫;Webhook 讓事件發生時即時觸發後續流程;開放式架構則確保與異質系統的相容性。(B) 直接對應整合需求,故正確。
【為何其他選項錯了?】
- (A):地端部署屬資料安全與合規的考量,與平台能否順利串接 ERP、倉儲與通知系統是不同層面的問題,無助於判斷整合能力。
- (C):將圖形化流程還原為原始程式碼,關乎未來自行維護與遷移彈性,不是與既有系統串接資料的關鍵特性。
- (D):封閉式架構限制外部系統的介接方式,與題幹的整合需求方向相反;以封閉換取安全,犧牲的正是串接能力。
提示:整合能力題的評估關鍵字:API、Webhook、Connector 與開放式架構。
在自動化工作流程中，Webhook 是一種由事件觸發、系統會主動回應的機制，請問下列何者最符合此運作邏輯？
- A你在訂位平台設定「開放提醒」，系統每隔10 分鐘會自動幫你重新查詢各餐廳空位狀況，若有變動再通知你；
- B餐廳將每日訂位與候位資料整理至公開看板，你可以隨時打開查看最新狀態；
- C你在餐廳留下聯絡方式並設定偏好條件，當有符合條件的空位釋出時，餐廳會依照事先約定方式直接將資訊傳送給你；
- D你加入餐廳的會員系統，餐廳會定期寄送電子報，內容包含近期優惠與部分訂位統計資訊
看正解與逐選項詳解
正解:C
正確答案:(C)
【正解解析】
Webhook 的運作邏輯:接收端事先向來源系統登記約定(接收方式與觸發條件),當事件發生時,由來源系統主動把資訊推送給接收端,接收端不需反覆查詢。選項 (C) 中,顧客事先留下聯絡方式與偏好條件(等同註冊接收方式與條件),符合條件的空位釋出(事件發生)時,餐廳依約定方式主動傳送資訊(主動推送),完整對應事件觸發與主動回應的機制,故正確。
【為何其他選項錯了?】
- (A):系統每隔 10 分鐘自動重新查詢屬於輪詢(Polling)機制,是接收端定期主動查詢,不是事件發生時由來源系統主動推送。
- (B):公開看板由使用者自行查看最新狀態,屬被動查閱,沒有事件觸發後主動傳送資料的機制。
- (D):定期寄送電子報屬排程推播,發送時間由排程決定,內容並非由特定事件即時觸發,不符 Webhook 的事件驅動特性。
提示:Webhook 是「事件發生,系統主動通知」;每隔固定時間去查詢的是輪詢,兩者方向相反。
某紡織品製造公司需建立品質控制流程：當AI 系統檢測到瑕疵產品時，自動通知品管人員、更新庫存系統，並生成品質報告。公司資訊人力僅兩人，主要負責系統維運，且不具備自行開發能力，若希望在不導入大型企業系統的情況下，快速完成流程建置，下列何者最適合？
- A使用No-Code 工具串接AI 檢測、通知與報表功能，快速建立自動化流程；
- B委託外部專業團隊，依公司需求客製化所有功能模組後再上線使用；
- C導入具流程自動化功能的SaaS 平台，並進行系統整合與客製化設定；
- D使用試算表與簡易腳本輔助記錄與通知，逐步優化現有人工流程
看正解與逐選項詳解
正解:A
正確答案:(A)
【正解解析】
題幹的限制條件:資訊人力僅兩人且主要負責維運、不具自行開發能力、不導入大型企業系統、希望快速完成流程建置。需求則是把 AI 檢測結果串接通知、庫存更新與報告產生。No-Code 工具以視覺化設定串接各項服務,技術門檻低、建置速度快,兩人團隊即可維護,最符合限制與需求的組合,故 (A) 正確。
【為何其他選項錯了?】
- (B):委外客製化所有功能模組的成本高、時程長,與「快速完成、不導入大型系統」的前提不符;後續修改與擴充也將持續依賴外部團隊。
- (C):導入 SaaS 平台後仍需進行系統整合與客製化設定,整合工作量與技術門檻超出兩人維運團隊的負荷,建置時程也較長。
- (D):試算表與簡易腳本難以穩定串接 AI 檢測、自動通知、庫存更新與報告生成的完整流程,仍高度依賴人工,不符合自動化目標。
提示:小團隊、低開發能力、要求快速建置自動化流程,是 No-Code 工具的典型適用情境。
某家企業希望開發股票交易輔助工具，要求該工具需要在接收到市場報價資料的50 毫秒內完成訊號判斷與下單指令，且每秒需處理超過一萬筆高併發交易。若選用Low-Code 平台開發，最難克服的先天限制為何？
- ALow-Code 平台無法串接任何金融市場的外部API，因此無法獲取即時報價資料；
- BLow-Code 平台無法串接任何券商平台的下單API，因此無法進行即時交易；
- CLow-Code 底層封裝通用框架，在毫秒級延遲與超高吞吐量（Throughput）的極限效能場景中，難以進行深度底層優化；
- DLow-Code 平台無法建立即時更新的使用者介面，無法顯示動態報價資訊
看正解與逐選項詳解
正解:C
正確答案:(C)
【正解解析】
題幹要求在 50 毫秒內完成訊號判斷與下單,且每秒處理超過一萬筆高併發交易,屬極低延遲、超高吞吐量(Throughput)的極限效能場景。Low-Code 平台的先天特性是以通用框架封裝底層,開發者難以深入控制記憶體管理、執行緒模型、網路傳輸等底層細節;封裝帶來的額外開銷與不可調校性,使其難以進行毫秒級延遲與高吞吐所需的深度底層優化,這是架構層面的先天限制,故 (C) 正確。
【為何其他選項錯了?】
- (A):Low-Code 平台普遍支援外部 API 串接,取得即時報價在技術上可行;「無法串接任何金融市場 API」的絕對化敘述不符事實,也非先天限制所在。
- (B):串接券商下單 API 同樣屬一般整合能力,多數平台可以做到;問題不在能否串接,而在極限效能的優化空間。
- (D):即時更新的使用者介面是 Low-Code 平台的常見功能;且本題瓶頸在交易判斷與下單的延遲與吞吐,不在報價顯示。
提示:Low-Code 的先天限制在底層封裝造成的效能上限;宣稱「完全無法串接」的絕對化敘述多半可排除。