【新智元导读】氛围编程彻底火了。刚刚，没有任何 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 设置了一种方法，可以动态重新加载客户端和服务器逻辑，无需用户刷新页面，就可以实时更新和迭代。
他还特意强调，如果自己清楚想要做什么，氛围编程才能发挥其优势。
还有人用两条提示，就能让游戏中 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 编码如同在暗藏技术雷区的迷宫中探索，需要持续积累直觉经验。
一句话总结就是，「氛围编程」值得所有「段位」的开发者亲身投入体验。
参考资料：