AI編程實戰！零基礎小白如何用Cursor獨立開發網站？

自 24 年 11 月起，我開始動手打造一個專注于 AI 視頻作品展示 的網站。在 AI 的助力下，我獨立完成了 前后端與插件開發，成功落地了人生第一款真正意義上的個人作品。目前，網站已收錄 300+ 優秀 AI 視頻。

GenLumio — AI Video Tools & Best Works ： https://genlumio.framer.website/

建議 PC 端魔法訪問。

這篇文章將圍繞 項目介紹、開發歷程、工具使用心得、小白成長思考 等方面，分享我在這幾個月中的所有收獲與感悟。

往期AI視頻整理：

一、網站介紹

1. 為什么會有這個項目

去年 9 月，我寫完 AI 視頻工具的測評后，原計劃 10 月快速推出一篇 AI 視頻作品推薦，展示當時的 AI 視頻能力。然而，行業更新速度驚人——Luma 崛起，國產 Kling、Hailuo 誕生，Hailuo I2V、Vidu 在動漫風格上的突破……每隔幾天，我都會在 X 上刷一波最新 AI 視頻案例，一篇文章已難以承載我想分享的內容。

正巧年末 Bolt AI、Cursor 爆火，AI Coding 走紅。我靈機一動，何不做個網頁，在我刷推時同步更新 AI 視頻動態？但...從未寫過代碼的我，能搞定這個項目嗎？

于是，我啟動了前期調研，確定項目涉及 插件開發、數據爬取、存儲、后端 API、前端開發 等工作，并正式踏上 小白 AI Coding 探索之路。

2. 功能介紹

網站 1 期

網站 1 期功能比較簡單，主要實現了數據的抓取和網頁前端的同步。你還可以篩選 AI 視頻使用的具體能力、產品、發布時間進行分類。通過標簽你可以了解到某類視頻創作者最常用的視頻創作工具是什么，比如 Vidu、Luma Ray2 是目前平面風格的寵兒，而代替 Sora，Veo 是當下 txt2vid 的王者。

目前涵蓋的全部分類字段

前端網站基于 Framer 進行搭建，一半使用代碼一半使用 Framer 實現交互邏輯。因目前數據存儲服務器在新加坡，目前需科學訪問。

接下來我想做什么

我打算優先迭代 AI 視頻工具模塊，旨在為大家提供最新工具訊息，參數對比甚至價格信息，以便找到適合自己的那款產品。

二、項目經歷全面分享

1 期開發的整個過程大概分為調研期 - 試水期 - 草莽期 - 規范期 - 收尾期，每個時期的經歷都非常豐富，多了很多“第一次”的嘗試。相信我，這個過程既讓人興奮，又讓人抓狂。

最終 1 期實現的全部功能

調研期｜讓 AI 參與規劃，技術小白不要怕

最開始，我滿腦子都是對這個項目的困惑：應該怎么實現？難度有多大？我能做到嗎？完全沒有頭緒。

于是，我打開 ChatGPT，將自己的想法全盤托出，然后讓 AI 給我解構：需要用到哪些技術？有哪些工具可以解決問題？哪些地方是盲區需要補課？

反復對話和檢索后，我的認知漸漸清晰：

網頁爬蟲：GitHub 上已經有類似項目，大概看了看思路，驗證這條路是走得通的。

后端云存儲：AI 給我推薦了 MongoDB Atlas 的免費方案，基本確認項目成本可控。

Framer + API 方案：了解到 Framer 自帶 fetch 功能，可以從服務器拉取數據隨機展示（雖然最后沒用這個，而是自己寫了代碼組件）。

前端視頻加載：淺淺了解了一下如何提高視頻加載速度，避免產品做出來用戶體驗太差。

雖然這些知識點當時只是粗淺了解，但它們給了我一個更明確點的感受：這項目應該能做。

試水期｜先行動起來，驗證最小可行性

和 AI 探討完項目規劃后，我已經迫不及待躍躍欲試了。于是我吭哧吭哧開始了 AI Coding 之路。這個階段先后完成了：

