雖然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的革命浪潮早已涌來，就必須迎頭趕上，順勢而為；同時，又要保持清醒的頭腦，只有以正確的方式做正確的事情，才能取得最優的結果。