John Cutler：产品开发中的瓶颈移除可能同时消除有益摩擦

John Cutler 2026年11月7日 24 1 3 分享

约束条件可以同时具有“赋能”和“限制”两种属性。

举个例子，我正在和一位不紧不慢的房屋承包商合作。这让人很烦躁，因为我真的很需要这个工程赶紧完工。但这件事也有一个附带的好处。有几次，被迫花点时间看看图纸、考虑一下成本、不耐烦地在屋子里转来转去、思考我们到底要怎么生活——这些反而激发了客观上更好的决策，让我们更清楚自己想要（和需要）什么。工程会完成得更慢，但（但愿）会更贴合需求。我怀疑这位承包商心里清楚这一点。这是他们用来改善项目成果的一种心理技巧。

当下产品开发面临的挑战之一在于，“瓶颈转移了”这种说法实在太简单化了。限制性的约束可能确实转移了，但你现在同时也移除了一个赋能性的约束。那个瓶颈既是瓶颈，也是赋能性约束。那件令人烦躁、充满挑战、慢如冰川、摧毁士气的事，同时也是迫使我们保持关注的事（哪怕我们讨厌它）。

那个“愚蠢”的项目 ROI 预测表，虽然过度依赖不靠谱的估算、又严重忽视了渐进式的风险降低，但至少迫使我们等上几天或几周，让更好的替代方案浮现出来。

结对编程——虽然远程做起来是巨大的负担，现在又“轻松”地被与 LLM 结对所替代——曾经是扩展团队集体智慧的关键方式。

一份文档经历六轮修改，每个人添加自己的视角、花时间把话说准确，花掉了整整一个下午，也意味着团队在按下发送之前有几天时间可以反思。

所以问题并不像“少点坏事，多点好事”那么简单。更准确的说法是：“好事确实是好事，但我们同时也跳过了一堆好事，因为很多苦差事和摩擦之中，交织着许多积极的东西。”

举一个我日常工作中的例子。从客户电话会议出来带着一份转录稿，一小时后看着一堆东西被部署上线，这感觉太棒了。简直是魔法！不用提工单。不用开那种令人麻木的“完成定义”会议。不用“演示”。什么都不用。

但在所有这些我宁愿不做的事情之中，交织着大量积极的摩擦。

“这个设计长期来看可行吗？” “等等，你确定你不是想说 _________？” “等等，这运行起来跟我想的不一样。”

所有这些摩擦都是做出更好决策的机会，哪怕它感觉像是在拖慢我们。我们必须非常有意识地为此留出空间。

问题在于，当人们转向自己那个小小的 AI 辅助宇宙、自己的智能体“团队”、自己的工作流时，耐心就更少了。按一个按钮、看着代码从另一头出来的即时满足感实在太强了。单人模式工作太容易了。相比之下，多人模式显得老古董。几乎有点滑稽。它提醒着人们那些混乱的摩擦。