數據爬取（MVP 驗證）—— 寫了個初步的爬蟲腳本，把推特的文本、圖片、視頻信息爬下來，導出 JSON 文件。

連接云服務器 —— 寫了初步的后端代碼，把爬取的數據直接存到服務器。

插件交互實現 —— 給插件加上彈窗進行標簽選擇。

在這段時間里，我差點被 MongoDB 勸退……

作為數據庫小白，選擇 MongoDB，也是無腦相信了 AI 的推薦，沒有進一步對比看看。結果我卡在 URI 連接報錯這一步遲遲無法解決，花了大量時間逐一嘗試 AI 給出的 N 種方案，卻始終無法連接成功，前前后后折騰了好幾天，甚至一度想放棄整個項目。

直到某天，在一個極不起眼的角落里，我無意間翻到了一條網友評論，才終于找到了正確的解法，這個解放和 AI 給的答案毫無關系。

現在回頭看，那時的我經驗不足，對 AI 言之鑿鑿的答案深信不疑，但與其死磕 AI 提供的方案，不如早點主動檢索或者換個工具。（如果當時更早了解 Supabase，或許數據管理的體驗會比 MongoDB 輕松得多。）

這一階段的收獲：

1. 理解插件與后端的協作 —— 搞懂了插件如何與后端交互，并掌握了 API 和路由的基本概念。
2. 掌握 API 測試工具 —— 學會使用 Postman 測試后端 API，提高了調試效率。
3. 版本管理入門 —— 學會如何把代碼推送到 GitHub，并掌握了基礎的版本管理方法。
4. 學會質疑 AI 的答案 —— 理解了不要盲目相信 AI，要結合 AI 建議與傳統檢索手段來解決問題。

草莽期｜終于可以開始設計了 & 陷入設計師思維陷阱

這個階段主要完成了：

產品起名、logo 和 1 期頁面的設計

視頻總數、視頻模塊在前端的展示

邊開發邊摸索和 AI 對話的方法

經歷了無數枯燥的爬蟲 & 后端調試，我終于可以 開始設計前端頁面了！不過這之前，先要給網站取個名字。

在后端 API 和前端打通上，我嘗試了 Framer 的 fetch 功能，最終還是轉向了自定義代碼組件，通過自己寫代碼組件實現數據拉取。

fetch 只能支持少量、隨機出現的數據，比較適合 Demo 使用

然而，嘗到一點 AI Coding 的甜頭后是真的很容易上頭，在這個階段，我也犯了一個典型的設計師思維錯誤 —— 過度關注設計效果。我無意間看到一個很酷的懸浮變字體效果，就立刻想將其應用到網站標題上。我花費了幾天時間實現鼠標懸停時的可變字體效果，卻最終受限于Framer對可變字體渲染支持不足而無法實現。后續項目復盤，我意識到這是一件非常不符合 MVP 原則的事。

體驗了一把“不用在設計軟件里做動畫，直接讓 AI 生成代碼”的快樂

這一階段的收獲：

1. 理解了線上部署的重要性 —— 本地開發 ≠ 線上可用，必須將后端代碼推到 Git上并部署到Vercel上，才能讓別人訪問我的網頁。
2. 認識到 MVP 的必要性 —— 不能對炫酷效果有貪念，把核心功能跑通后再考慮其他。

規范期｜溝通開始規范化 & 完成更難任務

在上個周期，我和 AI 的對話往往很隨意，用幾段話大致描述完背景和任務，等 AI 輸出后發現效果不是我想要的再反復溝通修改調整，比較費時間也很熬心態。而到了這個階段，開發的模塊逐漸復雜起來，我開始嘗試用 .md 文檔整理需求，嘗試將各類交互細節都盡可能溝通清楚后再讓 AI 撰寫代碼。

這個階段主要完成了：瀑布流、加載邏輯優化、分頁器、篩選等功能開發，此外還包括設計還原、優化加載機制緩存邏輯...

其中瀑布流布局可能是繼 MongoDB 連接錯誤之后，最讓我頭疼的部分。

