Manus AI 做網站實測：不會寫程式也能完成會員、資料庫、投票與 SEO？

不會寫程式，也能把一個只有概念的網站真正做上線嗎？我用 Manus AI 從零打造科技產品許願平台，實際測試會員登入、投票、留言、資料庫、排行榜、後台管理、重複提案偵測與 SEO。整個過程最讓我意外的，不只是建構速度，而是它連原本以為要另外處理的功能也一起完成了。

為什麼想用 Manus AI 做網站
- 從科技產品願望變成可投票的平台
- 先定義會員、資料庫與管理需求
用 Chat Mode 與 Blueprint 規劃網站
- 先用白話文講清楚需求
- 讓 Manus AI 拆解執行階段
Manus AI 建構網站的實際過程
- 選擇視覺風格並開始建構
- 約四十分鐘完成前台與後台
Wish Forge 網站功能實測
- 註冊、建立願望與投票留言
- 搜尋分類與管理員後台
AI 重複提案偵測與 SEO 優化
- 相似願望如何避免票數分散
- 網站 SEO 能做到哪些工作
發布、自訂網域與網站管理
- 從預覽直接發布到網路
- 儀表板、資料庫與檔案儲存
Manus AI 做網站的實際心得
- 哪些部分最讓我意外
- 沒有程式背景是否真的能上手

為什麼想用 Manus AI 做網站

從科技產品願望變成可投票的平台

我一直覺得，消費者想要的功能和科技品牌最後端出的產品，經常存在一段落差。有人希望手機重新支援記憶卡，有人期待 S Pen 回到摺疊手機，也有人不想看到小尺寸手機從市場消失。這些意見分散在留言區、論壇與社群裡，即使有不少人抱持相同想法，也很難用清楚的數字呈現需求到底有多強。
因此，我想做一個科技產品許願平台。每個人註冊帳號後，都能寫下希望品牌實現的功能；其他人認同就投支持票，不認同則投反對票。同一個帳號對同一項願望只能保留一個票態，避免重複灌票，也讓結果更接近實際意見。
我把網站命名為 Wish Forge，概念就像把零散願望送進熔爐，再透過支持與討論逐漸成形。網站還需要 Top 10 熱門願望榜，讓支持度最高的提案集中出現。如果這些願望累積到足夠明確的數量，我也能透過網站與平常接觸科技品牌的機會，把具體需求傳達出去。
實際完成的網站已經能在線上使用：Wish Forge 科技產品許願平台。這次實測的目標不是只做一張看起來像網站的展示頁，而是要讓帳號、願望、投票、留言與後台都真正運作。

先定義會員、資料庫與管理需求

開始建構前，我先把核心需求整理清楚。網站必須有會員登入，未登入的訪客可以瀏覽願望、留言、支持票與反對票；登入後則能建立願望、投票、留言、回覆與收藏。願望還要依品牌及產品類型分類，例如 Apple、Samsung、Sony，以及手機、平板、相機或智慧家庭等不同項目。
每一項願望都需要自己的資料紀錄，包括願望內容、建立者、支持數量、反對數量與留言討論。網站首頁則要顯示熱門榜及最新願望，搜尋頁能按照品牌或產品類型篩選，讓累積的提案不會全部擠在同一個畫面裡。
管理端也不能省略。我希望管理員可以新增品牌與產品分類，查看已發布或下架的願望，並針對不適當的內容下架或駁回。留言與檢舉同樣要能管理，否則網站一旦開放使用，很快就會遇到內容整理問題。
最後，我還加入一項需要 AI 參與的功能：建立願望前先檢查是否已有相似提案。如果兩個人的想法其實相同，系統應該先提醒目前已有類似願望，避免重複建立後把支持票分散到不同頁面。

用 Chat Mode 與 Blueprint 規劃網站

先用白話文講清楚需求

進入 Manus 後，我先開啟 Chat Mode。這個階段的重點不是立刻讓它開始寫網站，而是用對話把功能講完整。我把科技產品許願平台的概念、會員權限、品牌與產品分類、Top 10 排行榜、留言互動、相似提案偵測，以及管理員後台一次說明清楚。
我沒有寫程式規格，也沒有提供資料表結構，而是直接用平常描述產品需求的方式溝通。例如，一個帳號只能對同一個願望投一票；訪客可以觀看，會員才可以投票與留言；管理員必須能處理願望、分類、留言和檢舉。這些規則如果一開始說得含糊，後面做出來的流程就很可能和預期不同。
Chat Mode 適合先討論，我實際使用時不會在這段對話消耗點數。我也要求 Manus 先提供 Blueprint，而不是馬上建構。這樣可以先看它怎麼理解整個網站，再決定是否需要補充或修改需求。

讓 Manus AI 拆解執行階段

