氛围编程师崛起！年薪87万一天15小时，Karpathy用400行AI代码点燃硅谷

新智元报道

编辑：桃子 好困

【新智元导读】氛围编程彻底火了。刚刚，没有任何Swift编程经验的Karpathy亲自代言，通过与ChatGPT多轮对话，仅用400行代码构建出自己的首个iOS应用。

Vibe Coding（氛围编程），如今成为硅谷最新流行语。

首次提出这一概念的AI大神Karpathy，再度分享了自己的编程新姿势——用Swift编写首个完整卡路里追踪的iOS应用。

令人惊讶的是，他完全没有Swift编程经验，也没有翻阅任何文档。

通过与ChatGPT的多轮对话，Karpathy仅用1小时完成整个开发过程，并成功部署到手机上。

一则YC招聘启示中，一则YC招聘启示中，明确提出工作内容中的50%代码，均是由AI完成，年薪高达120k美金（87万元）。

职位介绍中，每天工作12-15小时，却成为了全网的华点。

如果AI真的提高了生产力，为啥还会有人每天狂干12-15个小时呢？

400行代码，ChatGPT化身编程导师

Karpathy如何用嘴，迅速完成一个iOS应用的开发？

推文中，他具体分享了自己与ChatGPT对话的四次过程：启动应用；功能增强；使用AppStorage持久化数据；部署到手机。

在启动应用阶段，Karpathy从0开始，告诉ChatGPT自己的需求：刚刚下载了Xcode，希望用SwiftUI构建一个iOS应用。

ChatGPT在接下来开启了「手把手」教学。

首先安装和启动Xcode，就这个环节已经细致到，打开点击具体某个选项。然后配置项目，包括命名、界面、编程语言等选择。

接下来，ChatGPT还提供了基础代码，包括SwiftUI的界面布局和逻辑实现，帮助Karpathy快速搭建了一个可运行的原型。

有了原型之后，便开始实操了——构建一个体脂追踪的计时器APP。

Karpathy就像一位产品经理一样，给出了自己的具体要求：「计时器」主要体现随时间变化而自然消耗的热量，用大号数字显示在屏幕中央，还要每秒更新一次消耗的热量。

ChatGPT按照指令，给出了分布构建过程，以及下一步建议。

接下来，Karpathy还要求其给出不同按键对应的功能代码搭建过程，以及每秒更新的配置。

第二部分，在基础版本完成之后，就是去做功能增强。

比如，支持明暗模式切换，简单的加减按钮、触觉反馈和动画等，ChatGPT均提供了具体的代码片段和实现建议。

为了让数据在应用关闭后依然保存，Karpathy还向ChatGPT询问了如何使用AppStorage。

ChatGPT详细讲解了AppStorage的使用方法，并帮他将卡路里数据存储到UserDefaults中。

最后一步，Karpathy需要将这款应用部署到iPhone上，ChatGPT指导他完成了Xcode配置、证书设置、设备部署的步骤，并最终让应用成功运行在手机上。

经过1小时的对话，卡路里计时器的应用完成了。

下面是计时器的主要功能，一共200行代码，只有几个UI元素和一些简单的逻辑。

第二天，Karpathy又通过与ChatGPT的3次对话，为应用添加了一些新功能：动画环、将固定值显示在 [-3500, 3500] 区间内。

刚刚，他还为其添加了日志、为+100/-100添加小字说明并隐藏BMR两个功能。

截至目前，这款应用代码也仅有400行。

网友疯狂整活

随着氛围编程越来越火，圈内大佬Min Choi也总结了一波效果拔群的案例。

开发者Luke Van In用大约1万行Claude编写的代码构建了一款游戏。

他认为，当前代码库的复杂库已经接近可控的极限，Claude已经能够重构20%代码，并自动添加了武器后坐力和镜头抖动的效果。

对于贴花系统，Luke又借助了Grok进行了一些手动调整。

xAI工程师kache设置了一种方法，可以动态重新加载客户端和服务器逻辑，无需用户刷新页面，就可以实时更新和迭代。

他还特意强调，如果自己清楚想要做什么，氛围编程才能发挥其优势。

还有一位开发者Louie Bacaj仅用Claude 3.7+o1 Pro，在几个小时内通过氛围编程做出一个益智游戏。

