當產品經理面臨自身痛點時，傳統的解決方案往往陷入開發排期難、外包成本高的困境。vibe coding 的出現徹底改變了這一局面，讓不會寫代碼的產品人也能實現從需求到上線的完整閉環。本文通過一個充電樁聚合頁面的真實案例，詳細拆解了如何用 AI 生成代碼、逆向破解小程序接口、部署服務器并實現自動化更新的全流程，為產品經理提供了一個完整的 DIY 解決方案。

———— / BEGIN / ————

一、從痛點到上線：一個產品經理的閉環實驗

做產品這么多年，我一直覺得自己做的事情就是用同理心解決別人的痛點。但有個尷尬的事實：當痛點出在自己身上時，往往束手無策。 不是想不到方案，而是做不出來。找開發排期，想屁吃，就一個玩票性質項目；找外包，一個簡單的數據看板報價兩萬起。自己學寫代碼？投入產出比不劃算。

但是 vibe coding 改變了這件事。所謂 vibe coding，就是你不一定需要會寫代碼，只要能把需求描述清楚，AI 就能幫你生成可運行的代碼。這對產品經理來說是一個質變。我們擅長定義問題和拆解方案，過去卡在實現環節，現在這個環節被 AI 補上了。

我拿自己遇到的一個真實痛點驗證了這件事。公司園區有免費充電樁，但體驗很差。想充電，要么親自下樓走到充電樁位置看有沒有空位，要么打開小程序查看。樓下有蔚來和公牛兩家供應商，蔚來的小程序入口藏了四五層才到充電樁狀態頁面，公牛又是一個完全不同的小程序。查一個空樁的操作成本，高到讓人想放棄。只能在充電接力群里求接力。

我的需求很明確：一個頁面聚合所有充電樁的實時狀態，空著、充著、占著一目了然，還支持郵件訂閱空閑提醒。產品邏輯拆解下來就三件事：后端定時采集數據存數據庫，API 接口給前端提供數據，前端展示狀態卡片加訂閱表單。

我讓 AI 寫了代碼，用的技術棧很樸素：前端原生 HTML + JavaScript + Tailwind CSS，后端 Flask + MySQL。沒有框架、沒有工程化、沒有測試用例，一個后端同學看了大概會搖頭，這代碼就是典型的”屎山”。但我不在意，因為從 0 到 1 的業務價值是真實的。

這個項目最難的地方是微信小程序逆向破解。充電樁的狀態數據藏在蔚來和公牛的小程序里，小程序沒有公開 API，網上找各種方法始終無法處理。后來發現一個野路子：把小程序的代碼包直接打包下來，扔給 AI 自己去分析接口和加密邏輯，破解過程全交給它，解決一切煩惱。這一步搞定了，后面就是定時請求存數據庫的事。

上線兩周，公司內部接近上百人每天用它查充電樁，訂閱通知發了幾百封郵件。一個沒人排期的需求，從想法到上線再到完全真正可用不到一周搞定。

這個體驗讓我重新審視了 vibe coding 的定位。很多開發同學批評 AI 生成的代碼質量差、沒有工程化、屎山一堆，這些批評都對。但對于不會寫代碼的人來說，”優雅的代碼”和”能跑的代碼”之間不是二選一，而是”能跑的代碼”和”根本沒有代碼”。vibe coding 解決的是后一個問題：讓你從 0 到 1 把東西做出來。先驗證業務邏輯是否成立，再考慮代碼質量是否需要優化。這也是互聯網產品的基本思路：先上線，再迭代。

說回正題。AI 幫我解決了寫代碼的問題，但代碼能跑在本地和真正能在互聯網上訪問，中間隔著一整條部署鏈路。網上關于部署的教程幾乎全是寫給開發者的，滿屏命令行和術語。這篇文章要講的，就是寫完代碼之后的事：一個不會寫代碼的人，怎么把項目從本地搬上互聯網。

二、選對部署方案：先判斷項目類型

很多人一想到部署就買服務器，其實有些項目根本用不著。選錯方案不僅浪費錢，還會增加不必要的運維負擔。

