用 Cursor 僅花 9 天打造 AI 網頁編輯器：推論成本不到 160 美元

大家好，我是 Charles。我在 9 天內利用 Cursor 打造了一個頂尖的 AI 網頁編輯器/創作者工具，推論成本約 160 美元。這是我開發過程的故事，希望你們喜歡。你可以透過 getWEB4.com 瀏覽這個已部署的專案。我是 Silicon Charles，也就是 Charles Romelus，歡迎在 X 上追蹤我：@r0melusr0melus。

九天前，WEB4 基本上只是一個想法：選擇一個設計，與它對話，然後發布。如今，它擁有超過 500 個設計範本、真正的視覺編輯器、對話式 AI 編輯功能、圖層/檢查器、多頁專案、持久化、發布、匯出、支付、AI 點數、語音輸入、區塊生成、復原、自訂網域功能，以及一個正式的資料庫。到目前為止，整個開發過程的模型推論成本不到 160 美元，而且幾乎所有功能都是在 Cursor 內部完成的。

有趣的是，最困難的部分並不是「讓 AI 寫程式碼」。真正的挑戰在於，如何在 AI 輔助下以驚人的速度推進開發，同時避免架構變得混亂不堪。

WEB4 實際上是一個 AI 網站建構器兼編輯器，但我刻意不想讓它變成那種「提示詞 → 重新生成整個網站 → 消耗大量 token」的工作流程。我最終圍繞著建構的模型更接近於：「意圖 → 代理動作 → 經過驗證的基本操作 → 持久化且可編輯的網站」。

你從數百個現成的設計中選擇一個開始。然後，你不需要重新建構整個網站，可以直接說：「把這個標題縮短」、「替換這張圖片」、「在這裡新增一個動畫圖庫」、「把這個區塊往下移」、「把這張圖片變成影片」、「建立一個關於我們頁面」、「讓整個區塊看起來更高級」。AI 會解釋你的請求，但編輯器本身仍然保持確定性，這個區別最終變得非常重要。

技術棧方面，這個應用程式主要採用常見的網頁技術：Next.js / App Router、TypeScript、Tailwind、shadcn 風格的 UI、Prisma、Neon Postgres、NextAuth/OAuth、Cloudflare R2、Vercel，以及在動畫確實能增強體驗時使用的 GSAP。

伺服器端的 AI 供應商則使用 OpenAI 進行語音轉錄，而實際生成的網站格式是純粹的 HTML/CSS/JS。WEB4 本身的執行時 AI 模型目前是 DeepSeek V4-Pro。在開發過程中，我會根據任務需求，在 Cursor 內部交替使用 Grok 和 Claude Sonnet。

我傾向於使用一個代理進行廣泛的調查/架構設計，而另一個則用於更精確的修改，這比假裝一個模型能解決所有問題要有效得多。

開發速度快得驚人。有時候，我會發布一個功能，然後立即發現其底層的架構缺陷，修復後又發現修復導致了三個使用者體驗問題，接著在睡覺前再建構一個主要的系統。一個正常的流程基本上是：想法 → Cursor 代理 → 實作 → 本機測試 → 發現錯誤 → 截圖錯誤 → 代理調查 → 修復 → 測試 → 下一個功能，有時甚至每小時重複多次。

我不斷問自己：「這需要一個框架，還是只需要 60 行簡單的程式碼？」結果，簡單的程式碼出乎意料地頻繁勝出。

這些挑戰才是最有趣的部分。1. 生成的 HTML 是個難搞的領域。一旦 AI 能生成任意佈局，你就會失去手動編寫 React 元件樹時那種舒適的假設。使用者可能會點擊一個深埋在五層容器中的東西，圖片可能位於奇怪的包裝器內，一個區塊可能帶有動畫類別、轉換過的父元素、生成的 ID、不尋常的 CSS，或是 DOM 結構與編輯器預期不符。

有一次，我遇到元素被錯誤分類，導致幾乎無法操作的問題。解決方案是我稱之為 ROOT 的功能：如果 WEB4 不確定你選擇了什麼，ROOT 會向上追溯，直到找到最近的有意義的區塊或容器，然後將控制權交還給使用者。這個小功能解決了一整類「AI 產生奇怪 DOM」的問題。

