虽然AI技术已经广泛应用到许多业务场景，但真正成熟且有价值的AI应用还是凤毛麟角，常见的应用主要集中在AI助手和知识库之类，虽然企业管理者也希望将AI真正嵌入到管理流程和业务流程中，但效果还有待验证。
之所以如此，一方面，LLM与AI技术还有待进一步完善和提高，另一方面，大多数企业缺乏合格的AI开发人员。除去这两方面的原因，我认为主要受制于AI应用开发面临的三个挑战。
挑战一：AI能力的不确定性限制了它的适用范围。
软件功能测试有一个原则，即每个测试都可重复执行（repeatable），且每次运行返回的结果都必须完全一致。放到AI来实现的功能就不同了。即便选用了完全相同的模型，输入完全相同的提示词，调用完全相同的一套代码，也可能得到完全不同的结果。这种不确定性决定了AI应用开发只能应用于开放式的、不要求精确结果的业务场景。为什么知识库在AI应用中最为常见？原因就在于用户对知识库知识的提炼需求是一个开放的结果，不仅不要求精确的结果，有时甚至希望能有一些不确定性，以便于激发创新的思想。
AI的这种不确定性特征，也带来了软件测试模式的改变，即针对AI功能，不再纠结于结果的重复正确性，而是确定一个测评阈值，通过评估（evaluating）方式对功能进行测评，只要达到事先确定的测评阈值，就可认为该功能是可接受的。
挑战二：AI功能的响应能力限制了它的适用范围。
只要需要调用LLM，就不可能做到实时响应。之所以流式接口在AI开发中大行其道，根由也是因为AI相对较慢的响应能力，只能采用流式输出以改进其用户体验。尤其是采用类似思维树这样的提示词模式，以及采用多智能体协作的架构，整个执行过程可能需要经历思考、行动、观察等环节，执行速度就不可能快得起来。
AI确实很聪明，但它天生受到GPT算法的限制，为了达成更高的智能，产生更好的效果，又必然需要持续迭代和反馈，以便于优化生成的结果；为了让人类更少参与，又必然需要“理解”问题，然后才能正确地做出决策。
以目前流行的MCP为例，一个MCP Server可以公开多个工具（通过@mcp.tool() ），但用户通过MCP Host与MCP Server交互时，需要LLM理解用户的请求，然后结合tool的描述，判断该请求应该“路由”给哪一个工具，之后，才会调用该工具执行相关的任务，执行完毕后，又要由LLM结合返回的结果生成用户希望看到的回答。这个过程的执行步长相对较多，几乎难以做到实时响应。
挑战三：开发人员使用的AI开发环境以及整个开发的过程受到制约。
以我们常见的企业知识库为例。首先，开发人员需要调用LLM，如果采用本地部署，就对开发所用的机器提出了更高的配置要求；其次，开发的功能需要持续进行测评，不断迭代，才可能找到生产环境的最优解，这无疑拉长了功能的开发周期；最后，开发AI应用需要用到的AI框架版本更新较快，兼容性也不太好，应用代码的变更频率较大。如果使用Python语言，还可能存在不同框架使用的Python语言版本的冲突。
当然，最重要的还是开发人员必须掌握足够的AI技能，并能跟上AI技术发展的步伐。由于许多传统企业无法做到开放地使用AI，开发人员只能在企业内部的环境中使用AI，使得许多好的商业工具与服务都无法使用，只得自己重复制造轮子，也制约了AI应用开发的效率。
我认为，以上归纳的三个挑战会在很长一段时间内一直存在。因此，我们需要正视AI的不足，千万不要因为AI的超强智能，就将企业内部的所有应用场景都AI化，而是应该各自发挥传统开发技术与AI开发技术的优势，并将它们合理地结合起来，各自寻找适合的应用场景。
在判断应用场景是否适合AI开发时，需要叩问自己：
- 不确定性的结果是否可以接受？或者说，是否期望接受开放性的结果？
- 愿意把思考和观察的过程交给人类，还是充分发挥AI的智能要素，以减轻人类的负担？
- 操作体验上，究竟是LUI（自然语言的用户交互）更适合，还是GUI更佳？
当然，无论挑战多么地难以克服，我们也不能因噎废食，放弃对AI技术的追求和拥抱。一贯以来，一个先进的IT企业或部门，都必须适当地保持IT技术的先进性甚至是领先性。既然AI的革命浪潮早已涌来，就必须迎头赶上，顺势而为；同时，又要保持清醒的头脑，只有以正确的方式做正确的事情，才能取得最优的结果。
