Andrej Karpathy：我的AI LLM 辅助编程体验

继续探索最佳的 LLM 辅助编程体验。特别是，我发现，与其专注于某个完美的单一方式，我的使用方式正越来越多样化，分布在几个不同的工作流中，并将它们的优缺点“拼接”起来：

1、对我来说，LLM 辅助的核心功能（大约占 75%？）依然是（Cursor）的 Tab 补全。这是因为我发现，自己在代码的正确位置编写具体的代码片段或注释，是一种高带宽的方式来向 LLM 传达“任务规范”。也就是说，这主要是关于任务规范的信息量——用文字表达我想要的内容需要太多信息量和太高的延迟，而直接在代码中、在正确的位置演示会更快。有时 Tab 补全模型会让人烦躁，所以我经常切换它的开启/关闭状态。

2、更高一层的用法是，选中一段具体的代码，然后请求进行某种修改。

3、再往上一层是 Claude Code / Codex 等工具，在 Cursor 旁边运行，我会用它们来处理一些功能块较大、但也相对容易在提示中明确说明的任务。它们非常有用，但整体效果依然参差不齐，有时还会让人有些沮丧。我不会用 YOLO 模式运行，因为它们可能会跑偏，做一些你不想要/不需要的蠢事，所以我经常按 ESC。我也还没学会如何高效地并行使用多个实例——一个就已经够难应付了。我还没找到一个好的方法来保持 CLAUDE[.]md 的质量或及时更新。

我经常需要进行一轮“清理”，以调整代码风格或代码品味方面的问题。比如，它们过于防御性，常常滥用 try/catch 语句，经常让抽象过于复杂，使代码臃肿（例如用嵌套的 if-then-else 结构，而列表推导式或单行 if-then-else 就能解决），或者重复代码块而不是创建一个优雅的辅助函数，诸如此类……基本上，它们没有代码品味。 在我涉足一些更偏向“氛围编程”的领域、自己不太熟悉的情况下，它们是不可或缺的（例如最近写了一些 Rust，或者 SQL 命令，或者其他我以前做得比较少的事情）。

我也尝试过让 CC 在编写代码的同时教我相关知识，但这完全行不通——它更想写代码，而不是在过程中解释任何东西。我还试过让 CC 做超参数调优，这过程非常有趣。它们在各种低风险的一次性定制可视化、工具或调试代码方面也非常有用，这些代码我平时根本不会去写，因为会花费太多时间。

比如，CC 可以一次性写出 1000 行庞大的临时可视化/代码，只为定位一个特定的 bug，找到后立刻全部删除。现在是代码后稀缺时代——你可以随时创建并删除成千上万行高度定制、极其短暂的代码，这没问题，它不再是那种珍贵昂贵的东西了。

4、最后一道防线是 GPT5 Pro，我会用它来处理最棘手的问题。比如，有几次我、Cursor 和 CC 都在同一个 bug 上卡了 10 分钟，但当我把整个内容复制粘贴到 5 Pro 时，它会运行 10 分钟，然后真的能找到一个非常微妙的 bug。它非常强大，能挖掘出各种深奥的文档、论文等。我也用它来处理其他更复杂的任务，比如给出如何清理抽象的建议（结果参差不齐，有时有好主意，但并非总是如此），或者做一整个关于人们如何做某事的文献综述，并能返回很好的相关资源和参考。

总之，编程现在在多种“类型”的编程方式和多种工具（各有优缺点）之间充满了可能性。很难避免那种焦虑感——担心自己没有站在集体能力的最前沿，因此才有了这种随机的周日淋浴时的思绪，以及对别人发现了什么的强烈好奇心。