2. 我最終建構了一個語義化的圖層面板。試圖讓所有可能生成的元素都能在視覺上輕鬆點擊，這是一場註定失敗的戰役。因此，我建構了一個圖層/檢查器系統，它不是一個巨大的開發者工具 DOM 樹，而是一個經過篩選的語義樹，其中包含使用者真正關心的元素，例如：區塊、背景、主要群組、標題、文字、圖片、影片、按鈕。

在圖層面板中選擇一個元素，會在預覽中高亮並捲動到該元素；在預覽中選擇一個元素，圖層面板也會同步顯示。這被證明是編輯器最重要的功能之一。

3. 區塊插入功能因幾何問題而失效。一個特別愚蠢的錯誤花費了比預期更長的時間來解決。WEB4 幾乎可以在所有地方正確新增區塊，除了某些生成頁面的底部。可見頁面比實際的最後一個 DOM 標記多延伸了大約 290 像素。因此，視覺上我點擊的是「最後一個區塊之後」，但從幾何學上來看，編輯器卻認為我在其他地方。

解決方案不是更多的 AI，而是對頁面尾部邊界有更好的確定性定義。這在這次開發中是一個反覆出現的教訓：當編輯器出錯時，不要要求大型語言模型變得更聰明，而是要修復基本操作。

4. AI 動畫導致整個頁面顯示異常。有些生成的頁面使用了揭示動畫，這些動畫會以非常低的透明度初始化內容，並依賴 JavaScript / IntersectionObserver 來顯示。在編輯器的 iframe 內部，這不總是我們想要的。

結果是：頁面存在，圖層面板也能看到所有內容，但視覺上整個區塊看起來像是失效或幾乎不可見。我的第一直覺可能是：重新生成頁面，但這是錯誤的答案。正確的解決方案是一個確定性的修復過程，它能偵測這類問題並為編輯器進行標準化。這不需要任何推論。再次強調：修復勝於重新生成。

5. 我過度強化了限制，後來不得不撤銷。一度，驗證器/沙盒變得過於嚴格。生成的頁面包含真實的 JavaScript，動畫也是允許的，有趣的網站會做一些不尋常的事情。如果你的驗證規則拒絕任何稍微有創意的地方，最終你只會建造一個監獄而不是產品。

我的規則改為：只設定最低限度的必要防護措施，盡可能優雅地修復，並優先發布。我仍然會拒絕明顯危險或損壞的東西，但我不再試圖預防每一個理論上的失敗，這極大地加速了開發。

6. 某個 AI 供應商技術上回傳了 HTTP 200，但實際上卻什麼都沒有。DeepSeek Flash 讓我遇到了這個專案中最喜歡的錯誤之一。請求會連線，回傳 HTTP 200，串流連線保持活躍，但隨後卻沒有任何可用的資料，只有永無止境的 keep-alive 流量。

這看起來像是我的串流實作出了問題。經過足夠的追蹤後，我將產品轉移到 DeepSeek V4-Pro，串流才變得可靠。教訓是：「200 OK」不代表你的整合沒有問題，務必監測實際的串流。

7. 持久化必須變得「無聊」，其他功能才能變得「酷炫」。核心表示方式大致變成了：基礎 HTML + 當前可編輯狀態 → 具體化 HTML。在讓 AI 變得花俏之前，儲存、重新開啟和發布功能必須是可靠的。我也將頁面建立設為原子操作，因為我發現一類嚴重的失敗情況，即生成過程可能部分地修改專案狀態。

現在，失敗的生成不會留下孤立頁面，失敗的操作不會悄悄消耗點數，並且只有在重要部分成功後，清單/狀態才會提交。這比 AI 生成聽起來不那麼光鮮亮麗，但也重要得多。

AI 不擁有編輯器。這可能是我學到最重要的架構教訓。在早期，讓模型操作任意 DOM 或為每個請求重新生成大量 HTML 是非常誘人的。但我後來放棄了這種做法。現在，代理會將意圖解析為受限的動作，例如：編輯文字、替換媒體、新增區塊、移動區塊、刪除區塊。

