---
title: "低程式碼（Low Code）"
slug: low-code
language: zh-TW
source: https://aiterms.tw/terms/low-code
updated_at: 2026-04-29
tags: [AI應用, AutoML, Python程式]
ipas_term: true
---

# 低程式碼（Low Code）

> **你有沒有看過同事不是工程師，卻也能做出一個可用的系統？**
> 你可以把低程式碼想成，用拖拉元件和少量程式碼拼出應用。
> 它其實就是把很多重複開發工作變成可視化流程。
> 這樣可以更快做原型，也讓公民開發者有機會參與。
>
>
> 你可以把它想成一個把抽象概念拉回日常判斷的提示，先知道它解決什麼問題，再看技術細節。

### 容易混淆
> **低程式碼 vs No Code**
> 低程式碼還能寫一點程式補強，No Code 則希望幾乎不用寫。
> 一個留給工程補洞，一個更偏完全拖拉。
>
> **低程式碼 vs 傳統開發**
> 傳統開發自由度最高，低程式碼換來的是速度和標準化。
> 一個重控制，一個重效率。
>
> **最關鍵的區別：** 低程式碼還保留一點手寫能力。
>
### 記住這句就好
> 少寫一點，先把能跑的系統做出來。
>
### 實際案例
> **內部表單流程**
> 人資想快速做請假審批流程，低程式碼平台可以先把版本跑起來。
>
> **產品原型驗證**
> 新功能還沒正式開發前，團隊先用低程式碼拼出流程驗證需求。
>
### 深入了解
> 低程式碼的價值在於縮短交付時間，讓流程、資料和權限更快串起來。
> 它適合需求清楚、變動頻率不高、又想快速上線的場景。
> 如果遇到複雜商業邏輯或高度客製化需求，還是要靠工程能力補上。
>
### 情境判斷
> **Q1（直覺題）： 部門想在兩週內做出可用的審批流程，該優先考慮什麼？**
>
> → 低程式碼很合適，因為它能快速拼出可用原型。
>
> **Q2（判斷題）： 低程式碼可以完全取代工程師嗎？**
>
> → 不一定，複雜整合、性能和維護仍然需要工程能力。
>
### iPAS 考題
> **Q：低程式碼最常被拿來解決什麼問題？**
> 快速建立可用應用，減少重複開發和跨部門協作成本。
>
> **Q：低程式碼和 No Code 的差別是什麼？**
> 低程式碼允許少量編寫程式，No Code 則更偏向完全視覺化組裝。
>
### 常見問題
> **Q：低程式碼適合哪些人？**
> 適合要快速交付流程應用的人，也適合懂一點技術、想自己做工具的團隊。
>
> **Q：低程式碼會不會限制客製化？**
> 會，尤其是複雜流程和特殊整合時，平台能力可能不夠。
>
> **Q：低程式碼適合正式產品嗎？**
> 看情況，簡單內部工具很適合，核心產品則要評估可擴充性。
>
### 相關術語
> - **公民開發者**：這類工具最常幫到的就是非工程背景的人。
> - **No Code**：先看它，就知道低程式碼還保留哪些彈性。
> - **API閘道**：需要串接外部服務時常會碰到。
> - **程式碼生成**：兩者都在減少手寫工作量，但方式不同。

---

來源：https://aiterms.tw/terms/low-code
快查頁：https://aiterms.tw/terms/low-code
外部參考：https://ipd.nat.gov.tw/ipas/certification/AIAP/news/ffdba0fcdbda40baadeef2a1bdc0230e
最後更新：2026/04/29
深度解說：https://aiterms.tw/learning/what-is-low-code