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

氛围编程如今风靡一时。刚才，没有任何 Swift 编程经历的 Karpathy 亲自实践，通过与 ChatGPT 进行多轮交流，仅用 400 行代码开发出了自己的首款 iOS 应用。

Vibe Coding（氛围编程）现已成为硅谷的最新流行语。

首次提出这一概念的 AI 领域专家 Karpathy，再次展示了他的编程新模式——用 Swift 制作第一个完整的卡路里追踪 iOS 应用。

令人意外的是，他完全没有 Swift 编程的背景，也没有查阅任何文档。

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

不仅如此，随着氛围编程的流行，许多网友纷纷创作不同类型的游戏和网站，甚至科技公司也开始招聘「氛围编程师」这一职位。

某次 YC 的招聘信息中，明确指出工作内容中有 50% 的代码是由 AI 完成，年薪高达 12 万美元（约 87 万元）。

职位描述中，要求每天工作 12-15 小时，这一情况引发了全网热议。

如果 AI 真的提升了生产力，为什么依然有人需要每天拼命工作 12-15 小时呢？

400 行代码，ChatGPT 成为编程助手

Karpathy 是如何以口述的方式迅速完成一个 iOS 应用开发的呢？

在推文中，他详细分享了与 ChatGPT 对话的四个阶段：启动应用；功能增强；使用 AppStorage 持久化数据；部署到手机。

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

随后，ChatGPT 开始了「手把手」的教学。

首先是安装和启动 Xcode，指导到细节，例如打开某个选项。然后配置项目，包括命名、界面、编程语言等选择。

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

有了原型，接下来就要实操了——构建一个体脂追踪的计时器应用。

Karpathy 像一名产品经理一样，明确了自己的要求：“计时器”需能反映随时间变化而自然耗费的热量，大数字显示在屏幕中央，每秒更新消耗的热量。

ChatGPT 根据指令给出了构建过程的分步建议，以及下一步计划。

接下来，Karpathy 还要求 ChatGPT 提供不同按键的功能代码搭建过程，以及每秒更新的配置。

第二部分，在基础版本完成后，进行功能增强。

比如，支持明暗模式切换、简单的加减按钮、触觉反馈和动画等，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

本文来源于微信公众号：新智元（ID：AI_era）