> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh-hant/2026/w16-nocode-rapid-iteration-and-new-engineering-constraints.md).

# W16-nocode、快速迭代與新的工程約束

上週 HR 發了一個金服 10 年的 Vlog 活動。整個項目是我們一位實習同學羅華煜用 nocode 做的。我上週看了看這個項目的代碼，有一些很有意思的發現。

第一，no-code 在這類項目上的生產力提升，幾倍甚至幾十倍，我都不會覺得意外。讓我驚訝的是，這個項目整個過程一共生成了 268 個版本。我們都知道，AI 會持續加快軟件交付速度，未來線上的生產項目大概率也會比今天快上幾倍。但速度變快之後會發生什麼，這個項目我覺得就是一個很好的例證。

前些年做類似抽獎活動時，通常是一個前端加一個後端，給半個多月時間，大家吭哧吭哧幹一個多星期，先做出一個 MVP。客戶看完提一輪建議，開發拿回去迭代，過兩天再給客戶看，往往還是不滿意，再繼續改一輪。最後常常是時間不夠了，客戶說“先這樣吧”。整個過程中，客戶真正能看到的版本，可能也就三四個，迭代條很快就走到頭了。

但 nocode 把需求到實現之間的距離壓縮到了很短，客戶獲得反饋的速度變快了，產生新想法的速度也變快了。同樣是半個月時間，迭代條卻往前走了 200 多個版本。以前很多根本不會發生的迭代，現在開始有條件發生。所以很重要的一點是，生產力提升以後，時間和資源未必會明顯下降，反而更可能符合傑文斯悖論。因為實現的門檻下降了，想法就會變多，迭代也會變多，需求是可以趨近於無限的。消失的未必是工作量，更多只是把原來做不到的迭代釋放了出來。

第二，看完這個項目的代碼，我有一種挺強烈的感覺，人平時很少會主動寫出這樣的代碼。這樣一個完整的 Web 服務，沒有獨立的 server 端，而是由前端直接訪問數據庫，一共用了 16 條數據庫存儲過程。整體上，這是一個很典型的 Frontend-only + BaaS 架構。前端用 React + Vite 構建 SPA，沒有單獨的後端服務，所有數據操作都通過 supabase-js 在瀏覽器裡直接調用美團私有化部署的 Supabase，底層數據庫是 PostgreSQL。

業務邏輯被拆成了兩部分。簡單校驗和頻率限制放在前端 worksApi.js 裡處理，涉及併發安全和數據一致性的核心邏輯，比如投票、點贊、刪除，則封裝成 PostgreSQL 存儲函數，通過 supabase.rpc() 來觸發，權限控制主要依賴數據庫層的 RLS 策略兜底。這樣的方案開發效率很高，也省掉了獨立服務端的維護成本，但問題也很明顯。業務邏輯同時散落在前端 JavaScript 和數據庫 PL/pgSQL 兩處，可維護性比較一般，一些敏感信息，比如管理員名單，也不得不以硬編碼的方式放在客戶端裡。

這個項目的價值，不只是說明 nocode 能把一個活動頁做得更快，而是很具體地展示了 AI 時代軟件交付的一種新常態。版本會變得更多，反饋會變得更快，架構也會越來越傾向於先走最短實現路徑。對團隊來說，這裡面既有很現實的生產力機會，也會帶來新的工程約束。以後真正稀缺的，可能不是把功能先寫出來，而是在極快迭代裡，仍然能守住架構邊界、可維護性和長期演進能力。