卡帕西都整破防了:AI Coding没门槛,可部署环节真嗯啊的难
8 小时前 / 阅读约8分钟
来源:36kr
AI Coding界明星卡帕西吐槽AI编程中部署难,认为代码不是瓶颈,部署才是。他分享了自己开发菜单图片生成器的经历,指出部署工具链问题,期待一体化平台出现。

我是真发现了,搁现在写代码不是难事儿,难的是你得搞一堆部署服务!!

这话,出自大神卡帕西

是的,这位AI Coding界的明星人物,开始公开吐槽一件事——代码已经不是AI编程的瓶颈了,部署才是。

更关键的是,人家卡帕西还直接把问题点破了:

所有应用产品的开发流程,都应该变成可以被代码直接调用的东西,最好人类完全不用手动配置!

卡帕西这番感慨一出,帖子底下的开发者网友们更是憋了一肚子牢骚,纷纷吐槽起AI编程里的各种部署坑:

AI编程部署的困扰,显然已经成了程序员们公认的大难题。

卡帕西:应用开发这事儿,部署忒难!

主要吧,卡帕西还是被自己过往的一段应用开发经历折磨坏了……

这事儿还要说回去年他自己用AI搓的一个「菜单图片生成器」产品——MenuGen

当时做这个产品的动机也很简单,主要是卡帕西平时去餐馆吃饭,看到那种纯文字菜单,经常不知道这道菜到底长啥样。

本来是想美美干饭,但是把时间全花在谷歌搜索菜单名这事儿上了,气不打一出来。

(于是人家干脆直接自己用AI搓了一个~)

你别说,从下面这产品效果看还真不错,把菜单输入进去就能呈现一个带食物图片的菜单了——

产品效果确实不赖,但整个产品应用的开发过程,多少给人家卡帕西留下点阴影。(doge)

在整个菜单项目开发环节,他几乎没怎么操心写代码这事儿, 整个项目基本都是靠Cursor+Claude搓出来的。

他做的只是把应用需求丢进去,Claude 3.7很快就把所有React前端组件写好了,速度快到离谱,也非常顺利~

到了这一步,天真的卡帕西一度以为,80%的开发进度肯定已经搞定了,但现实光速打脸——

等真正进入部署环节,他才意识到一件事:自己刚刚那一套操作,可能连20%都算不上。(天塌啦!)

麻烦,开始了。

在后续的部署环节中,卡帕西第一步是调用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的

,还要设置API等各种繁琐配置。

如果涉及到需要一只24小时运行的项目,问题可能会更多,终端掉了页面跟着完蛋,又得重蹈覆辙修修补补…

所以卡帕西这波吐槽之所以这么网友共鸣,也确实不是没有原因…

不管咋说,还是让我们狠狠期待一下有更多更好更省事儿的产品出现叭。

甚至没准真有那么一天,咱连提示词都不用写,直接脑机接口一步到位???(狗头)

大家有什么看法?欢迎评论区聊聊~

参考链接:

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

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

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