AI 很厲害，但有時也沒有那么強，盡管它給我科普了 Grid、Column、Flex、Masonry 布局的方案差異，但大戰 n 個來回，它就是寫不出類似網頁版小紅書的 Masonry 瀑布流效果，代碼在幾個錯誤的效果之間反復修改橫跳，導致我幾度想放棄這個嘗試，甚至考慮用自動加載來弱化布局問題。

那時候的瀑布流效果 emmm...

在這關鍵時刻，我的程序員朋友出手了，他幫我找到了一篇詳細解析 Masonry 布局的文章。我讀懂后，立刻讓 AI 閱讀學習，并在.md 文檔中詳細定義高度計算邏輯，最終成功實現了理想的瀑布流效果。

實現 Masonry 布局后的效果

這再一次說明，不要過分依賴現階段的 AI，適時主動搜索、借鑒已有經驗，比盲目試錯高效得多。

代碼開發的模塊全部完成后，我在 Framer 中繼續完善了網站的其他部分，比如 頂部導航、背景圖、品牌展示、底部欄、回到頂部模塊，以及不同屏幕尺寸的適配。選擇 Framer+Coding 的本質原因還是對 AI Coding 的效率不自信，比起和 AI 死磕，Framer 這樣的設計師工具用起來更順手，也更能為我節約時間。

這個階段，我終于告別了“草莽式開發”，進入了更規范的推進方式，進展也愈加順利了。

新周期｜項目并沒有結束，新功能開發、SEO、學習運營

當 1 期功能發布后，真正的挑戰才剛剛開始。很多看似細小的決定，讓我不得不反復權衡：

長期規劃：這個項目值得我長期投入嗎？長期愿景和后續的功能迭代計劃是什么？

資源投入：在沒有明確的成功預期下，是否應該為更多工具付費？

SEO：新品牌名不利于搜索排名，當初是不是應該蹭個關鍵詞？

合規與數據：是否要做國內數據備份和網頁備案？

開發 vs 運營：業余時間和精力有限，如何平衡開發和推廣？

與此同時，我也迎來了許多 “第一次”：第一次正式了解 SEO，第一次在海外 嘗試推廣個人項目，現在還處于邊學習邊實踐的狀態。

三、Cursor 高效溝通法則

下面這一節，我會回顧網站 1 期的開發經歷，講講開發過程中更加具體的實操經驗，如果你也想著手嘗試 AI Coding，希望這些經驗可以為你節約一點時間。

注：以下案例基于 Cursor 中的 Claude3.5 Sonnet 模型溝通開發

一個問題一個 Chat

使用 AI Coding 工具時，建議把大模塊需求拆分成小問題，并為每個新問題單獨開啟一個 Chat 對話。過長的對話可能導致 AI 記憶混亂、響應時間變長，同時也不利于回顧和管理。

我會有意識地管理我的對話，確保在遇到問題時能夠快速回溯，方便項目復盤

如果在某個 Chat 中感覺 AI 陷入了“死胡同”，常見表現包括：

AI 多次給出錯誤的解決方案，即使你已經指出問題；

AI 反復提供你已經驗證無效的方案，無法跳出思維定式。

此時，不妨新建一個 Chat，結合錯誤經驗重新描述問題。這往往能幫助 AI 重新梳理思路，更快找到正確的解決方案。

多文件修改使用 Composer

當涉及模塊間的數據聯調（即多個代碼文件需要協同工作）時，建議使用 Cursor 的 Composer 功能，而不是普通 Chat。

相比 Chat，Composer 能同時分析多個文件，理解代碼上下文，并提供更合理的修改建議，從而提高方案的準確性，大幅提升開發效率。

此外，兩者的另一區別在于代碼的應用方式：

Chat 模式：AI 提供的代碼修改方案需要手動點擊 "Apply" 才能生效。

Composer 模式：AI 的修改建議會自動 Apply 到代碼文件中（當然，不滿意的部分依然可以手動拒絕）。

如果你的工作流涉及多個文件的修改，優先選擇 Composer 會更高效。當然，如果你習慣在所有場景下使用 Composer，也完全沒問題。

避免 AI 在需求不清晰的情況下過早執行

告訴 Cursor 不要急于寫代碼

