AI落地不是做demo:从POC到量产的5个生死线

坦白讲，AI这个圈子有个怪现象。

客户提需求，技术团队两周怼出一个demo，效果惊艳，全场鼓掌。然后签合同、上项目，三个月后客户说”先停一停吧”。

为什么？因为POC和量产之间，隔着的不是技术难度，是五个很少有人提前想清楚的生死线。

我把这三年踩过的坑、交过的学费，一次性说清楚。

01 数据pipeline的稳定性，比模型精度重要十倍

很多团队做POC的时候，数据是精心准备好的。几十条测试样本，格式整齐、质量上乘，模型一跑，准确率95%，客户很满意。

但量产环境是什么情况？

客户的业务系统导出的数据，格式每周变一次。PDF里有的表格带边框，有的不带；Excel里有的sheet叫”数据”，有的叫”Sheet1″；甚至有时候直接扔过来一个压缩包，里面嵌套三层文件夹。更离谱的是，有些文件名义上是PDF，实际是用截图拼成的，OCR识别率直接打五折。

我们有个项目，POC阶段用的是客户”整理好的样本”，RAG检索准确率92%。上线第一周，真实数据灌进来，准确率直接掉到61%。客户当场就急了，说”你们这不是欺骗吗”。我们排查了三天，发现问题根本不在模型，而是数据清洗链路根本没搭好。

量产级别的数据pipeline，必须考虑三件事：

第一，格式兼容性。不能假设输入永远是你预期的格式，要能处理PDF、Word、图片、扫描件、网页各种来源，而且每个来源都要有降级策略。万一某个格式解析失败，系统不能崩溃，而是要能记录异常并继续处理其他数据。更重要的是，格式本身也会变化——同一个客户上个月和这个月导出的Excel，列名可能完全不一样。

第二，质量监控。不是等用户投诉了才发现数据有问题，而是要在pipeline里埋点，实时监控文档解析成功率、分块质量、嵌入向量分布。一旦发现异常分布，立刻告警。比如突然有一批文档的向量完全跑偏了，说明解析层出了问题，必须能够第一时间告警并触发回退。我们内部有个指标叫”脏数据拦截率”，目标是不让任何格式异常的数据进入模型层。

第三，增量更新机制。企业数据是活的，今天上线知识库，明天客户就要加新文档。你的pipeline能不能做到不停机更新？更新后历史数据要不要重新处理？这些POC阶段根本不会暴露的问题，量产时全是雷。有的场景需要实时更新，有的场景每天更新一次就够，这个频率必须在设计阶段就确定下来。而且增量更新和全量更新的策略完全不同，前者需要精细的变更检测，后者需要大规模并行处理能力。

我见过最惨的一个项目，客户每个月更新一次产品手册，团队每次更新都要全量重建向量库，重建一次四小时。客户忍了两个月，最后要求退款。后来我们改成增量更新，只处理新增文档和变更部分，更新时间从四小时压到三分钟。更关键的是，我们在更新流程里加了数据校验层，确保新数据不会污染已有索引。

所以我的第一条铁律是：POC阶段就要用”脏数据”测试，不要用准备好的样本。 直接拿客户业务系统里导出的原始数据来测，这样测出来的才是真实的水平。如果你的POC只有干净数据才能跑通，那这个方案本质上还没准备好量产。

02 成本结构，从实验级到生产级是十倍跳跃

POC阶段的成本账很好算。调个OpenAI API，测试几百条数据，花个几十美元，老板一看，挺便宜啊。

但量产的成本结构完全不同。

首先是token消耗。POC的时候一个用户一天测十条，量产后一千个用户每天各用五十条，token消耗是500倍。如果你的方案里有个地方prompt写得啰嗦了20%，量产时这就是真金白银。而且大模型的输出是不确定的，同一个问题可能这次用100个token下次用400个token，这种波动在大规模使用时会被放大。我们曾经遇到过一个prompt里的示例对话在特定场景下触发了模型超长回复，单次调用token数暴增8倍，直接导致当天API费用翻倍。

其次是并发成本。POC是单用户串行测试，响应慢点无所谓。量产后十个用户同时提问，你的推理层能不能扛住？要不要上缓存？要不要做请求合并？要不要考虑限流降级？这些都是POC不会暴露但量产一定会遇到的问题。缓存策略本身也是个坑——命中率低了浪费存储，命中率高了可能返回过期答案，这个平衡点需要在真实流量下才能找到。

