這個問題總是以特定方式出現。不是「我該不該用 AI 建構器」——那是另一篇文章,通常也是另一種人問的。這個問題來自那些已經花了六個月、八個月、十二個月建構出真正有效果的產品的人。真實的使用者、真實的營收,以及一種隱隱的感覺:自己快要撞上這個工具無法突破的牆。以下是我實際被問到的問題,大致按被問到的順序排列。
人真的會成長超越 AI 建構器嗎,還是這只是大家自我安慰的說法?
兩者都會發生,而且從外表看起來一模一樣。真正的成長超越是具體的:你需要一個三方分帳結算的付款流程,或是一個監管機構真的會去看的稽核軌跡合規流程,或者你在做一些運算上不尋常的事——即時影像處理、物理模擬、用自己的資料訓練的自訂推薦模型。這些是架構問題,不是提示問題。
假的版本則是一個你還沒寫出來的提示。「這個建構器做不到帶游標分頁的無限捲動」通常代表根本沒有人詳細描述過帶游標分頁的無限捲動——意思是有人試了一次「加上分頁」,結果不滿意,就悄悄把它歸類為限制,而不是再試一次。我猜大概四分之三「我碰到天花板了」的對話,最後都是靠更好的提示解決,而不是靠重寫。
我要怎麼分辨自己碰到的是哪一種?
| 感覺像成長超越 | 通常真的是 | 通常其實不是 |
|---|---|---|
| 「它做不到 X」 | X 需要平台完全沒有提供的基礎架構(自訂 TCP 協定、GPU 訓練任務、符合 HIPAA 稽核的資料流) | X 沒有被描述得夠具體,或是一次性提出而沒有反覆調整 |
| 「規模擴大後太慢了」 | 你已經超過生成程式碼和標準託管等級能撐得住實際負載的臨界點 | 你在猜測一個你根本還沒遇到的負載量 |
| 「我需要目前沒有的掌控權」 | 你需要在對話流程之外,直接手動編輯生成的程式碼來做特定修正 | 你還沒試過提供更多背景資訊,再要求修正一次 |
| 「我的團隊需要碰程式碼」 | 你已經聘請了工程師,他們需要正常的 git 工作流程 | 只有你一個人在碰它,只是想讓自己感覺更「真實」一點 |
老實說,關鍵在於你能不能說出具體的技術需求,還是只是在描述一種感覺。「我需要具備指數退避與死信佇列的 webhook 重試機制」是一項需求。「我就是感覺現在需要自己的東西了」是一種感覺,而感覺通常靠寫出更好的提示就能解決,不需要遷移。
如果我決定離開,我到底擁有什麼?
這是大家最焦慮的問題,也是答案最乾淨的一個:你擁有的是部署到你自己網域上的東西,加上你的資料。如果你透過 SFTP、透過自己的註冊商,把網站部署到你自己掌控的網域上,那麼伺服器上的檔案就跟你租用的任何伺服器上的任何程式碼一樣屬於你。沒有人能收回它。你的 Search Console 和 Analytics 連結是你自己授權的 Google 帳號;取消建構器的連結不會動到 Google 系統中已存在的歷史資料,因為那本來就從來不是建構器的資料。那是你的帳號,只是經過篩選。
你不會自動得到的是聊天記錄、規劃文件、驗證紀錄,以及建構器對你專案的內部理解模型——那些讓迭代速度變快的東西。這部分才是真正與平台綁在一起的東西,也是大多數人在用新工具重建這些脈絡之前,最容易低估其價值的部分。
我到底有沒有被綁定,還是我想太多了?
要看你說的「綁定」是什麼意思。如果指的是「他們能不能挾持我的網站」——不能,只要你從一開始就部署到自己的網域,而不是一直掛在子網域上,這正是擁有網域的意義所在。如果指的是「離開會不會讓我損失幾個月迭代累積的複合價值」——會,但那其實不算是綁定,只是沉沒成本,就跟你從任何投入過時間的工具轉換一樣。每個編輯器、每個框架、每個 CRM 都有這個特性。問題不在於轉換成本是否存在,而在於它是人為造成的(合約條款、資料挾持),還是自然形成的(你在某個地方建立了動能,搬走就意味著要重新建立)。人為的綁定是警訊,自然的轉換成本只是「精通一項工具」的代價。
什麼時候真正該聘請工程師,而不是再寫一個提示?
三種情況,依我看到的頻率排序:
- 你需要有人親自在場以符合合規要求——有些監管框架要求有一位具名、負責任的工程師,而不是一份 AI 生成的提交紀錄,無論那些提交品質多好都一樣。
- 你遇到了真正新穎的技術問題——不是「建一個市集」這種已經很成熟的東西,而是像根據專屬資料調校的自訂配對演算法這種,價值就在於其新穎性,你需要能夠針對特定數學問題進行推理的人,而不只是描述想要的結果。
- 你已經超過「生成的程式碼能跑」和「生成的程式碼經過剖析並針對你確切的流量型態調校過」開始出現分歧的規模——這是真實存在的,但比大多數人想像的更遠。很多感覺「大到建構器裝不下」的應用,其實每月活躍使用者只有低五位數,對結構良好的生成程式碼來說,這根本還不是規模問題。
注意這份清單上沒有的一項:「我想要更多掌控權。」想要更多掌控權是一種偏好,不是一種需求,值得誠實面對自己感受到的到底是哪一種。
如果我真的請來了工程師,他們該延伸 AI 建構出來的程式碼,還是該從頭開始?
幾乎總是延伸原有程式碼。我見過太多團隊因為預設「這是 AI 生成的,一定是用完即丟」而選擇從頭重寫,結果反而搞砸的案例。那是一種偏見,不是一種評估。先實際讀過程式碼。如果它的結構還算合理——而一個會在上線前先展示規劃與驗證步驟的建構器,往往能產出讀起來連貫的程式碼,因為連貫的規劃會產生連貫的程式碼——最快的路徑通常就是讓一位普通的工程師接手一個普通的程式碼庫。完全重寫是昂貴的選項,應該留給程式碼真的無法支撐接下來需求的情況,而不是因為它的出身。
人們在「畢業」離開建構器六個月後,真正會碰到的失敗模式是什麼?
他們失去了迭代循環，卻沒有建立替代方案。對大多數人來說，建構器真正的價值從來不只是「會寫程式碼」——很多工具都能寫程式碼。它的價值在於「提出→驗證→部署→衡量」能緊密循環運作，而不需要人在每一步都成為瓶頸。當團隊離開卻沒有重建同等緊密的循環——CI、預備環境、監控，以及從構想到上線的快速路徑——最終出貨速度會比使用建構器第一天還慢，而且他們通常好幾個月都不會察覺，因為程式碼庫 感覺 起來更「真實」。真實和快速並不是同一回事。如果你打算跳脫這個工具，請跳進一個至少同樣緊密的流程，而不只是換成更多由你自己維護的檔案。
「我們成長超越了它」誠實的版本,通常是「我們成長出了一個具體、可命名、它涵蓋不到的需求」。如果你說不出這個需求是什麼,你大概沒有成長超越任何東西——你只是停止迭代了。