还有角色扮演的小游戏，也是通过氛围编程就能完成。

还有人用两条提示，就能让游戏中NPC驾驶飞机。

不是所有AI辅助编程都是「氛围编程」

值得注意的是，并不是所有用上AI辅助的编程，都能称之为「氛围编程」。

在最近的一篇博客中，知名web框架Django的共同作者Simon Willison，就对这一概念进行了非常详尽的解释。

并且，还获得了「发明人」Karpathy的大加赞赏：

就个人体验而言，当我处于类似下面这条狗的状态时，就会称之为「氛围编程」——比如昨晚开发iOS应用时的场景。

但实际开发中，我很少彻底放任AI自由发挥，更多时候保持着渐进式迭代：审阅生成代码、分阶段增加复杂度、通过持续提出澄清问题来逐步理解模块间的交互逻辑。

氛围编程正当时

自从Andrej Karpathy在2月3日首次提出「氛围编程」后，这一概念随即登上各大主流媒体，并引发无数线上讨论。

为了避免偏离初衷，这里必须强调——氛围编程绝不等同于借助LLM编写代码，而是在不审查LLM产出代码的情况下构建软件。

「氛围编程」可以你完全沉浸在氛围中，拥抱指数级进步，甚至忘记代码本身的存在。这是因为LLM（例如Cursor Composer搭配Sonnet）已经变得足够优秀。我甚至可以只用SuperWhisper与Composer进行对话，几乎无需摸键盘。

我会提出最基础的要求，比如「将侧边栏的内边距减半」。并且总是点击「全部接受」，而不去查看代码差异。遇到报错，就直接复制到对话框中让LLM去修复。代码的复杂程度已超出我的日常认知，真要理解必须逐行细读。有时LLM无法修复bug，我就直接绕过或随机调整直到问题消失。

对于周末随便做的项目来说，可谓是充满趣味。只是观察、口述、运行、复制粘贴，结果居然大部分都能跑通。

作为天赋异禀的资深程序员，Andrej本无需AI辅助。他选择这种编程方式，是因为尝试疯狂的创意充满乐趣，且LLM的代码生成速度比最顶尖的人类程序员快几个数量级。

对于低风险的原型开发，何不放手让它发挥？

使用LLM写代码≠氛围编程

与专业软件工程师使用LLM的方式相比，这种「忘记代码存在」的开发方式有着本质差异。

首先，软件工程师需要构建的是符合多重标准的系统——不仅要可验证运行，还需具备人类可读性（及机器可解析性），并能支撑长期迭代开发。

其次，软件工程师需要在同时考虑显性需求与隐性约束的情况下，从数十种潜在方案中筛选出最优解，进而实现性能、可访问性、安全性、可维护性、成本效益等指标之间的平衡。

第三，软件工程师还需要对代码进行审查。生产环境AI辅助开发铁律是：任何无法向其他人精确解释工作原理的代码，都禁止进入版本库。

不难看出，当LLM生成代码后，软件工程师会完整地执行审查、测试，以及确保可解释性这一系列流程。也就是说，这本质上仍是传统软件开发范式。工具链中是否包含LLM，并不改变工程实践的属性。

氛围编程的价值

虽然氛围编程≠用LLM进行编程，但这并不意味着它是一种不负责任的开发方式。

这种突破性的编程形式，实则蕴含着改变世界的潜能——让数百万没有计算机学位或经过编程培训的普通人，也能借助工具，让计算机完成高度定制化任务，打造属于自己的个性化工具。

如此一来，那些原本和编程没什么交集的人可能会因此点燃热情，并最终成长为专业开发者。这个行业的最大壁垒——如同攀登悬崖般的初始学习曲线——将被氛围编程彻底铲平。

而资深的工程师们，也可以借此训练自己对模型能力边界的认知。正如此前所论述的，使用LLM编码如同在暗藏技术雷区的迷宫中探索，需要持续积累直觉经验。

一句话总结就是，「氛围编程」值得所有「段位」的开发者亲身投入体验。

参考资料：

https://x.com/karpathy/status/1903671737780498883

https://x.com/karpathy/status/1903870973126045712

https://x.com/minchoi/status/1903895144413159516