從項目規(guī)劃、技術(shù)選型、開發(fā)過程到上線運營，作者詳細記錄了每一個階段的挑戰(zhàn)與收獲，并提供了實用的Cursor提效攻略。如果你也想嘗試用AI開發(fā)自己的項目，這篇文章將為你提供寶貴的參考和啟發(fā)。

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

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

一、網(wǎng)站介紹

為什么會有這個項目

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

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

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

功能介紹

網(wǎng)站1期

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

目前涵蓋的全部分類字段

前端網(wǎng)站基于Framer進行搭建，一半使用代碼一半使用Framer實現(xiàn)交互邏輯。因目前數(shù)據(jù)存儲服務器在新加坡，目前需科學訪問。

接下來我想做什么

B端产品经理的能力模型与学习提升

B端产品经理面临的第一大挑战，是如何正确的分析诊断业务问题。 这也是最难的部分，产品设计知识对这部分工作基本没有帮助，如果想做好业务分析诊断，必须具备扎实 ...

查看详情 >

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

二、項目經(jīng)歷全面分享

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

最終1期實現(xiàn)的全部功能

調(diào)研期｜讓AI 參與規(guī)劃，技術(shù)小白不要怕

最開始，我滿腦子都是對這個項目的困惑：應該怎么實現(xiàn)？難度有多大？我能做到嗎？完全沒有頭緒。于是，我打開 ChatGPT，將自己的想法全盤托出，然后讓 AI 給我解構(gòu)：需要用到哪些技術(shù)？有哪些工具可以解決問題？哪些地方是盲區(qū)需要補課？

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

• 網(wǎng)頁爬蟲：GitHub 上已經(jīng)有類似項目，大概看了看思路，驗證這條路是走得通的。
• 后端云存儲：AI給我推薦了 MongoDB Atlas 的免費方案，基本確認項目成本可控。
• Framer + API 方案：了解到 Framer 自帶 fetch 功能，可以從服務器拉取數(shù)據(jù)隨機展示（雖然最后沒用這個，而是自己寫了代碼組件）。
• 前端視頻加載：淺淺了解了一下如何提高視頻加載速度，避免產(chǎn)品做出來用戶體驗太差。

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

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

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

• 數(shù)據(jù)爬?。∕VP驗證）—— 寫了個初步的爬蟲腳本，把推特的文本、圖片、視頻信息爬下來，導出 JSON 文件。
• 連接云服務器 —— 寫了初步的后端代碼，把爬取的數(shù)據(jù)直接存到服務器。
• 插件交互實現(xiàn) —— 給插件加上彈窗進行標簽選擇。

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

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

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

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

這一階段的收獲：

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

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

這個階段主要完成了：

• 產(chǎn)品起名、logo和1期頁面的設(shè)計
• 視頻總數(shù)、視頻模塊在前端的展示
• 邊開發(fā)邊摸索和AI對話的方法

經(jīng)歷了無數(shù)枯燥的爬蟲 & 后端調(diào)試，我終于可以 開始設(shè)計前端頁面了！不過這之前，先要給網(wǎng)站取個名字。

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

fetch只能支持少量、隨機出現(xiàn)的數(shù)據(jù)，比較適合Demo使用

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

這一階段的收獲：

1. 理解了線上部署的重要性 —— 本地開發(fā) ≠ 線上可用，必須將后端代碼推到 Git上并部署到Vercel上，才能讓別人訪問我的網(wǎng)頁。

2. 認識到 MVP 的必要性 —— 不能對炫酷效果有貪念，把核心功能跑通后再考慮其他。

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

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

這個階段主要完成了：瀑布流、加載邏輯優(yōu)化、分頁器、篩選等功能開發(fā)，此外還包括設(shè)計還原、優(yōu)化加載機制緩存邏輯…

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

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

那時候的瀑布流效果

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

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

實現(xiàn)Masonry 布局后的效果

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

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

新周期｜項目并沒有結(jié)束，新功能開發(fā)、SEO、學習運營

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

