No-Code / Low-Code 工具比較

No-Code vs Low-Code vs Full-Code 定義

💡 比喻：蓋房子

• No-Code = 買現成的組合屋。你選款式、選顏色，工人幫你組裝。 你完全不用懂建築，但能客製化的程度有限。
• Low-Code = 半自建房。基礎結構有模板，但你可以改隔間、加陽台。 需要懂一點建築知識，但比從零蓋快很多。
• Full-Code = 完全自建房。從打地基開始，一磚一瓦自己來。 可以蓋任何你想要的，但需要完整的建築知識和時間。

三者的差異

特性            No-Code         Low-Code         Full-Code
──────────────────────────────────────────────────────────────
需要寫程式嗎？  完全不用         少量             大量
學習門檻        極低             中等             高
客製化程度      低               中高             完全自由
開發速度        最快             快               慢
維護成本        低               中               高
效能控制        有限             部分             完全
適合場景        簡單網站/MVP     企業應用         複雜系統
代表工具        Bubble, Webflow  Retool, PowerApps ASP.NET, React

你該選哪一種？

問自己三個問題：                                       # 簡單的決策流程

1. 你的需求複雜嗎？
   簡單（Landing Page、表單）→ No-Code               # 用最簡單的工具
   中等（會員系統、後台管理）→ Low-Code               # 需要一些程式邏輯
   複雜（金流、即時通訊、大量數據）→ Full-Code        # 需要完全控制

2. 你有多少時間？
   一天內完成 → No-Code                              # 最快上線
   一週內完成 → Low-Code                             # 有時間微調
   一個月以上 → Full-Code                            # 精雕細琢

3. 你的預算是？
   免費或很低 → No-Code（有免費方案）                 # 省錢
   中等 → Low-Code（部分需要付費）                    # 合理投資
   有預算 → Full-Code（可能需要雲端主機）              # 完全控制

常見工具比較

No-Code 工具

1. Bubble

定位：No-Code 網頁應用開發平台                        # 可以做完整的 Web App
優點：
- 不用寫任何程式碼                                    # 真正的零程式碼
- 拖拉式介面設計                                      # 像在用 PowerPoint
- 內建資料庫和使用者系統                                # 不用另外設定
- 可以做出複雜的邏輯流程                                # 視覺化邏輯編輯器

缺點：
- 效能有上限                                          # 大量使用者時會慢
- 離開平台很困難（vendor lock-in）                     # 搬家很痛苦
- 複雜邏輯用視覺化編輯器反而更麻煩                      # 有時寫程式比較快
- 付費方案較貴                                        # 商用需要升級

適合：MVP 驗證、小型商業應用、個人專案                   # 快速測試商業想法

2. Webflow

定位：No-Code 網站設計工具                             # 專注於視覺設計
優點：
- 設計自由度極高（接近手寫 CSS）                       # 設計師最愛
- 產生的 HTML/CSS 品質好                              # 效能不錯
- 內建 CMS（內容管理系統）                             # 可以管理文章
- SEO 友善                                           # 搜尋引擎優化

缺點：
- 不適合做複雜的後端邏輯                               # 主要是前端工具
- 動態功能有限                                        # 需要整合其他服務
- 學習曲線比其他 No-Code 工具稍高                      # 需要懂設計概念

適合：品牌官網、作品集、行銷 Landing Page                # 以設計為主的網站

Low-Code 工具

3. Retool

定位：Low-Code 內部工具開發平台                        # 做企業後台超快
優點：
- 快速建立管理後台                                     # 拖拉式介面
- 可以直接連接資料庫                                    # 支援 PostgreSQL、MySQL
- 支援 JavaScript 客製化                               # 需要時可以寫程式
- 內建大量元件（表格、圖表、表單）                       # 現成的 UI 組件

缺點：
- 主要做內部工具，不適合面向使用者                       # 不是做公開網站的
- 付費方案較貴                                         # 商用價格高
- 設計自由度有限                                       # 長得都差不多

適合：企業內部管理系統、資料看板、客服後台                # B2B 內部工具

4. Power Apps

定位：微軟的 Low-Code 開發平台                         # 微軟生態系整合
優點：
- 和 Microsoft 365 深度整合                            # 用 Excel 當資料庫
- 企業級安全性和權限管理                                # 大公司的首選
- 可以做手機 App                                      # 跨平台支援
- 有 Power Automate 自動化流程                         # 搭配自動化很強

缺點：
- 介面設計比較陽春                                     # 不太好看
- 效能有限制                                          # 大量數據時會慢
- 需要 Microsoft 365 授權                              # 要付費
- 學習曲線比想像中陡                                    # 功能太多反而複雜

