Weave CTO 谈顶尖工程团队三大差异化做法

标题：顶尖团队的不同做法

招聘、并行化，以及为什么他们不再审查大多数 PR

收听 · 10 分钟

过去一年我一直在和 Andrew 交流，从这些对话中学到了很多，所以我请他在本文中更深入地谈谈其中几个话题。Weave 是 manager.dev 的长期合作伙伴和赞助商，我在我全职的 EM 工作中也在使用它。

过去 20 年，“好的软件工程”是什么样子一目了然：你显然在用 git，做小 PR、快速审查、CI、CD，至少每天部署一次。

今天，这套打法已经不够了。即使你是 AI 怀疑论者，也无法忽视软件工程正在发生变化。LinkedIn 和 X 上有很多关于最佳新实践的观点，但没有人真正知道答案（而且可能至少几年内都不会知道）。

我发现的最有效的自学方式，是深入了解其他工程团队哪些做法有效，而不是停留在表面的炒作层面。

今天的文章是一篇客座文章，作者是 Weave 的 CTO Andrew Churchill。他们的目标是帮助工程团队优化 SDLC，而且他们刚刚完成了 1350 万美元的 A 轮融资。

我们将介绍他认为当今每个工程团队都必须重点关注的 3 件事：

学会如何有效地进行并行化

这些内容既基于他自己的经验，也基于对使用 Weave 的最高效团队的观察。

对我而言，作为 CTO，招聘是最重要的一件事。招到合适的工程师，除了对公司有巨大好处之外，管理工作也会少很多。

在大多数公司，招聘流程和面试问题最多每几年更新一次，这意味着你忽略了每次面试中出现的许多重要信号。

对于每一次“失败”，我们都会思考如何在更早的阶段发现它。越早发现一个注定会失败的人，你的系统效率就越高。例如，我们认识到，必须尽早了解候选人为什么想在一家早期初创公司工作，并确保他们充分意识到其中的取舍。在初创公司工作，有很多方面比在舒适的大公司工作要糟糕。

另一个收获是，我们需要更好地了解人们实际能完成什么，而不仅仅是他们在“模拟”情境或对话中表现如何，所以我们开始做工作试用（3-5 天，全额带薪，包括机票和酒店）。

当我们发出工作试用邀请时，我们对那位候选人非常非常有把握。这意味着他们通过了典型招聘流程的每一道关卡。尽管如此，我们只向其中 60% 的人发出了 offer。每次不发 offer，我们都会试着理解在更早的阶段我们本可以做得更好。

有了编码智能体，在 4-5 个不同会话之间切换注意力实际上是一种非常可行的工作流程（而且与我们过去的工作方式非常不同）。

我们早期的每一位工程师通常都有一个主线程，他们的大部分注意力放在那里，另外还有 3-4 个“子线程”，这些是只需要较少注意力的小改进。对于新加入的工程师来说，他们最大的突破在于找到适合自己的并行化策略。

把它推到极致，然后弄清楚什么有效、什么无效，再找到平衡点。例如，看看同时处理 10 个任务会发生什么。那可能会疯掉，而且会非常难以维持上下文。但在 1 到 10 个并行任务之间的某个地方，存在一个适合你的位置，在那里你仍然可以专注于主任务，同时其他事情在后台进行。

当工程师说 1 个（甚至 2 个）会话就是他们的极限时，通常是因为：

每个会话都需要你非常频繁地关注，导致切换过多

或者编码智能体走错了方向，需要大量精力和照看来引导它

这两种情况都关乎上下文。大多数无效的 AI 使用，其实只是无效的上下文管理。

想象一下，今天有一个非常聪明的实习生加入你的团队。你会如何引导他们，让他们能立即开始高效工作？你需要以某种方式提炼出他们需要知道的一切：

需要遵循的事项，以及为什么它们很重要

大多数公司选择两种极端之一：

几乎不给任何信息，让他们边做边摸索。他们给你一个乱七八糟的 PR，你评论，他们慢慢学习。

为期 4 周的入职培训，包括录制的课程、入职任务等等。

现在想象每一个新的 LLM 会话都是一个全新的实习生。在第一种情况下，你当然会得到糟糕的结果。但在第二种情况下，你也会喂给它大量无用信息，从而损害结果。所以当 LLM 给出糟糕的结果时，你能做的 ROI 最高的事情就是停下来，改进它收到的护栏和指导，这样以后就不会再发生。

在这方面我们非常幸运，因为我们产品的一个主要功能就是帮助工程师弄清楚这一点——所以每个人都有责任花时间审查自己的 AI 使用指标，检查哪些地方运行良好，哪些地方可以改进。我们正在努力的下一个层次是一个能更有效做到这一点的系统，随着时间推移自我纠正。这是一个艰巨的挑战！

回到并行化——现在是开始弄清楚它的时候了。这很难，但如果你至少有扎实的上下文基础设施，这完全是可能的。

我看到的的最大错误仍然是要求对每一个 PR 进行人工审查。

2022 年的 Andrew 会告诉你“当然你必须审查每一个 PR，不这样建议简直是疯了”。但 2026 年的 Andrew 已经意识到，只要你有正确的护栏，不审查每一个 PR 将开启一个否则根本不可能达到的全新速度水平。

代码审查有三个主要好处：

编码标准。这是我们团队写代码的方式吗？

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）