Copilot实战整破防？真部署环节才是AI编程的最大门槛

梦瑶 发自 凹非寺
量子位 | 公众号 QbitAI

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

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

这话，出自大神卡帕西。

是的，这位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的

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

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

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

甚至没准真有那么一天，咱连提示词都不用写，直接脑机接口一步到位？？？（狗头）

大家有什么看法？欢迎评论区聊聊～

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

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

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