Karpathy氛围编程最新指南！

henry 发自 凹非寺
量子位 | 公众号 QbitAI

刚刚，大神Karpathy发布全新Vibe Coding指南！
在这份指南中，Karpathy不死磕单一模型，而是集众模之所长，总结出了一套AI编程的三层结构：


Cursor——主要负责自动补全与小范围代码修改，高效传达任务意图。Claude Code/Codex——用于实现较大功能块，快速原型开发和跨领域代码尝试。GPT-5 Pro——解决最棘手的bug或复杂抽象，提供深度文档/资料支持。
这三层递进的结构，不仅是Karpathy对编程技巧的分享，更是他对Vibe Coding概念的一次升级式售后。
让我们看看他是怎么做的吧！
顺境Cursor，逆境Claude/Codex，绝境GPT-5 Pro
总的来说，Karpathy这套三层结构源自个人编程的实战经验。
他根据工具的使用频率任务种类，对Cursor、Claude Code/Codex和GPT-5 Pro进行了结构化组织——
将常见、简单、局部的补全与修改交给Cursor，将较大功能块的实现交给Claude Code / Codex，当遇到它们都无法解决的问题，再求助GPT-5 Pro。
即所谓顺境Cursor，逆境Claude/Codex，绝境GPT-5 Pro。


展开来说，第一层，就是最常见的情况（约75%），通过Cursor的Tab键自动补全代码。


在此，Karpathy发现了一种和大语言模型高带宽沟通的方式——在项目的适当位置写下一些具体的代码片段或注释。
这样做的目的很明确：通过代码或注释直接展示任务意图，一次性传递大量、精确的信息，比单靠文字描述更快、更清晰。
（Karpathy注：有时候自动补全模型会有点烦人，注意来回切换开关）
除此之外，就是对一段具体代码进行高亮，然后请求某种修改。


第二层，就是Claude Code/Codex等可以在Cursor侧栏中配置的模型，Karpathy主要用它们来实现一些通过提示词比较容易指定的大功能块


整体看来，这些工具非常有用，但效果嘛，就有好有坏。
先说优点，在一些开发者比较陌生、比较Vibe Coding的领域里，它们是不可或缺的。
对于Karpathy而言，像写Rust、SQL语句，这些他以前没怎么做过的东西，这些工具就非常好用。与此同时，这些工具还能快速生成一次性的可视化或调试代码，为开发者省下大量重复劳动。
在此，代码可以随意地创造删除，不再像过去那样珍贵。于是，大神又造了一个新词：“代码后稀缺时代”（code post-scarcity era）
说完优点，我们来看看缺点：
首先，这类模型很容易跑偏，因此，Karpathy通常不用“YOLO模式”（全面托管），并且不得不常按ESC终止项目。
其次，AI写的代码非常容易出现屎山，毫无The Zen of Python的美感。
具体来说，AI编程工具一来经常滥用try/catch、让抽象过于复杂；二来会把代码膨胀得很大（比如用嵌套的if-else，而其实列表推导式或一行if-then-else就能解决）；三来会复制粘贴代码块，而不是抽出一个好用的辅助函数……
对此，开发者往往还得再手动做一轮“清理”，处理上述这些编码风格方面的问题。
此外，Karpathy的经验还反映了当前AI编程工具在解释性和交互性上的局限。
例如，他想让Claude Code在写代码的同时讲解，但发现完全行不通——AI工具显然更想“写代码”，而非解释为什么这样写代码。
最后一层是GPT-5 Pro，Karpathy会在最难的情况下求助于它。
比如，当Karpathy、Cursor和Claude Code卡在一个bug上10分钟无果时，他就会把整个问题复制粘贴给GPT-5 Pro，让它跑10分钟，结果还真能被它找到bug。
Karpathy表示，GPT-5 Pro非常强大，能挖掘出各种深奥的文档和论文。在处理清理抽象结构、做文献综述、调查研究等复杂任务中，也能返回高相关性的资源和线索。
最后，Karpathy总结道：
编程在不同“类型”的工作流和工具之间被彻底打开了各种可能性，每个都有自己的优缺点。但这也让人难以避免地产生某种焦虑：担心自己没站在“集体可能性”的最前沿。所以这就是我在周日胡思乱想的一些笔记，也带着好奇心想知道别人都在发现些什么。
实际上，这也体现了大神总结经验的意义：通过与开发者交流、分享使用心得，整个开发社区才能不断迭代和进步。
值得一提的是，在4个月之前，Karpathy分享了自己的Vibe Coding指南1.0：
把所有相关内容塞进上下文里（在大型项目中可能需要很久。如果项目够小，就直接把所有文件都塞进去。描述我们接下来要实现的那个具体的、增量式的小改动。不要直接要代码，而是要几种高层次的思路，并分析它们的优缺点。几乎总是会有多种做法，而大语言模型的判断并不总是可靠。然后（可选）再具体化。选择一种思路，请它写出第一版代码。进入复查/学习阶段：手动在浏览器里打开我不熟悉或没调用过的API文档，向模型提问解释、澄清、修改，必要时回退并尝试另一种思路。测试。Git commit。询问可以接下来实现什么。然后重复这个循环。
可以说，自今年2月Karpathy提出Vibe Coding以来，他一直在不断完善和实践这一构想，避免它沦为单纯的“概念游戏”。
基于此，网友们也纷纷给出了自己的尝试和答案。
网友在线，出谋划策
在大神的一番分享下，许多网友表示深有同感，觉得自己的经历和大神非常类似。
基本上就是小问题直接靠AI补全，大问题靠AI工具多roll给方向，自己来监督。


有网友表示：有时候一个模型卡在某个问题上，另一个模型却能快速解决。
而在不同的模型之间切换，为每个任务选择合适的模型，已然成为了一门艺术！


其他网友也是晒出了自己的心得：确保LLM生成代码一致性的最好方法是提供详细的需求说明和功能拆解，同时附上验收标准，包括代码风格和质量规范。


ps，有位网友发现了华点：我“双子座”去哪了？


你的Vibe Coding神操作是什么？快来炫一波！
[1]https://x.com/karpathy/status/1959703967694545296
[2]https://x.com/karpathy/status/1886192184808149383
[3]https://x.com/karpathy/status/1915581920022585597