像 Gemini 2.5 PRO 这样的前沿大模型，凭借其对众多领域的广博理解以及在几秒钟内吃透数千行代码的能力，能够延伸并放大程序员的能力。如果你能清晰地描述问题，并且愿意接受与大模型协作时必要的反复磨合，就能取得令人难以置信的成果，例如：

1. 在代码触及任何用户之前就消灭你引入的 bug：我在实现 Redis 的 Vector Sets 时就体会到了这一点。这些 bug 最终我自己也会逐一消灭，但其中很多在 Gemini / Claude 的代码审查下被立刻揪了出来。
2. 更快地验证某个想法是否可行，让大模型迅速写出用完即弃的测试代码，以尽快判断某个方案是否真的更高效、是否足够好，等等。
3. 开展结对设计，将你的直觉、经验和设计品味与大模型内编码的博士级知识相结合。在这个过程中，大模型有时会提出愚蠢的路径，有时又会给出极其出色的点子：而你作为人类的作用，就是帮助跳出局部最优和错误，并充分利用你的这位数字朋友在某些领域比任何人都懂得更多的优势。
4. 在你给出清晰规格说明的前提下，让它代写部分代码，从而加速工作。
5. 借助大模型去触及那些远离你专业领域、却与你能力相邻的技术（比如：为 Amiga 演示用 68000 汇编写代码？），把它当作你大脑中那些欠缺知识部分的延伸。

一年半前，我写过一篇题为“LLMs and programming in the first days of 2024”的博文。当时我就发现大模型已经很有用，但在过去的一年半里，它们的进步彻底改变了局面。然而，要想真正发挥它们的能力，与之交互的人必须具备某些素养并遵循特定的实践。接下来我们就来探讨一下。

大多数时候，拒绝氛围编程

在当下这个历史阶段，大模型是优秀的放大器，却是糟糕的单干选手。仍然有一些小型的、一次性的项目适合让大模型包办全部代码，比如测试、小工具这类几百行代码的程序。但大模型虽然能在你的严格监督下成功编写代码库的一部分（见后文），并带来可观的开发加速（或者说，在同样的时间里开发出更多、更好的东西——这正是我所做的），一旦让它们独自去完成非平凡的目标，它们往往会产出脆弱的代码库——体积过大、结构复杂、充满局部最优的选择，在许多方面都并非最优。不仅如此，当手头的任务复杂度超过一定阈值时，它们甚至会彻底失败。明天这一切或许都会改变，但就目前每天与大模型一起写代码的经验而言，我坚信最高质量的产出是通过“人+大模型”的组合来实现的。我相信人与大模型协作比单靠人更高效，但这有一个很大的前提，那就是人必须具备强大的沟通能力和丰富的大模型使用经验：高效沟通的能力是使用大模型的关键因素。

提供充足的上下文

当你想与大模型一起推敲某段代码的实现或修复时，你需要向它提供大量的信息：论文、目标代码库的大部分内容（如果可能的话，整个代码库，除非那样会让上下文窗口过大以至于损害大模型的性能），以及你对需要做什么的所有理解的一次彻底倾倒。这种倾倒尤其应包含以下内容：

• 关于那些看似不错实则不佳的方案的提示，以及它们为何可能并非最优。
• 关于潜在的优秀方案的提示，即使这些方案尚未被人类完全想清楚：大模型往往能借此找到正确的路径。
• 明确的目标、我们要求的不变量，甚至代码应有的风格。例如，大模型倾向于写出充斥着不必要依赖的 Python 代码，但通过提示可以缓解这个问题。就我的经验而言，它写的 C 代码通常要好得多。

在处理那些并不那么普及/显而易见的特定技术时，把相关文档也加入上下文窗口通常是个好主意。例如，在为 vector sets（一种新到大模型尚不了解的 Redis 数据类型）编写测试时，我会把 README 文件放进上下文：就靠这样一个微不足道的技巧，大模型立刻就能以专家水准来使用 vector sets。

选择正确的大模型

最有名的大模型并非最好的。编程工作主要应该使用：

• Gemini 2.5 PRO
• Claude Opus 4

就我的经验而言，Gemini 2.5 PRO 在语义理解上更强。能发现更复杂的 bug，推理更复杂的问题。Claude Opus 有时在编写新代码方面可能更胜一筹（有时则未必），用户界面也更友好，总的来说，对于复杂问题，你至少需要两个大模型来回切换、相互印证，以拓展你（作为人类）对设计空间的理解。如果只能选一个，那就选 Gemini 2.5 PRO。

对所使用大模型的基本要求是：不要使用智能体或编辑器集成式编程智能体之类的东西。你应该：

• 始终让最强的模型、也就是前沿大模型本身来处理所有信息。
• 避免任何只向大模型展示部分代码/上下文的 RAG。这会严重损害大模型的性能。你必须掌控大模型在给出回复时能看到什么。
• 始终身处循环之中，手动在终端和大模型网页界面之间搬运代码：这能确保你跟进每一个过程。你依然是那个写代码的人，只是得到了增强。

结论

尽管人们对能够独立编程的智能体抱有极大兴趣，但在当下，作为软件开发者，你通过以显式的方式使用大模型、并始终留在环路中，才能最大化你的影响力。未来这一点势必会改变，随着 AI 的进步，最终许多编程任务将更适合完全由 AI 来完成：在那样的未来，人类将决定 what & how，这依然至关重要。但我们还没有到那一步。就在此刻，保持掌控才能让你利用大模型产出最精悍的代码：在需要时保持精简，在必要时运用复杂的思想。

你将能够去做那些原本处于你知识/专业边界之外的事情，并在过程中学到很多（是的，你可以向大模型学习，就像你可以向书本或同事学习一样：这是教育的一种可能形式，一种新的形式）。然而，所有产出仍将遵循你对代码和产品的构想，保持高质量，不会因大模型引入的错误和缺陷而随机失败。你也将对所有已编写的代码及其设计保持深刻的理解。

不时去测试一下智能体能做到什么程度是明智的。但每当你觉得它们做得不如你好时，就回到你的终端，在 AI 的帮助下写代码（当你觉得它能提升产出时；有些时候你独自一人反而做得更好）。当智能体真的能做出卓越工作的那一天到来时，我会第一个转向它们，而自己写代码只出于热爱。但就目前而言，让我们抛开炒作，以最好的方式使用 AI，也就是：保持掌控。然而，还有另一种风险：出于某种意识形态或心理上的抗拒而回避大模型，从而不断累积劣势（并且无法培养出一整套——难以言表——与大模型协作所需的技能）。也许这正应了那句“In medio stat virtus”。