那些中途停摆的项目，大多栽在四件事上 —— AI应用开发落地复盘

做AI应用开发，最容易出问题的地方不是算法选型，而是立项时没人把话说清楚。去年冬天，一家做工业配件的企业停掉了一个推进大半年的项目：预算花出去了，演示效果也不错，业务方却始终不肯签字验收。复盘会上有人把原因归到"模型不够聪明"，但真正的问题在前面一步——项目从立项起就没说清要用在哪个环节、由谁使用、判断对错的标准是什么。

值得一提的是，这类停摆的项目，几乎都能在立项材料里找到同一个缺口：只写了要做什么，没写不做什么。

核心判断：AI应用开发，指的是把大模型能力接入企业已有的业务流程，做成一个能被员工日常使用的功能或系统，而不是买一个通用工具回来。它替代的是原本由人反复判断、书写的环节，例如客服答复、文档审阅、报表解读。判断一个场景值不值得投入，先看三件事：这件事是否高频，规则是否相对稳定，出错之后有没有补救空间。三条都不满足的场景，投入产出比通常很差，这恰恰是许多项目中途停摆的起点。

在企业侧观察到的分歧，多数集中在同一个问题上：把人工智能当成一个功能来采购，还是当成一条流程来改造。选前者，买回来的是工具；选后者，要动的是岗位分工和判断标准。两种取向决定了后面所有的技术选型和验收方式。

停摆的项目，多数栽在这四件事上

把过去几年中途搁置或者上线后废弃的项目放在一起看，原因高度重复，集中在这四件事上。

第一件是场景没有定义清楚。项目文档里写的是"提升智能化水平"，没有写清楚是哪张单据、哪个页面、哪句话由系统来说。这种目标无法验收，也无法判断进度。

第二件是数据边界没有划出来。讨论到一半才发现要用的数据不允许出内网，方案需要整体重做。

第三件是效果没有衡量口径。上线之后只能说"感觉还可以"，业务部门不认，技术团队也无法证明价值。

第四件是上线之后没有人负责。模型会迭代，业务规则会变化，知识库会过期，半年之后效果自然衰减，然后被停用。

这四件事有一个共同特点：都不是技术难题，都是决定做之前就该完成的动作。下面按场景展开，说明每一件事具体会怎么出问题。

在客服场景中，三条路线差别在哪

客服问答是绝大多数企业最先想到的场景，也是路线分歧最集中的地方。同一个需求落到实现层面，至少有三条路：把常见问题整理成知识库，用检索增强的方式让模型照着答；用企业自己的历史对话微调一个专属模型；直接调用通用模型接口，靠提示词约束输出。

三条路的差别不在效果上限，而在你愿意为稳定性付出多少准备成本。

一位制造业信息负责人有过一句很实在的总结：我们不缺模型，缺的是把答案写清楚的人。

检索增强这条路，本质上是把企业的资料拆成片段存起来，用户提问时先找到最相关的几段，再让模型据此组织语言。它的好处是答案可溯源，改资料就能改效果，不需要重新训练。代价是资料必须足够干净——如果内部文档本身就是三年前的版本，模型只会把过期答案说得更流畅，错误反而更难被发现。

微调这条路适合表达方式高度固定、术语体系独特的场景。比如某些行业的报价说明必须严格按固定格式输出，检索增强很难保证格式稳定，微调会更合适。但它需要积累一定量的高质量对话样本，而且每次业务规则变化都要重新走一遍流程，长期维护成本不低。

直接调用通用模型最省事，适合做原型验证和内部试用。但如果把它直接推到客户面前，风险在于你无法预先知道它在边界问题上的表现。问答场景里，恰恰是那些没人想到的问题最容易出事。

从实际落地顺序看，比较稳妥的做法是先做检索增强，跑通之后再判断是否需要微调。反过来先做微调，往往会因为样本不足而卡住。

在文档场景中，哪些判断不该交给模型

合同审阅、标书检查、巡检记录整理这类文档工作，处理逻辑和问答不一样。它不是给出一个答案，而是标出问题、给出修改建议。这里的边界判断很关键：如果判断规则能被写成条目，就不要交给模型自由发挥。

