在政企項目中，需求的不斷變化常常導(dǎo)致項目延期甚至失敗。為了應(yīng)對這一挑戰(zhàn)，一套基于AI的敏捷工作流被提出，旨在快速將需求轉(zhuǎn)化為可交付的產(chǎn)品。本文詳細介紹了這一工作流的四個階段：需求階段、設(shè)計階段、工程化實現(xiàn)階段和交付部署階段，并分享了如何利用AI工具在每個階段提升效率和質(zhì)量。通過實際案例和實用工具的推薦，文章為政企產(chǎn)品經(jīng)理提供了一種新的敏捷實現(xiàn)路徑。

我是Ben，一名政企行業(yè)的解決方案架構(gòu)師，目前正在往AI產(chǎn)品經(jīng)理角色轉(zhuǎn)型。

一、這個工作流適合誰

我將其命名為：基于AI的「需求直達產(chǎn)品」敏捷工作流

如名所示，此工作流并不適合所有人。

更適合與我本職工作類似的角色，比如售前、解決方案、產(chǎn)品經(jīng)理這些角色。

因為這些角色需要頻繁觸碰用戶需求、理解需求并及時轉(zhuǎn)化為「看得見摸得著」的產(chǎn)品。

二、為什么會有這個工作流

我所在的公司承接了些政府定制化項目，這類項目如果無法及時收口需求，往往陷入以下困境：

需求不斷變化->方案頻繁修改->產(chǎn)品原型反復(fù)調(diào)整->開發(fā)延期難驗收->項目爛尾->客戶投訴

以我經(jīng)歷某客戶的綜合業(yè)務(wù)型項目為例。由于涉及高度定制化創(chuàng)新，用戶對【最終交付成品】缺乏清晰認知，導(dǎo)致：

需求溝通階段：用戶提不出系統(tǒng)化的需求，多為以下兩類：

->模糊泛需求：你們好好做，要能讓一線人員用起來……

->領(lǐng)導(dǎo)的意志：領(lǐng)導(dǎo)說了要做XXXXX，你們?nèi)ピO(shè)計一下……

產(chǎn)品設(shè)計階段：用戶看到原型圖后依然模糊不清，僅說：”好，你們抓緊開發(fā)，領(lǐng)導(dǎo)要看效果”

開發(fā)交付階段：第一個模塊上線后，用戶才有了直觀體驗，各種修改意見和新增需求隨之涌現(xiàn)：

->修改速度慢則被催促質(zhì)疑

->領(lǐng)導(dǎo)不滿意則全盤否定，需徹底重構(gòu)產(chǎn)品

從上述案例可見：在定制化項目中，直到V1版本部署上線前，用戶很難對產(chǎn)品形成具體概念，更難以在項目初期提出明確需求。

因此，我開始思考：

如果在需求溝通后立即交付MVP版本，讓用戶實際體驗，是否能夠提前收集反饋并及時調(diào)整？

但傳統(tǒng)流程（需求整理→產(chǎn)品設(shè)計→UI設(shè)計→開發(fā)）周期過長！

有沒有可能通過高效方式由我直接完成這一過程？

于是乎，自己便嘗試與AI工具搭檔試驗，在多個項目的摸索與驗證后，我形成了這套工作流。

三、工作流詳解

本工作流共有4個階段：需求階段->設(shè)計階段->工程化實現(xiàn)階段->交付部署階段，每個階段都有給力的AI工具加持進行提質(zhì)提效！

1. 需求階段

利用通義實時記錄完整轉(zhuǎn)錄用戶需求。會議結(jié)束查看自動生成的【導(dǎo)讀】和【腦圖】以充分理解需求，并在【筆記】中記錄會議關(guān)鍵點。

需要補充信息時，可通過Google（基礎(chǔ)信息檢索）+秘塔搜索（知識深度檢索）獲取。最后，將所有信息匯總到釘釘文檔或飛書文檔中。

2. 設(shè)計階段

2.1 方案設(shè)計

有了需求匯總后，可能還難以立即構(gòu)思清晰的產(chǎn)品設(shè)計方案。

此時，可借助AI大模型輔助構(gòu)建，目前嘗試下來以ChatGPT和DeepSeek效果最佳。

提示詞模板示例如下供參考，自己可以盡情測試，這也是個有趣的過程。歡迎把你覺得好用的提示詞評論告訴我~

你是一名專業(yè)的政企行業(yè)產(chǎn)品經(jīng)理，請你基于下方的項目信息，為我設(shè)計并輸出產(chǎn)品方案，以便我可以將此方案交給前端工程師進行原型開發(fā)。————項目信息————1.項目背景：……2.業(yè)務(wù)需求：……3.使用對象：……

