如果做對，Vibe Coding 能幫助 No-Code 工具走得更長久
過去半年，有個問題讓我不斷思考：Vibe Coding 會取代 No-Code 平台嗎？
尤其是我開始使用 AI 幫助我開發各種在其他 No-Code 平台難以完成的工具，我彷彿感覺「AI 就是新時代的 No-Code 介面」
- 使用者一樣只要熟悉你要的業務流程、資料結構、互動方式，就可以開始建構專案
- 使用者一樣不用理解背後程式碼運作邏輯，從拖拉生成互動介面，轉換成 AI 直接生成
- 使用者一樣不用自己處理平台之間的整合串接，從 GUI 告訴你該給他什麼資料，變成 AI 問你 API Key 是什麼
當然，我相信真正使用像 Cursor 這種 IDE 來開發客製化企業軟體的人還是極少數，但本來使用 No-Code 工具的人就也是少數，作為一個 No-Code 平台從業者，自然而然的就冒出一些自我懷疑
與此同時，No-Code 工具們也沒閒著，相繼推出 AI 相關的功能，試圖讓自己的平台能因此帶來更多價值
我總結了過去兩年 No-Code App Builder 主要透過三種方式導入 AI：
1️⃣ AI 建構器：能透過提示詞建立完整的應用程式（例如 Notion、Airtable、Softr、Zite）
2️⃣ AI 欄位：能在欄位層級用各種方式處理資料（例如 Airtable、Glide）
3️⃣ AI 協作助理：幫助使用者理解和分析所有已有的資料與內容（例如 Notion、Airtable）
此外，還有一些較新的功能，例如能實際為用戶執行任務的 Agent（例如 Zapier Agent、Retool Agent、Superblocks 的 Clark，後兩者皆在低程式碼環境中運作）以及透過 AI 產生平台不具備的組件（例如 Glide 的 AI）
這些功能非常適合快速上手。但我持續觀察到的是：一旦使用者持續使用、遇到平台功能邊界時，他們不是直接放棄，就是將其交給外包開發人員處理
有些平台已經具備腳本功能（例如 Airtable、Jodoo）用以拓展平台功能邊界，但問題是：
「幾乎沒有人使用這些功能」
這類功能強大到令人望而生畏，使用者沒無法透過當前的設計跨越「拖放操作」與「實際編寫程式碼」之間的鴻溝
在 Jodoo，我們經常遇到這種情況：
使用者會要求特定的欄位或邏輯，而這些是我們的既有組件無法處理的；但為他們客製化建構這些功能，對我們而言並不具規模效益
Glide 開發了 AI 來生成組件，剛好展現了讓 AI 填補平台功能缺口的潛力。我認為在業務邏輯、甚至功能層面，AI 也有相同的潛力可運用，尤其是現在 No-code 平台本來就提供這種介面了
所以當我看到 Figma 發表 Figma Make 時，我很快便產生共鳴，因為這與我的想法不謀而合：
「以 AI 賦能使用者，而非以 AI 取代已有工具」
現在 IDE 已經透過 AI 改變了這類產品的使用模式，讓更多人建構更多有趣的專案，而 No-Code 產品不應該限制大家只能在有限的組件裡拖拖拉拉
結論：
當 Vibe Coding 工具和生態完善的那一天，可能真的有機會顛覆 No Code 產業，但現階段 No-Code 平台本身還有各種基礎建設，幫助使用者做出效能好、維護成本低、且安全的系統，這些點現在還很難讓 Vibe Coder 直接做到，談取代還言之過早，更應該關注兩者怎麼互補
中短期內，一個很有潛力的機會是：讓 No-Code 平台中的腳本編寫變得平易近人。讓使用者能用自己的話語來描述他們想要的功能、整合自動化、業務流程，或者介面設計，然後讓 AI 協助他們實現這些構想
如果我們能成功做到這一點，使用者不僅會更長久地使用平台，他們還會建構出更具企圖心的專案，並且真正感覺到自己對所創造的成果擁有主導權
本文首次發布於：2025/05/30
各類 AI 功能與 Agent 演示影片
以發佈時先由新到舊排序
