新智元报道
【新智元导读】氛围编程彻底火了。刚刚，没有任何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