2.2 原型構(gòu)建

接下來就是激動人心的【text to app】環(huán)節(jié)。

將上一步AI輸出的產(chǎn)品設(shè)計方案交給原型構(gòu)建工具：Lovable/ v0.dev / bolt.new / Tempo Labs，等待幾分鐘即可預(yù)覽產(chǎn)品原型。

建議同時使用多種工具生成不同版本的原型，然后從中選擇最佳方案。

注意：

• 查看原型后，可基于不滿意的地方在左側(cè)對話區(qū)域修改指令，并重新生成。
• 推薦僅構(gòu)建前端原型，不做后端數(shù)據(jù)對接。這些工具通常會自動生成模擬數(shù)據(jù)以增強原型的真實感。

下面是簡單的示例，我同時對4個工具下達同樣的指令（構(gòu)建一個文旅智導(dǎo)官），大約3-5分鐘就會生成產(chǎn)品原型。

依次是Lovable, v0.dev, Bolt.new和Tempo Labs：

3. 工程化實現(xiàn)階段

3.1 將原型源文件下載到本地

獲得基本滿意的產(chǎn)品原型后，需將源文件下載到本地進行更細致的修改。這4個AI工具的源文件下載方式分為兩類：

第一類是直接在右上角可以點擊下載，將整個項目的源文件下載到本地。（v0.dev / bolt.new）

第二類是先將項目發(fā)布到自己的github上，然后再從github上將項目下載到本地。(Lovable / Tempo Labs)

3.2 對產(chǎn)品進行修改直至滿意

打開Cursor/Windsurf/Trae這3個工具之一（個人強推Cursor），將上一步下載的文件夾導(dǎo)入。

這三款工具本質(zhì)上是AI增強型IDE（集成開發(fā)環(huán)境），可將項目相關(guān)文件一并導(dǎo)入作為知識庫，幫助它們根據(jù)你的需求創(chuàng)建、引用和修改文件。

首先要克服對”程序員專屬界面”的心理障礙——許多非程序員同事反饋看到這類界面就產(chǎn)生排斥感。

實際使用后你會發(fā)現(xiàn)它們并不復(fù)雜！

以Cursor為例，界面主要分為四個區(qū)域：

1）文件列表區(qū)域：展示項目內(nèi)所有文件；

2）文件內(nèi)容區(qū)域：顯示當(dāng)前選中文件的內(nèi)容；

3）終端運行區(qū)域：運行項目或執(zhí)行命令的交互區(qū)域；

4）AI對話區(qū)域：與AI交流以修改產(chǎn)品的核心區(qū)域；

關(guān)于Cursor的基本操作，網(wǎng)上教程豐富，此處不再贅述。任何你不會的，都可以直接在Cursor的AI對話區(qū)域瘋狂提問。

僅闡述2個觀點：

1. 只要指令清晰 + 小模塊迭代 + 保持耐心 → 100%可完成產(chǎn)品原型
2. 雖然我們不懂代碼，但隨著與AI交互深入，掌握一些基礎(chǔ)前端/后端技術(shù)概念有助于提出更精準的指令。

下面是一個淺顯易懂的舉例，當(dāng)你發(fā)現(xiàn)AI設(shè)計的按鈕太大不符合預(yù)期時，

->非精準指令：

“幫我把按鈕調(diào)小一點，現(xiàn)在太大了”

->結(jié)果：

AI將此按鈕調(diào)得過小，又需反復(fù)調(diào)整

->問題：

我們無法準確描述心中預(yù)期的按鈕大小

->解決方法：

觀察AI修改的文件和參數(shù)，學(xué)習(xí)相關(guān)概念后直接修改。

如下圖所示，AI在回復(fù)中說明了它修改了button.tsx文件中的size屬性（紅色表示原值，綠色表示修改后的值），并總結(jié)了高度從h-10減為h-9。下次不滿意時，你可以直接修改這些參數(shù)直至符合預(yù)期。

因此，當(dāng)你提出修改指令時，建議在指令最后添加：

“請在修改后為我總結(jié)修改了什么文件的什么參數(shù)，并說明這些修改的作用”

通過學(xué)習(xí)AI的回答，你會逐漸掌握”內(nèi)邊距”、”外邊距”、”邊框”等前端術(shù)語，使指令更加精準，而不僅限于”大一點”和”小一點”的模糊表述。

不要排斥學(xué)習(xí)新知識，它們往往沒有想象中那么困難（實踐是最好的祛魅方式）！

上述這一小節(jié)主要介紹方法論，實操中還有很多細節(jié)和技巧，我將在未來持續(xù)分享，但最重要的是親自動手實踐！

4. 交付部署階段

4.1 版本控制

