那些不再糟糕的“坏主意”：Claude 参与代码审查与团队分工的实践反思

我从事软件行业大约15年了，在这段时间里，我犯过很多错误，也从别人的许多错误中吸取了教训。这些经验是一口深井，在讨论技术和非技术问题的可能解决方案时，我可以从中汲取。正因如此，我才知道哪些解决方案在理论上听起来不错，但在实践中会遇到问题，或者哪种边缘想法实际上非常适合我们在这里试图解决的问题。这些知识和经验在很大程度上成就了我作为一名有效领导者的能力。

不过最近，很多我的直觉认为是坏主意的事情，结果却运作得非常好。在我们团队本周的回顾会上，这一点让我深受触动，对我来说是一个真正的学习时刻。它让我意识到，我一直依赖的很大一部分直觉可能不再像我以为的那么有价值了，我需要更频繁地质疑那些经验。

所以我想写下一些我们现在正在做的、实际上运作得非常好的“坏主意”，然后试着弄清楚这对像我这样的人意味着什么。

没有人审查别人的PR

几乎在我整个职业生涯中，代码审查的方式都是一样的：一个人编写代码并打开PR，然后团队中的另一个人在其合并之前进行审查。第二双眼睛能发现bug、在团队中传播知识，并防止任何一个人悄悄地把代码库带向自己的方向。未经审查就合并自己的PR，属于那种“紧急情况下才打破玻璃”的事情。

大约一个月前，我们彻底改变了这一点。由于PR开启的速度加快，我们一直在代码审查上苦苦挣扎，所以我们决定尝试一些疯狂的做法——干脆不做。现在，负责某个工单的工程师与Claude协作，然后由Claude打开PR，接着负责该工单的人审查Claude的工作。一旦CI通过且Greptile审查干净，如果负责该工单的人确信解决方案是可靠的，他们就合并PR。就这样。不用等队友找时间切换到你的改动上，也不用在Slack上@别人请求看一眼。

而且它运作得非常好！当我真正思考它为什么有效时，是因为代码审查原本要防范的东西仍然得到了防范。每个改动仍然有第二双眼睛——只不过作者是Claude，审查者是负责该工单的人。那个人比团队中任何人都更了解问题，因为他们就是一直在处理它的人。对于那个改动来说，他们比一个必须从头加载所有上下文的队友是更好的审查者。但同时，Claude和Greptile也更擅长发现代码审查中经常发现的那类问题，比如小bug或不一致之处。在这个阶段发现架构缺陷或意外产品影响之类的大问题，是相当罕见的（至少在我工作过的团队中是这样）。

我之前写过，审查关卡可能是缺乏信任的标志，所以也许我不该对取消一个审查关卡竟然奏效感到如此惊讶。但我的直觉仍然说“你不能没有别人看一眼就合并东西”，而我的直觉错了。至少到目前为止是这样——我们才改了一个月，但到目前为止感觉真的很好。

将团队拆分到不同的工作流中

这个问题在我们的复盘中出现了。最近我们有几个人休假，同时我们有几个并行且相对独立的工作流在进行。所以我们把它拆分了，基本上每个人负责一个工作流并推进它。

过去我一直不喜欢这样做。当团队中的每个人都在做不同的事情时，就会产生知识孤岛。只有一个人知道他们构建的东西是如何工作的，如果他们离开、生病或休假，团队就会陷入困境。更糟糕的是，我认为这会侵蚀真正作为一个团队的感觉。你们不再一起解决同一个问题，而只是一群人在同一时间解决不同的问题，恰好共享同一个站会。在我领导的几乎每个团队中，我都反对过这种设置。

但在复盘中，我们讨论了这个问题，我们并没有看到我担心的任何后果——至少在知识孤岛方面没有。原因是，了解别人的工作变得如此容易。如果我需要介入同事一直在做的事情，我可以对 Claude 说“嘿，让我了解一下他们一直在构建的东西——它是如何工作的，进展到哪里了，还有什么需要完成？”几分钟后，我就有了开始贡献所需的东西。我不需要任何人来引导我，也不需要花一天时间阅读代码来弄清楚发生了什么。

这里真正改变的是，上下文切换的成本大幅下降，因为我们是在比过去更高的层次上运作。我并不真的需要切换到具体的代码及其工作方式（或者至少开始工作时不需要那么多）。我确实需要切换的是问题本身。只要我对我们试图解决的问题有概念性的理解，并且大致了解我们追求的解决方案的形态，我就可以介入并发挥作用。

这种工作方式是否会有我们尚未看到的长期后果？也许吧！我 honestly 不确定。但“也许有一个我们还没看到的问题”与我一年前会提出的论点非常不同，那时我会说“我很确定这是个坏主意，我们会后悔的。”

不要深入

这个与其说是关于我的团队如何工作，不如说是关于我给所管理人员提供的建议。

