AI 做網站怎麼做？不會寫程式的上線工具路線與步驟

如果你完全不會寫程式，但手上有一個網站或小工具的點子，現在大致有三條路可以走：用對話生成可上線網頁的應用（像 Lovable、v0、Bolt.new）、保留程式碼讓你以後還能自己改的 AI 編輯器（像 Cursor、Trae）、或是能讀懂整個專案、自己跑測試再動手改的終端代理（像 Claude Code、Gemini CLI）。選哪一條路，取決於你會不會寫程式、想做到什麼程度、要不要上線。這篇只談「非工程師從零做出可上線成品」這件事該怎麼走，更完整的 Vibe Coding 概念可以參考這篇說明。

先講清楚一個容易誤會的地方：這整套做法不是「完全不用懂」，而是「不用一行一行手打程式碼」。AI 幫你寫、幫你改、幫你跑測試，但最後東西對不對、能不能給別人用，還是要人來把關。這點會貫穿下面每一段。

三類工具差在哪，該選哪一種

類型	代表工具	運作方式	適合情況
對話生成應用	Lovable、v0、Bolt.new、Replit	用自然語言描述想要的頁面或功能，對話生成後可直接預覽、部署，不用自己配置開發環境	完全不會寫程式，想做個人主頁、報名頁、有功能的 MVP
AI 編輯器	Cursor、Trae	補全與智慧體改程式碼在同一個視窗，新建專案時可從零生成，之後也能繼續手動調整	想保留程式碼、以後還想自己改、已經有一點點程式背景
終端代理	Claude Code、OpenAI Codex、Gemini CLI	讀懂整個專案，自己找出要改的檔案、產生修改、跑測試，再交給你確認	已有專案要維護、批次改程式碼、接手陌生程式碼庫

完全不會寫程式、目標是個人主頁或活動報名頁，最直接的起點是 Lovable、v0 或 Bolt.new，用中文描述想要的頁面，對話生成後就能上線，不用自己架開發環境。這三個工具裡也有分工：v0 比較擅長把一句話變成設計感強的前端介面，適合做原型；Lovable 能生成含前後端的全端應用，適合做有實際功能的 MVP；Bolt 在瀏覽器裡就能即時預覽整個全端專案，迭代速度快；Replit 則是雲端開發環境加 AI，做出來可以直接部署，適合想一站搞定所有事的人。

如果你想把程式碼留在自己電腦上、以後還想自己改，可以從 Trae（內建 Builder 智慧體可從零生成專案）或 Cursor（Agent 模式可跨檔案修改）開始，更細的 Cursor 上手方式可以看這篇教學。已經習慣 VS Code 或 JetBrains 的人，裝 GitHub Copilot 或通义灵码這類外掛即可，不用換工作習慣。如果是要接手別人留下的陌生專案，Qoder 可以自動生成專案知識庫，Claude Code 則是直接讀懂整個程式碼庫再動手；三種工具更完整的場景對照可以看這篇比較。

幾個工具的免費額度可以先摸過水再決定：Lovable 免費方案是每天 5 個 build credits（每月最多 30 個）加每月 20 個 cloud credits；v0 免費方案是每天 7 則訊息；Bolt 免費方案是每日 30 萬 token、每月 100 萬 token 的限制。付費方案的具體金額經常調整，請以官網最新公告為準。沒有哪個工具是「最強」的，只有最適合你目前程度與目標的那一個，先用免費額度做一個小東西試試手感，再決定要不要往下投入。

用一個真實案例，看完整流程怎麼跑

不會寫程式也能開始，但開始之前先把四個問題想清楚：誰會用這個東西、現在被卡在什麼、輸入什麼應該得到什麼、怎麼確認結果是對的。這四個問題沒想清楚，後面無論工具多厲害都在幫你把錯的方向做得更完整。

想清楚之後，流程大致是這樣跑的：你說明想解決什麼、怎樣才算完成，AI 讀取專案找出可能需要處理的地方，產生或修改程式，工具執行測試或打開預覽，你實際操作檢查，不對就繼續修。這和單純問 AI「我該怎麼做」最大的差別是，你最後拿到的不只是一份建議，而是一組真的改在專案裡、可以打開來檢查的成果。

