AI 把整個小程序寫完了，裡面卻一個 AI 功能都沒有：這件事值得做軟體的人想一想

（本文事件日期為 2026 年 9 月 18 日，開發者於掘金發布完整自述，此後在技術社羣持續被轉發討論。）

有一個微信小程序叫「廚菜記」，功能很樸素：把自己家做過的菜記下來，一家人共用一份菜單。打開看到的每一道菜，都是家裡人親手錄的，沒有推薦流，沒有美食博主，沒有演算法幫你「發現你可能喜歡」。撐起它的技術棧也是教科書等級的普通：微信原生框架加 MobX，後端 Spring Boot 加 MySQL，部署在自建的雲主機上。

特別的地方只有一個：這個小程序的程式碼，絕大部分是 AI 寫的。而它裡面沒有任何一個面向使用者的 AI 功能。

這個反差之所以值得停下來看，是因為它把「AI 作為產品賣點」和「AI 作為生產工具」這兩件常被混在一起談的事，拉到了同一個畫面裡。前者是你在簡報上寫的東西，後者是你在鍵盤上實際做的事。廚菜記屬於後者，而且做完了、上架了。

先看這個產品解決什麼

開發者列了三個很日常的場景。收藏了三百個食譜，真的要做那道酸湯肥牛時翻了六分鐘，最後點了外送。下午五點家庭羣開始商量今天喫什麼，商量到七點。還有你媽做了一盤很好的紅燒獅子頭，你請她把做法寫下來，她說這有什麼好寫的，看著就會了。

這三個場景對應到產品功能，就是三步：把家裡的菜記下來，把家人拉進同一個「廚房」，然後讓一家人點菜、下廚、打分。錄菜時食材與調味料會自動沉澱成資料庫，第二次寫「生抽」不用從頭輸入。每道菜帶著做過幾次和平均分，做過十二次、平均四點八分的那道，就是你們家的固定節目。點餐按早餐、午餐、晚餐、宵夜四個時段組織，成員分廚師長、管廚、食客三種角色，家庭羣裡發一張邀請卡片，點進來就在同一個廚房。

這個設計裡最值得注意的，是評價最後會沉回那道菜的分散，而不是流進一個動態牆。內容只在家人之間流動，累積的是家庭自己的資產，對任何平臺的推薦機制都沒有貢獻。這在注意力經濟當道的環境裡，幾乎是一種反方向的產品選擇。

分工：AI 把意圖變成能跑的東西，人判斷那是不是想要的東西

開發者很誠實地面對了一個繞不過去的問題：既然程式碼大部分是 AI 寫的，那「我到底做了什麼」。

按他實際花時間最多的地方說：做什麼、不做什麼全是他自己定的。冰箱食材管理那一整套需求是他自己砍掉的，AI 從來沒有主動提過「這個別做」。資料庫十九張表的關聯和欄位約束得他先想清楚，DDL、註解、實體類 AI 一口氣產出。後端分層骨架和大量增刪改查是 AI 的，但介面鑑權白名單、防重複提交註解、跨層欄位約束，是他自己提出的問題，因為 AI 不會反問一句「這個欄位被繞過前端直接打進來怎麼辦」。小程式的頁面結構和元件 AI 寫得多，互動細節是他一句一句磨出來的。分包載入是他逼 AI 做的，因為不拆也能跑，AI 沒有動機主動求好。

歸納成他自己的一句話：它負責把意圖變成能跑的東西，他負責判斷它變成的是不是想要的東西。

這個分工有個很苛刻的前提，就是人得看得出來哪裡不對。看不出來，AI 就會順著一條沒被驗證過的假設，把程式碼寫得非常完整，而且每一處都寫得像那麼回事。

廚房名稱欄位：三層各自正確，合起來漏水

原文裡最扎實的一段，是一個剛發生的例子。廚房名稱這個欄位，他去核了三層各自寫的約束：前端輸入框限制最多二十個字，資料庫欄位設 VARCHAR(50)，後端的驗證註解只檢查了非空。三層各自看都沒毛病，問題是三層對長度的上限分別是二十、五十、沒有。

只要有任何人不經過那個輸入框提交，一段腳本、一個舊版客戶端、或未來接進來的其他入口，寫六十個字進去，伺服器不會回一句「名稱太長了」，而是 MySQL 直接拋出例外，使用者面前彈出一個「系統繁忙」。

AI 不會主動來告訴你這件事。它寫每一層的時候都是局部正確的：約束有啊，資料庫裡寫著，前端也攔著。缺的是跨層的那條不變量，而「三種約束彼此是什麼關係」這個問題，只有一個人腦子裡同時裝著三處，才會想到要去問。

他現在的做法是，每讓 AI 寫完一個模組，固定追問三件事：這個欄位的約束在資料庫、後端、前端分別是什麼，不一致會怎樣；被繞過前端的呼叫打進來會怎樣；這個寫入介面連點兩次會怎樣。一次一分鐘，不追問就是線上事故。

這段經驗對所有用 AI 寫程式的人都有參考價值。AI 特別擅長製造一種「驗證很完善」的錯覺，註解一路掛下來，看起來每個欄位都被照顧到了。但驗證的價值不在於每一層有沒有寫，而在於層與層之間是否一致。這種一致性沒有單一位置可以檢查，它只存在於人的腦子裡。

第二次才談得上方法

還有一個容易被略過的脈絡：這不是他第一次這樣做。上一個用 AI 做完的小程序叫「簽小籤」，兩邊後端技術棧一模一連，連 MyBatis-Plus 和 Hutool 的版本號都沒動。他自己說得很清楚，第一次做完可以說運氣好，需求簡單、坑踩得少；第二次才談得上方法，因為同一套流程走兩遍，才知道哪一步是僥倖、哪一步是必然。

數字是他用 git 指令統計出來的：小程式端三百六十二個檔案、一點六六萬行程式碼，後端兩百六十九個 Java 檔案、一點三九萬行，十九張表，二十一個頁面，二十五個元件，從設計到上架五週。

跟上次最實在的差別，是他這次給 AI 交付的每一步，都先配了一個能自己跑的驗證手段。這句話背後的工程觀其實很傳統：不管程式碼是誰寫的，人寫的也好，模型寫的也好，能自動驗證的交付才叫交付。AI 改變的是產出速度，改變不了「怎麼知道它是對的」這個問題的性質。

所以呢

這個案例對不同讀者有不同的用處。

對想自己做一些小東西的人，它證明了門檻的形狀變了。會描述需求、會拆場景、會問對問題的人，現在能把五週的工程量扛下來。剩下的是把冰箱管理那種「聽起來很厲害」的需求砍掉的紀律，而這種紀律 AI 給不了。

對已經在寫程式的人，它給了一個明確的檢查清單雛形：欄位約束的三層一致性、繞過前端的直接呼叫、寫入介面的重複提交。這三問不依賴任何特定工具，換一家模型、換一種語言都成立。

對產品與商業側的人，它提醒了一件事：把 AI 塞進功能清單，和用 AI 把功能做出來，是兩個完全不同的競爭位置。前者賣的是名詞，後者省的是時間。廚菜記一家人共用的菜單裡沒有任何智慧推薦，但它從設計到上架只花了五週。在軟體這門生意裡，後者往往比前者更難被抄。

文／沈安