在工程化實現(xiàn)階段會多次修改，進而產(chǎn)生不同版本，需要及時保存并具備回退能力。

此時可借助GitHub進行版本控制。對開發(fā)人員而言，這是基礎(chǔ)技能，但對非技術(shù)人員可能較為陌生。

簡言之，GitHub允許你將項目文件的特定版本上傳至云端，在本地繼續(xù)修改后再次上傳，同時可隨時回退到云端的任何歷史版本。

Cursor等工具已內(nèi)置此功能：左側(cè)邊欄的分支圖標提供版本控制選項，選擇【初始化倉庫】即可開始。

填寫版本信息（如”V1版本”），點擊【提交】→【發(fā)布Branch】將項目發(fā)布到GitHub。

如需保密，選擇【Publish to GitHub private repository】。發(fā)布成功后，會出現(xiàn)云朵小圖標，表示此版本已提交。

后續(xù)修改先在本地完成，不會影響云端文件。決定提交新版本時，重復(fù)上述步驟即可。

非技術(shù)出身的小伙伴可能會疑惑：為何不直接用不同文件夾管理版本，而非要上傳至GitHub？

主要原因是GitHub除了能管理版本，還能極大簡化后續(xù)部署過程，下一節(jié)將細細道來。

4.2 部署上線（公網(wǎng)部署+公網(wǎng)訪問）

本小節(jié)適用于可上傳至公網(wǎng)部署的項目。如涉密不宜上傳公網(wǎng)，請?zhí)料乱还?jié)查看本地部署方案。

推薦使用Netlify（無需科學(xué)上網(wǎng)）或Vercel（需科學(xué)上網(wǎng)）進行在線部署。

這些平臺可無縫對接GitHub，首次部署完成后，后續(xù)能自動檢測并部署GitHub上的新版本，實現(xiàn)絲滑上線體驗。

以Netlify為例：

登錄后，點擊左側(cè)【Sites】→右側(cè)【Add new site】→選擇【Import an existing project】

點擊【GitHub】完成授權(quán)，選擇要部署的項目（即剛剛發(fā)布到GitHub的項目）。

進入部署頁面：填寫自定義Site name，點擊底部【Deploy XXXX】按鈕，等待部署完成即可。

部署完成后，就可以獲得一個公網(wǎng)可以訪問的鏈接。按需將此鏈接發(fā)給團隊/客戶進行評審溝通。

4.3 部署上線（本地部署+公網(wǎng)訪問）

若只需在本地運行項目，同時臨時獲取外網(wǎng)鏈接供客戶訪問，可使用ngrok（注意：有時訪問較慢，需耐心等待）。

訪問ngrok官網(wǎng)，點擊”免費開始”按鈕，完成注冊登錄后進入Dashboard頁面。

在Dashboard頁面，關(guān)注左側(cè)導(dǎo)航欄【Getting Started】中的兩個頁面：安裝ngrok工具和獲取個人token秘鑰。

完成必要配置后，在Cursor中運行項目，終端區(qū)域會顯示項目的局域網(wǎng)地址。新建終端，輸入：ngrok http 192.168.20.146:8080（替換為你的實際地址）。

回車等待片刻，箭頭指示處的網(wǎng)址即為可供外網(wǎng)訪問的地址，通過它可以訪問本地運行的項目。

注意：為避免安全風(fēng)險，此方案僅用于必要演示，用完立即關(guān)閉。

當(dāng)MVP版本上線后，客戶就可直觀體驗產(chǎn)品形態(tài)，提出更具體的需求。

如果產(chǎn)品框架獲得認可，后續(xù)小需求可直接從【工程化實現(xiàn)階段】開始，在Cursor中修改并一鍵部署。

4.4 PRD文檔輸出

經(jīng)過幾輪迭代，產(chǎn)品基本定型后，可交付給開發(fā)團隊進行生產(chǎn)級開發(fā)。當(dāng)然，這取決于你的意愿和技術(shù)基礎(chǔ)：

• 如你有意愿且具備技術(shù)基礎(chǔ)，可自己完成生產(chǎn)級開發(fā)（與AI工具配合邊學(xué)邊做），但可能周期較長且需自行維護；
• 如你僅擔(dān)任售前/解決方案/產(chǎn)品經(jīng)理角色，則需向開發(fā)團隊提供【完整產(chǎn)品DEMO】+【PRD文檔】；

在Cursor中打開項目，通過以下提示讓AI為你生成PRD文檔：

請你分析這個項目的代碼，基于代碼中體現(xiàn)的已實現(xiàn)功能、用戶界面結(jié)構(gòu)和與后端交互的API調(diào)用，生成一份詳細的產(chǎn)品需求文檔，保存在根目錄下，命名為**PRD.md**

