香港AI项目为何交付失败：三个工程师视角才能识别的采购陷阱

不是模型不够好，不是预算不足。香港AI项目失败最常见的三个原因来自工程师视角——是采购决策层难以在提案阶段察觉，但能够提前避免的结构性问题。本文不是要劝退读者部署AI，而是帮助您在签约前问到正确的问题。

AI项目管理采购决策香港企业工程师视角

前提：失败的定义

本文所指的"失败"不是系统宕机或完全无法使用。大多数AI项目的失败是更隐性的：系统上线了，但无人实际使用；或在运行三个月后出现问题，发现修复成本极高；或业务扩展时发现系统架构根本无法支撑。

这类失败的共同特点是：在提案审批阶段完全看不出来，但在工程师进行设计评审时是可以识别的结构性问题。

示范阶段，供应商展示系统能准确回答问题。采购方审批通过。上线后，系统开始出现"自信地回答错误"的情况——对知识库范围以外的问题，系统生成听起来合理但事实有误的答案。

这不是模型问题，而是系统设计问题。一个生产级RAG系统需要明确处理"置信边界"：当检索结果的相关性低于某个阈值时，系统应回答"在现有资料中找不到足够相关的信息"，而非强行生成一个回答。

在HKSoka及客户交付系统中，置信边界是设计的组成部分，而非事后加入的补丁。这个设计在token成本上有代价（需要额外的相关性评分步骤），但在可靠性上是必要的。

签约前询问："当系统知识库中找不到相关信息时，系统会如何响应？请展示一个您的系统无法回答的问题。"

AI系统的运营成本主要来自LLM API调用。示范环境通常以小数据量、短对话、低频率进行测试。生产环境则是真实用户、完整文件、高频调用——两者成本差距可达十倍以上。

更具体的问题在于context window管理。一个未做好context管理的系统，每次对话都将完整历史记录发送给LLM——对话越长，成本越高，速度越慢。

HKSoka系统的实测数据：通过token-based context window管理（取代message-count截断）、对话摘要pipeline与prompt caching，短对话每轮成本下降54%，长对话下降80至90%。这不是理论优化，而是生产系统的实际测量数字。

此类优化需要在架构设计阶段完成，而非上线后补救——因为上线后修改context管理逻辑，需要影响整个对话历史的处理方式。

签约前询问："请提供成本估算模型：基于多少用户、平均对话轮数、文件量。若用户量增加三倍，成本增加多少？系统采用了哪些成本控制措施？"

OpenAI、Anthropic、Google的API均有服务中断记录。若您的AI系统完全依赖单一供应商，服务中断即等同于系统中断。

这个风险在许多采购文件中完全未见提及，原因是供应商习惯上只展示正常运行的系统。然而生产环境需要考虑故障场景。

在为某香港航运公司交付的系统中，multi-LLM fallback chain是基础设计的一部分：主力供应商中断时，系统自动切换至备用供应商，对用户透明。具体哪个供应商担任主力，是依据翻译一致性、幻觉率、输出格式三个维度的实测评分决定，而非依据品牌。

另一个隐性依赖：若系统深度依赖某一供应商的特有功能（例如特有的API格式），未来该供应商调整定价或政策，迁移成本将极高。

签约前询问："若您使用的LLM供应商今日服务中断，系统如何应对？是否有fallback机制？系统是否深度依赖某个供应商的非标准功能？"

许多AI系统以LangChain或LlamaIndex等abstraction framework构建。这些framework加快了开发速度，但引入了一个隐性问题：framework本身有版本、有bug、有功能弃用（deprecation）。系统间接依赖一个无法控制的第三方代码库。

以native LLM API直接构建的系统，调用链更短，延迟更低，调试更直接，对framework版本变动免疫。代价是开发者需要自行实现orchestration逻辑，但这个逻辑是可控且可审计的。

这不是"native API必然优于framework"的绝对论断，而是要提醒：询问"您用什么framework构建"之后，同时询问"若此framework被弃用，您的系统会受到什么影响"。

本文所述的问题有一个共同特点：是工程师在设计评审时会考量的问题，但在销售提案中通常不会出现。

对应的采购策略是：在正式提案之前，先进行一次技术评审——以工程师视角评估供应商的设计决策，而非以销售材料作为评估依据。这个评审的成本远低于上线后发现问题的修复成本。

希望在签约前进行独立技术评审？提供独立AI项目技术评估——以工程师视角检视供应商的架构设计，而非供应商委托的合规审计。

Levi是驻香港的独立AI工程师，为内地推进AI数字化转型的中小企业构建生产级LLM应用、RAG pipeline及文件智能系统。