很长一段时间以来，我对工程师在技术和职业发展方面的标准建议是经典的“T 型”模式。首先你建立一个扎实的通用工程实践基础，然后你选择一两个领域并真正深入。成为性能专家、无障碍专家或分布式系统专家。或者选择一个广泛使用的框架并成为其专家——成为 Rails 或 Phoenix 的定期贡献者，了解其工作原理的所有细节。这种深厚的专业知识曾经是让自己变得非常有价值的最可靠方式之一。

现在我告诉人们的几乎相反。当你有一个协作者已经阅读了该框架的所有源代码，并且可以在几秒钟内回答任何相关问题时，特定技术的深厚专业知识就不那么有价值了。这是另一个例子（就像我上面提到的），知识不那么有价值，但判断力仍然重要。

我反而建议仍然要在工程基础方面打下非常扎实的根基，因为我认为这正是我们人类目前能提供最大价值的地方。比如如何架构代码、如何设计良好的抽象，以及如何判断某个抽象是否已经不再合适。也就是能够看着某个东西说“这开始变得有点薄弱了，我们应该把它拆开”，然后想出正确的抽象应该是什么。也就是注意到“我们这里似乎缺了某个需要命名的东西”，并且能够找到那个概念并给它命名。正是这些东西让高层架构、领域建模和数据建模保持高质量，也正是优秀工程师如今真正体现价值的地方。

但我也告诉他们，技术出色现在只是工作中很小的一部分。仅仅技术出色已经不够了。你需要更多地了解设计。你需要了解产品开发，以及如何做产品经理，至少懂一点。你需要擅长与用户交流、做研究，并真正了解业务。

在我带领的团队里，我一直鼓励这样做。我长期以来都认为产品工程是做好这份工作的最佳方式。但我过去把它看作让人变得出色的东西，而现在我认为它只是基本门槛。只会写代码、或者纯粹做技术的人，其价值已经比过去低得多了，我不确定五年后这个行业里还会剩下多少这样的人。

还有几个我也在侧目观望

一旦我开始留意这些，我就到处都能看到它们。下面还有几个我尚未完全改变想法、但已经不像过去那样对自己的直觉那么有把握的：

从零重写。“永远不要做大重写”几乎是我们这个行业里最接近普遍法则的一条。但重写之所以危险，很大程度上是因为它们耗时极长，而且在你开发新系统的同时，旧系统还在你脚下不断变化。如果一次重写只需要几天或几周，而不是几年，那么很多风险就消失了。

自建而非购买。当有 SaaS 产品能满足 80% 的需求时，我劝过很多团队不要自建内部工具。但当构建一个恰好满足 100% 需求的东西只需要一个下午时，这笔账就大不一样了。

用三种不同方式构建。为同一个功能写三个不同版本、然后扔掉其中两个，过去显然是在浪费时间。而现在，这往往是找出哪种方案真正正确的最快方式，而不是在设计文档里争论。我们可以跳过产品开发中的“粗略原型”阶段，如果愿意，直接在生产环境中用真实用户做 A-B 测试，这是质量高得多的测试，也能让东西更快发布。

引入团队里没人了解的语言或工具。“我们没人懂 Rust，所以不该用 Rust”过去几乎是个无可辩驳的论点。我现在不太确定了。当然，如果有些事情必须用某种语言，比如我们在 Beat81 用来对接系统某些部分的软件。团队里没人懂 C#，但它也是我们想用的一个非常好的 ANT+/BLE 接收器唯一可用的驱动。

我到底错在哪

把这些放在一起看，我觉得模式很清楚。每一件事因为某种成本而成了坏主意。我总是从成本与收益的角度思考。队友做代码审查值得，因为替代方案是根本没人看代码。知识孤岛不好，因为了解别人的工作需要的时间和成本很高。深度专业知识有价值，因为那种知识稀缺且难以获得。

AI 改变了很多这样的成本，而且改变得非常快。但建立在那些成本之上的规则不会随着成本变化自动更新，我的直觉也不会。我的直觉是在一个所有这些成本都相当稳定的世界里训练了 15 年，所以它一直以同样的自信告诉我那些曾经正确的事。

这才是这周回顾里真正击中我的地方。不是我在某件事上错了（我总是错）。而是我一直用来判断事情是不是好主意的那项技能（它在我职业生涯的成功中占了很大比重）现在给出坏答案的频率比过去高得多。

所以我在试着改变使用它的方式。当直觉告诉我某件事是坏主意时，我试着追问：让它成为坏主意的成本是什么，那个成本还在吗？有时还在，直觉仍然对。但越来越多时候，价值主张可能已经变了。我肯定倾向于至少多尝试一些过去可能会被我否掉的实验。

在拿了 15 年薪水、至少部分是因为有好直觉之后承认这一点有点奇怪。但我认为未来几年会做得好的领导者，是那些能更松散地持有自己经验的人，是愿意让团队证明自己错了的人。这是每个人都面临巨大变化的时代，所以我们都得适应。现在我认为重要的不是谁拥有最多的经验和知识（当然那仍然有一定分量），而是谁能最快地适应和学习以获得新的经验和知识。