6000字长文：陪跑一个AI项目后，我总结了AI落地的6个生死关

本文来自微信公众号： ToB老人家 ，作者：王戴明

最近几个月，我一直在陪跑一个企业级AI项目。准确地说，这个项目还没有完全结束，正在准备上线。但它已经做过一线业务实测，反馈很好，项目组也非常有信心。

更有意思的是，一期还没有完全上线，项目组服务的甲方客户已经主动催二期合同了。而且，还给项目组介绍了很多集团其他事业部的AI项目商机。

这个项目真正让我感触最深的，不是现在模型有多强，也不是提示词要写得多漂亮。而是一个AI项目能不能跑出来，很多时候不取决于技术——技术当然重要，但技术只是入场券。

真正决定项目生死的，是你能不能在一开始把项目范围控住，能不能把产品架构定对，能不能把业务规则拆清楚，能不能用测试集推进项目，能不能设计上线策略，能不能让客户上线后持续运营起来。

说白了，AI项目最难的不是做出一个demo。最难的是让它从一个demo，变成客户业务里真正能跑起来的东西。

今天，我就借着这个项目系统的复盘一下，一个企业级AI项目从0到1，到底要过哪几关。

第一关，是合同范围。

很多AI项目从签合同那一刻，就已经埋下了失败的种子。

项目制最大的问题，就是客户喜欢把需求尽可能塞进合同。客户当然希望花一笔钱，把能想到的问题都解决掉。而项目组为了不丢订单，往往也会有求必应。

甚至有些团队恨不得合同写得模糊一点。只要边界不说死，签单时就不容易和客户发生冲突。但问题是，签单时模糊掉的边界，后面都会变成项目成本。客户说要客户画像，要销售洞察，要会议纪要，要知识库问答，要商机评分，要销售训练，要方案生成。听起来每个都很有价值。

但项目资源是有限的，客户耐心是有限的，团队对业务的理解也是有限的。如果一开始就把范围铺得太大，后面一定会出问题。

这个项目早期也遇到过类似情况。

当时项目组和甲方客户谈了一个很大的范围。我看完以后，给了一个很明确的建议：砍掉80%相对次要的内容，先聚焦那20%真正决定业务结果的核心场景。

为什么？

因为甲方客户真正要的，不是一个看起来很完整的AI系统，而是提升商机转化率。如果那20%核心场景成功了，比如系统真的能帮销售筛选高价值商机，输出靠谱的销售策略，推动销售做出下一步动作，那么客户的核心目标就达成了。

反过来，如果这20%没做成，哪怕剩下80%功能都做完，也没有意义。

这就是企业级AI项目第一件要想清楚的事。签合同前，不能只问客户想做什么。要问客户到底想改善哪个业务环节？这个环节现在有什么问题？造成了什么坏结果？客户希望AI最后带来什么业务效果？

只有这些问题问清楚，项目范围才有可能收住。范围收住以后，成本才可控，交付才可控，客户价值也更容易被看见。

很多项目不是死在技术不行，而是死在一开始什么都想做。

第二关，是产品架构。

范围收住以后，接下来最关键的不是画页面。

这是很多传统软件团队做AI产品时最容易犯的错。他们习惯性地问：页面长什么样？菜单怎么分？按钮放哪里？流程怎么走？

这些问题当然要解决。但对AI产品来说，页面是结果，不是起点。传统软件的核心，更多是功能和流程。比如CRM，要记录客户信息、维护商机阶段、管理拜访记录、推进销售流程。但AI产品的核心，是交付业务结果。

在这个项目里，因为面向的是线下销售，所以我们最终要交付的业务结果，不是“多一个客户画像页面”，也不是“多一个AI对话框”。而是销售洞察。

比如，哪些商机值得优先推进？这个客户现在最可能关心什么？销售下一步应该问什么？这条商机为什么可以进入评审？哪些信息还没有补齐？这些才是AI产品真正要交付的东西。

所以在项目启动前的咨询里，我按Palantir本体论的思路，帮项目组把整个产品架构定了下来。

简单说，本体论不是一个玄乎概念。在企业AI项目里，它最有价值的地方，是逼你把业务拆成对象、属性和规则。

对象是什么？

可以是客户、商机、会议、拜访、痛点、预算、决策链。

属性是什么？

客户有什么行业、规模、业务场景；商机有没有预算、有没有明确决策人、当前处在哪个阶段；会议里有没有提到痛点、金额、时间、竞争对手。

规则是什么？

在什么条件下，这个商机值得推进？在什么条件下，销售应该补充信息？在什么条件下，客户只是有兴趣，还不能算真正商机？

这些东西如果不拆清楚，AI就只能靠大模型自己猜。大模型一猜，结果就不稳定。

后面整个项目基本都是按当时定下的产品架构往下落，实践证明方向是对的。

我也建议所有做企业AI的朋友，都认真研究一下Palantir的本体论。但这里要特别提醒一句：学本质，不要照抄。