Blueprint 產生後，Manus 把需求整理成幾個主要模組，包括會員功能、願望與投票機制、搜尋與排行榜、社群互動、AI 輔助及後台管理。原本一長串口語描述，到了藍圖裡已經變成比較接近產品規格的架構，也把每個區塊預計包含的功能列得更完整。
它同時提出分階段執行的建議：先完成願望、投票和整體架構，再處理會員登入，後續導入社群互動與 AI，最後優化後台。Blueprint 也提到 SEO 開發與相似度偵測可以放在後續階段，避免一開始的範圍過大。
不過，我希望第一個可用版本就具備完整功能，因此直接要求第一階段全部執行。這個選擇並不是把藍圖略過，而是看完規劃後，再明確告訴 Manus 這次要把哪些項目一起完成。對我來說，Blueprint 最大的價值是能在正式動工前確認方向，而不是等網站做完才發現漏掉會員或後台。

Manus AI 建構網站的實際過程

選擇視覺風格並開始建構

確認藍圖後，Manus 讓我繼續選擇網站風格。我希望科技許願平台帶有更明顯的數位感，因此選擇較偏 Digital 的視覺方向，也把需要的 LLM 功能勾選起來，接著才按下立即建構。
這裡有一個和我原本預期不同的小細節。我一開始以為送出後它會立刻一路做到完成，但中間仍會再次確認計畫，確認之後才真正依照藍圖開始建構。整體並不是按下一次按鈕就完全不需要看，而是先規劃、確認，再進入實作。
建構期間，我不需要自己處理前端版面、後端邏輯或資料庫。原本若要完成會員、投票與留言平台，通常會拆成設計、前端、後端及資料庫等不同工作；這次我只需要描述目標、確認藍圖與選擇風格，其餘工作交由 Manus 執行。

約四十分鐘完成前台與後台

從開始建構到看見完整成品，實際等待時間大約四十分鐘。最讓我意外的是，我原本只說先做第一階段，結果 Manus 最後按照藍圖把多項功能都完成，並不是只交出首頁或幾個不能互動的按鈕。
完成後，預覽畫面已經是一個有明確視覺風格的網站。Wish Forge 採用偏賽博龐克的數位介面，首頁預先建立 Samsung、Google、Sony 等品牌，也放入手機、相機、智慧家庭等產品分類。頁面上能看到 Top 10 熱門願望與最新願望訊號，整體結構和最初描述的方向一致。
這四十分鐘完成的並不是純粹的網頁外觀。會員登入、建立願望、投票、留言、搜尋、分類、管理後台與 AI 相似提案功能，都已經出現在可操作的網站裡。接下來最重要的工作，就是逐項驗證它們是否真的能用，而不是只看畫面就認定完成。

Wish Forge 網站功能實測

註冊、建立願望與投票留言

我先用自己的 Manus 帳號登入 Wish Forge，確認會員流程能正常完成。登入後，網站會保留帳號紀錄，也開放建立願望、投票與留言等會員功能。這代表帳號不只是畫面上的登入按鈕，而是確實會影響可以執行的操作。
接著，我建立一項 Samsung 摺疊手機支援 S Pen 的願望，選擇 Samsung 品牌及手機與平板分類，填入願望標題與原因，再按下「鑄造願望」。送出後，新提案會出現在首頁，也能進入獨立頁面查看完整內容。
願望頁面可以投支持票或反對票，也有留言與回饋區。我實際發布留言後，內容能正常顯示。這幾個環節串起來後，網站才真正形成最初想要的互動流程：提出願望、累積票數，再透過留言補充理由，而不是只有單向提交表單。

搜尋分類與管理員後台

資料庫累積願望後，搜尋和分類會直接影響網站是否容易使用。我在搜尋頁切換 Samsung 品牌時，系統只顯示相符內容；改選 Apple 後，沒有對應願望便顯示空白。產品分類也能用相同方式縮小範圍，代表品牌與類型並不是單純顯示在卡片上的文字，而是能實際參與篩選。
管理終端則能查看已發布與已下架的願望數量，也可以新增分類。管理員若認為某項願望不適合留在網站上，可以直接下架或駁回。這些功能讓平台在開放使用後仍有基本的內容控制能力，不必每次修改資料都回到程式碼或資料庫手動處理。
從前台註冊、發文、投票和留言，到後台分類與內容管理，這次建立的網站已經具備一套完整的基本循環。對我而言，這也是判斷 AI 做網站是否有實用價值的關鍵：不是畫面做得多漂亮，而是一般使用者和管理員的流程能不能真的走完。

AI 重複提案偵測與 SEO 優化

相似願望如何避免票數分散

相似提案偵測是這次網站裡最能體現 AI 用途的功能。我刻意建立一個和既有願望相近的新提案，再按下鑄造。系統隨即找出已有的相似願望，並提醒如果繼續建立，可能會分散原本的支持票。
這項提醒不會只靠完全相同的標題才觸發，而是針對內容相近的願望進行判斷。對許願平台來說，這比單純禁止重複標題更符合實際情況，因為不同人可能用不同句子描述同一個需求，例如希望摺疊手機支援手寫筆，或希望 S Pen 回到下一代摺疊機。
如果沒有這層檢查，同一個需求可能出現好幾篇，每篇都只有少量票數，最後很難看出真正的支持規模。Manus 把這項功能直接做進建立願望的流程，不需要我另外串接一套檢查工具，實測時也確實能顯示相似內容。

