[AI 分享] Vibe Coding 先定技術路線

摘要 : 用AI做專案別急著寫程式，先確定產品形態與技術棧，選成熟方案並寫進文件，避免專案一路跑偏。

內容:

如果你一開始就讓 AI 直接寫程式碼，專案很可能從第一步就開始跑偏。剛開始用 AI 做專案的人，最缺的通常不是寫程式的能力，而是不知道應該讓 AI 依照什麼技術路線、框架規範與開發邊界來執行。

AI 很強，但如果沒有明確邊界，它就容易自由發揮，今天這樣寫、明天那樣改。最後表面上看起來能跑，實際上專案內部可能已經變得很混亂。因此，立項之後不要急著開發，先確定技術棧才是更重要的下一步。

所謂技術棧，可以簡單理解成這個專案要用哪些技術、框架、工具與 SDK 來完成。你做的是網站、小程式、APP，還是純後端介面，不同產品形態會直接決定後續的開發方式。產品形態不同，技術棧就不同，連帶影響專案結構、開發流程與部署方式。

第一步，是先確定產品形態。你要先問自己，這個產品最後是以什麼形式提供給使用者？是網站、小程式、APP、後台管理系統，還是只提供給其他系統呼叫的純後端介面？如果這個問題還答不上來，就不適合讓 AI 開始寫程式，因為連產品形態都沒確定，後面的技術選型一定會混亂。

如果做的是網站，就優先考慮 Web 前端技術棧；如果做的是小程式，就要遵守對應平台的開發規範；如果做的是 APP，就要思考原生、跨平台或其他技術方案；如果是純後端介面，重點則會落在 API 設計、資料庫與服務部署，而不是前端。

如果你無法判斷產品應該做成哪種形態，可以請 AI 根據立項文件來分析，結合產品目標、使用場景、核心功能與後續規劃，判斷最適合的形式並說明理由。重點不是讓 AI 隨便替你拍板，而是讓它基於已知事實，給出清楚的主線判斷。對新手來說，真正需要的不是很多看似合理的方案，而是一條當下最適合執行的方向。

第二，技術棧不是越高級越好。很多新手很容易被流行框架或新工具帶偏，今天看到這個很火，明天又覺得那個很新，就認為自己的專案也應該跟上。但做專案不是比誰技術名詞多，尤其在用 AI 開發時，更不能為了看起來厲害就亂選技術。

如果只是一般官網，未必需要一開始就搭很複雜的前後端架構；如果只是輕量工具，也不一定要引入大型框架。當你連部署、維護與後續更新都還沒想清楚時，過度追求高級技術，只會讓專案更難收尾。技術選型最重要的從來不是新，而是合適。它要適合產品形態、專案複雜度，也要適合 AI 理解與後期維護。

第三，優先選成熟框架與 SDK。現在很多常見功能其實早已有成熟方案可用。專案中會遇到的技術棧、功能模組、第三方 SDK，通常都有現成輪子。這些成熟方案不只是讓你開發更快，更重要的是能幫你減少大量試錯、重寫與踩坑時間。

尤其對不會寫程式的人來說，更不應該讓 AI 在沒有框架約束的情況下從零亂造。成熟框架的價值，不只是提供現成能力，更在於它通常自帶專案結構、開發規範、最佳實踐與社群經驗。它不只告訴你能怎麼寫，也告訴你應該怎麼寫。

新手最缺的往往就是規範。AI 雖然是很強的編碼助手，但如果缺乏規範，它很容易亂寫、繞路、補丁式修修補補。相反地，如果你選擇成熟框架，並且明確要求 AI 必須遵守官方規範、目錄結構與推薦寫法，專案品質通常會穩定很多。你甚至可以直接要求 AI：這個專案必須嚴格遵守框架官方規範，不允許為了省事繞開框架設計。這樣能有效降低 AI 在開發過程中的飄移。

第四，要學會判斷一項技術靠不靠譜。即使你不懂程式碼，也不代表完全無法判斷技術風險。你可以要求 AI 幫你檢查一些關鍵指標，例如：這個技術是否有足夠多人在用、是否仍在持續維護、文件是否完整、社群是否活躍、最近更新時間是否過久，以及授權協議是否允許商業使用。

如果是開源專案，還可以請 AI 檢查 GitHub 的 Star 數、Issue 活躍度、最近提交時間、版本釋出記錄與實際使用案例。Star 不是唯一標準，但可以反映一定程度的關注度。社群活躍度則非常重要，因為一旦技術出了問題卻沒人維護，後續會非常痛苦。

授權協議也不能忽略。有些專案可以自由商用，有些則有限制。如果未來要正式上線、收費或營運，就一定要先讓 AI 協助確認授權是否允許商業使用。若對某個 SDK 有疑慮，也可以進一步追問 AI：它是否長期未更新、是否存在明顯風險、是否適合商業專案、未來使用者量變大時是否容易出現瓶頸。你不需要自己成為技術專家，但要學會讓 AI 把風險講清楚。

第五，讓 AI 給你唯一推薦方案。沒有程式碼基礎的人，當然可以讓 AI 推薦技術棧，而且應該這麼做。但關鍵不在於能不能問，而在於怎麼問。不要只問「這個專案適合什麼技術棧」，而是應該把整理好的立項文件、產品形態、功能範圍、目標使用者、部署要求與後期規劃一併提供給 AI，再要求它根據這些條件，給出當前專案的唯一推薦技術棧。

因為對新手來說，最麻煩的不是沒有方案，而是方案太多。AI 常常會一次列出三四套技術棧，每一套看起來都合理，但你最後反而不知道怎麼選。技術判斷能力不足時，很容易在不同方案之間來回搖擺。所以你要要求 AI 直接推薦一條最適合的主線，並清楚說明為什麼選它、為什麼其他方案不適合目前專案、這套技術棧能滿足哪些需求，以及後續可能有哪些風險。

如果確實有備選方案，也應該只把它們作為取捨說明與風險補充，而不是把它們變成新的選擇題。專案一旦啟動，就必須先收斂到一條清楚的技術路線。用 AI 做專案最怕的，就是技術路線不穩，今天用這個、明天換那個，最後專案很容易變成一堆拼湊起來的程式碼。

第六，技術棧一定要寫進專案文件。技術選型討論完之後，不要只是口頭聊完就開始開發。因為隨著專案時間拉長、對話上下文變多，AI 很容易忘記當初為什麼這樣選，也可能在中途引入一些根本不必要的新技術。

你應該要求 AI 把技術選型正式寫進立項文件或專案規劃文件中，至少包含：產品形態是什麼、前端用什麼、後端用什麼、資料庫用什麼、主要框架與 SDK 是什麼、為什麼這樣選、哪些技術刻意不用，以及在什麼情況下才需要重新評估技術路線。

這份文件不是裝飾品，而是後續 AI 開發專案時的重要依據。每當 AI 想引入新框架、新工具或新架構時，都應該先回頭檢查這份文件，確認是否符合目前的技術主線、有沒有破壞專案邊界、會不會讓專案變得更複雜。技術選型不是為了限制專案，而是為了讓專案始終維持清楚的主線。

最後，選擇技術棧的本質，其實就是在替專案打地基。很多人一開始做 Vibe Coding，最容易犯的錯誤，就是一上來就讓 AI 開始生成程式碼，卻沒有先把技術方向、框架規範與開發邊界定清楚。程式碼可以很快寫出來，但如果地基沒打穩，後面專案越做越大時，問題只會越來越多。