判斷方法很簡單：問自己一個問題，你的項目有沒有后端邏輯？后端邏輯包括需要數據庫、需要定時任務、需要服務端處理請求。如果都沒有，你的項目就是純靜態的。

純靜態項目，也就是只有 HTML、CSS、JavaScript，所有邏輯在瀏覽器里跑、不依賴服務端的項目，有三條路可選。OSS 對象存儲托管最省事，阿里云 OSS、騰訊云 COS、Cloudflare R2 都支持把靜態文件直接扔上去當網站用，創建 Bucket、開啟托管、傳文件三步搞定，費用按流量算，個人項目一個月幾毛錢。GitHub Pages 更簡單，代碼推到倉庫，Settings 里開一下 Pages 就自動部署，免費且自帶 HTTPS。Vercel 和 Netlify 適合 React、Vue 項目，推代碼自動構建部署，免費額度夠用。這三種方案共同點是不用管服務器、不用裝環境、不用配 Nginx，但前提是你的項目沒有后端。

一旦涉及數據庫、定時任務、API 接口，上面那些方案就不夠用了，你得有一臺服務器。有人會問 Docker 容器化呢？確實更規范，但對新手來說學習成本太高，Dockerfile、鏡像構建、容器編排每一步都是新概念。第一個項目我建議直接買輕量應用服務器，用最樸素的方式部署。理解了全鏈路之后再考慮容器化也不遲。

我這次選了阿里云輕量應用服務器，2 核 2G 內存，一年 68 元。騰訊云也有同類產品，價格差不多。云廠商新人都有優惠，買完一個第二年換個廠商可以繼續薅。

三、服務器部署四步走

服務器買完是個空殼，你要做四件事：裝環境、拉代碼、起服務、配域名。下面一步步講，重點說清楚每步為什么做、哪里容易踩坑。

第一步，裝基礎環境。服務器需要裝 Python 3 跑后端、MySQL 存數據、Nginx 做流量分發、Git 拉代碼。Ubuntu 22.04 自帶 Python 3，其他的基本上一條命令就能裝好。以前裝這些環境得在網上翻各種教程，一篇博客能踩三四個坑?，F在不用了，打開豆包、元寶或者 Gemini，直接問「xxx 操作系 怎么裝 MySQL 和 Nginx」，它會一步步給你命令，遇到報錯把錯誤信息丟給它接著問就行。更狠一點，直接把服務器 IP 和密碼發給 Claude Code 或者 Codex，讓它 SSH 上去幫你把環境全部配好，你坐在旁邊喝咖啡就行。這里有個容易忽略的事：MySQL 裝完要初始化，初始化時會讓你設 root 密碼、決定是否允許遠程登錄。建議不允許遠程登錄，安全性更高。然后單獨創建一個數據庫和用戶給項目用，別用 root 賬號連數據庫。

第二步，把代碼拉到服務器。代碼在 GitHub 上，服務器上 clone 下來就行。但拉之前要配 SSH Key，讓服務器能免密訪問你的 GitHub 倉庫。原理不復雜：服務器上生成一對密鑰，公鑰貼到 GitHub 的 SSH Keys 設置里，私鑰留在服務器上，配好后就能用 SSH 方式 clone 倉庫了。拉下來之后裝 Python 依賴，再把 API Token、數據庫密碼這些敏感信息填到 .env 文件里。.env 是環境變量配置文件，代碼通過它讀取敏感參數，不用硬編碼在代碼中。確認 .gitignore 里已經排除了 .env，千萬別提交到倉庫。我見過有人把數據庫密碼推到公開倉庫，半天就被掃描到了，比你想的快得多。