網站 SEO 能做到哪些工作

網站主要功能完成後，我再要求 Manus 針對 SEO 進行優化。SEO 和登入或投票不同，很難只從畫面立刻判斷是否完成，因此處理結束後，我直接詢問它實際做了哪些工作。
Manus 回覆的內容包含多項網站 SEO 所需步驟。這些工作平常不一定會直接出現在首頁，但會影響搜尋引擎理解網站結構與頁面內容。這次 SEO 並不是在建構完成時就假設全部做好，而是我另外提出需求後，它再執行一輪優化。
這點對整個流程很重要。用 AI 建立網站不代表只要畫面能開就算結束，仍然要回頭確認曝光、登入方式、資料管理與發布設定。好處是，這些後續工作同樣能用自然語言提出，不必先知道每一個技術步驟要在哪個檔案修改。

發布、自訂網域與網站管理

從預覽直接發布到網路

Manus 完成網站後，可以先在預覽中檢查，再按下發布。發布時能選擇擁有連結的人都可查看，或限制只有受邀者才能進入。這讓測試版與公開版能使用不同權限，不需要一完成就強制對所有人開放。
網站發布後會取得 Manus Space 網址，也能修改前方名稱，讓連結更短、更容易辨識。Wish Forge 最後使用的網址是 https://wishforge.manus.space/。平台同時提供自訂網域選項，可以購買網域或連接既有網域，讓正式網站不必一直使用 Manus 的子網域。
我實際複製網址重新開啟，網站能正常進入並登入，先前建立的願望紀錄也仍然存在。這一步確認了發布不是只有暫時預覽，而是已經能把連結分享出去，讓其他人註冊與使用。

儀表板、資料庫與檔案儲存

除了前台網站，Manus 的專案介面還能看到程式碼、儀表板、資料庫與檔案儲存。儀表板可以查看網站有多少人瀏覽，資料庫則負責保存會員、願望、投票與留言等內容。這些區塊都和網站一起建立，不需要先自行準備另一套服務才能開始測試。
登入方式也比我預期完整。除了 Manus 帳號，網站還能支援 Facebook、Google、Microsoft、Apple，以及自行使用電子郵件登入。對真正要公開使用的平台來說，多種登入方式能減少註冊阻力，也讓不同裝置與帳號習慣的人有更多選擇。
從發布、網址、登入到資料保存，這次實測已經走過一個網站正式上線所需的主要環節。即使我沒有親手編寫前端、後端與資料庫，仍能在同一個專案裡看到這些組成，而不是只拿到無法繼續管理的靜態頁面。

Manus AI 做網站的實際心得

哪些部分最讓我意外

這次最讓我意外的，是 Manus 不只把需求轉成好看的介面，而是讓多個功能真正連動。會員身分會影響投票與留言權限，建立願望後會進入首頁和分類搜尋，相似提案偵測會在送出前提醒，管理員則能從後台處理願望與分類。這些都是需要前後端與資料庫共同運作的部分。
第二個意外是完成範圍。我原本以為第一階段只會出現基本架構，最後卻連社群互動、後台、AI 偵測與發布流程都具備。建構時間約四十分鐘，期間主要工作是確認計畫與等待，不需要我在不同工具之間自己拼接功能。
當然，整個流程仍需要清楚提出需求並逐項測試。若一開始沒有說明一個帳號只能投一次、訪客與會員權限不同，或管理端需要下架功能，AI 不一定會自動猜中所有規則。完成後也不能只看首頁，帳號、投票、留言、搜尋、後台與重複提案都要親自操作一次。

沒有程式背景是否真的能上手

以這次從零建立 Wish Forge 的過程來看，不會寫程式並不妨礙把概念做成可以使用的網站。我使用的主要工具是自然語言：先描述目的，再補上會員、資料、互動與管理規則，接著透過 Blueprint 確認 Manus 的理解，最後才讓它開始建構。
這種做法把門檻從「會不會寫前端與後端」轉成「能不能把需求講清楚」。對沒有工程背景的人來說，依然要思考網站是給誰用、誰能做什麼、資料如何分類，以及出現問題時誰能管理；只是這些思考不再必須先翻譯成程式碼。
Manus 從前端、後端、資料庫一路做到發布與 SEO，讓我在一個中午內完成原本規模不小的科技產品許願平台。最後的成品不只是展示概念，而是真的能註冊、建立願望、投票、留言、搜尋與管理。這次經驗讓我最確定的一件事，是 AI 做網站已經不只適合快速畫原型，也開始能把一個具體想法推到可上線測試的階段。

Manus AI： https://manus.im/redeem?c=havefun

Redeem Code：『havefun』