有個郵遞區號查詢工具的例子很能說明這件事沒有表面看起來那麼簡單。看起來只是把地址翻譯成郵遞區號，實際上要符合中華郵政正式寫法，牽涉到三萬多筆路名的官方中英對照資料，還需要另外設計測試與抽樣驗證,前後跑過數百項單元測試才敢放出去用。AI 可以協助整理資料、修改程式、補測試、修正錯誤，但「這份資料應該相信誰」「什麼結果才敢交給別人使用」這兩個判斷，還是得由人來做。

這類工具通常不是一次就想好全部功能，而是從一個小東西開始，慢慢累積成一系列：先做一個計算類的小工具（像複利計算器），接著做文字處理類（顏文字、QR Code 生成），再做查詢類（郵遞區號），甚至延伸到互動性更高的練習工具或連線小遊戲。最適合當第一個練習題目的東西，通常小到有點不起眼：一張報名表、一個費用計算器、一個可以搜尋的資料頁、一個你自己真的會打開來用的按鈕。先把這種小東西做完、做對，比一開始就想做一個複雜產品更容易成功。

非工程師最容易卡住的四件事

驗收標準寫不出來

很多人卡關不是因為工具不會用，而是說不出「怎樣才算做對」。好的需求描述要包含三個元素：意圖（我要什麼結果）、限制（不要什麼）、驗收（怎麼算對）。如果你只說「幫我做一個報名頁」，AI 很難知道要不要收費、要不要寄確認信、填錯格式要怎麼提示。把這三件事先想過一輪，再開始對話，會少走很多回頭路。

不知道東西放哪

用 AI 編輯器類工具時，新建專案一開始就寫一份簡單的規則檔（告訴 AI「做什麼、不能改什麼」），結果會穩定很多。另外，動手改之前先建一個 Git 分支（版本控制工具用來記錄每次修改、方便回退的機制），每完成一步就提交一次，這樣就算哪一步改壞了，也能退回上一個版本，不會卡在「東西到底存在哪裡、改到哪一版」的狀態。

改一版壞一版

這是最常見也最容易被忽略的風險。AI 說「修好了」不代表真的修好了，永遠要先看它改了什麼（diff）、先跑測試，確認沒問題才提交。如果一次給太多步驟，複雜任務拆成小步，每一步驗收完才做下一步；如果一次丟太多檔案，AI 可能會開始亂改不相關的地方，與其把整包 repo 丟給它，不如只挑出任務入口、核心邏輯、資料結構、類似範例、驗證方式這幾類真正相關的檔案（常見做法約 5 個左右），而不是隨便限定一到三個。更完整的審查習慣可以參考這篇 Code Review 檢查清單，裡面雖然是寫給工程師看的流程，但「先看 diff 再決定要不要接受」這個原則對非工程師一樣適用。

資料與隱私

如果要處理的資料裡有客戶名單、公司內部文件，先確認這些資料能不能放進去給 AI 工具處理，有些工具的服務條款會說明客戶資料存在哪裡、誰能存取。密碼、API 金鑰這類敏感資訊,不要直接複製貼給 AI，應該放進獨立的設定檔並排除在外，避免不小心被工具讀到或存進對話紀錄。如果是公司內部要正式導入，建議先看過這份權限與風險檢查清單，把資料政策確認清楚再開始。

成品上線前的檢查清單

• 每一步修改都用 Git 提交，留下可以回退的紀錄
• 提需求時先讓 AI 給出修改計劃,你確認過再讓它動手
• 每個任務結束前，請 AI 寫一個小測試證明功能真的跑得通，並實際執行給你看
• 自己親手操作一次，不要只看 AI 的文字說明就相信「修好了」
• 敏感資訊（密碼、金鑰）確認已經放進獨立設定檔，沒有出現在對話紀錄或程式碼裡
• 如果資料來源涉及法規或正式用途（例如地址、帳務、個資），額外設計測試與抽樣驗證,不要只靠 AI 說「沒問題」
• 確認資料政策：這份資料能不能交給目前使用的 AI 工具處理

什麼時候該停下來找工程師

完全不會寫程式，靠這套方法可以做出微型自動化（檔案整理、資料轉換、報表彙整）這類東西，但距離「給客戶正式使用的產品」之間還有一段落差，這段落差通常需要先補一點基礎能力，或是找工程師接手。

把 AI 當成加速你把事情做出來的工具,而不是取代掉「這件事該不該做、做得對不對」的判斷，這個分界線拿捏好，才是這整套做法真正能用得久的地方。