我们去年有一个客服助手项目，POC阶段用的是GPT-4，效果确实好。量产后算了笔账：一个月API费用要八万多。最后被迫降级到GPT-3.5+微调模型，效果掉了15%，但成本降到一万二。最终我们找到了平衡点：常见问题用小模型处理，复杂问题再调用GPT-4，综合成本降低70%而效果只掉5%。这个路由策略本身就需要大量A/B测试来调优。

更隐蔽的是infra成本。 向量数据库、缓存层、日志监控、备用实例，这些POC阶段都是本机跑，量产时全是云服务账单。有一个客户问我”为什么POC免费，量产要收服务器钱”，我解释了半天。后来我学聪明了，POC阶段就要把云服务成本也算进去，客户心里有个准备。但更重要的是，你要帮客户算清楚这笔账——很多时候客户自己也不知道量产后要花多少钱，这个预期管理做不好，后面全是扯皮。

我的建议：POC阶段就要做成本压力测试。 拿个计算器，按真实用户量、真实调用频率、真实数据规模，把账算清楚。把API费用、服务器费用、运维人力，全部摊到每个用户每次调用上。如果这个数字客户接受不了，要么改方案，要么别做。

千万别等到量产了才发现”这生意亏钱”。那时候你已经签了合同、收了首付款，进退两难。

03 人机协同的边界，必须比代码先定好

这是最容易被低估的一条线。

POC演示的时候，产品经理坐在旁边，遇到模型答不上来的问题，悄悄换个说法重新问，或者干脆自己接过去回答。客户看到的永远是”流畅的对话”。但真实的流畅，很多时候是有人在兜底。

量产之后呢？用户半夜十二点提问，你不可能安排个人在旁边兜底。更别说在B端场景下，一个错误回答可能导致客户金钱损失，这个后果是POC时完全无法想象的。我们曾经有个金融客户，AI助手在深夜时段给出了错误的费率计算结果，用户按照这个结果签了合同，第二天发现多付了两万块。这个锅算谁的？

所以人机协同的边界，必须在设计阶段就写进PRD，而不是上线后靠人工救火。

具体来说，三个问题必须提前回答：

第一，什么情况下必须转人工？ 不是”答不上来就转”这么简单。是置信度低于多少转？是涉及金额超过多少转？是用户连续追问三次不满意转？每个规则都要有明确数值。我们有个标准：置信度低于0.7自动转人工，涉及财务数据转人工，用户表达不满意超过两次转人工。这些规则不是拍脑袋想出来的，是在量产后被用户教育了三个月才确定下来的。

第二，转人工之后怎么交接？ 不能只丢一句”请稍等，正在为您转接”，而是要把对话上下文、用户意图分析、系统推荐答案，全部打包给人工坐席。否则人工接手后还得重新问一遍，用户体验极差。最好还能让用户知道为什么转人工了，比如”这个问题比较复杂，为了给您更准确的回答，我帮您转接到专家”，这比突然中断AI对话要好得多。我们花了两个月时间打磨这个交接体验，把平均接管时间从45秒降到了8秒。

第三，模型答错了怎么办？ 谁来担责？POC阶段可以说”AI仅供参考”，量产时客户真按错误答案操作了，造成损失算谁的？必须在合同里明确责任边界，在系统里设置免责声明和确认机制。我们有个金融客户，AI助手推荐了一款理财产品，用户买了之后亏了。虽然合同里写了”不构成投资建议”，但用户说”是你们系统推给我的”。最后扯皮了三个月。后来我们在每次推荐前加了强制确认步骤，用户必须点击”我已理解风险并确认操作”，纠纷才结束。但这个改动又带来了新问题——确认步骤多了，转化率掉了12%。产品、法务、技术三方拉扯了很久才找到平衡。

人机协同不是技术问题，是产品设计和法律合规问题。 但大多数技术团队在这个环节上把自己当成了纯技术角色，结果吃了大亏。

04 可观测性，是量产阶段的氧气

POC阶段出bug，开发者在旁边，打开控制台就能看日志。量产阶段出bug，客户在电话里骂街，你连复现都复现不了。

可观测性（Observability）不是”加几行日志”那么简单，是完整的三层体系。

第一层，请求级追踪。 每个用户请求要有唯一trace_id，从网关层到模型层到数据库层，全链路串联。用户说”刚才问了个问题，答得不对”，你能根据trace_id在三十秒内定位到完整的调用链、输入输出、中间状态。这不是可有可无的，是量产环境的必需品。没有trace_id，你在海量的日志里找一条用户请求，就像在大海里捞针。

