Vibe Coding 如今在硅谷成为了最新的流行语。
AI 大神 Karpathy 首次提出了这一概念，他再次分享了自己的编程新姿势，即使用 Swift 编写了首个完整的卡路里追踪的 iOS 应用。
他完全没有 Swift 编程经验，这令人惊讶。并且他也没有翻阅任何文档。
Karpathy 通过多轮与 GPT 进行对话，仅花费 1 小时就完成了整个开发过程，并且成功将其部署到了手机上。
一则 YC 招聘启示明确指出，其工作内容的 50%代码是由 AI 完成的，并且年薪高达 120k 美金（约 87 万元）。
职位介绍中，每天工作12-15小时，却成为了全网的华点。
如果 AI 真的提升了生产力，那为什么还会有一些人每天要不停地工作 12 到 15 个小时呢？
400行代码，GPT化身编程导师
Karpathy如何用嘴，迅速完成一个iOS应用的开发？
推文中，他分别分享了以下四个与 GPT 对话的过程：一是启动应用；二是功能增强；三是使用 AppStorage 来持久化数据；四是部署到手机。
在启动应用的阶段，Karpathy从最开始也就是 0 开始，向 GPT 表明了自己的需求，即刚刚下载了 Xcode，期望能够用 SwiftUI 来构建一个 iOS 应用。
GPT在接下来开启了「手把手」教学。
首先要进行 Xcode 的安装和启动，这个环节非常细致，需要打开并点击具体的某个选项。接着要对项目进行配置，包括给项目命名、选择界面以及编程语言等。
GPT 接着提供了基础代码，其中包含 SwiftUI 的界面布局以及逻辑实现，这帮助 Karpathy 迅速搭建起了一个能够运行的原型。
有了原型后，就开始进行实际操作了。具体来说，是构建一个能够进行体脂追踪的计时器 APP。
Karpathy 给出了自己的具体要求，就如同一位产品经理。他要求“计时器”主要能体现随时间变化自然消耗的热量，并且要将其用大号数字显示在屏幕中央，同时还需每秒更新一次消耗的热量。
GPT按照指令，给出了分布构建过程，以及下一步建议。
接下来，Karpathy 要求其给出不同按键所对应的功能代码的搭建过程。同时，Karpathy 还要求其给出每秒更新的配置。
第二部分，在基础版本完成之后，就是去做功能增强。
例如，它支持明暗模式的切换，还有简单的加减按钮、触觉反馈以及动画等方面。GPT 都给出了具体的代码片段以及实现的建议。
为了使数据在应用关闭后能够得以保存，Karpathy向 GPT 咨询了怎样去使用 AppStorage 。
GPT详细地讲解了 AppStorage 的使用办法，并且帮助他把卡路里数据存储到了 UserDefaults 里。
Karpathy 需将这款应用部署到 iPhone 上，GPT 指导他完成了一系列步骤，包括 Xcode 配置、证书设置以及设备部署，最终使应用在手机上成功运行。
经过1小时的对话，卡路里计时器的应用完成了。
以下是计时器的主要功能，其代码行数为 200 行，仅包含几个 UI 元素以及一些较为简单的逻辑。
第二天，Karpathy 进行了 3 次与 GPT 的对话。在这些对话之后，他为应用添加了一些新功能。这些新功能包括动画环以及将固定值显示在 [-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 进行编码就好像在充满技术隐患的迷宫中进行探索，这需要持续地积累直觉经验。
总结来说，“氛围编程”值得各个“段位”的开发者亲自去投入并体验。
参考资料：