Palantir的很多实现方式其实很传统，很重，很适合它自己的客户和项目形态，但不一定适合所有AI产品。

你真正应该学习的，不是它的页面长什么样，而是它为什么要把业务拆成对象、属性、关系和规则。学的是这个底层思路。

第三关，是详细方案设计。

很多人一说企业AI，就会陷入一个误区：总想找最先进、最完整、最像标杆公司的技术方案。但我这次更深的感受是，企业AI里没有最好的技术，只有最适合当前场景的技术。

比如业务规则这一块。如果照着Palantir的方式做，你可能会做很多页面，让用户在页面上维护对象、属性、关系和规则。这当然可以。但在这个项目里，我们没有这么做。我们把大量行业知识和业务规则，放进了RAG知识库。为什么？

因为这个项目不追求工业制造那种0误差。它要解决的是销售洞察问题。销售业务本身就有很多模糊判断、经验判断和概率判断。在这种场景下，用RAG知识库维护行业知识、销售规则和判断逻辑，成本更低，调整更快，也更适合项目当前阶段。

提示词做相对固定的推理框架，RAG知识库承载行业知识和业务差异。这就是一个更合适的分工。

很多AI项目失败，不是因为技术不够高级，而是因为技术选择和业务场景不匹配。

有些场景必须追求极高确定性，你就不能太依赖模糊知识库。有些场景本来就需要快速试错、快速迭代，你却非要做一套很重的规则维护系统，项目成本就会被拖死。

产品经理在这里的价值，不是追逐最新概念。而是判断，在当前业务目标、客户预算、交付周期和团队能力下，什么技术方案最合适。

在详细方案阶段，关键点不是把功能写细，更不是把提示词写长。

真正的详细方案，要同时回答两个问题。

第一，如何让AI给出准确、有价值的洞见？

第二，这个项目做完以后，能不能产品化？

前一个问题，是规则工程。后一个问题，是商业视野。

先说规则工程。很多业务人员说规则的时候，会说得很自然。比如，这个客户很有潜力。这个商机值得推进。这个客户有明显痛点。这个销售下一步应该去问预算。人听得懂。但AI不一定能稳定执行。你必须继续往下拆。

为什么这个客户有潜力？是因为行业匹配？规模匹配？现有痛点强？预算明确？决策链清晰？客户近期有相关项目？

为什么这个商机值得推进？是因为客户目标清晰？时间紧迫？预算明确？内部有支持人？竞争对手还没进入？

这些判断背后，都要拆成对象、属性和规则。

规则最好尽量结构化。比如if-then，比如阈值，比如大于小于，比如多个条件之间是and还是or。这听起来很笨，但很重要。因为AI项目里，最怕的就是“人觉得差不多，AI执行起来完全不是一回事”。

再说商业视野。为什么详细方案阶段要有商业视野？

因为做项目的目的，不能只是把这一单交付掉。如果你做的是一个0到1的企业AI项目，那你真正应该关心的是：这个项目做完以后，能不能形成标准产品？能不能形成标准实施方法论？这套标准产品和标准方法，能不能继续卖给其他客户？

这背后也是在提前设计护城河。AI时代，咨询+软件可能会变得越来越重要。咨询提供的是业务理解、行业经验和判断框架。软件把这些能力放大，让它可以标准化、规模化、持续交付。在这个过程中，知识库、业务规则、实施方法和客户现场经验，都可能变成护城河。

但前提是，你不能把每个项目都做成一次性定制。你要在项目里不断追问：哪些东西可以标准化？哪些规则可以复用？哪些场景可以复制到下一个客户？哪些知识库会越积累越有价值？

第四关，是项目推进。

企业AI项目推进到一定阶段以后，最大的问题会变成：AI产品到底做得对不对？

传统软件里，很多东西相对清楚。流程有没有跑通，字段有没有保存，权限有没有生效，报表有没有出来。

但AI项目不一样。AI输出的是一段洞察、一段建议、一个判断。这个判断好不好，研发不一定知道。客户今天觉得好，明天可能又觉得不够准。不同销售、不同业务负责人，对“好”的理解也可能不一样。

所以我在这个项目里反复强调一件事：没有黄金测试集，AI项目就没有方向盘。

什么是黄金测试集？

不是随便拿几条数据测一下。而是拿真实业务场景，明确输入是什么，规则是什么，正确输出应该是什么，并且经过客户确认。

比如一段真实销售录音，里面提到了客户痛点、预算模糊、决策链不清。那这条数据放进测试集时，就不能只保存录音。还要标清楚：这个场景属于哪一类业务？AI应该识别出什么痛点？应该判断商机处于什么阶段？应该提醒销售补充什么信息？哪些内容不能编造？

测试集要分层。

第一类是高频业务。这些场景决定80%的使用体验，必须先跑通。

第二类是高难业务。这些场景容易判断错，最能暴露系统能力。

第三类是红线业务。比如绝对不能编造预算，不能虚构客户表态，不能把不该推进的商机推上去。

