前言
最近做了很多无用功，因此写一篇博客记录一下，也算是给自己一个教训。
前段时间，我被要求实现一个效果 C，同时拿到了一个 Demo 作为参考。
Demo 中采用的方案是：
A -> B -> C
看上去似乎挺不错的。
一段时间后，我把这套方案移植到了指定的设备上。但是经过测试，最后得到的数据并不太好看。
于是有人问：
A -> B 这一步能不能省略，直接走 B -> C ？
当时我也没有认真研究过，只是感觉理论上应该可行，于是就直接开始实现了。
最后做出来的效果确实不错，测试数据也很好看。
但是，它又产生了新的问题。
由于 B 存在一些限制，比如无法压缩、传输带宽不够等，反正最后发现它不能直接作为输入。
于是，我又开始测试：
D -> C
结果这个方案最后也炸了。
兜兜转转一圈，最后还是回到了最开始的方案
A -> B -> C
最后在这套方案的基础上勉强优化一下，凑合着使用。
前面做的很多工作，基本都白费了。
问题出在哪里？
回头来看，最大的问题就是：在真正开始实现之前，没有先对齐需求，也没有认真调研哪些方案是合理的。
最开始拿到 Demo 后，我几乎是直接照着它的方案进行移植，没有先确认这套方案是否适合目标设备。
后来发现数据不好看，又在没有充分分析的情况下，凭感觉切换到了另一个方案。
每次都是先投入时间实现，做完以后才发现存在新的限制，然后再换一个方向重新开始。
整个过程中，我其实并不清楚每个方案的可行性，也没有提前整理清楚它们分别会受到哪些条件限制。
最后的结果就是：花费了大量时间，实现了好几套最终无法使用的方案。
应该怎么做？
在真正开始实现一个功能之前，应该先尽可能收集资料，弄清楚需求和限制，再讨论有哪些可行的方案。
比如，可以先询问 AI 获取一些思路。具体方法可以参考我之前的博客。
当然，AI 给出的内容也不能直接当成最终结论，只能作为一种参考。遇到关键问题，还是要结合项目实际情况进行验证。
除此之外，也应该多和同事沟通。
尤其是对项目更加熟悉的人，可能提前就知道某些方案为什么不可行，或者知道设备上存在哪些不容易发现的限制。
与其自己花几天时间把方案完整实现出来，再发现走不通，不如提前花一点时间讨论一下。
如果经过分析后，发现现有条件下确实无法实现需求，也应该及时向领导汇报。
需要说明当前存在哪些限制、为什么原方案不可行，以及是否存在其他替代方案。
不要明知道任务可能无法完成，却还是闷头实现到最后。
你也不想天天加班，最后才发现自己做出来的东西根本不能用吧
当然，讨论方案并不代表完全不能写代码。
有些问题只靠分析无法确定，还是需要通过实际测试来验证。
不过，这时候应该只实现最少的必要逻辑，先做一个小型测试，验证方案中最关键、最不确定的部分。
这样即使方案最终不可行，损失的也只是一小段测试代码，而不是一整套已经实现完的逻辑。
同时也好给领导交差，领导可不好糊弄啊
总结
总之，在开始实现一件事情之前，应该先和相关人员对齐需求，并讨论大致的方案。
不要等到功能已经全部做完以后，才拿着结果去和别人讨论。
对于不确定的部分，可以先实现少量必要逻辑，进行一些小规模测试，验证最关键的假设。
确认方案可行以后，再逐步补充完整实现。
因为在开发初期，需求、资源限制和技术方案都可能发生变化。
如果一开始就投入大量时间完成全部逻辑，后期很可能因为各种原因进行大改，甚至整套推翻重做。
先讨论，再验证，最后才是完整实现。
这样或许不能保证一次就选对方案，但至少可以少做一些无用功。
文章作者：成元
上次更新：2026-07-29