第三步，讓服務持續運行。你直接運行 python server.py，終端關了服務就停了。Linux 有個服務管理工具叫 systemd，專門解決這個問題。寫一個配置文件告訴它程序怎么啟動、掛了自動重啟、開機自動啟動，服務就在后臺持續運行了。我的項目有兩個后端服務：API 服務和數據采集器，分別寫了 service 配置，都設了 Restart=always。API 服務用 gunicorn 啟動，這是 Python 的生產服務器，比 Flask 自帶的開發服務器穩定得多。這里有個坑：每次修改 service 配置文件之后，必須執行 systemctl daemon-reload，否則 systemd 用的是內存中的舊配置，你改的東西不會生效。我踩過兩次。

第四步，Nginx 統一入口。兩個服務跑起來了，但用戶怎么訪問？API 監聽 5001 端口，前端是靜態文件，用戶總不能輸端口號吧。Nginx 做的事就是統一入口：用戶訪問 80 端口，Nginx 根據請求路徑分發，訪問頁面返回前端靜態文件，訪問 API 轉發到后端 5001 端口。這個機制叫反向代理。你可以這么理解：Nginx 是前臺接待，用戶來了先問它，它根據你要辦什么事（訪問路徑），把人帶到對應的窗口。配好 Nginx 之后，域名解析到服務器 IP，瀏覽器輸入域名網站就上線了。HTTPS 建議配上，certbot 一行命令申請免費證書，自動續期。沒有 HTTPS，瀏覽器標不安全，微信里打開還可能被攔截。

四、自動化部署與避坑從手動到自動：推代碼就上線

第一次部署是手動操作的，SSH 登錄服務器、拉代碼、裝依賴、重啟服務、驗證，一套下來十幾分鐘，每次改代碼都得重復。這種重復勞動不能忍。

自動化部署的思路：代碼推到 GitHub 的 main 分支，GitHub 自動 SSH 到你的服務器執行部署腳本。你只管 push，線上自動更新。

整件事的關鍵在于建立 SSH 信任鏈。在 GitHub 倉庫里配置三個 Secret：服務器 IP、登錄用戶名、服務器的 SSH 私鑰。私鑰來源跟前面一樣，服務器上生成密鑰對，公鑰留在服務器的授權列表里，私鑰配到 GitHub Secrets 里。私鑰是敏感信息，只能放在 Secrets 里，絕對不能提交到倉庫。

這個事情本質也簡單，配置完登錄信息后，直接讓 CC 或者 Codex 寫個 deploy.yaml 腳本即可。，遇到問題就讓 Agent 自己分析，你只需要負責驗證最終完成的效果即可。

部署腳本要完成三件事：更新代碼和依賴、重啟服務、驗證部署成功。更新就是 git pull 加 pip install。重啟之前要先更新 service 配置和 Nginx 配置（如果改過的話），然后 daemon-reload 再 restart。驗證這步很多人會省，但我覺得最不該省。部署完不驗證，怎么知道上線成功了？腳本最后會請求健康檢查接口和前端頁面，確認 API 正常響應、頁面正常訪問，任何一步失敗就中斷部署。

從這以后，本地改完代碼，git push 一下，等一兩分鐘線上就更新了。

五個高頻踩坑點

部署這條路上坑不少，把我踩過的和幫別人排查過的整理一下。

坑一，Flask 開發服務器上線。最常見的新手錯誤。Flask 自帶的 app.run() 是開發服務器，單線程、沒有容錯、沒有并發能力，一掛就沒了。線上環境必須用 gunicorn 或 uWSGI。別用 Flask 開發服務器上線，別問我是怎么知道的（其實小項目也可以）。

坑二，敏感信息硬編碼。API Token、數據庫密碼寫在代碼里推到公開倉庫，半天之內就會被自動化掃描工具發現。GitHub 上每天都有機器人掃描泄露的密鑰。用 .env 文件管理，.gitignore 排除，部署腳本里檢查 .env 是否存在，沒有就中斷部署。

坑三，Nginx 配置改完不測試。Nginx 配置寫錯了不會彈窗報錯，直接用錯誤配置 reload 會導致整個網站掛掉。養成習慣：改完配置先 nginx -t 測試語法，通過之后再 reload。部署腳本里也要加這個檢查。

