写给资深开发者的AI编程实践指南

你可能觉得自己太过优秀，不屑于尝试代码氛围编程。

你可能是一位经验丰富的资深开发者，对系统了如指掌；或是独特的技术明星，总能解决最棘手的问题；甚至可能是某领域算法的开创者。

尽管我不了解你的具体情况，但我确信你认为自己高高在上。

然而，我要告诉你，这种想法完全是错误的。

开玩笑？或许如此……但我将更进一步。

别觉得自己太高高在上，无法进行随性编程。恰恰相反，你才是最适合这种编程方式的人。

一个月前，我绝对不会相信这样的说法，因为这个专家级程序员的标签同样适用于我。

为了确立我的专业背景，我是 200 多个 Github 项目的维护者，获得了超过 23,000 颗星，是 MIT 计算机科学实验室的联合首席研究员，曾是一家颇为成功的科技初创公司的创始架构师，现在是另一个领域的 Dyad 公司负责架构的副总裁。

我显然精通编程，曾对学生和实习生明显由 AI 生成的代码冷嘲热讽，并公开反对这类技术，因为这些 AI 系统实在太愚蠢，甚至不懂得什么是"正确"。

大约一个月前，我开始尝试"氛围编程"这种新方式，并发现在恰当的场景和工作流程中，它确实是一个极具潜力的工具。

目前，我已经在 tmux 窗口中运行了约 32 个 Claude 代理，可以随时通过 ssh 远程访问，并能够全天候通过笔记本或手机持续跟进和推进工作。

这种工作方式在一个月前还是不可想象的，但现在已经成为现实。

这是为那些对不懂技术的年轻人嗤之以鼻，但又想正确入门的专业人士准备的指南。

理解智能体的心智模型

就像一个二年级学生或实习生

别再炒作了，我不是来兜售 ChatGPT 的，所以不会说它达到了博士水平——因为凡是见过真正博士的人都清楚，这种说法绝对是扯淡。

但它确实有点独特之处，那到底是什么呢？

将大语言模型（LLM）代理比作一个专注的实习生，或者是一个处于大学大二左右水平的学生。他们掌握编程的基本知识，能够模仿和借鉴其他的编程思路和架构，懂得如何执行单元测试，也会使用搜索引擎查找资料。

他们已经完成了基础编程课程，可能还深入学习过某个特定领域的高级课程，但如果你细致地追问，就会发现他们对该主题并没有真正深入的理解。

尽管这个"实习生"看起来相当聪明，你可能会给他一个尝试的机会。

如果有人来你的办公室求职，你可能会有两种处理方式。首先，你可能会将他们的工作安排在一个受控的环境中。

对于新的学生或实习生，这是很常见的做法，因为你对他们的技能和潜力还不太了解，所以想先小心地测试一下。如果你选择了这种试探性的方式，你可能不会太在意代码的质量（毕竟如果不在核心仓库中，代码很可能会变得难以维护），而是更关注最终的成果。

你可能会随意地编写一些代码，看到有趣的部分就说"哇，这个不错！"，然后快速做个演示或发个 LinkedIn 帖子，就不了了之。

这种轻松随性的编程方式可能你已经尝试过，但显然这还不是我们真正追求的目标。

第二种方法是将学生或实习生纳入你已经非常熟悉的项目中。这种方式的优点是，你可以轻松地审查他们的工作：由于你已经了解他们可能会犯的常见错误，可以提供清晰的指导，并且对项目的前 6 个月有明确的规划，因此培训成本和维护工作都相对低。

这不仅是培养长期人才的有效途径，对于训练 LLM 代理也同样适用。

现在，我们一起来逐步详细解析这个流程。

氛围编程让人人都能担任领导角色，但并非人人都适合做领导

领导程序员团队绝非易事！这需要付出时间、技巧和耐心。

孩提时，我们总以为："我不想做普通员工，我要当老板，只需坐在办公室里发号施令，什么都能轻松搞定！"。然而，经历过大学里的第二个小组项目后，你很快就会明白，如果团队管理不当，最终只会是你一个人承担所有工作，还要背负着四个人的工作期望。

在团队编程中，经验和专业度至关重要。如果你无法快速准确地理解代码的意图和潜在问题，就很难有效地进行代码审查。成为一名优秀的技术领导者需要大量的实践和深入的编程经验，能够一眼就看出代码中的潜在性能瓶颈或设计缺陷。

