當(dāng)研發(fā)進(jìn)入“節(jié)能模式”（俗稱(chēng)“躺平”），如果產(chǎn)品經(jīng)理還想推動(dòng)需求，你可能得付出好幾倍的心理能量。一邊像哄孩子一樣哄著研發(fā)，一邊又帶著“怒其不爭(zhēng)”的無(wú)奈——這種狀態(tài)，真的很消耗人。

怎么辦？

也許你只差一個(gè)真正的幫手——一款專(zhuān)用型AI編碼平臺(tái)。

注意，我說(shuō)的是“專(zhuān)用”，不是“通用”。

它不同于 Cursor、Trae 這類(lèi)通用編碼工具，也不同于百度秘搭等平臺(tái)產(chǎn)品。為什么？因?yàn)槿绻闶且幻?dú)立網(wǎng)站或小程序的產(chǎn)品經(jīng)理，它們確實(shí)能幫你完成從需求到上線(xiàn)的全流程。

但如果你是一名SaaS產(chǎn)品經(jīng)理，情況就完全不同了。

我每天面對(duì)的是超過(guò) 5000 條待處理需求，每周還會(huì)新增十幾條。按我們現(xiàn)在的產(chǎn)能，再迭代十年也解決不完。

SaaS 需求的特點(diǎn)就是典型的長(zhǎng)尾分布——這 5000 多條里，超過(guò) 80% 都是只有一兩個(gè)客戶(hù)提出的獨(dú)立需求，難以整合推進(jìn)。

怎么辦？

有人選擇做 PaaS，卻因研發(fā)復(fù)雜度高而長(zhǎng)期虧損；有人搭建插件生態(tài)，但中小企業(yè)很難形成有效生態(tài)；也有人采用低代碼，可它的能力邊界明顯，未必能完美解決個(gè)性化問(wèn)題。

每個(gè)方案都有優(yōu)劣，但對(duì)中小企業(yè)而言，插件生態(tài)仍是一個(gè)值得嘗試的方向。關(guān)鍵在于：如何真正解決產(chǎn)能瓶頸？如果社會(huì)化研發(fā)資源不愿進(jìn)入，自身產(chǎn)研人力又有限，該怎么提升效率？

答案就是：自建一款專(zhuān)用AI編碼平臺(tái)，讓懂業(yè)務(wù)、懂用戶(hù)的人（比如產(chǎn)品經(jīng)理、測(cè)試、客戶(hù)成功等），用自然語(yǔ)言就能完成從需求、PRD、設(shè)計(jì)、編碼、測(cè)試到上線(xiàn)的全流程。

案例1：實(shí)現(xiàn)個(gè)性化考勤扣款

需求場(chǎng)景 ：少數(shù)客戶(hù)提出：遲到或早退 5 分鐘內(nèi)，每月豁免 3 次不扣款；超過(guò) 3 次后，每分鐘扣 1 元；遲到早退超過(guò) 5 分鐘，則直接每分鐘扣 1 元，不設(shè)上限。

這類(lèi)需求受眾少，放進(jìn)通用版本迭代 ROI 太低，但若不解決，可能會(huì)流失客戶(hù)。最合理的方案是做獨(dú)立插件，讓客戶(hù)按需開(kāi)通。

以前的做法

• 寫(xiě) PRD：用 AI 輔助寫(xiě)初稿（約 1 小時(shí)）
• 畫(huà)原型：在現(xiàn)有頁(yè)面基礎(chǔ)上用 Axure 簡(jiǎn)單調(diào)整（0.5 小時(shí)）
• 等設(shè)計(jì)：等設(shè)計(jì)師排期出 UI 稿（1–3 天）
• 評(píng)審需求：說(shuō)服研發(fā)與測(cè)試同學(xué)
• 等排期：評(píng)審后等研發(fā)排期（1–3 天）
• 跟進(jìn)測(cè)試：等測(cè)試用例設(shè)計(jì)與排期
• 研發(fā)提測(cè)：1–2 周后
• 測(cè)試階段：2–4 天
• 上線(xiàn)：等運(yùn)維處理（0.5天）

現(xiàn)在的流程

