SaaS 裡埋一個 AI builder,長尾需求的問題真的解了嗎?
最近在 HN 上看到一個叫 Gigacatalyst 的東西,概念是讓 sales、CS、或者客戶直接在你的 SaaS 裡用自然語言做出 one-off 的小 feature,不用排進 roadmap、不用開工程師 ticket。我當下的反應是:「這概念我以前想過但沒想清楚,他們想清楚了嗎?」
講講我自己的脈絡。在前一家公司的後期,我們的工程 backlog 大概有 1/3 是長尾客製需求——某家企業客戶要一個特殊的匯出格式、某個 sales 說如果能多一個篩選條件就能成交那筆大單。每一個需求單獨看都不難做,但加在一起就是一個無底洞。PM 最後的解決方案是「幫我開一個 custom feature request 資料庫」,然後這個資料庫本身又變成了沒人維護的 backlog。
問題的核心不是「工程師做太慢」,是這類需求本質上不值得進 roadmap,但又真的有人需要。
這就是為什麼 embedded AI builder 的概念讓我停下來想了一下。它試圖做的事情,不只是「讓非技術的人能做東西」,更是試圖把一個原本需要工程介入的流程,轉成可以在品牌範圍內自助完成的事情。Gigacatalyst 那篇提到它會去學你的資料模型、接你的 product API、還要符合你的 design system——這三件事如果真的都能做,那這個工具的定位比我以前玩過的 no-code 工具要高一個層次。
我實際上試過幾個類似的東西(比較接近的是 Retool 的 AI feature 和 Glide 的 AI columns),踩到的最大坑是:工具本身的學習曲線跟你想省下來的工程成本差不多。特別是當你的資料結構稍微複雜一點,自然語言的翻譯準確率就開始掉。我測過一個場景,讓工具自動產生一個「跨三個 table 的彙整報表」,成功率大概是 3/10,而且失敗的時候不是跳錯誤,是靜靜地給你一個看起來正確但數字不對的結果——這比直接壞掉還危險。
所以我對這類工具現在的判斷標準是:失敗要明顯,不能靜悄悄地出錯。如果一個 AI builder 做出來的東西在業務邏輯上出錯,但介面看起來正常,那它不是在減少工程 overhead,是在製造新的 QA 地獄。
Gigacatalyst 的方向我覺得是對的——把長尾需求從「工程 backlog 的噪音」轉成「客戶可以自理的流程」,這個轉換如果成立,對 SaaS 公司的影響是很具體的:客製化請求的 SLA 從「等 sprint 排進去」變成「客戶自己當天搞定」。但真正做到這件事,需要的不只是一個好的 UI,而是讓這些 AI 生成的流程可被治理——誰可以建、建了誰能看、有沒有 audit trail、如果邏輯錯了怎麼 rollback。
這是我目前在觀察的點。如果有人在自己的 SaaS 產品裡接過這類 embedded builder,不管是 Gigacatalyst 還是其他家,很想聽聽你在「治理」這塊是怎麼處理的。
作者:AutoKitty