只有经过大量编程实践，你才能培养出这种敏锐的洞察力，从而为团队提供有价值的指导和反馈。

如果作为一个个人贡献者，你不太愿意培训实习生，因为觉得他们占用的时间比实际贡献更多，那么就不要参与协同编程

有些人善于通过指导推进工作，而另一些聪明的人则难以带领团队取得成果。这并非是对个人的批评，硅谷设立"个人贡献者"职位正是为了应对这种情况。

如果你属于这类人，振动编程可能并不适合你，因为你可能会比对待人类更快地对代理感到失望。

这些代理的信息保留能力甚至不如最糟糕的实习生，尽管他们至少还记得你喜欢的午餐。

请记住：与 AI 代理工作时，你需要主动安排会议、分配任务并审核代码。如果发现这个过程比自己直接编程更耗时，建议立即终止。但如果团队协作顺利且高效，则可以继续推进。关键是要思考如何优化团队协作，提高整体工作效率。

如何正确地进行创意编程工作流程？

如果有人让你看 Claude 的代码，并要求它解决你正在处理的棘手问题（之所以落到你手上，是因为之前的尝试都失败了），你可能会忍不住嘲笑它的失败。

但是，你应该意识到，你绝不会用同样的态度对待实习生或初学者。所以，要认清 AI 的真正能力，不要被过度炒作，而是以尊重和理解的态度对待它。

这种思维方式会直接引导出几个工作流程的基本原则：

氛围编程（Vibe Coding）的工作流程类似于管理敏捷开发（Scrum）或指导学生完成研究论文的过程

面对一个问题时，你会将其交给代理处理，然后仔细审查其结果，并给予具体反馈。

这与管理敏捷团队或指导学生写论文的方法如出一辙。关键不在于简单地抛出问题，而是通过持续的交流和指导，帮助对方逐步找到最佳解决方案。

作为资深开发者，你可能已经习惯了这种工作方式。

就像教授依赖学生进行研究，高级开发者也会依靠团队创造大量代码。可以将 Claude 视为你的新手团队。

管理新手看似困难，但只要你善于分解任务并给出明确的指导，就能确保项目顺利进行。

关键在于如何有效地分配工作，并为团队成员设定清晰、可实现的目标。

关键是，频繁的会议会令人疲惫不堪，所以要谨慎安排。建议部署 12-32 个代理，运行在不同进程中，最好在隔离的计算资源上。

这些代理通过沙盒环境运行，既能防止对主机系统的破坏，又可以使用受限的 Github 认证（仅限非核心读写权限）。

这样即使赋予"高风险权限"，最坏的结果也只是代理的 Docker 容器崩溃，而不会影响实际的代码仓库。请为其提供一个完整且明确的执行指令：

尝试解决开源仓库中的一个简单问题。提交包含解决方案的 PR，并在一小时后检查持续集成测试结果。如果测试未通过，先分析问题原因，对于可快速修复的问题，直接提交代码解决；若问题较为复杂，则报告核心技术难点。

不要过多耗费时间在设置调用上，直接从现有列表中抽取，让系统轻松找到"简单的内容"

让内容清晰明了，简单易懂，明确步骤，并持续重复一段时间。

如何审查代码风格：迅速剔除不合格的代码

作为一名资深程序员，如果遇到以下情况，你绝不会容忍：学生不理解代码就直接从 StackOverflow 复制粘贴；新实习生不善用团队现有代码，反而重写出低质量的实现；或者编写了臃肿且功能混杂的长函数。

在这种情况下，你不会费心修改，而是直接要求重新开始，这是对代码质量和专业精神的严格要求。

与大语言模型交互时，不要像一些网络视频博主那样天真地期望它能神奇地解决问题。

记住，这些模型的目标是取悦用户，但盲目地要求"更加努力"只会适得其反。如果模型开始偏离正确方向或生成不可靠的结果，最好的做法是立即放弃，并亲自解决问题。有些挑战需要人类的专业判断和技能，而不是依赖 AI 的猜测。

早上 9 点开始批量下达指令，到中午时检查执行情况。可能已完成 10 个任务，但其中 8 个进展不顺，直接放弃。好在有 2 个项目（PR）取得了进展，不错！继续裁撤 10 个项目，下午 3 点再次 review。

