一小時寫完程式碼,等了二十二天備案:AI把開發成本壓到接近零之後,帳記到了流程上
一位工程師用AI工具WorkBuddy在1小時內開發出九宮格拼圖小程序,但備案等了22天,本文從技術替代曲線與開發流程瓶頸移轉,拆解個人開發者的成本帳。
刊登 閱讀約 4 分鐘
(事件日期:2026年11月1日,掘金平臺文章發布,回顧整理)
一組對比先看落差
程式員「曉凡」在掘金發文,記錄自己用AI開發工具WorkBuddy做出第一支微信小程序「九格圖文」的完整過程。幾個關鍵數字:全程未手寫一行程式碼;從想法到第一版可預覽的小程序,用時不到1小時;而小程序備案審核,等了22天;個人主體認證費30元人民幣。
這組數字的意義在於時間結構的倒轉。在傳統開發流程裡,程式碼撰寫佔據主要工時,備案與審核只是收尾動作。當AI把前者壓縮到1小時以內,整個專案的瓶頸就完全移到了平臺行政流程那一端:開發端耗時佔比從過去的絕對主導,跌到不足備案等待期的二十分之一。
這與我們先前整理過的家庭菜譜小程序20天601名訪客的獨立開發帳可以對照:當時的結論是AI已把「能不能做出來」的門檻拆掉,剩下的難題全在獲客。這次的案例又推進了一步,連「懂不懂小程序框架」都不再是前提。
開發流程被壓縮成什麼形狀
照原文描述,這套流程被簡化為四步:把想法丟給工具並讓它反向提問確認、生成功能列表文件、生成HTML原型圖、最後依這兩份文件自動生成小程序程式碼。過程中唯一需要使用者做決策的環節,是是否開啟雲服務(涉及資料儲存、用戶登入、檔案上傳或大模型呼叫)。
值得注意的是作者的兩個操作細節。其一,在提示詞中要求「有不清楚的需要跟我確認」,這實質上是把需求範圍管理的責任從人轉給AI,避免專案範圍失控;其二,每個新項目建立獨立工作空間,以維持AI的上下文記憶乾淨。這兩個習慣對應的正是過去軟體專案裡最難量化、也最容易被低估的成本:需求變更與環境配置。
技術替代曲線在這裡的含義很具體。作者自述兩年前買了幾本小程序開發書,看了幾章後擱置,一直未能上線作品;如今同一個人、同樣的技術儲備,1小時內得到可預覽成品。被替代的不是這名工程師的職位,而是「入門學習」這個階段的時間投入。對個人開發者而言,試錯成本從以月計降到以小時計。
誰受惠,誰承壓
受惠端首先是工具方與平臺方。WorkBuddy要求5.6.1以上版本並內建開發環境與雲服務接入,等於把微信小程序的技術棧包裝成一個訂閱或下載商品;微信生態則因個人開發者供給增加,小程序總量與內容多樣性同步擴張。個人認證費30元雖然金額極小,但按潛在開發者規模放大,仍是平臺一筆穩定的準入收入。
承壓端有兩層。第一層是低複雜度小程序的外包市場:當工具類、展示類小程序的製作時間跌到1小時級別,這類訂單的合理報價基礎被直接侵蝕,情況與我們在副業帳本裡十套小程序只賣四十六元的案例中看到的單價崩落互相印證。第二層是審核與備案體系本身:備案22天成為全流程最長環節,若開發者供給因AI工具而放量,平臺行政處理能力將成為供給曲線上最陡的一段。
數字有限時,判斷也該有限
這是一篇單一作者的個人紀錄,樣本數為一。1小時的開發時長對應的是九宮格拼圖這類功能極簡的品類,不能直接外推到需要後端邏輯、支付或資料合規的小程序。文章也未提供WorkBuddy的收費模式細節與雲服務的後續費用,這部分的成本帳目前無法核實。
可以確認的是趨勢本身:程式碼生產環節的邊際成本趨近於零之後,個人開發者的總成本結構已經改由三塊構成,平臺準入費、等待審核的時間成本、以及上線之後的獲客成本。前兩塊是固定且透明的,第三塊才是決定這門生意能否成立的變數。工具把門敲開了,門後面的流量分配邏輯沒有變。