夢瑤 發自 凹非寺
量子位 | 公眾號 QbitAI

• 我是真發現了，擱現在寫代碼不是難事兒，難的是你得搞一堆部署服務?。?/li>

這話，出自大神卡帕西。

是的，這位AI Coding界的明星人物，開始公開吐槽一件事——代碼已經不是AI編程的瓶頸了，部署才是。

更關鍵的是，人家卡帕西還直接把問題點破了：

所有應用產品的開發流程，都應該變成可以被代碼直接調用的東西，最好人類完全不用手動配置！

卡帕西這番感慨一出，帖子底下的開發者網友們更是憋了一肚子牢騷，紛紛吐槽起AI編程里的各種部署坑：

AI編程部署的困擾，顯然已經成了程序員們公認的大難題。

卡帕西：應用開發這事兒，部署忒難！

主要吧，卡帕西還是被自己過往的一段應用開發經歷折磨壞了……

這事兒還要說回去年他自己用AI搓的一個「菜單圖片生成器」產品——MenuGen

當時做這個產品的動機也很簡單，主要是卡帕西平時去餐館吃飯，看到那種純文字菜單，經常不知道這道菜到底長啥樣。

本來是想美美干飯，但是把時間全花在谷歌搜索菜單名這事兒上了，氣不打一出來。

（于是人家干脆直接自己用AI搓了一個～）

你別說，從下面這產品效果看還真不錯，把菜單輸入進去就能呈現一個帶食物圖片的菜單了——

產品效果確實不賴，但整個產品應用的開發過程，多少給人家卡帕西留下點陰影。（doge）

在整個菜單項目開發環節，他幾乎沒怎么操心寫代碼這事兒， 整個項目基本都是靠Cursor+Claude搓出來的。

他做的只是把應用需求丟進去，Claude 3.7很快就把所有React前端組件寫好了，速度快到離譜，也非常順利～

到了這一步，天真的卡帕西一度以為，80%的開發進度肯定已經搞定了，但現實光速打臉——

等真正進入部署環節，他才意識到一件事：自己剛剛那一套操作，可能連20%都算不上。（天塌啦?。?/p>

麻煩，開始了。

在后續的部署環節中，卡帕西第一步是調用OpenAI API做OCR識別，先得把API key搞定。

結果光是在后臺找項目、配權限就繞了一大圈，Claude還不斷給出過時的API、模型名和調用方式，來回踩坑，只能反復對著文檔一點點修。

好不容易跑通一次調用，又立刻撞上非常嚴重的限速問題——每10分鐘只能發出寥寥幾次請求……

接下來，問題開始一波接一波地如魔鬼纏繞般上演：

卡帕西想做圖像生成，自己又去注冊了一個Replicate API key，結果幾乎是同一套坑再來一遍；

LLM給的調用方法依舊過時，文檔也沒完全跟上更新，API甚至不再返回JSON，而是變成了一種他和Claude都看不懂的流式對象。

好不容易對齊接口吧，又撞上限速，調試幾乎沒法推進……

在上線環節更是離譜，在注冊賬號、GitHub連接這些配置場景上，也是接連出現各種問題。

日志里全是lint問題，本地一點事沒有，這些問題好不容易修完，結果網站還是打不開。

卡帕西請教完Claude，請教ChatGPT，甚至開始懷疑是不是哪步理解錯了，折騰了快一小時，才發現是個特別低級的問題：

API key都寫在.env.lacal里，而這個文件本來就不會被提交，于是卡帕西又手動去Vercel后臺，把環境變量一條條補進去。

您猜怎么著，Vercel直接生成了一個公網鏈接就能訪問，但這項目其實還是私有倉庫，連對外展示都還沒準備好。

產品，就這么……被順手上線了。

上線之后問題依舊不斷：認證、支付、域名、OAuth，一路串多個平臺來回配置，卡帕西直接被這套流程折騰麻了。

大家也看得出來，產品確實是很產品，但產品背后在部署配置的一系列心酸楚苦也是實打實存在的…

聊到這次一波三折的菜單項目，卡帕西自己也忍不住總結了一句：

• 本地跑demo的時候，vibe coding確實很爽；但一旦變成真正要上線的應用，整個過程就變得忒痛苦！??！

因此他也給出了一個結論——

那就是讓幾乎沒有Web開發背景的人，用vibe coding從零做一個應用，確實能做出來，而且比過去快很多，代碼幾乎不是問題。

但問題是一到部署、接服務、配環境就頻頻卡住，體驗直接崩塌，問題不在AI，而在工具鏈。

這些部署工具本來就是為專業開發者設計的，現在一個人配合AI就想跑完整流程，到了工程鏈路這一步，當然就會頻頻卡bug了。

對此，卡帕西從這次一波三折的開發經歷中也得出了一些經驗和建議，在他看來：

• 一體化平臺非常重要，最好有產品能直接把整套部署能力打包好，讓大家直接能開箱即用。（附議！
• 目前市面上這些開發工具，幾乎給AI用的，不太像是給人用的，最好能的方法是讓AI自己去調用和配置。
• 與其整一堆復雜配置流程框架，不如用簡單架構更省事，基礎前端+簡單后端，反而更適合快速做應用。

他認為，很多應用壓根不需要做成完整產品，應用不應該是代碼堆出來的，而應該是用一句話生成出來的。

哪怕時隔了一年多的時間，卡帕西再談到這個項目時，依舊有感而發，be like：

AI編程下半場，開始卷「部署自動化」了

老話說，有問題就有解法。

卡帕西這次突然感慨AI編程部署，其實也是因為他轉發了一款正試圖填這塊坑的產品——Stripe Projects。

這款產品，出自支付基礎設施公司Stripe聯合創始人兼CEOPatrick Collison及其團隊之手。

Stripe Projects的要做的事兒，就是——

通過一個開發基礎設施總入口，讓開發者或AI agent用幾條命令就能把賬號注冊、托管、認證、賬單這些麻煩事搞定。

而這也恰好和卡帕西對AI編程的理想設想高度一致。

事實上，這兩年除了Stripe Projects外，一些在AI編程部署環節優化的產品也陸陸續續出現。

比如——Firebase Studio。

官方說法是是能用AI Agent來原型、開發、測試、迭代并發布全棧AI應用，本質上也是把寫代碼+配后端+發上線盡量收進一個工作區里。

再例如——Railway。

主打的也是一個「開箱即用」，它已經能把一些多服務模板自動連好，甚至自動通過環境變量把服務串起來，減少用戶的手動配置～

看下來只能說，AI編程這事兒，現在確實有點魔幻。

一邊是Claude、Cursor幾分鐘就把前端頁面搓出來，另一邊是API key、各種配置連環暴擊，分分鐘把人打回現實。

而且最近倆仨月身邊最直觀的一個例子就是——OpenClaw。

想讓龍蝦做一個開發網站，前提是要不停調試那個動不動就卡bug的

如果涉及到需要一只24小時運行的項目，問題可能會更多，終端掉了頁面跟著完蛋，又得重蹈覆轍修修補補…

所以卡帕西這波吐槽之所以這么網友共鳴，也確實不是沒有原因…

不管咋說，還是讓我們狠狠期待一下有更多更好更省事兒的產品出現叭。

甚至沒準真有那么一天，咱連提示詞都不用寫，直接腦機接口一步到位？？？（狗頭）

大家有什么看法？歡迎評論區聊聊～

[1]https://karpathy.bearblog.dev/vibe-coding-menugen/

[2]https://www.menugen.app/

[3]https://firebase.google.com/