• 說(shuō)需求：直接和 AI 助理對(duì)話(huà)，像和研發(fā)評(píng)審一樣（15 分鐘）
• 出 PRD：AI 自動(dòng)生成（1 分鐘）
• 寫(xiě)代碼：提供接口文檔，AI 開(kāi)始編碼，有疑問(wèn)會(huì)反問(wèn)我（1–2 小時(shí)）
• 發(fā)布測(cè)試：AI 發(fā)布到測(cè)試環(huán)境，自行調(diào)測(cè)。編譯出錯(cuò)時(shí)，把錯(cuò)誤信息貼給它，它會(huì)自行修正；結(jié)果不符合預(yù)期時(shí)，它自動(dòng)打印日志并分析問(wèn)題，提出修改方案，我只需確認(rèn)（0.5–1 天）
• 上線(xiàn)：測(cè)試通過(guò)后，一鍵發(fā)布（30 分鐘）

效果對(duì)比

• 周期：從 10–15 天 → 2–3 天，提升 5–10 倍
• 人力：從 3–4 人 → 僅需 1 人（產(chǎn)品經(jīng)理）
• 心力：從反復(fù)說(shuō)服、推諉拉扯 → 幾乎無(wú)心理壓力，直接提出要求即可

案例2：實(shí)現(xiàn)不同城市出差補(bǔ)貼差異化

需求場(chǎng)景 ：一線(xiàn)城市出差補(bǔ)貼 100 元/天，二線(xiàn)城市 80 元/天，三四線(xiàn)城市 50 元/天。

這屬于少數(shù)客戶(hù)需求，標(biāo)準(zhǔn)產(chǎn)品無(wú)法支持，插件仍是合理方案。

這個(gè)需求比案例 1 復(fù)雜 2–3 倍，我斷斷續(xù)調(diào)試了近一周才完成。

難點(diǎn)主要在兩方面

1. 業(yè)務(wù)邏輯復(fù)雜：出差可按自然日或工作日計(jì)算；支持按天或按小時(shí)申請(qǐng)；同一出差單可能跨月；出差后還支持部分/全部銷(xiāo)差。

2. 接口支持度低：8 月的出差單可能在 6 月發(fā)起，但需計(jì)入 8 月工資，直接獲取對(duì)應(yīng)數(shù)據(jù)很困難。

調(diào)試過(guò)程：

第一次：用AI寫(xiě)了 2000 多行代碼，發(fā)現(xiàn)銷(xiāo)差單無(wú)法關(guān)聯(lián)出差單，只好請(qǐng)研發(fā)新增接口，最終只支持最簡(jiǎn)單場(chǎng)景（不跨月、按工作日、按天計(jì)算）。

第二次：把全部場(chǎng)景告訴 AI，結(jié)果它陷入混亂，始終計(jì)算錯(cuò)誤。我逐條打印日志跟蹤，又花近一天，結(jié)果仍錯(cuò)，且 AI 開(kāi)始遺忘之前對(duì)話(huà)，最終因?qū)υ?huà)輪次上限被迫放棄。

第三次：換思路，以員工實(shí)際出差日期為準(zhǔn)、審批單為輔，明確告訴 AI 執(zhí)行邏輯與接口，調(diào)試一天后終于成功。

這個(gè)過(guò)程雖有沮喪和阻塞，但也讓我體驗(yàn)到不用求人的痛快，以及創(chuàng)造一件事的“心流”狀態(tài)。

如果交給研發(fā)同事，估計(jì)早就被婉拒，甚至要吵上好幾輪。

說(shuō)了這么多，帶你看看效果圖吧。

實(shí)現(xiàn)效果圖：每次報(bào)表計(jì)算時(shí)，插件自動(dòng)執(zhí)行并計(jì)算員工當(dāng)月出差補(bǔ)貼后，呈現(xiàn)在報(bào)表中。

出差補(bǔ)貼-效果圖.png

出差補(bǔ)貼-關(guān)聯(lián)字段.png

員工出差審批記錄：?jiǎn)T工出差申請(qǐng)時(shí)，自選到哪個(gè)城市出差。

出差補(bǔ)貼-審批單.png

需求溝通：用自然語(yǔ)言描述需求場(chǎng)景，并逐步在AI引導(dǎo)下完成需求確認(rèn)，直至它完成PRD（即需求文檔）。

出差補(bǔ)貼-原始需求.png

出差補(bǔ)貼-需求細(xì)節(jié).png

