AI项目没人用:技术人最容易陷入的自我感动

有时候，我会有一种很矛盾的感觉。

明明做了不少项目，学了很多新技术，也解决过不少复杂的技术问题。每当一个项目终于跑通，看到功能正常运行，心里还是会有一种成就感。

但回过头看，真正有人持续使用的东西，好像并没有多少。

有些项目发布之后，除了自己偶尔打开看看，几乎没有其他人使用。还有些项目，自己觉得解决了一个很有意思的问题，分享出去之后，却没有多少人关心。

最开始，我可能会觉得是产品还不够完善。

是不是界面不够好看？是不是功能还不够多？是不是模型效果不够好？是不是再优化一下，就会有人愿意使用？

于是继续开发，继续加功能，继续打磨细节。

但后来我开始怀疑一个更根本的问题：

有没有可能，我们一直在努力把一个东西做得更好，却从来没有认真验证过，它到底是不是别人需要的东西？

一、技术人很容易获得一种特殊的成就感

技术人做项目有一个天然的优势：我们有能力把想法变成现实。

一个想法出现之后，我们会开始分析技术方案、选择框架、设计架构、编写代码、解决问题。即使中间遇到困难，也能通过不断尝试，把原本做不到的事情逐渐实现。

这个过程本身就很有吸引力。

尤其是 AI 出现之后，很多过去需要大量时间才能完成的事情，现在可能几天就能做出原型。

我们很容易因此产生一种正反馈：功能实现了，说明我有能力；技术跑通了，说明方案可行；产品做出来了，说明这个想法值得继续。

但这里其实存在一个很大的跳跃。

技术上可行，不等于需求真实存在；功能实现了，也不等于用户的问题得到了解决。

我们解决了一个自己感兴趣的技术问题，却很容易把它理解成解决了一个用户的问题。

这就是很多项目走到最后，只有开发者自己还在使用的原因。并不是我们没有付出努力，而是努力的方向可能从一开始就偏了。

二、我们为什么总想继续加功能？

一个项目没人用时，最容易想到的办法，就是继续完善它。

没有用户？那就增加几个功能。使用体验不好？那就重新设计界面。效果不够稳定？那就换一个模型，优化提示词，调整工作流。

这些事情本身没有错，但它们有一个共同点：我们依然可以通过自己熟悉的方式推进项目，而不必直接面对用户是否需要它这个问题。

写代码、优化架构、调试模型，这些事情大多在我们的掌控范围内。但用户需求不一样。

你可能花了一周时间做出一个工具，最后发现目标用户根本没有这个使用习惯；也可能把功能做得很完善，却发现他们用现有方法已经足够方便。

这类结果很难让人接受。于是，我们有时会下意识地回避这个问题，转而继续开发。至少，代码写得更多了，功能增加了，项目看起来也更完整了。

可项目的完成度不断提高，并不代表它离用户更近了。

我们不是不努力，而是有时用持续努力的感觉，替代了对方向的判断。

三、AI 让这个问题变得更加明显

过去，一个人做项目，技术实现本身就是一道门槛。想法再好，如果没有足够的工程能力，也很难真正落地。

但现在，这道门槛正在下降。一个人可以借助 AI 写代码、生成页面、搭建接口、处理数据，甚至完成一部分测试和部署工作。

这意味着，越来越多的人有能力把自己的想法做出来。但当实现能力不再那么稀缺时，另一个问题就会变得突出：

你做出来的东西，为什么值得别人使用？

如果一个工具只是把某个常见功能重新实现了一遍，那么即使它能正常运行，也未必有足够的理由让用户改变原来的习惯。

如果一个 AI 应用只是把模型的能力包装成一个页面，那么当用户可以直接在现有平台上完成同样的事情时，这个应用的独立价值又在哪里？

当然，这不代表所有小工具都必须拥有复杂的商业模式，也不代表只有能够赚钱的项目才有价值。

如果目标是学习技术，那么一个没人使用的项目也可以很成功。但如果目标是做出真正有人使用的产品，就需要另一套评价标准。

我们不能再只看自己完成了多少功能，还要看用户是否愿意尝试、是否真的解决了问题，以及是否有理由继续使用。

四、下一次做项目，先不要急着写代码

我开始觉得，一个更好的项目起点，可能不是一个技术想法，而是一个具体的工作场景。

例如，你想做一个 AI 文档助手。以前的思路可能是：现在的模型已经很强了，可以做一个支持上传文件、自动总结、提取信息、生成报告的工具。接下来就开始搭建系统。

