我如何用 Vibe Coding，把一個簡報工具做成完整平台

最初開發 SlideX 時，我並沒有打算做一個完整的簡報平台。

當時的想法很單純：做一個可以在瀏覽器中編輯簡報、快速整理內容，最後匯出成 PowerPoint 的工具。

沒有寫完整的產品規格，而是直接把想法告訴 AI，請它協助建立介面、元件和基本功能，再一邊操作、一邊修改。這大概就是現在常說的 Vibe Coding：從模糊的想法開始，透過不斷描述、測試和修正，把產品慢慢做出來。

不過真正困難的，不是讓 AI 寫出第一個頁面，而是如何把一個「可以運作的工具」，變成一個「真的有人願意使用的產品」。

凡是都有第一步的開始

SlideX 的第一個版本很簡單，使用者可以建立投影片、輸入內容、調整基本版面，並在瀏覽器中預覽與匯出簡報。

這個階段最重要的事情，是先確認核心流程能不能成立：

建立簡報、編輯內容、預覽結果、匯出檔案。

AI 確實讓這些功能很快就能被實作出來。

原本只存在腦中的想法，幾個小時後就能變成可以點擊和操作的畫面。

但當我真的開始使用時，很快就發現「能使用」和「好使用」之間，還有很大的距離。

例如，建立多份簡報後要去哪裡管理？內容編輯一半要如何保存？不同投影片之間怎麼切換？匯出的版面會不會跑掉？

這些問題開始逼著 SlideX 從單一編輯器，逐漸變成一套完整的產品。

從工具變成工作空間

當簡報數量增加後，我加入了專案管理功能。

使用者不再只是打開一個編輯器，而是先進入自己的工作空間，建立、整理和管理不同的簡報專案。

看起來只是多了一個頁面，背後卻改變了整個產品架構。

我必須開始處理專案儲存、資料載入、更新時間、封面、狀態同步，以及不同專案之間會不會互相影響。

這也是我第一次真正感受到：產品不是把很多功能放在一起，而是把每一段使用流程連接起來。

從建立專案、編輯內容、預覽，到最後匯出，只要其中一個環節讓人困惑，整個產品就會像是一個尚未完成的 Demo。

簡報不只是生成，而是持續修改

後來我也開始重新思考簡報工具的核心。

很多 AI 簡報產品強調一鍵生成，但產生完成後，使用者通常還是需要重新調整標題、段落、圖片、順序與版面。

如果生成後很難修改，那麼速度再快，也很難真正進入工作流程。

因此，SlideX 後來把重點放在結構化內容與編輯體驗。

我選擇使用 MDX 作為核心格式之一，讓簡報內容可以像文件一樣被閱讀與編輯，同時保有元件化與程式化的彈性。

這也讓 SlideX 的定位慢慢改變。

它不只是另一個線上簡報編輯器，而是一個能讓使用者、程式與 AI 一起操作簡報的工作空間。

讓 AI 直接操作產品

一開始，AI 主要是協助我開發 SlideX。

我會請它建立元件、修改程式碼、檢查錯誤，或快速嘗試不同的互動方式。

但後來我開始思考：既然 AI 可以協助我開發 SlideX，為什麼不能直接使用 SlideX？

因此，我加入了 MCP 與 Agent 整合，讓 Claude、Cursor 或其他支援工具，可以建立專案、新增投影片、修改內容和調整結構。

AI 不再只是輸出一段簡報文字，而是能真正進入產品工作流程。

我希望未來的簡報製作不是一次性的生成，而是 AI 先建立初稿，使用者修改，再讓 AI 根據新的需求持續調整。

Vibe Coding 仍然需要產品判斷

Vibe Coding 的確大幅降低了開發門檻，但它沒有取代產品判斷。

AI 可以幫忙寫出一個按鈕，卻不會自動知道按鈕應該放在哪裡。

它可以快速完成一個功能，卻不一定知道這個功能是否真的解決使用者的問題。

開發過程中，我也經常遇到某個功能單獨看起來正常，接進整個產品後卻造成狀態不同步、資料結構混亂，或影響其他頁面。

這時需要的已經不只是下提示詞，而是理解問題、拆解需求，並判斷哪些東西應該保留，哪些應該重做。

AI 加快了開發速度，也可能讓沒有整理的問題更快累積。

結語

SlideX 從最初的簡報編輯工具，逐漸加入專案管理、視覺編輯、MDX、匯出、模板與 Agent 整合，最後慢慢形成一個完整平台。

這個過程並不是一開始就規劃好的。

很多功能來自實際使用時遇到的問題，也有不少設計是在完成後又被推翻重做。

對我來說，Vibe Coding 並不是毫無方向地讓 AI 寫程式，而是利用 AI 快速把想法做成可以測試的產品，再從每一次操作、錯誤和回饋中，找出下一步。

AI 可以加速開發，但最後決定產品能不能成立的，仍然是使用者是否願意持續使用它。

參考來源：

https://slidexdeck.com/zh-TW/