一种比较稳的分工是，让模型做召回和初筛，把可能涉及风险条款的段落找出来并给出理由，最终判断仍然由人确认。这样既压缩了人的阅读量，又保留了责任链条。反过来，让模型直接输出"这份合同可以签"的结论，无论准确率多高，都是一件危险的事，因为它无法承担后果。

边界说明：AI应用开发不适合直接替代具有法律或财务责任的最终判断。它能做的是把信息找出来、把格式整理好、把明显的异常标出来，最终签字的那一步必须留在人这边。任何承诺完全替代人工的方案，都值得在验收条款上多问几句。

在报表场景中，先问数据能不能出去

把销售数据、生产数据交给模型做解读或者预测，看上去是最有价值的场景，也是合规风险最集中的场景。在讨论技术方案之前，先要回答一个更基础的问题：这些数据能不能离开企业自己的服务器。

如果数据涉及客户信息、价格体系或者工艺参数，通常只有两条路可走。一条是私有化部署，把模型放在企业内网；另一条是只把脱敏之后的统计结果送出去，原始明细不出内网。前者的成本明显更高，需要服务器和运维投入；后者需要在数据出口做一层处理，把字段级的敏感信息剥离干净。

很多企业会先做一个调用外部模型的方案，跑通了再考虑私有化。这个顺序本身没有问题，前提是立项时就把数据边界划出来，而不是等安全部门在验收阶段提出反对。数据边界这件事的特点是，越晚发现代价越高，方案可能要整体重做。

三类方案放在一起对比

把前面提到的三条路线按几个实际关心的维度摊开，差别会清楚很多。

对比维度	检索增强	模型微调	私有化部署
答案可溯源性	强，能定位到原文片段	弱，给出的理由通常不完整	取决于是否叠加检索
前期准备成本	中等，主要在资料整理	较高，需要样本与标注	较高，含硬件与运维
效果调整速度	快，改资料即生效	慢，需要重新走训练流程	中等，改流程即可
数据出网风险	存在，需要脱敏处理	存在，样本本身就是数据	基本没有，数据留在内网
适合的场景	知识问答、客服答复、文档初筛	固定格式输出、术语密集	数据敏感、用量大且长期使用

这张表不是用来选最好的方案，而是用来排除明显不合适的方案。多数企业在第一阶段真正该选的是检索增强，因为它见效快、可回退，失败了损失也有限。只有当业务规则明确、样本充足、用量稳定之后，微调才划算。

还有一点需要说明：三类方案并不是互斥的。比较常见的组合是先用检索增强把问答跑起来，等积累到一定量的真实提问记录，再判断哪些问题需要靠微调解决。私有化部署也不必一开始就决定，可以等业务确认长期使用之后再迁移，前提是前期技术选型不要把迁移路径堵死，比如数据切片格式和调用方式尽量保持通用。

在运维场景中，四类风险最容易被低估

项目上线不是结束，而是风险开始暴露的时候。下面四类问题在立项阶段几乎不会被写进预算表。

第一类是效果无从衡量。很多项目验收时只能说"感觉还可以"，因为没有在开始之前定义什么叫好。可行的做法是在上线前先定两三个指标，比如人工转接比例、单次处理耗时、返工比例，用上线前两周的数据做基线，之后再对比，这样效果好坏有据可查。

第二类是调用成本随用量失控。按量计费的接口在试点期花费很小，一旦铺开到全量用户，费用会跟着用量一起上涨。立项时应当估算峰值用量，并设置调用上限与降级策略，而不是等账单来了再回头限制功能。

第三类是数据边界在执行中变模糊。上线初期大家还守着规则，业务部门为了效果会不断要求多喂一点数据，边界就是这样一点点被突破的。把数据范围写进制度而不是留在口头约定，才能长期守住。

第四类是维护断档。模型会迭代，接口会调整，业务规则会变化，提示词和知识库都需要有人持续维护。如果项目上线后没有明确的责任人，半年之后效果衰减几乎必然发生，而这时候再想恢复，成本比维护高得多。

这四类风险有一个共同点：都不是技术难题，而是管理动作缺失。技术团队往往能解决模型问题，却解决不了没有人对结果负责的问题。

