政企產(chǎn)品經(jīng)理AI工作流分享:需求->產(chǎn)品的敏捷實(shí)現(xiàn)(深度長文)
在政企項(xiàng)目中,需求的不斷變化常常導(dǎo)致項(xiàng)目延期甚至失敗。為了應(yīng)對這一挑戰(zhàn),一套基于AI的敏捷工作流被提出,旨在快速將需求轉(zhuǎn)化為可交付的產(chǎn)品。本文詳細(xì)介紹了這一工作流的四個(gè)階段:需求階段、設(shè)計(jì)階段、工程化實(shí)現(xiàn)階段和交付部署階段,并分享了如何利用AI工具在每個(gè)階段提升效率和質(zhì)量。通過實(shí)際案例和實(shí)用工具的推薦,文章為政企產(chǎn)品經(jīng)理提供了一種新的敏捷實(shí)現(xiàn)路徑。
我是Ben,一名政企行業(yè)的解決方案架構(gòu)師,目前正在往AI產(chǎn)品經(jīng)理角色轉(zhuǎn)型。
一、這個(gè)工作流適合誰
我將其命名為:基于AI的「需求直達(dá)產(chǎn)品」敏捷工作流
如名所示,此工作流并不適合所有人。
更適合與我本職工作類似的角色,比如售前、解決方案、產(chǎn)品經(jīng)理這些角色。
因?yàn)檫@些角色需要頻繁觸碰用戶需求、理解需求并及時(shí)轉(zhuǎn)化為「看得見摸得著」的產(chǎn)品。
二、為什么會(huì)有這個(gè)工作流
我所在的公司承接了些政府定制化項(xiàng)目,這類項(xiàng)目如果無法及時(shí)收口需求,往往陷入以下困境:
需求不斷變化->方案頻繁修改->產(chǎn)品原型反復(fù)調(diào)整->開發(fā)延期難驗(yàn)收->項(xiàng)目爛尾->客戶投訴
以我經(jīng)歷某客戶的綜合業(yè)務(wù)型項(xiàng)目為例。由于涉及高度定制化創(chuàng)新,用戶對【最終交付成品】缺乏清晰認(rèn)知,導(dǎo)致:
需求溝通階段:用戶提不出系統(tǒng)化的需求,多為以下兩類:
->模糊泛需求:你們好好做,要能讓一線人員用起來……
->領(lǐng)導(dǎo)的意志:領(lǐng)導(dǎo)說了要做XXXXX,你們?nèi)ピO(shè)計(jì)一下……
產(chǎn)品設(shè)計(jì)階段:用戶看到原型圖后依然模糊不清,僅說:”好,你們抓緊開發(fā),領(lǐng)導(dǎo)要看效果”
開發(fā)交付階段:第一個(gè)模塊上線后,用戶才有了直觀體驗(yàn),各種修改意見和新增需求隨之涌現(xiàn):
->修改速度慢則被催促質(zhì)疑
->領(lǐng)導(dǎo)不滿意則全盤否定,需徹底重構(gòu)產(chǎn)品
從上述案例可見:在定制化項(xiàng)目中,直到V1版本部署上線前,用戶很難對產(chǎn)品形成具體概念,更難以在項(xiàng)目初期提出明確需求。
因此,我開始思考:
如果在需求溝通后立即交付MVP版本,讓用戶實(shí)際體驗(yàn),是否能夠提前收集反饋并及時(shí)調(diào)整?
但傳統(tǒng)流程(需求整理→產(chǎn)品設(shè)計(jì)→UI設(shè)計(jì)→開發(fā))周期過長!
有沒有可能通過高效方式由我直接完成這一過程?
于是乎,自己便嘗試與AI工具搭檔試驗(yàn),在多個(gè)項(xiàng)目的摸索與驗(yàn)證后,我形成了這套工作流。
三、工作流詳解
本工作流共有4個(gè)階段:需求階段->設(shè)計(jì)階段->工程化實(shí)現(xiàn)階段->交付部署階段,每個(gè)階段都有給力的AI工具加持進(jìn)行提質(zhì)提效!
1. 需求階段
利用通義實(shí)時(shí)記錄完整轉(zhuǎn)錄用戶需求。會(huì)議結(jié)束查看自動(dòng)生成的【導(dǎo)讀】和【腦圖】以充分理解需求,并在【筆記】中記錄會(huì)議關(guān)鍵點(diǎn)。
需要補(bǔ)充信息時(shí),可通過Google(基礎(chǔ)信息檢索)+秘塔搜索(知識深度檢索)獲取。最后,將所有信息匯總到釘釘文檔或飛書文檔中。
2. 設(shè)計(jì)階段
2.1 方案設(shè)計(jì)
有了需求匯總后,可能還難以立即構(gòu)思清晰的產(chǎn)品設(shè)計(jì)方案。
此時(shí),可借助AI大模型輔助構(gòu)建,目前嘗試下來以ChatGPT和DeepSeek效果最佳。
提示詞模板示例如下供參考,自己可以盡情測試,這也是個(gè)有趣的過程。歡迎把你覺得好用的提示詞評論告訴我~
你是一名專業(yè)的政企行業(yè)產(chǎn)品經(jīng)理,請你基于下方的項(xiàng)目信息,為我設(shè)計(jì)并輸出產(chǎn)品方案,以便我可以將此方案交給前端工程師進(jìn)行原型開發(fā)?!?xiàng)目信息————1.項(xiàng)目背景:……2.業(yè)務(wù)需求:……3.使用對象:……
2.2 原型構(gòu)建
接下來就是激動(dòng)人心的【text to app】環(huán)節(jié)。
將上一步AI輸出的產(chǎn)品設(shè)計(jì)方案交給原型構(gòu)建工具:Lovable/ v0.dev / bolt.new / Tempo Labs,等待幾分鐘即可預(yù)覽產(chǎn)品原型。
建議同時(shí)使用多種工具生成不同版本的原型,然后從中選擇最佳方案。
注意:
- 查看原型后,可基于不滿意的地方在左側(cè)對話區(qū)域修改指令,并重新生成。
- 推薦僅構(gòu)建前端原型,不做后端數(shù)據(jù)對接。這些工具通常會(huì)自動(dòng)生成模擬數(shù)據(jù)以增強(qiáng)原型的真實(shí)感。
下面是簡單的示例,我同時(shí)對4個(gè)工具下達(dá)同樣的指令(構(gòu)建一個(gè)文旅智導(dǎo)官),大約3-5分鐘就會(huì)生成產(chǎn)品原型。
依次是Lovable, v0.dev, Bolt.new和Tempo Labs:
3. 工程化實(shí)現(xiàn)階段
3.1 將原型源文件下載到本地
獲得基本滿意的產(chǎn)品原型后,需將源文件下載到本地進(jìn)行更細(xì)致的修改。這4個(gè)AI工具的源文件下載方式分為兩類:
第一類是直接在右上角可以點(diǎn)擊下載,將整個(gè)項(xiàng)目的源文件下載到本地。(v0.dev / bolt.new)
第二類是先將項(xiàng)目發(fā)布到自己的github上,然后再從github上將項(xiàng)目下載到本地。(Lovable / Tempo Labs)
3.2 對產(chǎn)品進(jìn)行修改直至滿意
打開Cursor/Windsurf/Trae這3個(gè)工具之一(個(gè)人強(qiáng)推Cursor),將上一步下載的文件夾導(dǎo)入。
這三款工具本質(zhì)上是AI增強(qiáng)型IDE(集成開發(fā)環(huán)境),可將項(xiàng)目相關(guān)文件一并導(dǎo)入作為知識庫,幫助它們根據(jù)你的需求創(chuàng)建、引用和修改文件。
首先要克服對”程序員專屬界面”的心理障礙——許多非程序員同事反饋看到這類界面就產(chǎn)生排斥感。
實(shí)際使用后你會(huì)發(fā)現(xiàn)它們并不復(fù)雜!
以Cursor為例,界面主要分為四個(gè)區(qū)域:
1)文件列表區(qū)域:展示項(xiàng)目內(nèi)所有文件;
2)文件內(nèi)容區(qū)域:顯示當(dāng)前選中文件的內(nèi)容;
3)終端運(yùn)行區(qū)域:運(yùn)行項(xiàng)目或執(zhí)行命令的交互區(qū)域;
4)AI對話區(qū)域:與AI交流以修改產(chǎn)品的核心區(qū)域;
關(guān)于Cursor的基本操作,網(wǎng)上教程豐富,此處不再贅述。任何你不會(huì)的,都可以直接在Cursor的AI對話區(qū)域瘋狂提問。
僅闡述2個(gè)觀點(diǎn):
- 只要指令清晰 + 小模塊迭代 + 保持耐心 → 100%可完成產(chǎn)品原型
- 雖然我們不懂代碼,但隨著與AI交互深入,掌握一些基礎(chǔ)前端/后端技術(shù)概念有助于提出更精準(zhǔn)的指令。
下面是一個(gè)淺顯易懂的舉例,當(dāng)你發(fā)現(xiàn)AI設(shè)計(jì)的按鈕太大不符合預(yù)期時(shí),
->非精準(zhǔn)指令:
“幫我把按鈕調(diào)小一點(diǎn),現(xiàn)在太大了”
->結(jié)果:
AI將此按鈕調(diào)得過小,又需反復(fù)調(diào)整
->問題:
我們無法準(zhǔn)確描述心中預(yù)期的按鈕大小
->解決方法:
觀察AI修改的文件和參數(shù),學(xué)習(xí)相關(guān)概念后直接修改。
如下圖所示,AI在回復(fù)中說明了它修改了button.tsx文件中的size屬性(紅色表示原值,綠色表示修改后的值),并總結(jié)了高度從h-10減為h-9。下次不滿意時(shí),你可以直接修改這些參數(shù)直至符合預(yù)期。
因此,當(dāng)你提出修改指令時(shí),建議在指令最后添加:
“請?jiān)谛薷暮鬄槲铱偨Y(jié)修改了什么文件的什么參數(shù),并說明這些修改的作用”
通過學(xué)習(xí)AI的回答,你會(huì)逐漸掌握”內(nèi)邊距”、”外邊距”、”邊框”等前端術(shù)語,使指令更加精準(zhǔn),而不僅限于”大一點(diǎn)”和”小一點(diǎn)”的模糊表述。
不要排斥學(xué)習(xí)新知識,它們往往沒有想象中那么困難(實(shí)踐是最好的祛魅方式)!
上述這一小節(jié)主要介紹方法論,實(shí)操中還有很多細(xì)節(jié)和技巧,我將在未來持續(xù)分享,但最重要的是親自動(dòng)手實(shí)踐!
4. 交付部署階段
4.1 版本控制
在工程化實(shí)現(xiàn)階段會(huì)多次修改,進(jìn)而產(chǎn)生不同版本,需要及時(shí)保存并具備回退能力。
此時(shí)可借助GitHub進(jìn)行版本控制。對開發(fā)人員而言,這是基礎(chǔ)技能,但對非技術(shù)人員可能較為陌生。
簡言之,GitHub允許你將項(xiàng)目文件的特定版本上傳至云端,在本地繼續(xù)修改后再次上傳,同時(shí)可隨時(shí)回退到云端的任何歷史版本。
Cursor等工具已內(nèi)置此功能:左側(cè)邊欄的分支圖標(biāo)提供版本控制選項(xiàng),選擇【初始化倉庫】即可開始。
填寫版本信息(如”V1版本”),點(diǎn)擊【提交】→【發(fā)布Branch】將項(xiàng)目發(fā)布到GitHub。
如需保密,選擇【Publish to GitHub private repository】。發(fā)布成功后,會(huì)出現(xiàn)云朵小圖標(biāo),表示此版本已提交。
后續(xù)修改先在本地完成,不會(huì)影響云端文件。決定提交新版本時(shí),重復(fù)上述步驟即可。
非技術(shù)出身的小伙伴可能會(huì)疑惑:為何不直接用不同文件夾管理版本,而非要上傳至GitHub?
主要原因是GitHub除了能管理版本,還能極大簡化后續(xù)部署過程,下一節(jié)將細(xì)細(xì)道來。
4.2 部署上線(公網(wǎng)部署+公網(wǎng)訪問)
本小節(jié)適用于可上傳至公網(wǎng)部署的項(xiàng)目。如涉密不宜上傳公網(wǎng),請?zhí)料乱还?jié)查看本地部署方案。
推薦使用Netlify(無需科學(xué)上網(wǎng))或Vercel(需科學(xué)上網(wǎng))進(jìn)行在線部署。
這些平臺(tái)可無縫對接GitHub,首次部署完成后,后續(xù)能自動(dòng)檢測并部署GitHub上的新版本,實(shí)現(xiàn)絲滑上線體驗(yàn)。
以Netlify為例:
登錄后,點(diǎn)擊左側(cè)【Sites】→右側(cè)【Add new site】→選擇【Import an existing project】
點(diǎn)擊【GitHub】完成授權(quán),選擇要部署的項(xiàng)目(即剛剛發(fā)布到GitHub的項(xiàng)目)。
進(jìn)入部署頁面:填寫自定義Site name,點(diǎn)擊底部【Deploy XXXX】按鈕,等待部署完成即可。
部署完成后,就可以獲得一個(gè)公網(wǎng)可以訪問的鏈接。按需將此鏈接發(fā)給團(tuán)隊(duì)/客戶進(jìn)行評審溝通。
4.3 部署上線(本地部署+公網(wǎng)訪問)
若只需在本地運(yùn)行項(xiàng)目,同時(shí)臨時(shí)獲取外網(wǎng)鏈接供客戶訪問,可使用ngrok(注意:有時(shí)訪問較慢,需耐心等待)。
訪問ngrok官網(wǎng),點(diǎn)擊”免費(fèi)開始”按鈕,完成注冊登錄后進(jìn)入Dashboard頁面。
在Dashboard頁面,關(guān)注左側(cè)導(dǎo)航欄【Getting Started】中的兩個(gè)頁面:安裝ngrok工具和獲取個(gè)人token秘鑰。
完成必要配置后,在Cursor中運(yùn)行項(xiàng)目,終端區(qū)域會(huì)顯示項(xiàng)目的局域網(wǎng)地址。新建終端,輸入:ngrok http 192.168.20.146:8080(替換為你的實(shí)際地址)。
回車等待片刻,箭頭指示處的網(wǎng)址即為可供外網(wǎng)訪問的地址,通過它可以訪問本地運(yùn)行的項(xiàng)目。
注意:為避免安全風(fēng)險(xiǎn),此方案僅用于必要演示,用完立即關(guān)閉。
當(dāng)MVP版本上線后,客戶就可直觀體驗(yàn)產(chǎn)品形態(tài),提出更具體的需求。
如果產(chǎn)品框架獲得認(rèn)可,后續(xù)小需求可直接從【工程化實(shí)現(xiàn)階段】開始,在Cursor中修改并一鍵部署。
4.4 PRD文檔輸出
經(jīng)過幾輪迭代,產(chǎn)品基本定型后,可交付給開發(fā)團(tuán)隊(duì)進(jìn)行生產(chǎn)級開發(fā)。當(dāng)然,這取決于你的意愿和技術(shù)基礎(chǔ):
- 如你有意愿且具備技術(shù)基礎(chǔ),可自己完成生產(chǎn)級開發(fā)(與AI工具配合邊學(xué)邊做),但可能周期較長且需自行維護(hù);
- 如你僅擔(dān)任售前/解決方案/產(chǎn)品經(jīng)理角色,則需向開發(fā)團(tuán)隊(duì)提供【完整產(chǎn)品DEMO】+【PRD文檔】;
在Cursor中打開項(xiàng)目,通過以下提示讓AI為你生成PRD文檔:
請你分析這個(gè)項(xiàng)目的代碼,基于代碼中體現(xiàn)的已實(shí)現(xiàn)功能、用戶界面結(jié)構(gòu)和與后端交互的API調(diào)用,生成一份詳細(xì)的產(chǎn)品需求文檔,保存在根目錄下,命名為**PRD.md**
這份PRD應(yīng)包含以下章節(jié):
1.**項(xiàng)目概述 (Project Overview):**簡要描述項(xiàng)目的類型和主要用途。
2.**已實(shí)現(xiàn)的功能列表 (Implemented Features):**列出代碼中實(shí)現(xiàn)的主要功能模塊和子功能。例如:用戶認(rè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):****這是核心部分,請?jiān)敿?xì)分析。**列出前端代碼中發(fā)現(xiàn)的所有與后端交互的API接口。
對于每個(gè)接口,請包含(如果能從代碼中推斷出):
* 接口名稱/用途 (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ù)實(shí)現(xiàn)細(xì)節(jié) (Technical Notes – Based on Code):**簡要提及代碼中可以看出的一些技術(shù)實(shí)現(xiàn)方式,例如使用了哪些主要框架/庫(React/Vue/Angular)、狀態(tài)管理庫、數(shù)據(jù)獲取方式等。
**重要**
* 請務(wù)必專注于從代碼中可以直接分析出的內(nèi)容,不要推斷,臆測或虛構(gòu)。
* 以清晰、結(jié)構(gòu)化的格式輸出,使用標(biāo)題和列表。
* 輸出語言為中文。
注:此提示詞不是固定模板,可根據(jù)需要調(diào)整。也可以先粗粗讓AI理解項(xiàng)目代碼并生成PRD文檔,然后基于輸出內(nèi)容迭代調(diào)整你的提示詞。
既然產(chǎn)品原型的代碼都已經(jīng)有了,Cursor就能夠深入理解產(chǎn)品,輸出相關(guān)的文檔就會(huì)更真實(shí)可用,舉一反三:
- 可以讓其生成用戶交互流程圖(輸出mermai代碼,然后在線轉(zhuǎn)成流程圖)
- 可以讓其為你書寫投標(biāo)所用的建設(shè)方案(最好喂一些模版文件)
- ……
當(dāng)然,最終文檔仍需你親自審閱把關(guān)!
四、總結(jié)
恭喜!讀到這里的你已經(jīng)超越了90%的傳統(tǒng)型售前工程師/解決方案架構(gòu)師/產(chǎn)品經(jīng)理。
總結(jié)一下:我把【需求→最小可行性產(chǎn)品】的鏈路拆分為四個(gè)階段:
- 需求階段:利用通義的實(shí)時(shí)記錄記錄用戶需求,通過Google / 秘塔搜索補(bǔ)充相關(guān)信息,最終歸檔到釘釘文檔或飛書文檔中。
- 設(shè)計(jì)階段:借助GPT4o / DeepSeek梳理需求并產(chǎn)出產(chǎn)品方案,再通過Lovable / v0.dev / Bolt.new / Tempo Labs快速生成產(chǎn)品原型。
- 工程化實(shí)現(xiàn)階段:將原型代碼下載到本地或同步至GitHub,導(dǎo)入Cursor / Windsurf / Trae中進(jìn)行優(yōu)化調(diào)整。
- 交付部署階段:根據(jù)需要,將項(xiàng)目部署到Netlify / Vercel實(shí)現(xiàn)公網(wǎng)部署與訪問,或利用ngrok實(shí)現(xiàn)本地部署+公網(wǎng)訪問。最后通過Cursor分析項(xiàng)目代碼,生成PRD及相關(guān)文檔。
在這個(gè)過程中,我的心得和建議是:
AI是一位全天候在線、情緒穩(wěn)定、執(zhí)行力超強(qiáng)的合作伙伴,我們需要做的是清晰地表達(dá)指令。
當(dāng)AI輸出不符預(yù)期時(shí),保持耐心,重新審視提示詞,逐步調(diào)整完善。
希望這套工作流能夠?qū)δ阌兴鶈l(fā),助你提升工作效率,享受生活!
最后,以陸游《冬夜讀書示子聿》的名句作結(jié):
紙上得來終覺淺,絕知此事要躬行。
作者:Ben的AI實(shí)驗(yàn)室 公眾號:Ben的AI實(shí)驗(yàn)室
本文由 @Ben的AI實(shí)驗(yàn)室 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)
用的什么工具啊,畫界面倒是很快,天馬行空的方向倒是可以找的很快,配合AI落地需求快多了
文章里不是已經(jīng)舉例說了4個(gè)工具了么。。。
按這個(gè)流程可以實(shí)現(xiàn)一下小規(guī)模產(chǎn)品的從0到1搭建,但是政企產(chǎn)品要的是全流程的規(guī)范性、可維護(hù)性,客戶說出來的需求只是冰山一角,每次制作原型不可能都重構(gòu)所有交互,代碼也可不能都丟棄重寫,這些才是現(xiàn)在AI落地最難的地方,也是一定要由人來彌補(bǔ)的地方。
你說的很對,目前用的最做的還是【需求–>高保真原型階段(直接用脫敏數(shù)據(jù))】,這樣可以讓客戶看到近乎90%的效果。
然后進(jìn)行幾輪原型的迭代后,才會(huì)移交給開發(fā)團(tuán)隊(duì)進(jìn)行開發(fā)。
畢竟產(chǎn)品經(jīng)理直接從頭做到尾也不合適。
政企相關(guān)單位不會(huì)更注重系統(tǒng)安全性嗎,感覺全篇都在互聯(lián)網(wǎng)邊界上瘋狂試探
真正的落地項(xiàng)目,基本上我只負(fù)責(zé)需求到原型階段。后續(xù)的開發(fā)還是會(huì)移交到研發(fā)團(tuán)隊(duì)的。
有這樣的工具應(yīng)用能力完全可以單干
缺少市場資源哈,說白了還不知道需求在哪
是這樣,ai工具可以幫助我們盡快的落地想法,并且提供一些可能沒想到的方向,從而更好的幫助產(chǎn)品經(jīng)理去進(jìn)行后續(xù)文檔化內(nèi)容的梳理,還是可以提升工作效率的。
bingo!
我也一直在嘗試?yán)胊i工具提高需求??產(chǎn)品方案的效率,但是同樣也是苦需求模糊的現(xiàn)狀久矣。也像評論區(qū)所說,目前ai生成產(chǎn)品方案或原型的實(shí)際效果還是達(dá)不到期望,但是我認(rèn)為不是提示詞的問題,而可能是因?yàn)楫a(chǎn)品方案本身不像代碼一樣有那么多開源的信息,即使有可能也是解決局部問題的設(shè)計(jì)方案,所以ai本身的設(shè)計(jì)能力會(huì)比較欠缺全局性的。因此可以退而求其次,只讓ai解決產(chǎn)品方案里的局部難題,比如我會(huì)告訴它我在設(shè)計(jì)某個(gè)功能的時(shí)候遇到了一個(gè)兩難的問題,讓它幫我盡可能找可行的解法,為我提高效率。但我還是覺得,愿意花時(shí)間搭建ai工作流是很有鉆研和實(shí)踐精神的嘗試,我很佩服。
確實(shí)如此
共勉,相信隨著技術(shù)迭代,你的需求也會(huì)被滿足的!
說說我自己的實(shí)際體驗(yàn)與研發(fā)同學(xué)的討論,以下僅為個(gè)人感受,歡迎指正:
1、無論是生成原型圖還是業(yè)務(wù)代碼,工具輸出成果均需投入大量時(shí)間調(diào)試修改,最終僅能達(dá)到勉強(qiáng)可演示的基礎(chǔ)效果,想快速成型不太可能。(也有可能是不熟練的緣故)
2、涉及稍復(fù)雜的業(yè)務(wù)邏輯或交互需求時(shí),僅優(yōu)化提示詞的時(shí)間成本已接近傳統(tǒng)開發(fā)模式下從零構(gòu)建 Demo 的周期
3、我反而覺得傳統(tǒng)方式更高效。明確功能邊界、手繪原型草稿,再由前后端聚焦核心業(yè)務(wù)邏輯與頁面開發(fā)的模式推進(jìn)
感謝你的回復(fù),一看就是有過大量實(shí)踐的。誠然讓AI開發(fā)出高質(zhì)量產(chǎn)品難度不亞于傳統(tǒng)鏈路。
我個(gè)人的想法,這套工作流的重點(diǎn)其實(shí)不在于“替代傳統(tǒng)開發(fā)”,而在于加速“從想法到明確產(chǎn)品路徑”這段早期階段的探索。
尤其是自己還不明確產(chǎn)品形態(tài)的時(shí)候,我可能壓根畫不出產(chǎn)品原型圖。
至于“調(diào)試時(shí)間”,我覺得換個(gè)角度看,其實(shí)是在訓(xùn)練自己的 AI 使用習(xí)慣 —— prompt 調(diào)試確實(shí)是一種新型“編程能力”,剛上手確實(shí)比手寫代碼更慢,但一旦熟練,其背后的通用性(能做 Web、做文檔、做接口、做流程)會(huì)逐漸顯現(xiàn)出優(yōu)勢。
當(dāng)然,如果項(xiàng)目目標(biāo)已明確,傳統(tǒng)方式從零構(gòu)建肯定更穩(wěn)定可控。
再次感謝你的評論!
1