適合：已經用 Microsoft 365 的企業                       # 善用現有工具

AI 輔助開發工具

💡 比喻：交通工具

• Copilot = 副駕駛。你在開車，它幫你看路、提建議。
• Cursor = 高級自動駕駛。大部分路段自動開，你偶爾接手。
• Claude Code = 專屬司機。你說目的地，它幫你開到。
• v0 = 計程車。你說要什麼，它直接載你到。

GitHub Copilot

定位：程式碼自動補全工具                               # 寫程式時即時建議
運作方式：你打字 → 它猜你要寫什麼 → 按 Tab 接受        # 像手機打字預測

優點：
- 深度整合在 VS Code / Visual Studio                   # 不用離開編輯器
- 即時補全，速度極快                                    # 打幾個字就能補完
- 支援幾乎所有程式語言                                 # 通用性高

缺點：
- 只能補全程式碼，不能執行指令                          # 不能跑 dotnet build
- 不能讀取整個專案結構                                  # 上下文有限
- 不能操作檔案系統或瀏覽器                              # 功能單一

適合：已經會寫程式，想要加速的開發者                     # 進階使用者

Cursor

定位：AI 驅動的程式碼編輯器                            # VS Code 的 AI 強化版
運作方式：在編輯器內和 AI 對話 → AI 直接改程式碼        # 聊天式開發

優點：
- 可以讀取整個專案結構                                  # 理解完整脈絡
- 可以直接修改多個檔案                                  # 批次修改
- 有內建的 AI Chat 和 Composer 功能                    # 多種互動方式
- 介面直覺，適合視覺型使用者                            # 圖形化介面

缺點：
- 不能執行終端機指令                                    # 不能跑 build
- 不能操作瀏覽器                                       # 不能預覽網站
- 免費版有使用限制                                     # 高頻使用需付費

適合：想要視覺化 AI 開發體驗的人                        # 介面友善

Claude Code

定位：CLI 版的 AI 全端開發工具                         # 功能最完整
運作方式：在終端機和 AI 對話 → AI 讀檔、改檔、跑指令    # 全自動化

優點：
- 可以讀寫檔案、執行指令、操作瀏覽器                    # 功能最全面
- MCP 擴充系統無限擴充                                  # 可以裝各種外掛
- CLAUDE.md 持久化記憶                                 # 跨 Session 記住規則
- Skills 和 Hooks 自動化                               # 自動化流程

缺點：
- 需要用終端機介面                                     # 沒有圖形化介面
- 需要 API Key（按使用量計費）                          # 不是免費的
- 對新手來說終端機可能不太習慣                           # 需要適應

適合：想要完全自動化開發流程的人                         # 追求效率的開發者

v0 (by Vercel)

定位：AI 生成前端 UI 的工具                            # 專注於畫面生成
運作方式：描述你要的畫面 → AI 生成 React 元件           # 一句話出畫面

優點：
- 專精於前端 UI 生成                                   # 畫面品質很高
- 生成的程式碼可以直接用                                # 複製貼上就能跑
- 支援 React / Next.js                                # 現代前端框架
- 有即時預覽功能                                       # 馬上看到結果

缺點：
- 只做前端，不做後端                                   # 需要自己處理後端
- 只支援 React 生態系                                  # 不支援 ASP.NET
- 免費版有使用次數限制                                  # 高頻使用需付費

適合：需要快速做出漂亮前端的人                          # 前端為主的專案

工具比較總表

工具          能讀專案  能改檔案  能跑指令  能看網頁  需要寫程式
─────────────────────────────────────────────────────────────
Copilot       部分     建議    ❌       ❌       ✅ 必須
Cursor        ✅      ✅     ❌       ❌       ✅ 部分
Claude Code   ✅      ✅     ✅       ✅       ❌ 可不用
v0            ❌      ❌     ❌       ✅ 預覽  ❌ 可不用

什麼時候該用 No-Code vs 寫程式

決策流程圖

你的需求是什麼？
│
├── 簡單的靜態網站（Landing Page、作品集）
│   └── → Webflow 或 No-Code 工具                     # 最快最省
│
├── 需要使用者登入、資料庫
│   ├── 資料量小、邏輯簡單
│   │   └── → Bubble 或 Low-Code                      # 夠用就好
│   └── 資料量大、邏輯複雜
│       └── → Full-Code（Claude Code 輔助）            # 需要完全控制
│
├── 企業內部工具
│   ├── 用 Microsoft 365 的公司
│   │   └── → Power Apps                              # 生態系整合
│   └── 其他
│       └── → Retool                                  # 快速建後台
│
└── 需要高效能、高客製化
    └── → Full-Code（Claude Code 輔助）                # 沒有替代方案