伺服器會驗證這些動作，編輯器則執行已知基本操作。模型負責說明「應該發生什麼」，而我的應用程式則決定「如何發生」。這顯著減少了：隨機損壞、token 使用量、幻覺式變異、難以處理的復原邏輯，以及持久化問題。這也讓更換模型變得更容易。「代理式」不等於「最大化 token 使用」。

我目前不同意的一種假設是，代理式軟體必須意味著重複傳送巨大的上下文視窗。WEB4 極力避免這樣做。一旦意圖被轉換為已知的編輯器操作，確定性軟體就會接管。這也是為什麼儘管開發速度很快，開發推論費用仍低於 160 美元的部分原因。我積極地使用模型進行推理，但盡量不讓它處理一般軟體已經知道如何做的事情。

Cursor 改變了我的除錯方式。我越來越常做的是給代理提供「證據」，而不是「理論」。我不再說：「移動區塊似乎壞了，修復它。」而是給它：螢幕截圖、重現步驟、相關頁面、預期結果、實際結果、控制台/日誌輸出，以及首先追蹤實際執行路徑的指令。品質差異巨大。一個好的提示詞越來越不像程式設計請求，而更像是一個非常煩人的 QA 工程師提交的錯誤報告。

另一個教訓是：讓代理證明事情。我不再接受：「這應該會成功。」我會要求：相關測試、型別檢查、確切修改的檔案、根本原因、生產環境行為，以及刻意未修改的部分。對於危險的流程，我會特別要求進行測試，例如：第一個候選方案失敗 → 第二個成功 → 僅發生一次發布。這種紀律防止了大量 AI 生成的無意義內容。

我也停止讓代理重新設計所有東西。現在我給 Cursor 最有用的指令，可能就是類似於：「不要重寫不相關的程式碼，只做最小且正確的修改。」大型模型幾乎有一種難以抗拒的衝動，想在修復房屋的同時改善整個社區。在這種開發速度下，這會是致命的。精確的修改會累積效益，而隨意的重構也會累積，只是方向相反。

這 9 天內發布的部分功能包括：超過 500 個現成的起始設計、全頁 AI 生成、真實可編輯的圖片、可編輯的文字/標題/按鈕/連結、AI 生成的區塊、區塊移動/刪除、圖片與影片轉換、圖層/檢查器、ROOT 選取復原、復原功能、多頁專案、儲存/重新開啟專案、持久化、匯出、發布、自訂網域流程、語音轉錄、免費方案使用限制、AI 點數錢包、付費點數包、真實結帳/支付流程、正式資料庫、響應式編輯器 UI，以及正式的登陸頁面/SEO 頁面。

是的，仍然存在一些粗糙之處，但這正是重點。視覺方面比我預期的更重要。我來自視覺/3D 背景，所以可能比大多數開發人員更執著於此。但 AI 讓功能性軟體更容易生產，這意味著「品味」變得更有價值，而不是更少。很多工作並不是「Cursor 能否實作這個？」

它能。真正的問題是：「這應該是什麼感覺？」編輯器的光澤、圖層互動、選取行為、語音狀態、載入狀態，以及一個技術上可行但卻無法吸引人停留的生成區塊之間的差異。代理可以以驚人的速度執行指令，但如果沒有人提供方向，它們的用處就小得多。

我會給任何以這種方式使用 Cursor 進行開發的人一些建議：1. 將推理與執行分開。讓模型深入推理，然後限制它實際允許修改的內容。2. 修復基本操作，而不是圍繞著損壞的架構不斷輸入提示詞。如果需要十個提示詞才能避免一個編輯器錯誤，那就修復那個編輯器錯誤。

3. 建構修復系統。生成的內容偶爾會很奇怪，修復可恢復的輸出通常比拒絕或重新生成它更好。4. 在確定性程式碼有優勢的地方使用確定性程式碼。並非所有事情都需要推論。5. 提供代理螢幕截圖和重現步驟。視覺證據對於前端除錯非常有用。6. 在編輯之前要求找出根本原因。否則你只會不斷地解決表面症狀。7. 讓代理進行精確的修改。