第二层，业务指标监控。 不是看CPU内存这种机器指标，而是看”问答满意度””首次响应准确率””用户重复提问率”这些业务指标。这些指标掉了，说明系统有问题，哪怕机器指标一切正常。我们内部有个”红线指标”：如果某个小时内，用户重复提问率超过15%，自动触发on-call，必须在30分钟内响应。这个阈值也是不断调整的——一开始设的10%，结果太敏感，频繁误报；调到20%，又漏掉了几次真实问题，最后15%是平衡点。

第三层，模型行为监控。 大模型的输出是不确定的，同样的输入两次答案可能不同。你需要监控模型输出的分布变化、拒绝率、幻觉率、平均token数。一旦发现模型行为漂移，立即触发告警。比如某个版本更新后，模型开始频繁拒绝回答某类问题，这很可能是prompt被篡改或上下文管理出了问题。我们曾经遇到过一次，上游供应商偷偷更新了模型版本，导致我们的客服助手在特定场景下开始给出完全错误的答案。幸亏有模型行为监控，两小时内就发现了异常。

还有个容易被忽视的点：A/B测试能力。量产阶段不可能一次性全量上线新版本，必须有灰度发布、流量分流、效果对比的基础设施。POC阶段不需要这个，但量产时没有这个，每次发版都是赌博。有一次我们一次性全量上线了一个新提示词版本，结果某个行业的用户群体问答满意度下降40%，回滚花了六个小时，损失了好几千个用户的信任。从那以后，任何改动都必须先灰度5%，观察24小时没问题再扩大。

05 稳定性文化，是被忽略的第五条线

前面四条说的都是技术和产品层面的生死线。但还有一条更重要，只是不太好意思说。

那就是：你的团队准备好做生意了吗？

POC阶段大家都很兴奋，经常是博士、研发经理亲自上阵，24小时在线回复。但量产后上线，你不可能让博士每天去看日志。更关键的是，POC阶段的英雄主义在量产阶段是毒药——依赖某个人的经验和记忆来排查问题，这在规模化场景下完全不靠谱。

量产系统需要运维。服务器挂了谁来重启？数据库满了谁来清理？模型版本更新了谁来验证？这些不是研发工作，是运维工作。很多AI团队是研发型团队，缺少运维基因，上线了才发现没人管。我们曾经有个项目，向量数据库磁盘满了，整个检索服务瘫痪了四小时。原因是没有设置磁盘告警，也没有自动清理策略。最后排查发现，日志文件占了80%的磁盘空间——而这个问题在POC阶段根本不存在，因为数据量太小。

更重要的是故障响应机制。量产环境出问题时，不是找”最熟悉代码的人”，而是要有标准化的应急预案和分级响应流程。P0级故障多久响应？P1级多久修复？哪些场景可以先降级？哪些必须立即回滚？这些都需要在上线前写好。

我们内部定了个规则：核心模型回答错误影响用户资金安全的是P0，15分钟内必须回滚；系统恢复缓慢是P1，2小时内修复；界面显示异常是P2，24小时内处理。每个级别都有明确的响应人和操作手册。这个手册不是写一次就完事的，每季度要演练一次。上次演练就发现有个回滚脚本因为依赖了某个开发者的个人API key，那位同事休假了，脚本跑不通——这就是典型的单点故障。

最后说一点：上线后的优化节奏。 POC阶段模型答对了90%就觉得不错了，量产后必须持续追踪各类指标，每周运营会议分析。哪些问题是模型层面的？哪些是数据质量的？哪些是产品设计的？必须有固定的迭代节奏。不能上线了就觉得万事大吉。AI系统是活的，需要持续喂养和优化。我们现在的做法是每周五下午开运营复盘会，看过去一周的指标变化，确定下周的优化重点。这个会雷打不动，哪怕只有两个人也要开。

写在最后

说完这五条生死线，你可能会觉得AI量产太难了。

确实难。但难不是因为技术有多深奥，是因为从POC到量产，本质是从”做演示”切换到”做生意”。

演示只需要一个场景跑通，生意需要所有场景都不出错。演示可以容忍偶尔的人工干预，生意需要系统自己能闭环。演示的成本可以忽略不计，生意的每一分钱都要算清楚。

我见过太多团队把POC的水平当成量产的水平，结果栽了大跟头。也见过一些团队POC阶段故意”示弱”，把脏数据、高并发、异常场景全部纳入测试，量产反而顺风顺水。

区别不在技术能力，在做事的认知。

如果你正在把一个AI项目从POC往量产推，建议你拿这五条生死线逐一对照。哪条还没准备好，就先把那条补上，别着急上线。

毕竟，延期上线的代价是时间，上线后崩盘的代价是口碑。

而口碑这东西，AI圈子里传得特别快。