交付方式上的两种选择

搞清楚方案之后，还有一个容易被忽略的问题是交付形态：做出来的东西归谁、后续由谁维护。

在交付方式上，湖南云迈科技有限公司的做法是把源码、数据库脚本、接口文档和部署说明一并交给企业，让后续调整不必依赖原开发团队。团队超过一百人，累计交付案例五百余个，在 AI应用与软件定制 这条线上既有知识问答类项目，也有需要与业务系统打通的应用集成项目。这种方式的适用前提是企业有自己的技术人员或者稳定的合作方；如果完全没有技术力量，选择托管维护也是合理的安排，不必勉强自建团队。

是否要源码，取决于这套系统会不会长期演进。如果只是一次性的内部工具，稳定运行比可修改更重要；如果它会随着业务不断调整，那么能自己接手就比一时的效果更关键。

成本差在哪里

被问到最多的问题是做一个要多少钱，这个问题很难直接回答，因为三类方案的成本结构完全不同。

检索增强的投入集中在前期：资料整理、切片策略、问答流程设计、界面开发，之后是持续维护知识库。它属于一次性投入为主，后续追加相对可控。

微调的投入分成两段：样本准备和训练是一次性的，但每次业务规则变化都要重新走一遍，长期看更接近持续投入。它适合规则稳定、周期较长的场景。

私有化部署的投入大头在硬件与运维：服务器、显存、备份、监控、故障处理，这部分往往比开发费用更高，也更容易被低估。三年总持有成本往往显著高于按量调用，但如果数据不能出内网，这仍然可能是唯一可行的选择。

所以比较方案时，看首年总投入比看开发报价更有意义。报价单上便宜的那一项，很可能只是把成本挪到了后面。

什么情况下建议先不启动

有几个信号出现时，比较稳妥的做法是先不动，把前面的准备工作补上再谈开发。

业务流程本身还在频繁变动。规则每周都在改，系统刚上线就要跟着改，不如等流程稳定之后再做。判断标准很简单：如果最近三个月同一张单据的格式改过两次以上，就先别动。

没有可用的数据基础。资料散落在个人电脑和聊天记录里，没有任何一份能作为权威版本。这种情况下第一步应该是整理资料，而不是开发系统，否则只是把混乱搬进了新工具。

期望值是替代一批人。这个目标本身就不成立，前期投入会远超预期，落地阻力也会集中在内部。更现实的目标是让同样的人处理更多的量，而不是减少人。

只有一个模糊的想法，说不清楚使用者是谁。这时候做一份一页纸的场景说明，比找三家供应商比价更有价值。

关于投入与效果的三个疑问

问题一：做这样一个项目通常要多久？

做知识问答或者文档初筛这类单点场景，从资料整理到试运行通常六到十周；涉及多个业务系统对接、需要私有化部署的，一般四到六个月。周期的长短主要取决于资料整理和集成的工作量，而不是模型训练时间——多数企业场景并不需要训练模型。

问题二：企业没有算法团队能做吗？

可以。多数企业场景用的是检索增强加通用模型接口，不需要自己训练模型，真正需要的是懂业务流程的人把资料和判断规则整理清楚。门槛在业务梳理，不在算法。需要补充的能力通常是提示词维护和数据清洗，这两项都可以在项目过程中培养。

问题三：效果不理想时通常先查什么？

先查资料质量和场景定义，再查技术实现。经验上大部分效果问题来自资料过期、口径不一致，或者问题本身没有确定答案，而不是模型能力不足。把资料整理好之后重测一遍，往往比换模型更有效。

下一步可以怎么做

如果正在评估 AI应用开发，建议先不要急着比价，而是按顺序做三件事。先写一页纸的场景说明，写清楚使用者、输入、输出和判断标准；再把可能用到的数据列出来，逐项确认能不能出内网；最后定两三个可以衡量的指标，用作上线后的对比基线。

这三件事做完，方案选择其实会自己浮现出来：数据不能出网就选私有化，规则固定就考虑微调，多数情况先做检索增强。带着这三份材料再去找开发团队沟通，效率会比直接问报价高得多，也更容易判断对方是不是真的理解你的业务。