從項目規劃、技術選型、開發過程到上線運營，作者詳細記錄了每一個階段的挑戰與收穫，並提供了實用的Cursor提效攻略。如果你也想嘗試用AI開發自己的專案，這篇文章將為你提供寶貴的參考和啟發。
自 24 年 11 月起，我開始動手打造一個專注於 AI 視頻作品展示 的網站。在 AI 的助力下，我獨立完成了 前後端與外掛程式開發，成功落地了人生第一款真正意義上的個人作品。目前，網站已收錄 300+ 優秀 AI 視頻。
這篇文章將圍繞 項目介紹、開發歷程、工具使用心得、小白成長思考 等方面，分享我在這幾個月中的所有收穫與感悟。
去年 9 月，我寫完 AI 視頻工具的測評后，原計劃 10 月快速推出一篇 AI 視頻作品推薦，展示當時的 AI 視頻能力。然而，行業更新速度驚人——Luma 崛起，國產 Kling、Hailuo 誕生，Hailuo I2V、Vidu 在動漫風格上的突破……每隔幾天，我都會在 X 上刷一波最新 AI 視頻案例，一篇文章已難以承載我想分享的內容。
正巧年末 Bolt AI、Cursor 爆火，AI Coding 走紅。我靈機一動，何不做個網頁，在我刷推時同步更新 AI 視頻動態？但…從未寫過代碼的我，能搞定這個專案嗎？
於是，我啟動了前期調研，確定專案涉及 外掛程式開發、數據爬取、存儲、後端 API、前端開發 等工作，並正式踏上 小白 AI Coding 探索之路。
網站1期
網站1期功能比較簡單，主要實現了數據的抓取和網頁前端的同步。你還可以篩選AI視頻使用的具體能力、產品、發佈時間進行分類。通過標籤你可以瞭解到某類視頻創作者最常用的視頻創作工具是什麼，比如Vidu、Luma Ray2是目前平面風格的寵兒，而代替Sora，Veo 是當下txt2vid的王者。
目前涵蓋的全部分類欄位
前端網站基於Framer進行搭建，一半使用代碼一半使用Framer實現交互邏輯。因目前資料儲存伺服器在新加坡，目前需科學訪問。
接下來我想做什麼
我打算優先反覆運算AI視頻工具模組，旨在為大家提供最新工具訊息，參數對比甚至價格資訊，以便找到適合自己的那款產品。
1期開發的整個過程大概分為調研期 – 試水期 – 草莽期 – 規範期 – 收尾期，每個時期的經歷都非常豐富，多了很多“第一次”的嘗試。相信我，這個過程既讓人興奮，又讓人抓狂。
最終1期實現的全部功能
最開始，我滿腦子都是對這個專案的困惑：應該怎麼實現？難度有多大？我能做到嗎？完全沒有頭緒。於是，我打開 ChatGPT，將自己的想法全盤托出，然後讓 AI 給我解構：需要用到哪些技術？有哪些工具可以解決問題？哪些地方是盲區需要補課？
反覆對話和檢索后，我的認知漸漸清晰：
雖然這些知識點當時只是粗淺瞭解，但它們給了我一個更明確點的感受：這項目應該能做。
和AI探討完項目規劃後，我已經迫不及待躍躍欲試了。於是我吭哧吭哧開始了AI Coding之路。這個階段先後完成了：
在這段時間里，我差點被 MongoDB 勸退……
作為資料庫小白，選擇 MongoDB，也是無腦相信了 AI 的推薦，沒有進一步對比看看。結果我卡在URI 連接報錯這一步遲遲無法解決，花了大量時間逐一嘗試 AI 給出的 N 種方案，卻始終無法連接成功，前前後後折騰了好幾天，甚至一度想放棄整個專案。
直到某天，在一個極不起眼的角落裡，我無意間翻到了一條網友評論，才終於找到了正確的解法，這個解放和AI給的答案毫無關係。
現在回頭看，那時的我經驗不足，對 AI 言之鑿鑿的答案深信不疑，但與其死磕 AI 提供的方案，不如早點主動檢索或者換個工具。（如果當時更早瞭解 Supabase，或許數據管理的體驗會比 MongoDB 輕鬆得多。）
這一階段的收穫：
這個階段主要完成了：
經歷了無數枯燥的爬蟲 & 後端調試，我終於可以 開始設計前端頁面了！不過這之前，先要給網站取個名字。
在後端API和前端打通上，我嘗試了 Framer 的 fetch 功能，最終還是轉向了自定義代碼元件，通過自己寫代碼元件實現數據拉取。
fetch只能支援少量、隨機出現的數據，比較適合Demo使用
然而，嘗到一點AI Coding的甜頭后是真的很容易上頭，在這個階段，我也犯了一個典型的設計師思維錯誤 —— 過度關注設計效果。我無意間看到一個很酷的懸浮可變字體效果，就立刻想將其應用到網站標題上。我花費了幾天時間實現滑鼠懸停時的可變字體效果，卻最終受限於Framer對可變字體渲染支援不足而無法實現。後續項目復盤，我意識到這是一件非常不符合 MVP 原則的事。
這一階段的收穫：
1. 理解了線上部署的重要性 —— 本地開發 ≠ 線上可用，必須將後端代碼推到 Git上並部署到Vercel上，才能讓別人訪問我的網頁。
2. 認識到 MVP 的必要性 —— 不能對炫酷效果有貪念，把核心功能跑通后再考慮其他。
在上個週期，我和 AI 的對話往往很隨意，用幾段話大致描述完背景和任務，等 AI 輸出后發現效果不是我想要的再反覆溝通修改調整，比較費時間也很熬心態。而到了這個階段，開發的模組逐漸複雜起來，我開始嘗試用 .md 檔整理需求，嘗試將各類交互細節都盡可能溝通清楚后再讓AI撰寫代碼。
這個階段主要完成了：瀑布流、載入邏輯優化、分頁器、篩選等功能開發，此外還包括設計還原、優化載入機制緩存邏輯…
其中瀑布流佈局可能是繼 MongoDB 連接錯誤之後，最讓我頭疼的部分。
AI很厲害，但有時也沒有那麼強，儘管它給我科普了Grid 、Column 、Flex、Masonry佈局的方案差異，但大戰n個來回，它就是寫不出類似網頁版小紅書的 Masonry 瀑布流效果，代碼在幾個錯誤的效果之間反覆修改橫跳，導致我幾度想放棄這個嘗試，甚至考慮用自動載入來弱化布局問題。
那時候的瀑布流效果
在這關鍵時刻，我的程式師朋友出手了，他幫我找到了一篇詳細解析 Masonry 佈局的文章。我讀懂後，立刻讓 AI 閱讀學習，並在.md 檔中詳細定義高度計算邏輯，最終成功實現了理想的瀑布流效果。
這再一次說明，不要過分依賴現階段的AI，適時主動搜索、借鑒已有經驗，比盲目試錯高效得多。
實現Masonry 佈局後的效果
代碼開發的模組全部完成後，我在Framer中繼續完善了網站的其他部分，比如 頂部導航、背景圖、品牌展示、底部欄、回到頂部模組，以及不同螢幕尺寸的適配。選擇Framer+Coding的本質原因還是對AI Coding的效率不自信，比起和AI死磕，Framer這樣的設計師工具用起來更順手，也更能為我節約時間。
這個階段，我終於告別了“草莽式開發”，進入了更規範的推進方式，進展也愈加順利了。
當1 期功能發佈后，真正的挑戰才剛剛開始。很多看似細小的決定，讓我不得不反覆權衡：
與此同時，我也迎來了許多 “第一次”：第一次正式瞭解 SEO，第一次在海外 嘗試推廣個人專案，現在還處於邊學習邊實踐的狀態。
下面這一節，我會回顧網站1期的開發經歷，講講開發過程中更加具體的實操經驗，如果你也想著手嘗試AI Coding，希望這些經驗可以為你節約一點時間。
注：以下案例基於 Cursor 中的 Claude3.5 Sonnet 模型溝通開發
使用AI Coding工具時，建議把大模組需求拆分成小問題，並為每個新問題單獨開啟一個 Chat 對話。過長的對話可能導致 AI 記憶混亂、回應時間變長，同時也不利於回顧和管理。
我會有意識地管理我的對話，確保在遇到問題時能夠快速回溯，方便項目復盤
如果在某個 Chat 中感覺 AI 陷入了“死胡同”，常見表現包括：
此時，不妨新建一個 Chat，結合錯誤經驗重新描述問題。這往往能説明 AI 重新梳理思路，更快找到正確的解決方案。
當涉及模組間的數據聯調（即多個代碼檔需要協同工作）時，建議使用 Cursor 的 Composer 功能，而不是普通 Chat。
相比 Chat，Composer 能同時分析多個檔，理解代碼上下文，並提供更合理的修改建議，從而提高方案的準確性，大幅提升開發效率。
此外，兩者的另一區別在於代碼的應用方式：
如果你的工作流涉及多個檔的修改，優先選擇 Composer 會更高效。當然，如果你習慣在所有場景下使用 Composer，也完全沒問題。
告訴Cursor不要急於寫代碼
相比 Windsurf，Cursor 更傾向於直接提供代碼，哪怕你只是想討論需求可行性，它也會立刻開始寫代碼（以至於有時會顯得不那麼聽話）。
在專案前期，我們可以先進行發散討論，讓 AI 説明補充不明確的細節，而不是一上來就寫代碼。這時，可以明確要求 AI 暫緩執行，等思路確認后再讓它動手，這樣 Cursor 就會變得更配合。
應用案例：
引導 AI 提問，避免無腦執行
Cursor 預設相信你的判斷，如果你嘗試誤導它，它大概率不會質疑，而是直接按照你的錯誤思路執行。 所以，如果你自己都拿不准解法，一定要讓 AI 反問你，主動確認更多細節。
應用案例：
讓AI繼續向我確認需求細節
強調不要修改無關代碼
在持續優化大型代碼檔時，AI 的不可控性往往讓人頭疼——它可能在優化新功能的同時，反覆誤刪或修改不相關的代碼。
為了減少這種情況，我們可以：
做好 .md 需求文件沉澱
在開發過程中，我們往往需要在新建Chat中向 AI 反覆描述專案背景、進度和新需求。第一，我是通過臨時記錄（微信輸入框、文件等）複製貼上到 AI，對話管理較為混亂。
直到在播客中聽到 Soga 作者分享他用 AI 共同維護 20 萬字 PRD 文檔的經驗后，我開始優化對話策略：
調用Prd.md檔並說明最新任務
除了@ 文件，建議大家用文字再次說明需要AI閱讀檔。因為我們可能同時@多個檔，不重點強調可能會造成AI的漏讀。
在完成了一些大的功能改動后，在進入下一步反覆運算之前，先讓AI先閱讀一遍代碼，自行描述需求細節，完善Prd.md文件。
AI幫我總結的功能需求點
非常建議在Prompt中強調“不需要用代碼的形式呈現，只需要像產品需求說明那樣，文字總結即可”，還是前面提到的，Cursor真的太愛寫代碼了的問題 。沒有這句話，在你反應過來時，它已經又用代碼呈現剛實現過的功能了。
這個方法是從即友@MooreAI那裡學到的，”思維鏈”（Chain of Thought）是一個有效的 AI 提示技巧，它可以減少 AI 的模糊推理，讓它進行更嚴謹的邏輯思考，適用於 複雜計算、代碼分析、任務規劃 等場景。
在實現 視頻瀑布流方案 時，我讓 AI 設計了一套較複雜的計算邏輯。我不想深入閱讀、學習代碼，但仍然需要確認它是否按預期運行。
除了 肉眼觀察判斷，更高效的方法是：
這種方法比起猜測解決方案、胡亂嘗試更高效。
在 Cursor 中，你可以引導 Claude 以更豐富的方式解釋模糊概念，增強理解。
當我不理解某些名詞定義時，Claude 會 舉例說明。儘管Cursor中的Claude目前無法直接生成圖片，但仍可通過 符號、文字排列的方式，讓我更直觀的感受差異。
案例：對比Perplexity和Claude 對瀑布流佈局概念的解釋差異
Perplexity 僅提供文字描述，難以直觀理解
Claude 3.5（在 Cursor 中） 通過 示意圖+對比描述，更形象地説明我理解
經歷過這幾個月的AI Coding，我真實且深刻感受到一個小想法落地成產品的複雜度。還好這是我個人的第一個專案，也是個為了個人學習需求、入門AI Coding的練手專案，我不會有數據目標壓力。
但如果帶入到實際項目場景，我想我們還是要盡可能用更簡單、更輕量的方式去驗證想法。因為一旦決定啟動專案，需求定義、設計、開發、運營都是巨大的工作量。打造一款真正解決問題的產品能讓你更早獲得反饋，也更容易堅持下去。
用完整產品來驗證市場需求，成本太高了。
在需求規劃階段，不妨多問自己：這個功能真的必要嗎？這個效果能簡化嗎？因為即使是讓AI寫代碼，打字描述需求也會打到手指酸痛，讓AI一遍遍改報錯的時候也常常會陷入自我懷疑。
作為設計師，我們尤其需要警惕完美主義的陷阱，學會捨棄，專注MVP。
你可能會好奇，如果單看最終呈現的網頁，功能很簡單——但為什麼我說成本高呢？
這些細節的耗時，可能是設計師在企業合作中容易忽略的。設計之外，需求定義、開發、運營，每一環節都不容易。這份體驗讓我在跨職能協作時多了一分理解，少了一分抱怨。
說來慚愧，儘管做設計多年，也設計過各種用戶端和後台產品，但直到這個個人項目的實踐，我才真正理解了許多基礎概念。
“後端數據如何通過API傳輸給前端”、”後端數據是如何保存在伺服器上的”、”後端和前端數據是怎麼打通的”……這些我曾經從未深究過的問題，以一種具象的方式呈現在我面前。
當我看到自動化腳本控制我的電腦打開不同網頁並爬取數據時（也許這對於開發同學來說真的沒什麼），作為一個小白，我真切地體驗到了Aha moment。
開玩笑的說，這一次和AI協同做項目的經歷，是個對獨立開發“祛魅”的過程（人通常會對被AI加持後的事情想得太簡單）。開發完前端網頁后我問過程式師朋友，這麼些功能你來做需要多久？他的回答讓我汗顏
AI的潛力遠超我們的想像，但使用工具的人的能力往往決定了工具發揮的上限。
好了，說了這麼多心路歷程，希望AI Coding小白朋友們不要被我勸退（這和宣傳10分鐘就能開發出產品的自媒體完全不一樣啊哈哈哈哈）。就像學習任何設計技能一樣，我的大部分時間都花在了”學習-理解-實操-沉澱”的迴圈中。度過最初的幾道坎，積累一些經驗后，進度自然會越來越快。
其實，我很難繼續用言語和你表達第一次獨立完成專案是怎樣的一種感覺，我想這必定只有親自實踐後才能瞭解，AI Coding 正在以前所未有的頻率為我帶來 Aha moment。
我也意識到我是真的熱愛這個行業，熱愛創造些什麼。大浪到來時，願我們都身處其中，迎著浪花前行。
作者：Bay，騰訊體驗設計師，公眾號：Bay的設計奧德賽
本文由 @Bay 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖由作者提供