相比 Windsurf，Cursor 更傾向于直接提供代碼，哪怕你只是想討論需求可行性，它也會立刻開始寫代碼（以至于有時會顯得不那么聽話）。

在項目前期，我們可以先進行發散討論，讓 AI 幫助補充不明確的細節，而不是一上來就寫代碼。這時，可以明確要求 AI 暫緩執行，等思路確認后再讓它動手，這樣 Cursor 就會變得更配合。

應用案例：

引導 AI 提問，避免無腦執行

Cursor 默認相信你的判斷，如果你嘗試誤導它，它大概率不會質疑，而是直接按照你的錯誤思路執行。 所以，如果你自己都拿不準解法，一定要讓 AI 反問你，主動確認更多細節。

應用案例：

讓 AI 繼續向我確認需求細節

減少 AI 亂改代碼的概率

強調不要修改無關代碼

在持續優化大型代碼文件時，AI 的不可控性往往讓人頭疼——它可能在優化新功能的同時，反復誤刪或修改不相關的代碼。

為了減少這種情況，我們可以：

強調自己是代碼小白，讓 AI 生成更詳細的中文批注，幫助我們理解代碼邏輯，方便后續人工檢查 AI 的改動建議。

在需求描述中明確范圍，指明哪些代碼可以修改，哪些不能動，以降低 AI 誤改的概率。

做好 .md 需求文檔沉淀

在開發過程中，我們往往需要在新建 Chat 中向 AI 反復描述項目背景、進度和新需求。最初，我是通過臨時記錄（微信輸入框、文檔等）復制粘貼到 AI，對話管理較為混亂。

直到在播客中聽到 Soga 作者分享他用 AI 共同維護 20 萬字 PRD 文檔的經驗后，我開始優化對話策略：

建立 .md 需求文檔，記錄項目背景、核心邏輯、已實現功能等內容，每次開發新功能時，讓 AI 先閱讀文檔，確保理解上下文。

 

調用 Prd.md 文件并說明最新任務

明確指示 AI 閱讀需求，避免因多個文件 @ 過多而遺漏關鍵內容。

除了@ 文件，建議大家用文字再次說明需要 AI 閱讀文件。因為我們可能同時@多個文件，不重點強調可能會造成 AI 的漏讀。

讓 AI 總結代碼變更，在迭代新功能前，先讓 AI 復盤代碼，更新需求文檔，確保需求同步。

在完成了一些大的功能改動后，在進入下一步迭代之前，先讓 AI 先閱讀一遍代碼，自行描述需求細節，完善 Prd.md 文件。

AI 幫我總結的功能需求點

非常建議在 Prompt 中強調“不需要用代碼的形式呈現，只需要像產品需求說明那樣，文字總結即可”，還是前面提到的，Cursor 真的太愛寫代碼了的問題 。沒有這句話，在你反應過來時，它已經又用代碼呈現剛實現過的功能了。

強調“思維鏈”提高 AI 推理能力

這個方法是從即友@MooreAI 那里學到的，"思維鏈"（Chain of Thought）是一個有效的 AI 提示技巧，它可以減少 AI 的模糊推理，讓它進行更嚴謹的邏輯思考，適用于 復雜計算、代碼分析、任務規劃 等場景。

高效 Debug：添加調試代碼，幫助定位原因

在實現 視頻瀑布流方案 時，我讓 AI 設計了一套較復雜的計算邏輯。我不想深入閱讀、學習代碼，但仍然需要確認它是否按預期運行。

除了 肉眼觀察判斷，更高效的方法是：

讓 AI 添加調試代碼

將代碼粘貼到 Framer 的代碼編輯器 運行，查看實際執行情況。

如結果不符預期，可截圖反饋給 AI，幫助快速定位問題。

這種方法比起猜測解決方案、胡亂嘗試更高效。

讓 Claude 展示豐富回復幫助理解

在 Cursor 中，你可以引導 Claude 以更豐富的方式解釋模糊概念，增強理解。

當我不理解某些名詞定義時，Claude 會 舉例說明。盡管 Cursor 中的 Claude 目前無法直接生成圖片，但仍可通過 符號、文字排列的方式，讓我更直觀的感受差異。

