我之前想过一个问题：大家总说木桶能装多少水，由最短的那块板决定。那如果把桶换个角度放呢？

这个想法并不是为了证明短板不重要。我想说的是，遇到一个项目时，我们好像很容易先列出一堆“自己还不会的东西”，然后默认必须全部学会，才能开始往前做。

可现实里的时间、人员和预算都有限。尤其临近交付的时候，有些能力确实来不及补齐。这个时候，除了继续硬补，能不能调整一下做法，让已经擅长的部分先发挥作用？

先把这个比喻讲准确一点

把桶斜过来，不代表一定能多装水。静止的水面仍然保持水平，不会跟着桶一起倾斜。缺口在哪一侧、桶本身的形状、倾斜方向和角度，都会影响结果。斜错了，反而会更早漏水。

之前的版本把这件事说得太绝对，还写了固定倾斜 45 度。这不准确。我想保留的是调整使用方式的思路，并不想把它包装成一条物理定律，更不是给一个普遍成立的最优角度。

查看原图

简化剖面示意：把较短的一侧抬高，可以改变最低溢出点的位置；水面始终水平。图中省略了前后壁，不是实际木桶的容量测量，也不表示所有桶倾斜后都能多装水。

回到项目里，“换个角度”可以是调整分工、减少非必要功能、换一种实现方式，也可以是让合适的工具帮忙。它的前提是要求仍然能满足，而不是换个说法，把没有解决的问题藏起来。

要先看清楚，到底是哪块短板卡住了事情

有些短板只是让我做得不够快，有些却会直接让项目无法交付。这两种情况不能用同一种态度处理。

比如我擅长硬表面和材质，也做过引擎美术和团队管理，但代码并不是我的强项。做一个个人工具或网站时，我可以借助 AI 辅助开发，把自己的精力放在需求、体验和结果检查上，先让产品跑起来。这算是调整做事方式。

但如果某个功能出了问题，我完全看不懂，也没有办法验证和恢复，那它就会变成新的短板。用工具绕过了一部分写代码的困难，不等于维护问题也已经解决。

同样，场景性能不足时，也不能看到 CPU 忙，就说把所有逻辑搬到 GPU 上。适不适合并行、有没有数据传输和同步成本、结果需要什么时候回来，都得先弄清楚。换一种实现本身也有代价。

我会先问：这是当前任务必须具备的能力，还是我们沿用了某种习惯做法，才显得非它不可？前一种需要补、需要找合适的人；后一种才有可能通过调整方案来解决。

倾斜之后，那块支撑也要提前准备

我原来的想法里，还有一块“垫在桶下面的砖”。它对应的是做新尝试时，能够维持基本交付的成熟方案。

假设一个效果想尝试新的生成或制作方法，我会希望先保留一版简单但完整的做法。新方法值得试，就给它一个明确的试验时间；到了约定节点还达不到要求，就回到已有方案继续推进。

这里的关键，是备用方案不能只停在脑子里。它至少得验证过能接进工程，输入输出也要说清楚。否则等新方案失败了，才发现旧方案也得从头补，那块砖其实一直没有垫上。

当然，也不是每个小功能都值得养两套完整流程。预算很紧时，可能只需要保留可回滚版本、一份可靠的输出，或者一个降低要求后仍能交付的方案。支撑做到什么程度，要看失败的代价。

别为了试新方法，把主线也拖住

我觉得比较难的，是承认一个试验该停了。新方法已经投入不少时间，效果又有一点希望，就容易不断往后延，最后把原来还算充裕的修改时间也消耗掉。

所以在开始之前，我更愿意先约定几个具体条件：需要做到什么程度，最晚什么时候判断，没通过以后用哪条路继续。这样停止一个方案，就不完全取决于当天的情绪。

两套方案如果共用同一个不可靠插件，或者只有同一个人能维护，也不算真正分散了风险。表面上有 A 和 B，关键环节却还是卡在同一个地方。

这部分我以前用了不少“对冲”“Alpha”“期权”之类的词。现在觉得没有必要。工程里的时间、人力和返工，直接讲清楚就够了，也不存在靠一套备用方案就保证项目绝对准时的事。

短期换做法，长期还是要补功课

如果一种短板在每个项目里都出现，一次次让别人或工具替我兜底，那迟早还是要认真补。调整分工可以帮当前项目过关，但不能成为我一直不学的理由。

我想反对的是不分轻重地补齐所有能力。离交付只剩几天时，先保证能用；阶段结束以后，再回头补最影响自己判断和维护的那一块。两个阶段的重点可以不一样。

所以，“把木桶斜过来”对我来说，是提醒自己别只盯着缺什么。也看看手里已经有什么，有没有更合适的组织方式，以及换了做法以后，需要补上哪些支撑。

桶还是要站得稳，水也还是得装得住。这个前提没有变。

配图为 AI 辅助生成的概念插画与简化剖面示意，不是实验照片。本文讨论的是项目取舍，不提供固定角度或容量提升结论。