這份PRD應(yīng)包含以下章節(jié)：

1.**項目概述 (Project Overview):**簡要描述項目的類型和主要用途。

2.**已實現(xiàn)的功能列表 (Implemented Features):**列出代碼中實現(xiàn)的主要功能模塊和子功能。例如：用戶認證（登錄/注冊）、數(shù)據(jù)展示（列表、詳情）、數(shù)據(jù)輸入（表單）、搜索/過濾等。3.**用戶流程/頁面結(jié)構(gòu) (User Flows / Page Structure):**描述用戶在應(yīng)用中的主要路徑或頁面之間的導(dǎo)航關(guān)系，基于路由配置和組件交互推斷。

4.**數(shù)據(jù)接口清單 (Data Interface Specification):****這是核心部分，請詳細分析。**列出前端代碼中發(fā)現(xiàn)的所有與后端交互的API接口。

對于每個接口，請包含（如果能從代碼中推斷出）：

* 接口名稱/用途 (Purpose – 簡要說明功能)* HTTP 方法 (GET, POST, PUT, DELETE等)

* 請求 URL 路徑 (Request URL Path)

* 請求參數(shù)/請求體結(jié)構(gòu) (Inferred Request Parameters/Body Structure) – 列出主要字段名和推斷的數(shù)據(jù)類型。

* 響應(yīng)數(shù)據(jù)結(jié)構(gòu) (Inferred Response Data Structure) – 列出主要響應(yīng)字段名、推斷的數(shù)據(jù)類型，以及常見的數(shù)據(jù)示例結(jié)構(gòu)（如對象、數(shù)組）。

5.**技術(shù)實現(xiàn)細節(jié) (Technical Notes – Based on Code):**簡要提及代碼中可以看出的一些技術(shù)實現(xiàn)方式，例如使用了哪些主要框架/庫（React/Vue/Angular）、狀態(tài)管理庫、數(shù)據(jù)獲取方式等。

**重要**

* 請務(wù)必專注于從代碼中可以直接分析出的內(nèi)容，不要推斷，臆測或虛構(gòu)。

* 以清晰、結(jié)構(gòu)化的格式輸出，使用標題和列表。

* 輸出語言為中文。

注：此提示詞不是固定模板，可根據(jù)需要調(diào)整。也可以先粗粗讓AI理解項目代碼并生成PRD文檔，然后基于輸出內(nèi)容迭代調(diào)整你的提示詞。

既然產(chǎn)品原型的代碼都已經(jīng)有了，Cursor就能夠深入理解產(chǎn)品，輸出相關(guān)的文檔就會更真實可用，舉一反三：

• 可以讓其生成用戶交互流程圖（輸出mermai代碼，然后在線轉(zhuǎn)成流程圖）
• 可以讓其為你書寫投標所用的建設(shè)方案（最好喂一些模版文件）
• ……

當(dāng)然，最終文檔仍需你親自審閱把關(guān)！

四、總結(jié)

恭喜！讀到這里的你已經(jīng)超越了90%的傳統(tǒng)型售前工程師/解決方案架構(gòu)師/產(chǎn)品經(jīng)理。

總結(jié)一下：我把【需求→最小可行性產(chǎn)品】的鏈路拆分為四個階段：

1. 需求階段：利用通義的實時記錄記錄用戶需求，通過Google / 秘塔搜索補充相關(guān)信息，最終歸檔到釘釘文檔或飛書文檔中。
2. 設(shè)計階段：借助GPT4o / DeepSeek梳理需求并產(chǎn)出產(chǎn)品方案，再通過Lovable / v0.dev / Bolt.new / Tempo Labs快速生成產(chǎn)品原型。
3. 工程化實現(xiàn)階段：將原型代碼下載到本地或同步至GitHub，導(dǎo)入Cursor / Windsurf / Trae中進行優(yōu)化調(diào)整。
4. 交付部署階段：根據(jù)需要，將項目部署到Netlify / Vercel實現(xiàn)公網(wǎng)部署與訪問，或利用ngrok實現(xiàn)本地部署+公網(wǎng)訪問。最后通過Cursor分析項目代碼，生成PRD及相關(guān)文檔。

在這個過程中，我的心得和建議是：

AI是一位全天候在線、情緒穩(wěn)定、執(zhí)行力超強的合作伙伴，我們需要做的是清晰地表達指令。

當(dāng)AI輸出不符預(yù)期時，保持耐心，重新審視提示詞，逐步調(diào)整完善。

希望這套工作流能夠?qū)δ阌兴鶈l(fā)，助你提升工作效率，享受生活！

最后，以陸游《冬夜讀書示子聿》的名句作結(jié)：

紙上得來終覺淺，絕知此事要躬行。