實際案例判斷

案例 1：個人部落格
→ No-Code（Webflow）                                  # 不用寫程式
理由：靜態內容，不需要複雜邏輯                          # 簡單需求用簡單工具

案例 2：小型電商（< 100 個商品）
→ No-Code（Shopify）                                  # 專門的電商工具
理由：金流和物流都有現成方案                             # 不用自己做

案例 3：客製化學習平台
→ Low-Code + AI（Claude Code）                        # 需要一些客製化
理由：需要自訂學習進度邏輯，但 UI 可以用模板              # 混合策略

案例 4：大型企業 ERP 系統
→ Full-Code                                           # 完全客製化
理由：複雜的業務邏輯、大量資料、高安全性需求              # 不能妥協

混合策略：No-Code 前端 + API 後端

💡 比喻：餐廳分工

• No-Code 前端 = 外場服務生。面對客人、點餐、送餐。 不需要會煮菜，只要會接待客人。
• API 後端 = 內場廚師。在廚房裡準備食材、烹飪。 不需要面對客人，專心把菜做好。
• 兩者透過「出菜口」（API）溝通。

混合架構圖

使用者（瀏覽器）
    │
    ▼
No-Code 前端（Webflow / Bubble）                      # 負責畫面和互動
    │
    │  透過 API 呼叫
    ▼
ASP.NET Core Web API 後端                             # 負責邏輯和資料
    │
    ▼
資料庫（PostgreSQL / SQLite）                          # 負責儲存資料

為什麼要混合？

純 No-Code 的限制：                                    # 簡單但有天花板
- 複雜的業務邏輯做不了                                  # 邏輯太複雜
- 資料處理效能不夠                                     # 資料量太大
- 安全性無法完全控制                                    # 無法自訂安全機制

純 Full-Code 的成本：                                  # 強大但花時間
- 前端 UI 要花很多時間                                  # 刻畫面很慢
- 設計能力要求高                                       # 不是每個人都會設計
- 維護成本高                                          # 什麼都要自己來

混合策略的優勢：                                       # 兩全其美
- 前端用 No-Code 快速做出漂亮畫面                       # 省時間
- 後端用 Full-Code 處理複雜邏輯                         # 有完全控制權
- 各自發揮所長                                        # 效率最高

實作範例

前端（Webflow）：                                      # 拖拉式設計
- 設計精美的課程列表頁面                                # 不用寫 HTML/CSS
- 表單送出時呼叫後端 API                               # 透過 Webflow 的整合功能

後端（ASP.NET Core Web API）：                         # Claude Code 輔助開發
- 課程 CRUD API                                       # 資料操作
- 使用者驗證                                          # 安全性
- 付款處理                                            # 複雜邏輯

// 後端 API Controller 範例
[ApiController]  // 標記為 API 控制器
[Route("api/[controller]")]  // 設定路由前綴
public class CoursesController : ControllerBase  // 課程 API 控制器
{
    private readonly AppDbContext _context;  // 資料庫上下文

    public CoursesController(AppDbContext context)  // 建構式注入
    {
        _context = context;  // 儲存資料庫上下文
    }

    [HttpGet]  // 處理 GET 請求
    public async Task<IActionResult> GetAll()  // 取得所有課程
    {
        var courses = await _context.Courses.ToListAsync();  // 從資料庫讀取所有課程
        return Ok(courses);  // 回傳 200 OK 和課程資料
    }

    [HttpGet("{id}")]  // 處理 GET /api/courses/{id} 請求
    public async Task<IActionResult> GetById(int id)  // 依 ID 取得課程
    {
        var course = await _context.Courses.FindAsync(id);  // 查找指定 ID 的課程
        if (course == null) return NotFound();  // 找不到就回傳 404
        return Ok(course);  // 找到就回傳課程資料
    }
}

未來趨勢：AI 時代的開發者角色

開發者角色的轉變

過去的開發者：                                         # 傳統模式
- 角色：打字員（把邏輯打成程式碼）                       # 重點在「寫」
- 技能：熟記語法、框架 API、設計模式                     # 記憶型技能
- 工作：8 小時有 6 小時在打字                           # 產出 = 打字速度

現在的開發者：                                         # 轉型中
- 角色：指揮官（告訴 AI 要做什麼）                       # 重點在「想」
- 技能：需求分析、系統設計、品質審核                     # 思考型技能
- 工作：8 小時有 6 小時在思考和審核                      # 產出 = 思考品質

未來的開發者：                                         # 趨勢預測
- 角色：架構師 + 品管                                   # 重點在「審」
- 技能：商業理解、使用者體驗、AI 協作                    # 綜合型技能
- 工作：定義需求、審核 AI 產出、確保品質                  # 產出 = 決策品質