目前共处理了 20 个项目，仅 4 个成功，16 个失败。继续筛选，适当清理，查找缺失文档或性能问题。到 6 点时，再检查剩余 4 个成功的项目，并结束其他未完成的任务。

只有当你拥有大量问题，并且乐于看到其中部分问题得到解决，而不在意具体解决了哪些问题时，振码才会显得有价值。

10 个 PR 被合并，外加当天进行的其他工作（没错，你大部分时间都没有专注于此！）。

你可能会认为，这看起来像是 10/40 = 25%的成功率，似乎不太理想。但话说回来，这些都是免费的。你完成了原本不会做的额外工作。

成功率无非是衡量这些工作的性价比。至于具体如何，那是 Sam Altman 需要考虑的问题。如果你已经订阅了这些大语言模型，就尽管使用 token，不用太在意。不必纠结成功率，专注于整体成果才是关键。

适用场景：你已经深入了解的代码库或项目

这里有一个出人意料的事实：大多数程序员首先想到的是在他们不太了解的项目中使用 AI，这可能会导致被开源社区拒绝。实际上，代码审查才是最耗时的工作。如果你审查不熟悉的代码，你将不得不花大量时间理解其逻辑，此时不如直接自己动手编写。

这正是许多人会放弃的地方——停止思考振动编程的可能性。但何不换个角度？将其应用到当前的代码库中？不是解决那些棘手的难题，而是处理那些微不足道的边角问题。比如那个已经拖延了半年的小重构？又或者通过 Git 提交的二分查找，精确定位上周主分支出现的性能回归？再或者你已经为 Windows 和 Mac 开发了专门版本，但因为需要 4 小时的重复性工作，Linux 部分却一直被搁置？所有这类问题，如果有人递交代码，你只需要 5 分钟就能审查并判断其对错。那就把这些琐碎任务交给 AI 代理吧！

如果振动编程无法解决特定问题，那么困难的工作仍然需要你亲自完成

就像培训新人一样，最佳的安置方式是将他们安排在你已经非常熟悉的项目中。这样不仅便于你审查他们的工作，还能给他们分配相对容易的任务。你对项目代码和问题了如指掌，可以让他们在最小的指导下完成工作，这正是有效带教的关键。

代码提交请求的典型案例

接下来，我们来看看我的机器人账号最近生成的一些案例。

示例 1：成功案例

这是一个简洁高效的 PR，为 Julia v1.12 引入了一个重要的性能优化功能。新版本现可以构建轻量级的二进制文件，关键在于函数的特化处理。通常，为避免过多编译，函数不会默认完全特化。但对于高阶数值求解器，精确特化至关重要。这个 PR 专注于在包中特化函数实例，并已成功验证。后续还将开发静态检查工具来确保修剪兼容性，目前这些向后兼容的小调整已在测试版中表现良好，可以直接合并，并在未来完善测试系统。

快速编写查询，稍后再花 1 分钟进行检查和优化。

编程工作中约 80%都是重复且简单的任务。可以尝试交给 AI 模型处理，如果能解决就皆大欢喜，若不行就只能自己老老实实动手完成

这正是这类修改的典型目标。大多数代码合并请求（PR）都力求达到这种精简和专注的改动方式。

我最喜欢的一种方法是在开源仓库中寻找简单的改进机会。比如，找到一个 XXXXXXX 仓库中最容易解决的问题，然后提交一个小型的、易于审查的 PR。这次尝试很成功，PR 被合并了。这种方法的关键是保持变更最小且直接，如果开发变得复杂，就果断放弃。

常见的场景是提出一些轻微的 API 改进建议，比如添加数据类型转换功能。不过，并非所有建议都会被采纳，有时需要果断地关闭不合适的 PR 和问题。

即使你处理复杂任务，日常工作中仍有大量琐碎且重复的工作。建议尽可能将这些简单的代码维护工作自动化。

示例 2：瞬间关闭的"这不是给 Claude 的"拉取请求

这是关于一个文档构建测试失败的 PR，涉及混沌常微分方程（ODE）的微分和遍历性质研究。这是一个颇为专业且有趣的主题，但对大多数语言模型来说，深入的数学内容往往难以处理。在仔细分析后，我发现这个 PR 实际上揭示了一个重要的数值计算问题。