• 長期規(guī)劃：這個項目值得我長期投入嗎？長期愿景和后續(xù)的功能迭代計劃是什么？
• 資源投入：在沒有明確的成功預期下，是否應該為更多工具付費？
• SEO：新品牌名不利于搜索排名，當初是不是應該蹭個關(guān)鍵詞？
• 合規(guī)與數(shù)據(jù)：是否要做國內(nèi)數(shù)據(jù)備份和網(wǎng)頁備案？
• 開發(fā) vs 運營：業(yè)余時間和精力有限，如何平衡開發(fā)和推廣？

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

三、Cursor高效溝通法則

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

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

一個問題一個Chat

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

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

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

• AI 多次給出錯誤的解決方案，即使你已經(jīng)指出問題；
• AI 反復提供你已經(jīng)驗證無效的方案，無法跳出思維定式。

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

多文件修改使用 Composer

當涉及模塊間的數(shù)據(jù)聯(lián)調(diào)（即多個代碼文件需要協(xié)同工作）時，建議使用 Cursor 的 Composer 功能，而不是普通 Chat。

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

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

• Chat 模式：AI 提供的代碼修改方案需要手動點擊 “Apply” 才能生效。
• Composer 模式：AI 的修改建議會自動Apply到代碼文件中（當然，不滿意的部分依然可以手動拒絕）。

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

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

告訴Cursor不要急于寫代碼

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

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

應用案例：

引導 AI 提問，避免無腦執(zhí)行

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

應用案例：

讓AI繼續(xù)向我確認需求細節(jié)

減少AI亂改代碼的概率

強調(diào)不要修改無關(guān)代碼

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

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

• 強調(diào)自己是代碼小白，讓 AI 生成更詳細的中文批注，幫助我們理解代碼邏輯，方便后續(xù)人工檢查AI的改動建議。
• 在需求描述中明確范圍，指明哪些代碼可以修改，哪些不能動，以降低 AI 誤改的概率。

做好 .md 需求文檔沉淀

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

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

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

調(diào)用Prd.md文件并說明最新任務

• 明確指示 AI 閱讀需求，避免因多個文件 @ 過多而遺漏關(guān)鍵內(nèi)容。

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

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

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

AI幫我總結(jié)的功能需求點

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

這個方法是從即友@MooreAI那里學到的，”思維鏈”（Chain of Thought）是一個有效的 AI 提示技巧，它可以減少 AI 的模糊推理，讓它進行更嚴謹?shù)倪壿嬎伎迹m用于 復雜計算、代碼分析、任務規(guī)劃 等場景。

高效Debug：添加調(diào)試代碼，幫助定位原因（??重要經(jīng)驗 ）

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

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

1. 讓 AI 添加調(diào)試代碼
2. 將代碼粘貼到 Framer 的代碼編輯器 運行，查看實際執(zhí)行情況。

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

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

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

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

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

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

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

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

四、小白開發(fā)者的思考

精簡，再精簡一點

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

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

用完整產(chǎn)品來驗證市場需求，成本太高了。

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

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

工作量，遠不止呈現(xiàn)給用戶的頁面內(nèi)容

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

• 比如，思考產(chǎn)品定義，反復權(quán)衡模塊的優(yōu)先級。
• 比如，會在乎實現(xiàn)方案選型，用Framer + Coding進行最終效果的實現(xiàn)也是我思考確認后決定的
• 比如，獨立模塊開發(fā)完成后，代碼之間還需要打通，讓數(shù)據(jù)流轉(zhuǎn)起來，還要對每個模塊進行邊界場景測試，確保產(chǎn)品穩(wěn)定可用。
• 比如，需要考慮數(shù)據(jù)緩存，減少 API 消耗；優(yōu)化加載規(guī)則，保證頁面流暢度和體驗。

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

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

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

“后端數(shù)據(jù)如何通過API傳輸給前端”、”后端數(shù)據(jù)是如何保存在服務器上的”、”后端和前端數(shù)據(jù)是怎么打通的”……這些我曾經(jīng)從未深究過的問題，以一種具象的方式呈現(xiàn)在我面前。

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

雖然有了AI，但你原先的能力仍然重要（這里感覺要補充）

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

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

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

五、節(jié)語

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

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