但如果换一种方式，可以先问：谁每天都要处理这些文档？他们现在怎么做？最耗时的是哪一步？现有工具为什么不够好？如果我做出一个新工具，他们为什么要改变原来的工作方式？

这些问题看起来不像技术问题，却会直接影响后续的技术选择。

假设真正的痛点不是总结太慢，而是文档里的关键信息容易遗漏。那么，你应该优先验证信息提取的准确性，而不是先做一个漂亮的聊天界面。

如果用户最在意的是结果能否追溯，那么来源定位和审核机制可能比更复杂的 Agent 更重要。

如果用户每天只处理两份文档，原来的方法又只需要几分钟，那么即使你的工具技术上很先进，也未必值得他们专门学习和使用。

需求判断并不是开发之前的一道形式化流程。它决定了你究竟应该做什么，以及哪些事情根本不值得做。

五、用一个小实验，代替一个大项目

对于个人开发者来说，我觉得最实用的改变是：不要一开始就把目标定为完成一个产品，而是先验证一个关键假设。

假设你认为某个工作流程可以通过 AI 自动化。不妨先做一个足够简单的版本，甚至可以先不开发完整的软件。

找几个真正遇到这个问题的人，让他们提供真实任务。你可以先用脚本、现成工具，甚至人工辅助的方式，把结果交付出来。

接下来重点观察三个方面：

第一，用户有没有真实投入？不只听他们说“这个想法不错”，而是看他们是否愿意拿真实任务来试，是否愿意花时间提供资料、反馈问题。

第二，新方案究竟改善了什么？和用户原来的方法比较：结果是否更准确，操作是否更简单，时间是否更短？不要只看 AI 能不能生成结果，还要看结果能不能被实际采用。

第三，这件事有没有持续使用的理由？用户是否会再次回来？如果没有，是因为体验不够好，还是原本的问题就不够重要？持续使用的阻力，往往比第一次体验更能说明问题。

此外，还要算一笔实际的账：系统节省了多少时间，又增加了多少模型调用、人工审核、错误处理和维护成本？

一个工具即使节省了十分钟，如果每次都需要人工检查半小时，就很难说真正提高了效率。

这些反馈不能保证一个产品一定成功，但能让你更早发现方向是否值得继续。如果验证结果不好，也不必立刻认为项目失败。你可能发现问题不够重要，也可能发现用户群体选错了，或者原来的方案没有解决真正的痛点。

相比花一个月做完产品后才发现没人需要它，早点得到这样的反馈，通常更有价值。

六、给过去的项目换一套评价标准

如果你已经做过很多项目，我觉得不必急着否定过去的自己。可以把它们重新分成两类。

一类是学习型项目。它们的目标是让你理解某种技术、熟悉某种架构，或者验证一种实现方式。只要你确实学到了东西，就有它的价值。

另一类是产品型项目。它们的目标是解决某个真实问题，因此除了技术实现，还需要看用户是否使用、结果是否有效，以及项目能否持续维护。

真正的问题，不是学习型项目没人使用，而是我们把学习型项目当成了产品，却没有意识到两者的评价标准完全不同。

以后每次启动项目之前，可以先明确三个问题：

1. 我做这个项目，是为了学习，还是为了让别人使用？

2. 如果是为了学习，我希望通过它掌握什么？

3. 如果是为了让别人使用，我准备通过什么方式验证需求？

这样一来，即使项目最终没有用户，你也能知道自己究竟完成了什么目标，而不是在不断开发、不断完善之后，才发现自己从来没有定义过成功。

写在最后

回头看，做了很多没人用的项目，并不一定是一件坏事。它至少说明，我们有想法，也愿意动手把事情做出来。

只是当技术实现越来越容易，我们可能需要逐渐改变对自己的要求。

以前，我们更关心自己能不能把一个东西做出来。现在，除了实现能力，还需要学习如何观察问题、理解用户、验证假设，并根据反馈调整方向。

这不是要让每个技术人都变成产品经理，也不是说技术本身不再重要。而是说，如果我们希望自己的项目真正产生价值，就不能只在熟悉的技术世界里不断获得成就感。

有时候，最重要的进步不是又完成了一个功能，而是发现某个需求并不成立，及时停下来，换一个更值得解决的问题。

AI 可以帮助我们更快地实现想法，但想法是否值得实现，仍然需要我们自己判断。

与其不断做出更多没人使用的东西，不如认真找到一个真实的问题。哪怕最初只服务好几个人，也比单纯追求项目数量，更能帮助我们成长。