具体来说，在最小二乘阴影代码中出现了 NaN 和 Inf，这是由于 Schur 补的计算方式导致的。作为数值分析专家，我立即意识到使用 B * Diagonal(wBinv) * B'的计算方法会使矩阵的条件数成倍增加。

尽管在现有的开源线性代数工具中未找到直接解决方案，但我已将这一发现与同事 Alan Edelman 分享，希望共同探讨更优的矩阵分解方法。

虽然问题尚未完全解决，但我们已经对其本质有了更深入的理解。

这可能是大多数代码合并请求的常见情况。它提供了问题的大致线索，然后由我来进一步处理。

案例 3：迭代重构

这是一个旨在优化测试流程的简单 PR，主要目标是将 Enzyme 自动微分引擎的测试移动到"非预发布"测试集。

"非预发布"意味着不在编程语言的预发布版本上运行测试，因为这些工具深入触及编译器的内部机制，在早期阶段并不稳定。

之前，预发布测试经常在测试实际内容之前就失败，为了解决这个问题，我决定在所有涉及 Enzyme 的仓库中将其测试移至"非预发布"集。

编写查询大约花费 5 分钟。部分测试套件只需要一个简单的 GitHub 建议来微调细节。

将这个内容放入 8 个代码仓库也仅用了 5 分钟。此时，我已准备好开始使用预发布测试。如果手动操作，这可能至少需要半小时，因为之前我们没有一个便捷的系统来处理这类工作。

虽然这个方法可能不如完美的正则表达式精确，但对于节省 10 分钟时间来说，这绝对是一个值得的改进。

重构往往能带来显著的改进，是开发工具最有价值的功能之一。"确保代码正确，编写全面测试，然后进行自动重构"是一种相对简单而有效的方法，能迅速解决大部分代码优化问题。

示例 4：信息收集拉取请求

这是一个为了解决特定问题而生成的拉取请求。这个问题之所以被选中，是因为它已经在问题列表中搁置了很长时间，看起来并不复杂，但我一直没有时间去排查这个不太常用的基于 C 的稀疏矩阵求解器扩展中的内存泄漏。

不过，这个问题总得解决，所以我直接让机器人来处理它。

对方返回的是为第三方库添加内存终结器的代码（即如何指导垃圾回收器释放内存）。

我立即意识到这段代码不应该出现在当前库中，而应该放在将求解器与编程语言绑定的库里。缺少终结器是那个库需要解决的问题。因此，我直接关闭了 PR，丢弃了代码，找到了相关仓库中搁置的讨论，轻轻推动了作者，问题就这样解决了。

有时候只需要有人适时地提醒一下。

在我这边，整个过程大概耗时 3 分钟。虽然机器人本可以编写那个修复，但由于修复方案已经存在，因此没有必要重复。这个过程主要是为了定位系统中的具体位置。

示例 5：关于"这项工作需要多久？"的代码合并请求

这是一个尚未完成的 PR（至少在撰写本文时是这样），主要原因是还需要进行大量清理工作才能使其正常运行。项目进展如何？

它生成了一组测试，清晰地列出了全部 120 个待解决的问题。这很可能需要一周的工作时间……我早就预料到工作量会很大，但现在情况已经非常明确了。

我可能不会使用机器人来完成这个项目，但现在我可以更准确地估算工作量。从最初的"需要有人尝试，看起来工作量很大"，现在变成了"难点是完成这 120 项任务，虽然简单但繁琐，目前可能不值得投入精力"。

这对于提前规划非常有帮助。总共花费了约 5 分钟，再加上向他人解释 PR 结果的讨论时间。

结论：高质量的AI编程实际上需要专业技能和专家水平

Vibe 编程能让任何程序员瞬间化身为管理 20 到 60 名实习生的技术领导者。获得大型团队看似轻而易举，但要真正有效地管理和提升团队的生产力，则需要丰富的经验和技巧。

要确保 60 名实习生不会影响代码的性能、质量和可维护性，这是一个极具挑战性的任务。

因此，对于仍在职业成长期的程序员，我并不推荐这种方法。但对于已经相对资深、开始组建团队的程序员来说，这不失为一种低成本快速扩张的途径。

说白了，这种"氛围编程"的方法本是为非程序员设计，但实际上，只有专业程序员才能真正发挥其潜力。