關(guān)鍵接口與邏輯說(shuō)明：明確告訴AI可用接口，以及大概邏輯，細(xì)節(jié)它自行會(huì)讀取并寫(xiě)代碼。

出差補(bǔ)貼-關(guān)鍵接口與邏輯.png

遇到錯(cuò)誤時(shí)：代碼編譯過(guò)程有問(wèn)題，直接把問(wèn)題粘貼給AI，它自行理解并修復(fù)。

出差-錯(cuò)誤解決.png

修改Bug時(shí)：功能測(cè)試時(shí)有問(wèn)題，直接把Case告訴它或把日志粘貼給它，自行修改Bug。

出差補(bǔ)貼-修改bug.png

你可能會(huì)問(wèn)

“這些需求太簡(jiǎn)單，復(fù)雜需求它搞不定吧？”

是的，我們?cè)u(píng)估過(guò)，現(xiàn)有 5000 多條需求中，約 30% 適合用插件解決——也就是至少 1500 條。它們雖然屬于長(zhǎng)尾需求，卻真實(shí)影響客戶(hù)滿(mǎn)意度。

“這對(duì)使用者的能力要求很高吧？非技術(shù)人員能用嗎？”

目前確實(shí)需要對(duì)插件機(jī)制、接口和業(yè)務(wù)有一定了解，產(chǎn)品經(jīng)理、測(cè)試、研發(fā)等角色完全可以實(shí)現(xiàn)“一人團(tuán)隊(duì)”——一個(gè)人搞定一個(gè)插件的全流程。

“專(zhuān)用 AI 助理和 Cursor、Trae、秘搭有什么區(qū)別？”

它們更通用，能寫(xiě)網(wǎng)站、小程序、小游戲，但不理解我們 SaaS 產(chǎn)品的插件機(jī)制、設(shè)計(jì)規(guī)范與業(yè)務(wù)上下文。專(zhuān)用 AI 雖不通用，卻更貼合真實(shí)企業(yè)場(chǎng)景，能與現(xiàn)有系統(tǒng)自然銜接。

最后想說(shuō)

也許我舉的例子看起來(lái)并不復(fù)雜，但對(duì)我而言，能走到這一步已經(jīng)非常振奮。因?yàn)樗娴脑诮鉀Q企業(yè)的真實(shí)問(wèn)題，真的讓“一人團(tuán)隊(duì)”成為可能——至少在插件生態(tài)中如此。

對(duì)一款商業(yè)化近十年的成熟 SaaS 產(chǎn)品來(lái)說(shuō)，我們走到這也花了一年多。因?yàn)楣馐前熏F(xiàn)有產(chǎn)品改造成支持插件模式，就消耗了不少資源。

插件生態(tài)不是單打獨(dú)斗，而是多角色協(xié)作：

• 產(chǎn)研團(tuán)隊(duì)：構(gòu)建穩(wěn)定、開(kāi)放的插件生態(tài)，提供足夠的插件切入點(diǎn)和接口，設(shè)計(jì)合理的分成機(jī)制；
• 業(yè)務(wù)團(tuán)隊(duì)：洞察客戶(hù)需求，學(xué)會(huì)用 AI 編寫(xiě)簡(jiǎn)單插件，推廣現(xiàn)有插件；
• 第三方伙伴（含渠道）：主動(dòng)挖掘需求，通過(guò)插件解決客戶(hù)問(wèn)題，推廣自己的插件并獲取傭金。

路還很長(zhǎng)，我們只是從 0 走到了 1。但方向清晰，目標(biāo)明確，不迷茫不內(nèi)耗——繼續(xù)往前走就對(duì)了。

互動(dòng)一下

你現(xiàn)在是否已經(jīng)在使用 AI 編碼工具（如 Cursor、GitHub Copilot、通義靈碼等）？主要用它來(lái)做什么？

• A、寫(xiě)?yīng)毩㈨?xiàng)目（網(wǎng)站/小程序等）
• B、輔助日常代碼補(bǔ)全與調(diào)試
• C、嘗試過(guò)但還沒(méi)真正用起來(lái)
• D、還沒(méi)用過(guò)，正在觀望

歡迎在評(píng)論區(qū)分享你的使用場(chǎng)景（A、B、C、D），一起聊聊“AI+產(chǎn)品”的下一站可能在哪。