导语
Andrej Karpathy 是在我的学习名单上的顶尖导师之一。他是 OpenAI 创始成员之一、前特斯拉 AI 总监。他的油管频道分享了大量 LLM 原理和应用的教学视频。他还是 Vibe Coding 概念的提出者，大力推广 AI 编程。
上个礼拜，Karpathy 在 X 上分享了他目前的 AI 编程工作流，通过灵活组合不同的工具来实现效果的最大化。对于希望提升 AI 编程效率的开发者来说，这篇文章非常值得一读。
以下是原文与译文的对照，附带我自己的深度解析。
译文
Continuing the journey of optimal LLM-assisted coding experience. In particular, I find that instead of narrowing in on a perfect one thing my usage is increasingly diversifying across a few workflows that I “stitch up” the pros/cons of:
继续我对于最佳的大模型辅助编程体验的探索之旅。我尤其发现，我并非专注于寻找某一种完美的工具，而是将我的使用方式日益分散到几种不同的工作流中，通过组合它们来取长补短：
Personally the bread & butter (~75%?) of my LLM assistance continues to be just (Cursor) tab complete. This is because I find that writing concrete chunks of code/comments myself and in the right part of the code is a high bandwidth way of communicating “task specification” to the LLM, i.e. it’s primarily about task specification bits - it takes too many bits and too much latency to communicate what I want in text, and it’s faster to just demonstrate it in the code and in the right place. Sometimes the tab complete model is annoying so I toggle it on/off a lot.
就我个人而言，大语言模型辅助中，最主要（约 75%）的部分仍然只是（Cursor 的）Tab 键代码补全。这是因为我发现，亲自在代码的正确位置编写具体的代码块或注释，是向大语言模型传达“任务指令”的一种高带宽方式。也就是说，这主要关乎传递任务指令的信息量——通过文本来沟通我的需求，信息量太大、延迟也太高，远不如直接在代码的正确位置进行演示来得快。有时代码补全模型很烦人，所以我经常会频繁地开关这个功能。
nettee 批注：
Cursor 的 Tab 代码补全是一种半自动的 AI 辅助编程方式，对于代码水平很高的人来说，这种方式的效率其实比让 AI 全自动编程要更高。
Cursor 在 AI 编程软件中是属于比较「复古」的一个存在。它不追求全自动的 AI 编程，而是希望你能实现人机协作编程：AI 编写 —— 人工审核 —— 手动修改 —— 继续 AI 编写。
这种人机协作的流程如果能够非常快速地进行循环，很容易产生心流感觉，这也是 Cursor 能够大火的原因之一。Karpathy 所说的「带宽」「延迟」，其实就是指这种人机协作流程的循环速度。
Next layer up is highlighting a concrete chunk of code and asking for some kind of a modification.
再上一层是选中一段具体的代码，然后要求模型进行某种修改。
Next layer up is Claude Code / Codex / etc, running on the side of Cursor, which I go to for larger chunks of functionality that are also fairly easy to specify in a prompt. These are super helpful, but still mixed overall and slightly frustrating at times. I don’t run in YOLO mode because they can go off-track and do dumb things you didn’t want/need and I ESC fairly often. I also haven’t learned to be productive using more than one instance in parallel - one already feels hard enough.
更上一层，是在 Cursor 旁运行的 Claude Code / Codex 等，当需要实现更大块、并且也比较容易用提示词说清楚的功能时，我就会求助于它们。这些工具超级有用，但总体上好坏参半，有时还有点令人沮丧。我不会不经检查就全盘接受它们生成的代码（即 YOLO 模式），因为它们可能会跑偏，做一些你不需要的蠢事，所以我经常按 ESC 键打断它。我也还没学会如何同时高效地使用多个实例——只用一个就已经感觉够难了。
nettee 批注：
Claude Code 和 Codex 其实是一类 AI 编程工具，都是希望能够全自动生成代码，不需要人的参与。
Karpathy 的意思是他会同时使用 Cursor 和 Claude Code / Codex，Cursor 用来做半自动化的任务，Claude Code / Codex 用来做大块的、全自动的任务。这是根据任务特点来选择不同的工具。
I haven’t figured out a good way to keep CLAUDE[.]md good or up to date. I often have to do a pass of “cleanups” for coding style, or matters of code taste. E.g. they are too defensive and often over-use try/catch statements, they often over-complicate abstractions, they overbloat code (e.g. a nested if-the-else constructs when a list comprehension or a one-liner if-then-else would work), or they duplicate code chunks instead of creating a nice helper function, things like that… they basically don’t have a sense of taste. They are indispensable in cases where I inch into a more vibe-coding territory where I’m less familiar (e.g. writing some rust recently, or sql commands, or anything else I’ve done less of before). I also tried CC to teach me things alongside the code it was writing but that didn’t work at all - it really wants to just write code a lot more than it wants to explain anything along the way. I tried to get CC to do hyperparameter tuning, which was highly amusing.
我还没找到一个好方法来维护 CLAUDE[.]md 文件（指代与 Claude 交互的上下文），让它保持良好或最新的状态。我经常需要对它们生成的代码在风格或个人品味方面进行一轮“清理”。例如，它们的代码写得过度防御，经常滥用 try/catch 语句；它们常常把抽象搞得过于复杂；它们会使代码臃肿（比如，当列表推导式或单行 if-then-else 就能解决问题时，却用了嵌套的 if-then-else 结构）；或者它们会重复代码块，而不是创建一个好用的辅助函数，诸如此类……它们基本上没有“品味”可言。然而，在某些情况下它们又是不可或缺的，比如当我进入一个不那么熟悉、更多是凭感觉编程的领域时（例如最近写一些 Rust，或者 SQL 命令，或其他我以前做得较少的事情）。我还尝试让 CC 在写代码的同时教我一些东西，但这完全行不通——它只想写代码，远甚于沿途解释任何东西。我试着让 CC 做超参数调优，结果非常滑稽。
They are also super helpful in all kinds of lower-stakes one-off custom visualization or utilities or debugging code that I would never write otherwise because it would have taken way too long. E.g. CC can hammer out 1,000 lines of one-off extensive visualization/code just to identify a specific bug, which gets all deleted right after we find it. It’s the code post-scarcity era - you can just create and then delete thousands of lines of super custom, super ephemeral code now, it’s ok, it’s not this precious costly thing anymore.
此外，在编写各种风险较低、一次性的自定义可视化、实用工具或调试代码时，它们也超级有帮助，如果没有它们，我根本不会去写这些代码，因为太花时间了。例如，CC 可以快速生成 1,000 行一次性的大段可视化代码，只为了定位一个特定的 bug，找到之后这些代码就全部删掉了。这是一个“代码后稀缺时代”——现在你可以随手创建，再随手删除成千上万行高度定制、转瞬即逝的代码，这没关系，它再也不是什么珍贵、成本高昂的东西了。
nettee 批注：
这些都是 Karpathy 在使用 Claude Code 时候的经验之谈。可以看到，Claude Code 最擅长的任务就是全自动写代码：你交给它一个任务，然后等它完成就可以了。
这里给我最大的启发是，Claude Code 是一个比较有特点、剑走偏锋的工具，所以一定要给它适合的任务。如果任务适合，它就能完成得很好；如果任务不适合，它的效果就很糟糕。
Final layer of defense is GPT5 Pro, which I go to for the hardest things. E.g. it has happened to me a few times now that I / Cursor / CC are all stuck on a bug for 10 minutes, but when I copy paste the whole thing to 5 Pro, it goes off for 10 minutes but then actually finds a really subtle bug. It is very strong. It can dig up all kinds of esoteric docs and papers and such. I’ve also used it for other meatier tasks, e.g. suggestions on how to clean up abstractions (mixed results, sometimes good ideas but not all), or an entire literature review around how people do this or that and it comes back with good relevant resources / pointers.
最后一道防线是 GPT5 Pro，我用它来处理最棘手的事情。例如，有好几次，我、Cursor 和 CC 都被一个 bug 卡住了 10 分钟，但当我把所有东西复制粘贴给 5 Pro 后，它处理了 10 分钟，然后真的找到了一个非常隐蔽的 bug。它非常强大。它能挖掘出各种冷门的文档、论文之类的东西。我也用它来处理其他更重量级的任务，比如就如何清理抽象层给出建议（结果好坏参半，有时想法不错，但并非总是如此），或者对人们如何做某件事进行全面的文献综述，它能返回很好的相关资源和线索。
nettee 批注：
这里就体现了不同模型的能力特点。我对 GPT 的印象也是这样的：如果有非常难排查的问题，我会交给 o3 或者 GPT 5 来思考。这是因为 GPT 模型在推理能力上做了特殊的强化，使得它非常适合思考这类问题。
这体现了对模型能力把握的重要性，了解模型的特点、模型的能力边界，你在指挥它们编程的时候会变得更加游刃有余。
Anyway, coding feels completely blown open with possibility across a number of “kinds” of coding and then a number of tools with their pros/cons. It’s hard to avoid the feeling of anxiety around not being at the frontier of what is collectively possible, hence random sunday shower of thoughts and a good amount of curiosity about what others are finding.
总之，在各种不同“类型”的编程工作中，借助这些各有利弊的工具，我感觉编程的可能性被完全打开了。这让人很难不产生一种焦虑感，担心自己没能站在技术浪潮的最前沿。因此，也就有了这些周日的胡思乱想，同时也让我非常好奇其他人都有什么新发现。
总结
我们可以从 Karpathy 的这篇文章中看出，他综合使用了三种不同的工具：
- Cursor 的 Tab 补全用来实现半自动化的编程
- 用 Claude Code / Codex 做一些大块的、全自动的任务
- 用 GPT5 Pro 解决一些特别难的问题
从这样的一篇分享中，我们可以看出，现在其实不存在一种万能的工具，可以解决各类问题。开发者最优的方案还是要灵活组合各种方法，搭建自己的工作流，才能获得最佳的 AI 编程效果。
善于发掘工具的特点，取长补短，也许这就是顶级开发者必备的素质。
你的 AI 编程工作流是怎样的？欢迎在评论区分享你的看法。