坑四，前端更新了用戶看不到。Nginx 默認緩存靜態資源，你更新了前端代碼，用戶瀏覽器還在用舊的緩存版本。解決方案是區分對待：圖片字體設 7 天緩存，JS 和 CSS 設不緩存，確保更新立即生效。不然你改了 bug 用戶還在看舊版本，提了工單你一臉懵。

遇到問題怎么排查？方法只有一個：看日志。服務跑不起來了，systemctl status 服務名 看狀態，journalctl -u 服務名 看日志。Nginx 報錯了看 /var/log/nginx/error.log，MySQL 連不上了看 /var/log/mysql/error.log。

別瞎猜，日志會告訴你到底哪里出了問題。95% 的部署問題看日志都能定位到原因。

五、從 0 到 1 的方法沉淀

回頭看整個鏈路，可以抽象成一個通用的六步法，以后做別的項目照著走就行。

第一步，判斷項目類型。有后端邏輯就買服務器，沒有就選靜態托管。別上來就買服務器，花錢還增加運維負擔。這一步決定了你后面所有工作的復雜度，選錯了回頭再改成本很高。

第二步，買服務器裝環境。輕量應用服務器就夠，別買 ECS。系統選 Ubuntu，裝好 Python、數據庫、Nginx、Git。MySQL 裝完記得初始化，創建項目專用的數據庫用戶。這步最怕的是跳過 MySQL 初始化直接用，后面數據庫權限問題會一直追著你。

第三步，代碼上服務器。配 SSH Key 免密訪問 GitHub，clone 倉庫，裝依賴，填環境變量。環境變量放 .env 文件，確認 .gitignore 排除了它。這步最怕的是把 .env 推到倉庫，敏感信息泄露的風險比你想象的大得多。

第四步，服務持續運行。用 systemd 管理，設置自動重啟和開機啟動。service 文件改完一定要 daemon-reload，不然改了白改。這步最怕的是直接 python server.py 前臺跑，終端一關服務就沒了。

第五步，Nginx 統一入口。前端走靜態文件，API 走反向代理。配域名解析，加 HTTPS。這步最怕的是 Nginx 配置改完不測試就 reload，一個語法錯誤整站掛掉。

第六步，自動化部署。GitHub Actions + SSH，推代碼自動上線。部署腳本必須包含驗證步驟，不然你永遠不知道上線到底有沒有成功。

這六步走完，項目就是一個可以在互聯網上訪問、自動部署、掛了自動恢復的正式網站了。

最后想多說一點。

踏出第一步，比什么都重要。

很多人會給自己預設一堆困難：「我不會寫代碼」「我不懂服務器」「我連 Git 都不會用」。這些在今天都不再是障礙。

模型方面，不用非得等 GPT 的額度，國產的 GLM5.1、Mimo 2.5Pro、DS4Pro 都能用，日常開發夠了。

工具方面，Claude Code、Codex 這些 Agent 可以直接在瀏覽器里用，網上搜一下教程就能上手。

Git 不會用？直接問 AI，它會一步步教你，比翻文檔快十倍。遇到任何問題，把報錯信息扔給 AI，它比 Stack Overflow 好使。

我說一個最實際的建議：用 AI 做一個小產品，走完從開發到部署上線的完整閉環。這個過程本身就是在學，而且學到的東西比看十篇文章都多。等你走完一遍，后面再做項目就是復制粘貼改參數的事。

vibe coding 讓不會寫代碼的人也能把需求變成可運行的產品，這件事的意義比很多人想象的要大。開發同學可能會覺得 AI 生成的代碼質量差、沒有工程化、屎山一堆，這些批評都對。但站在產品視角，從 0 到 1 的業務價值是真實的。我的充電樁項目代碼寫得糙，可它確實解決了很多人每天查充電樁的問題。一個自己用的需求，根本不會進入任何人的排期。先讓它跑起來、讓用戶用起來、讓數據跑起來，再談重構和優化。

技術的門檻在消失，真正剩下的門檻只有一個：你愿不愿意動手。

本文來自公眾號：進擊的零度 作者：零度Pasca