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