案例：對比 Perplexity 和 Claude 對瀑布流布局概念的解釋差異

Perplexity 僅提供文字描述，難以直觀理解

Claude 3.5（在 Cursor 中） 通過 示意圖+對比描述，更形象地幫助我理解

五、小白開發者的思考

精簡，再精簡一點

經歷過這幾個月的 AI Coding，我真實且深刻感受到一個小想法落地成產品的復雜度。還好這是我個人的第一個項目，也是個為了個人學習需求、入門 AI Coding 的練手項目，我不會有數據目標壓力。

但如果帶入到實際項目場景，我想我們還是要盡可能用更簡單、更輕量的方式去驗證想法。因為一旦決定啟動項目，需求定義、設計、開發、運營都是巨大的工作量。打造一款真正解決問題的產品能讓你更早獲得反饋，也更容易堅持下去。

用完整產品來驗證市場需求，成本太高了。

在需求規劃階段，不妨多問自己：這個功能真的必要嗎？這個效果能簡化嗎？因為即使是讓 AI 寫代碼，打字描述需求也會打到手指酸痛，讓 AI 一遍遍改報錯的時候也常常會陷入自我懷疑。

作為設計師，我們尤其需要警惕完美主義的陷阱，學會舍棄，專注 MVP。

工作量，遠不止呈現給用戶的頁面內容

你可能會好奇，如果單看最終呈現的網頁，功能很簡單——但為什么我說成本高呢？

比如，思考產品定義，反復權衡模塊的優先級。

比如，會在乎實現方案選型，用 Framer + Coding 進行最終效果的實現也是我思考確認后決定的

比如，獨立模塊開發完成后，代碼之間還需要打通，讓數據流轉起來，還要對每個模塊進行邊界場景測試，確保產品穩定可用。

比如，需要考慮數據緩存，減少 API 消耗；優化加載規則，保證頁面流暢度和體驗。

這些細節的耗時，可能是設計師在企業合作中容易忽略的。設計之外，需求定義、開發、運營，每一環節都不容易。這份體驗讓我在跨職能協作時多了一分理解，少了一分抱怨。

把手弄臟了，所以能更具象的感知

說來慚愧，盡管做設計多年，也設計過各種客戶端和后臺產品，但直到這個個人項目的實踐，我才真正理解了許多基礎概念。

"后端數據如何通過 API 傳輸給前端"、"后端數據是如何保存在服務器上的"、"后端和前端數據是怎么打通的"……這些我曾經從未深究過的問題，以一種具象的方式呈現在我面前。

當我看到自動化腳本控制我的電腦打開不同網頁并爬取數據時（也許這對于開發同學來說真的沒什么），作為一個小白，我真切地體驗到了 Aha moment。

雖然有了 AI，但你原先的能力仍然重要

開玩笑的說，這一次和 AI 協同做項目的經歷，是個對獨立開發“祛魅”的過程（人通常會對被 AI 加持后的事情想得太簡單）。開發完前端網頁后我問過程序員朋友，這么些功能你來做需要多久？他的回答讓我汗顏

AI 的潛力遠超我們的想象，但使用工具的人的能力往往決定了工具發揮的上限。

好了，說了這么多心路歷程，希望 AI Coding 小白朋友們不要被我勸退（這和宣傳 10 分鐘就能開發出產品的自媒體完全不一樣啊哈哈哈哈）。就像學習任何設計技能一樣，我的大部分時間都花在了"學習-理解-實操-沉淀"的循環中。度過最初的幾道坎，積累一些經驗后，進度自然會越來越快。

六、節語

其實，我很難繼續用言語和你表達第一次獨立完成項目是怎樣的一種感覺，我想這必定只有親自實踐后才能了解，AI Coding 正在以前所未有的頻率為我帶來 Aha moment。

我也意識到我是真的熱愛這個行業，熱愛創造些什么。大浪到來時，愿我們都身處其中，迎著浪花前行。

最后歡迎大家訪問我的網站：GenLumio — AI Video Tools & Best Works｜ https://genlumio.framer.website/