最近在 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 還是其他家，很想聽聽你在「治理」這塊是怎麼處理的。