被低估的AI应用开发难度

一开始我也和许多人一样觉得，AI 应用开发应该是一件挺简单的事：选个模型，调个 API，写点 prompt，一个 demo 很快就能跑起来。

但最近随着真正开始做一些 AI 应用相关的尝试、学习和踩坑，我越来越强烈地意识到：这个理解其实非常片面。

我个人觉得AI应用开发的难点并不在于构建本身，而是在于以下两点：

1. 找到一个合适的应用场景
2. 让应用的效果足够稳定、可靠，达到可用的程度

难点一：找到一个合适的场景很难

• 场景如果过于垂直，应用范围会非常小，用户规模有限，投入与收益不对等；
• 场景如果过于宽泛，能力又很容易被现有的大模型产品或成熟应用直接覆盖；
• 而那些真实存在需求、用户愿意用、同时又还没有成熟解决方案的场景，其实并不多。

很多时候，技术方案还没来得及展开，项目就已经在“有没有必要做”这一步卡住了。

难点二：从 Demo 到可用，中间隔着巨大鸿沟

相比之下，做一个能跑的 demo 反而是最简单的部分。现在各种 RAG、Agent 框架层出不穷，只要模型可用，接个 API，跑起来几乎没有门槛。但问题在于：能跑和好用之间差得非常远。AI 应用和传统工程开发最大的不同在于：它天然带着不确定性。同样的输入，不一定每次都得到同样质量的输出；很难像传统程序一样写清晰的对错判断。稍微换一个 prompt、换一份上下文，行为就可能发生明显变化。而一个真正可用的 AI 应用，必须在这种不确定性之上依然给用户提供稳定、可预期的体验。

当你开始认真对待效果问题时，会发现事情迅速变复杂了。

首先是评测：用什么指标来衡量效果？评测数据从哪里来？是人工标注，还是用 LLM 做自动评估？ 即使评测结果出来了，发现效果不好，接下来也并不轻松：是 prompt 设计有问题？还是 RAG 的检索、切分、召回流程需要优化？是否需要调整 agent 系统的架构？要不要走到微调，甚至强化学习这一步？

假设效果终于达到了一个还算满意的水平，工程上的问题又会接踵而来：成本太高怎么办？如何减少 token 消耗？是否需要自己部署模型？延迟太高怎么办？要不要引入缓存？是否需要对推理过程做加速？规模一旦上来，还能不能扛得住？

这些问题在 demo 阶段几乎不会出现，但在真正面向用户时，却一个都绕不开。

写在最后

上面提到的很多问题，我现在其实也没有完整的答案，还在不断学习和尝试中。但至少有一点是确定的：AI 应用开发远不只是调 API、写 prompt 这么简单。真正有价值的 AI 应用，往往花在“打磨效果”和“控制不确定性”上的时间，远远超过最初把它跑起来的那一刻。也正是这些看起来“麻烦”的地方，构成了 AI 应用真正的门槛。