學習路線圖 · AI應用規劃師初級
階段 4 No/Low-Code
學習No/Low Code概念、優勢與限制；練習常見工具（Bubble/Adalo/Airtable）建立簡單應用。
觀念教學
不寫程式也能交付應用:階段 4 練的是用 No-Code 與 Low-Code 平台,快速把想法變成能操作的原型 — 規劃師展示概念的最快武器。
這一階段學什麼
- 概念與差異:No-Code 全圖形化拖拉、Low-Code 可少量寫程式擴充;共同點是把開發交給平台元件
- 優勢與限制:快速、低門檻、業務人員能參與;代價是客製彈性受限、依賴平台、複雜邏輯難處理
- 平台裡的「模型(Model)」:在 Low-Code 語境多指資料模型 — 定義欄位、型態與關聯的資料結構,不是機器學習模型
- 常見工具:Airtable 管資料、Bubble 建網頁應用、Adalo 做行動 App
- 可測試性與整合:跨部門流程與外部服務串接時,模組化設計與清楚的介面約定,讓系統可測、可維護
為什麼是現在學
前三階段都在建觀念,這是路線第一個「動手交付」的階段。它也直接銜接階段 5:No/Low-Code 快速生成介面,搭配生成式 AI 自動產出內容與素材,正是快速原型的黃金組合,也是科目二喜歡的整合情境題。
怎麼練(具體行動)
- 用 Airtable 建一個小型資料庫:設計欄位、型態與表間關聯,親手體會「資料模型」是什麼
- 用 Bubble 或 Adalo 做一個簡單應用原型:表單輸入、資料儲存、清單展示
- 替原型串一個外部服務或自動化流程,記錄哪些環節需要測試、怎麼測
- 寫一頁選型筆記:什麼需求適合 No/Low-Code、什麼情況該回頭找工程師開發
完成標準
- 用 No/Low-Code 工具建出一個能操作的簡單應用(呼應里程碑:建立簡單 AI 應用)
- 能說出 No-Code 與 Low-Code 的差異,以及各兩點優勢與限制
- 能解釋平台中「模型」指資料結構定義,並說明如何維持應用的可測試性
⚠️ 常見誤區:把 Low-Code 的「模型」當成 AI 模型 — 它是資料結構的定義,這是科目二的經典陷阱選項。
這一階段對應科目二「生成式AI應用與規劃」的工具應用題,快速原型力也是規劃師簡報時的殺手鐧。
📝 本節掛載 3 題 iPAS 歷屆試題 — 讀完往下到「iPAS 考題練習」直接實戰。
里程碑
✓ 建立簡單 AI 應用
範例專題
No-code 專案原型
應用場景
iPAS 歷屆考題詳解(3 題)
先自行作答,再展開詳解。題目出處均為 iPAS AI 應用規劃師正式考題,著作權屬原主辦單位。
在 Low Code 平台的開發應用設計中，關於「模型（Model）」，下列敘述何者最符合實際情況？
- A模型僅扮演設計視覺化的輔助工具，對應用邏輯的影響有限
- B模型是用來抽象描述資料結構、業務流程與介面邏輯的核心元素，影響應用的設計與維護
- C模型僅依循 UML（Unified Modeling Language）等傳統建模方式，缺乏針對 Low Code 環境的延展性
- D模型在 Low Code 平台中已被自動程式碼生成全面取代，實際價值有限
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
在 Low-Code 平台的模型驅動開發(Model-Driven Development)概念中,模型(Model)是對資料結構、業務流程與介面邏輯的抽象描述,平台依據模型自動產生或組裝實際應用。模型是應用的核心藍圖:修改模型會連動影響資料庫結構、業務邏輯、前端綁定與權限設定,因此直接決定應用的設計品質與長期維護成本。(B) 正確描述模型的核心地位。
【為何其他選項錯了?】
- (A):模型不是視覺化的輔助工具;在 Low-Code 平台中,應用邏輯與資料結構正是由模型定義而來,模型變更會直接改變應用行為,影響絕非有限。
- (C):Low-Code 平台的模型並不限於 UML 等傳統建模語言;多數平台已將表單流程、狀態機、權限規則、計算欄位等納入模型體系,是針對 Low-Code 環境擴充後的設計,並非缺乏延展性。
- (D):自動程式碼生成是「依模型產出程式」的機制,模型是生成的輸入依據而非被取代的對象;沒有模型,程式碼生成便失去來源。
提示:Low-Code 題看到「模型」,對應「抽象描述資料、流程與介面,並驅動生成與維護」的核心元素定位。
某企業利用 No Code/Low Code 平台開發內部營運系統。為確保系統在跨部門流程與外部服務整合下仍具良好的可測試性（Testability），下列哪一項作法最為合適？
- A依賴 No Code/Low Code 平台提供的即時預覽與基本單元測試功能，快速驗證常見流程
- B導入可重複執行的自動化測試流程，並透過 API 或服務虛擬化進行模組化驗證
- C將測試聚焦於使用者介面互動與操作流程驗證，檢查系統表面功能
- D依靠使用者回饋與正式上線後的監控資料，作為修正依據
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
題幹要求在跨部門流程與外部服務整合下確保可測試性(Testability),關鍵有二:測試必須可重複執行,外部依賴必須可被隔離。導入自動化測試流程,讓回歸測試能在流程修改後反覆執行(常見工具如 Playwright、Robot Framework、Postman/Newman);並透過 API 層驗證與服務虛擬化(Service Virtualization,如 WireMock 等以模擬服務替代真實外部系統)進行模組化驗證,即使外部服務不穩定或尚未就緒,整合邏輯仍能穩定測試。(B) 同時滿足可重複性與依賴隔離,最符合題意。
【為何其他選項錯了?】
- (A):即時預覽與基本單元測試只能驗證單一畫面與常見流程,無法涵蓋外部 API 逾時、權限衝突、資料一致性等跨系統整合問題,不足以支撐整體可測試性。
- (C):僅聚焦使用者介面與操作流程屬表面功能驗證;業務邏輯與資料完整性在 UI 測試中難以覆蓋,整合缺陷容易漏檢。
- (D):依賴上線後的使用者回饋與監控屬事後補救,問題已流入正式環境才被發現,與「確保可測試性」的事前設計目的相違。
提示:可測試性題抓兩個關鍵:測試可重複自動執行、外部依賴可虛擬化隔離。
某設計團隊要在短時間內完成行動應用程式，需兼顧高度個人化體驗、快速生成介面與行銷內容自動產出。結合 No Code/Low Code 與生成式 AI，下列哪一種整合策略最符合目標？
- A使用生成式 AI 自動產生 API 呼叫與元件配置，並由開發者手動整合至 No Code 平台流程
- B透過生成式 AI 在 No Code 平台中自動建立介面模板，並結合使用者數據即時生成個人化功能與行銷推播內容
- C在 No Code 平台中導入生成式 AI，快速建立跨專案可重用的通用模組，專注於提升開發速度
- D在 No Code 平台中完全依賴生成式 AI 自動產生所有應用功能與流程，不經人工設計或驗證
看正解與逐選項詳解
正解:B
正確答案:(B)
【正解解析】
題幹目標有三:高度個人化體驗、快速生成介面、行銷內容自動產出,且須在短時間內完成。(B) 的策略讓生成式 AI 直接在 No-Code 平台內自動建立介面模板,加速介面開發;同時結合使用者數據即時生成個人化功能與行銷推播內容,三項目標在同一流程中全數對應,並保留 No-Code 平台快速部署的優勢,是最符合題意的整合策略。
【為何其他選項錯了?】
- (A):由 AI 產生 API 呼叫與元件配置後,再由開發者手動整合,整合工作回到人工,拖慢時程;且此策略未處理個人化體驗與行銷內容產出,目標覆蓋不完整。
- (C):建立跨專案可重用的通用模組著眼於開發速度與重用性,通用化的方向與「高度個人化體驗」相反,也未涵蓋行銷內容自動產出。
- (D):完全依賴 AI 自動產生所有功能與流程且不經人工設計與驗證,生成品質無從把關,錯誤功能與不當內容可能直接上線,不是可行的整合策略。
提示:先列出題幹的全部目標,再檢查選項是否全數覆蓋;只滿足單一目標或省略人工驗證的選項應排除。