这三类数据组合起来，项目才有判断标尺。

后面发现bad case，也不能只是记一句“这里错了”。要追根因。是对象属性缺了？是规则没写清？是提示词有问题？还是知识库上下文不足？

改完以后，再拿同一批真实案例重新测一遍。不是只看这个bad case修好了没有，还要看原来正确的判断有没有被改坏。

这件事听起来不性感。但它决定AI项目能不能从感觉驱动，进入工程化推进。

第五关，是上线准备。

很多团队对上线的理解太简单。他们以为上线就是系统部署到生产环境，用户能登录，功能能点开。

但企业级AI项目不是这样。上线不是系统上线。上线是组织和机制上线。因为AI项目进入真实使用以后，会暴露很多问题。

数据从哪里来？谁负责提供真实业务输入？谁判断AI输出对不对？谁收集问题？谁决定改规则？谁和客户解释当前效果？谁推动销售继续使用？

如果这些问题没有提前设计，系统一上线，就会乱。所以我在项目后期建议他们做上线策略。

上线策略要写什么？

至少四件事。

第一，客户资源安排。

谁参与试用？谁提供数据？谁做业务判断？谁有权推动一线团队配合？

第二，交付物清单。

到底交付什么？知识库、测试集、规则表、培训材料，分别到什么程度？

第三，验收和质量标准。

什么叫上线成功？是进入生产环境，还是一批真实销售能跑通核心场景？哪些指标必须达标？哪些问题可以上线后继续优化？

第四，时间安排和责任人。

哪一天做测试，哪一天评审，哪一天进生产，出现问题谁响应，谁向高层汇报。

这些东西要尽量白纸黑字对齐。否则双方对“上线成功”的理解不一样，后面一定扯皮。

而且有一点很关键。上线前暴露问题，客户通常还能接受。因为大家知道这是准备阶段。但上线后暴露问题，尤其是一线用户开始怀疑系统不靠谱，这种信任损失很难挽回。

所以企业AI项目上线前，不能只盯功能，还要盯组织机制。必要时要建立一个虚拟组织，明确谁负责业务判断，谁负责数据，谁负责产品，谁负责技术，谁负责向高层汇报，谁负责协调资源。

这不是形式主义。这是让AI系统进入客户组织的必要条件。

第六关，是客户自运营。

很多人以为系统上线，项目就结束了。

但对AI产品来说，上线往往只是开始。尤其是企业级AI项目，刚上线就能做到100分，基本不现实。能做到60分，已经不错。但这里有一个前提。60分不是降低标准。

60分只是说明，这个系统已经跑通了核心场景，证明方向是对的，具备继续运营到80分、90分的基础。如果没有这个基础，60分没有意义。如果有这个基础，后面真正关键的就是客户运营机制。

我在这个项目里一直强调，要围绕黄金测试集建立运营机制。这个机制大概是这样的。

第一，让真实用户使用系统，产生真实业务输入。比如真实销售录音、真实会议记录、真实商机推进过程。

第二，从真实使用里找bad case。哪些洞察不准？哪些建议没用？哪些信息AI没识别出来？哪些内容AI编造了？哪些场景根本没有覆盖？

第三，把bad case更新到测试集。不是只在群里说一句“这个错了”，而是把它变成一条可复测的数据。

第四，根据bad case判断要改哪里。可能是对象属性缺了，可能是规则没写清，可能是提示词要调整，也可能是知识库里没有足够上下文。

第五，再拿测试集重新测。确认整体效果变好了，再更新到线上。

这就是从60分到90分的运营机制。

AI产品的准确性，很多时候不是一次性开发出来的，而是运营出来的。这也是企业AI和传统软件很不一样的地方。

传统软件上线后，更多是修bug、补功能、做培训。AI产品上线后，还要持续补规则、补知识、补场景、补测试集。

如果客户不参与，这件事做不成。如果项目组没有机制，这件事也做不成。所以我现在越来越觉得，一个企业级AI项目真正的交付物，不只是系统。还包括一套让客户自己能持续运营AI的机制。

回头看这个项目，我最大的感受是：AI项目成败，真的不取决于技术。不是说技术不重要。而是技术只是其中一环。

如果合同范围没控住，技术越强，项目越容易发散。

如果产品架构没定对，模型再强，输出也不可控。

如果详细方案没有商业视野，项目做完也只是一次性定制，很难产品化。

如果没有黄金测试集，团队根本不知道自己是在进步，还是只是在改来改去。

如果没有上线策略，系统进了生产环境，也可能没人用、没人负责、没人持续推动。

如果没有客户自运营机制，AI永远停在一个看起来还不错、但无法持续变好的状态。

所以，AI项目最后拼的，不是谁更懂模型。拼的是谁能把范围、架构、规则、测试、上线和运营，一项一项跑起来。这件事听起来不性感。但大部分企业级AI项目，最后就死在这些不性感的地方。