不會被 AI 取代的技能

1. 商業邏輯理解                                        # AI 不懂你的商業模式
   "這個功能該不該做？值不值得投資？"                   # 需要商業判斷

2. 使用者體驗設計                                       # AI 不懂人的感受
   "使用者會怎麼用這個介面？哪裡會卡住？"               # 需要同理心

3. 系統架構決策                                        # AI 不知道你的限制
   "用 Microservice 還是 Monolith？"                  # 需要經驗和判斷

4. 安全性思維                                          # AI 可能忽略安全漏洞
   "這個 API 有沒有被攻擊的風險？"                     # 需要安全意識

5. 程式碼審查能力                                      # AI 寫的不一定對
   "這段程式碼有沒有隱藏的 bug？"                      # 需要批判性思維

6. 溝通和團隊協作                                      # AI 不能取代人際互動
   "如何和設計師、PM 溝通需求？"                       # 需要軟實力

給初學者的建議

1. 不要害怕 AI 取代你                                  # AI 是工具，不是對手
   → AI 取代的是「打字」，不是「思考」                   # 你的價值在腦袋

2. 基礎還是要學                                        # 不能完全依賴 AI
   → 至少要看得懂 AI 寫的程式碼                          # 不然怎麼審查？
   → 至少要知道基本的架構概念                            # 不然怎麼設計？
   → 至少要會 Debug（AI 也會寫錯）                       # 不然怎麼修？

3. 善用 AI 學習                                        # 把 AI 當最好的老師
   → 每次 AI 寫完，問它："為什麼這樣寫？"               # 學習最佳實踐
   → 每次 AI 修完 bug，問它："為什麼會錯？"              # 學習避免錯誤
   → 每次 AI 選了某個架構，問它："為什麼選這個？"         # 學習決策邏輯

4. 掌握 AI 協作技巧                                    # 新時代的必備技能
   → 學會寫好的 Prompt（需求描述）                       # 溝通的藝術
   → 學會審核 AI 的產出                                  # 品管的能力
   → 學會迭代開發流程                                    # 效率的方法

🤔 我這樣寫為什麼會錯？

❌ 錯誤 1：用 No-Code 做需要複雜後端邏輯的專案

❌ 常見情況：
用 Bubble 做一個需要即時通訊的社交平台                    # No-Code 做不好的事
→ 效能不夠，使用者多了就卡                               # 技術限制
→ 想加自訂演算法，但 Bubble 做不到                       # 客製化限制
→ 想搬到自己的伺服器，但程式碼帶不走                      # vendor lock-in

✅ 正確做法：
1. 先想清楚需求的複雜度                                  # 評估再決定
2. 簡單需求 → No-Code                                  # 合適的工具
3. 中等需求 → Low-Code 或 AI 輔助                       # 彈性方案
4. 複雜需求 → Full-Code + AI 輔助                       # 完全控制

💡 選工具要看需求，不是看哪個最流行。

❌ 錯誤 2：以為 AI 可以取代學習程式

❌ 錯誤觀念：
"有了 AI 就不用學程式了"                               # 危險的想法
→ AI 寫了一段有 bug 的程式碼                             # AI 不是完美的
→ 你看不懂，不知道有 bug                                # 因為你沒學過
→ 上線後出問題，你不知道怎麼修                           # 沒有能力處理
→ 損失慘重                                             # 最後果

✅ 正確觀念：
"AI 讓我學得更快、做得更多"                             # 健康的心態
→ 用 AI 寫程式碼，同時學習每一段的意思                    # 邊做邊學
→ 看得懂 AI 寫的程式碼，能判斷對不對                     # 品質控制
→ 出問題時知道方向在哪                                   # 有能力處理

💡 AI 是加速器，不是替代品。基礎知識是你的安全網。

❌ 錯誤 3：一開始就選最複雜的工具

❌ 常見情況：
初學者想做一個個人部落格                                  # 簡單的需求
→ 直接學 ASP.NET Core + React + Docker + Kubernetes     # 超級複雜的技術棧
→ 學了三個月還沒做出來                                   # 學不完
→ 放棄了                                               # 太挫折

✅ 正確做法：
1. 先用 No-Code 工具做出來（1 天）                       # 快速實現
2. 覺得需要更多功能 → 用 AI 輔助寫簡單的後端             # 漸進式學習
3. 有基礎了 → 學更進階的技術                             # 循序漸進
4. 最終：你懂原理，也會用工具                            # 全方位能力

💡 從最簡單的工具開始，需要時再升級。
   這叫「漸進式複雜化」，比一步到位更有效。

本章重點整理