当一个企业AI项目的阶段性成果汇报会上，项目团队眼中的‘扎实基建’与高层管理者期待的‘业务变革’产生激烈碰撞，项目价值的认知错位暴露无遗。本文通过一个真实咨询顾问的深度复盘，犀利剖析了从‘建设型成果’到‘经营型成果’的鸿沟，并提供了校准高层预期、重塑项目解释权的四项关键策略。

同一个项目，不同的理解

前段时间，我参加了一个客户公司的AI项目研讨会。

对方是我已经跟了一段时间的企业 AI 项目，前面已经做过调研，需求方案也陆续调整过好几轮，几个核心智能体的方向、边界和基本逻辑，都比较明确了。按原本的安排，这场会一部分是内部同事分享各自最近怎么用 AI 工具，一部分是回顾项目进展，再往后，是讨论下一步怎么推进。

如果只看流程，这是个再正常不过的项目阶段会。

所以在进会之前，我也没太当回事。虽然我知道企业项目推进到这个阶段，多少都会有分歧，也知道高层和执行层看问题的角度不一样，但至少在我当时的判断里，这个项目还谈不上失控。因为需求明确、也有了阶段性产出，客户公司内部也灰度上线了几个智能体给员工内测。问答类、合同审核类、销售助手类，每类智能体都有对应的业务背景，也都有一套相对完整的需求设计逻辑。

在项目推进期间，我花了大量时间把业务的底层逻辑做了清晰梳理，明确了知识怎么分、规则怎么写、边界怎么控、回答方式怎么统一、流程怎么嵌入系统等等。

从咨询顾问和产品设计的视角看，这些都是不太容易在汇报里出彩的脏活累活。但我之前也写文章讲过它们的重要性，并且在切身认真执行着。所以那天在参会期间，我一开始是带着惯性在听，觉得这应该又是一场企业项目里常见的阶段性汇报。无非是大家对齐一下进展，讲讲现在做到了哪里，下一步该怎么推进。

但总裁在会上连续追问的几个问题，让我开始觉得不对劲。她问得很直接：

• 现在到底做成了什么？
• 这些智能体具体解决了什么问题？
• 如果做了这么久，最后呈现出来的还是问答、知识库、审查结果，那它和真正能改变业务动作的东西，到底差在哪里？

说实话，任何一个管理者，在项目推进到一个阶段之后，都会很自然地这样问。但我突然发现，她问这些问题时所站的位置，和我理解这个项目所站的位置，不是一回事。

我原本更习惯站在方案和建设过程的角度看项目。

我会去想，这个场景能不能做，用户会怎么问，知识从哪来，规则能不能被模型直接理解，流程接到哪里比较合理，哪些能力现在能落地，哪些能力还要再等等模型进化。我会本能地把项目拆成一段一段的路径去看，先做底座，先把结构搭起来，先让它跑通，再去看怎么接业务系统，怎么优化体验，怎么做更前置的流程嵌入。

这种做法也是很多企业 AI 项目一开始最现实的推进方式。

但那天客户总裁不是这么看的。

她不是在听你这个方案设计的是不是完整，也不会判断你是不是把边界考虑到了。她最关心的是：

做了这么久，这件事对业务来说，到底已经发生了什么实质变化？

这两种视角之间的差别，平时如果不被放到一个很尖锐的场合里，其实并不容易被看出来。

对我来说，这是个从0到1的项目，还在建设中。它有阶段，有前后顺序，有些成果是表层的，有些成果是底层的。有些东西现在看上去不显眼，但不做，后面根本走不动。有些场景方向上是成立的，只是眼下还没能让高层一眼看到价值。

但总裁不是这样理解的。

她看到的是：公司已经投入了资源，也已经推进了一段时间，那么现在拿出来给管理层看的，就不该只是一个仍然停留在建设期语言里的东西。她关心的是现在你到底改变了什么业务动作，减少了什么人工判断，前置了什么流程风险，形成了什么新的工作方式。如果这些问题讲不清楚，那在她眼里，项目就很容易被理解成：看起来做了很多，但并没有什么能拿得出来的成果。

也是在那个时候，我第一次非常清楚地感觉到，企业 AI 项目里，不同角色看问题视角带来的观念错位，有多么严重：

• 项目团队很容易把“已经做了很多基础建设”理解为“项目正在稳步推进”。
• 高层则更容易把“还没看到足够强的业务变化”理解为“项目价值感还不够”。

这两种判断都没错，但却不能在同一个层面讨论。

前者是在看建设过程，后者是在看结果感受。

前者是在判断这件事有没有往前走，后者是在判断这件事值不值得继续往前投。

站在我这样的外部咨询顾问角度来讲，会觉得虽然大家关注点不同，但至少看的还是同一件事。可那场会让我第一次意识到，项目推进过程中的每个人，都有一套自己的理解逻辑。

有人看的是方案成立不成立，有人看的是执行到没到位，有人看的是团队有没有把事情讲明白，有人看的是这件事最终有没有成为一个真正的经营抓手。最后凑在一起，大家就会越来越听不懂彼此到底在说什么。

尽管企业项目里，被质疑、被追问、被施压，本就是常态。但我却由此开始反思：为什么在我原来的理解里，这个项目并没有偏到那么离谱，可一到总裁那里，却会被认为做了半天没啥成果。

这里面最需要复盘的，是从一开始，大家就在用不同的标准看同一个项目。这才是很多企业 AI 项目真正麻烦的地方。

真的是方案有问题么？

尽管理解不同角色看问题的视角不一样，但那场会之后，我还是会觉得有点别扭。

毕竟我是这个项目的实施顾问，又确实参与了需求调研、方案设计、场景梳理，听到客户高层对项目表达出明显不满意，很难完全不把这件事往自己身上带一点。哪怕理性上知道，一个企业项目走到最后呈现成什么样，不可能只由一个人决定，但情绪上还是很容易先冒出一个念头：是不是我哪里一开始就想错了？或者我给出的方案，根本就没有真正打中他们的需求？

后来我把写过的几份需求方案又重新翻了一遍。

我本来是想看看，有没有哪些地方是当时没想清楚，或者有没有哪类问题，在方案阶段就被忽略掉了。但重新看完之后，我反而越来越确认一件事：至少从需求设计这个层面来说，这些方案并没有跑偏。

先说问答类智能体。

这类场景在企业里本来就成立，而且我现在依然觉得它是很多企业 AI 项目最现实、也最容易先落下去的一类能力。制度散、流程多、文件版本复杂、不同人解释不一致，新人找不到，老人也不见得说得准，这类问题在很多组织里都真实存在。问答类智能体的本质，是为了把原来分散在制度、流程、FAQ、培训材料里的内容，变成一个更容易被检索、理解和调用的服务入口。

如果从产品设计的角度看，这类智能体要成立，至少要想清楚几个问题：它服务谁，覆盖哪些问题，哪些问题适合单轮直接回答，哪些问题需要多轮澄清，知识库怎么分层，问答库和知识库怎么配合，遇到超范围问题怎么兜底，回答风格怎么统一，入口怎么设计。前期我在做这部分方案的时候，也是沿着这套逻辑去梳理的，而且尽量把问题类型、知识来源、回答方式、边界和访问入口都具体化。这个方向本身并没有问题，它解决的也确实是企业里一类真实存在、频率并不低的问题。

再说合同审核类智能体。

这一块在整个项目里属于业务目标比较清楚、流程逻辑也比较扎实的场景。合同审核这个需求本来就是带着具体问题来的：不同合同版本之间能不能自动对比改动点，能不能根据已有规则对合同文本做一轮风险识别，能不能把合同审核功能嵌入 OA 审批流。

也正是因为这个场景更接近真实流程，前面做方案时，我才花了大量时间和业务同学抠细节。尤其是审核规则的定义上，要先判断哪些规则模型可以直接依据文本判断，哪些规则依赖外部事实、系统数据和流程材料；还要考虑合同类型和规则的映射关系；以及要讲清楚测试材料如何准备，和后续规则如何维护。说白了，这一块前期做的不只是个AI智能体，而是一个围绕合同审查流程搭起来的半结构化审核系统。

如果只从需求设计看，这个方向是企业里一个很具体的提效点，只不过它后面发挥多大价值，除了方案本身，还取决于接口、流程接入、规则质量、法务财务配合程度以及最终呈现方式。

还有一类在会议上被总裁否定最多的，是专门给销售人员设计的销售助手智能体。这个方案也是会后我最先反思的：是不是销售助手从一开始方向就有问题？

但我后来还是觉得，场景选择的没问题。销售过程里本来就有大量零散、口头化、难沉淀的内容：客户说了什么、顾虑在哪、导购怎么接的话、哪些话术更有效、哪些线索值得跟进、哪些经验可以复用。把这些从原始对话和销售过程里结构化提出来，再反向服务销售动作，这个逻辑本身完全讲得通。

双方观点冲突的关键在于，这个想法要成立，依赖条件远比想象的更苛刻。

销售场景和问答、合同审核不一样，它对数据规模、业务配合、使用入口、持续运营、系统回流这些东西的依赖非常强。销售助手不是方案设计对了就能顺利滑推进的项目，真正要做出经营出价值，必须同时满足很多外部条件。

所以如果一定要说我当时哪里做的不到位，那就是没把销售场景价值成立的前提说清楚。我知道它要靠数据、靠业务、靠运营，但却没有在一开始就把这件事上升到一个高度，让所有人都清楚：这个场景不是把功能做出来就完事了，它本质上是一个要靠持续供给数据、持续使用和持续反馈才能跑起来的系统。

判断一个方案是否有价值的关键，在于它是不是在解决一个真实问题，以及有没有抓准这个问题的结构。从这个角度看，前面这些方案，大多数都不是伪需求。问答类智能体解决的是企业内部知识服务的问题，合同审核解决的是规则辅助审查和流程提效的问题，销售助手解决的是销售过程中的知识沉淀与动作辅助问题，这几类问题都是真问题。

但方向上成立，不等于高层会认可；需求逻辑清晰，也不等于项目推进过程中不会被挑战。

这个差别我不是不明白，只是没像开那场会之后感受得这么具体。

站在咨询顾问的角度，我天然会更关注业务场景是否真实、需求是否清晰、边界是否明确，功能之间是不是自洽，落地路径有没有前后顺序。这些固然重要，但企业高层看到的，是这个东西拿出来，有没有带来改变业务动作的成果。

而这一点，恰恰是我反思的关键。

我前面做的很多工作，更像是给项目搭脚手架，因为很多企业 AI 项目要依赖它才能稳步跑起来。但到了高层视角里，他们不会因为架构搭得工整，就默认这栋楼已经建起来了。对他们来说，最终被看到的，是里面到底有没有人真正住进去，是这栋楼现在到底起了什么作用。你讲的是产品逻辑，客户高层则是用经营逻辑来评价它，二者说的并不是一回事。而真正需要引起注意的是：方案被落实成什么、被讲成什么、以及最终被谁以什么标准看到。

建设型成果和经营型成果的差别

总的来讲，总裁否定的重点，不是方案本身，而是一种结果感。

结果感这个词，我觉得特别适合用来解释很多企业 AI 项目为什么明明做了不少，最后却还是容易让高层失望。

一个企业 AI 项目中，通常会有2种“成果”。

一种是建设型成果。比如知识库梳理、规则库整理、问题分类、回答结构、权限设计、数据表字段定义、流程节点拆分、测试集整理。它们的建设价值很高，结果感却不一定强。

一种叫经营型成果，比如合同在进入法务前，系统已经能先自动拦下一批明显有问题的条款；比如业务人员不用再在几个系统和一堆文件里来回找，直接能拿到清晰的一步步指引；比如销售一线不只是获得一段推荐话术，而是真的有一套持续回流数据、不断优化动作、能带来成交辅助的机制；再比如原来需要人来反复判断、解释、补充的步骤，现在被更前置、更标准地替代掉了一部分。

而高管层往往会用后者的标准看项目。

这也是为什么项目团队看来已经做了很多事，但在高管眼里仍会认为给实际业务带来的变化还不够。

这还只是第一层。

更往下看，除了“建设型成果”和“经营型成果”之间的错位，还有另一种错位：一期能力和终局预期之间的错位。

很多乙方公司在和客户沟通时，特别容易把终局状态讲得很美好。因为不这样讲，项目很难启动；讲得太保守，甲方听起来也没感觉。于是慢慢地，前面方案里写的是长期想达到的能力，推进中做的是当前阶段能先上线的能力，但到了汇报时，又很容易不自觉地把当前阶段成果往长期目标上靠。

这件事一旦发生，高层的期待值就会被自动拉高。

你原本做的只是一期的底层基座，他会认为这时候已经可以看到应用价值了。而一旦高层带着这种预期进会议室，后面只要他看到的结果还不够明显，就很容易认为：为什么做了这么久，还只是到这种程度？

坦率说，站在项目组的视角，听到这种评价都会觉得委屈，因为他们会觉得自己明明已经做了很多脏活累活，却还得不到认可。可高层说这句话的时候，也不一定是在否定这些工作，他只是在表达另一层观点：你现在拿给我看的东西，还不足以支撑我心里原来建立起的预期。

说到底，这是方案、阶段成果和高层预期之间没有对齐。

AI 项目天然就比一般信息化项目更讲究前期业务治理。很多模型和Agent能力，虽然在技术上已经成立，但只要它没有真正嵌进业务流程、没有形成稳定的组织协同效应，就很容易做成半成品：内部人知道它不止这些，高层看到的却只有这些。

而一旦一个项目长期处在这种状态，高层必然会不满意。

除了确保方案质量，提前校准预期也很重要

随着进一步反思，我突然发现，外部顾问在这类项目里，很容易把自己放在一个很被动的位置上。

通常在我入场后，项目的预算、边界、合作团队和 sponsor 都定好了。很多时候，是等到项目已经决定要做了，才把我拉进来参与调研、方案设计和实施推进。这样的背景下，我很容易默认自己的职责就是把需求理清楚、把方案设计完整，做好交付、推进项目。

但只做到这里是不够的。

企业 AI 项目最容易出问题的地方，就在于如何有效传递信息。尤其是你的项目，最后会被客户公司内部的人，以什么方式理解、在什么阶段判断、用什么标准评价。

如果不提前讲清楚这些事，等到向高层汇报阶段性成果时，大家会发现，项目团队、管理团队、外部顾问，大家虽然说的都是同一个项目，但认知上根本就没对齐。

所以站在解决方案负责人的视角上看，我觉得十分有必要在确保方案合格的基础上，去提前校准项目的未来方向。

具体做法如下：

第一步，尽量把一个大而全的项目目标，拆成几个阶段性目标。

通常一个 AI 项目在立项时，都会画一张很大的蓝图。比如要做若干个智能体，要实现某类业务提效，要完成知识沉淀，要改善流程体验，要支撑内部推广等等。站在项目立项的角度，这种写法很正常，毕竟写得太保守，管理层也未必愿意投入。

但这类目标很容易会让人默认：项目交付时，就应该实现预期效果。

但大多数企业 AI 项目真实的推进路径，是先搭底座，再把功能做得可用，再接入流程，再看推广和运营，最后才有可能慢慢呈现出比较稳定的业务效果。

所以如果我们没有没有主动把这个路径拆开，后面就很容易吃亏。我认为现在做的是第一阶段，客户高层可能会拿第三阶段的标准来评估。

因此，哪怕项目边界不是我来定，至少也要自己主导定义阶段性目标。目的是让所有人知道：这个项目不是一口气走到终点，而是每个阶段完成不同的事。

比如有的项目，一期本质上做的是知识治理，那就明确说清楚这一期最核心的成果是什么，以及它未来的价值在于让后面的问答效果更精准，但这并不等于已经完成了业务重构。这样高层才不至于把基建成果按结果型成果来评价。

第二步，是在方案里写清楚，这个项目的价值成立，依赖哪些前提条件。

过去做方案，我的主要工作是写场景、流程、输入输出、功能边界、知识来源、系统接口、验收方式。但还少了一个很关键的层面：产品价值如果真的要成立，还依赖哪些条件。

尤其在企业项目里，很多场景不是你把功能做出来，价值就自动成立的。

问答类场景相对还好，因为它更偏知识服务，只要知识质量、分类、检索和回答方式处理得当，还是比较容易体现价值的。但像销售助手、线索打标、话术推荐这类场景的成立，同时依赖真实业务规模、业务持续供给数据、使用者意愿度、数据回流机制、组织反馈、运营动作这一整套条件。

这些条件不成立，项目最后很容易只做成一个局部可演示、却很难持续跑起来的东西。

所以在做这类方案时，除了明确功能逻辑外，还要明确写清楚它能跑起来的前提条件。这么做不是为了甩锅，而是为了明确权责分工，让体现业务价值这件事更接近现实情况。

很多时候，价值成立往往会依赖产品之外的东西。

第三步，不要只汇报方案，还要主动校准项目的表达方式。

我一直觉得自己的汇报能力还可以，直到开了这场会，才发现要再补补课了。

实际上，我们的方案未必真的差，也不是完全没成果，但项目在被汇报、被转述、被呈现的过程中，被讲成了另一种样子。

原本做的是建设型成果，但汇报时用了太多结果型语言；原本做的是内测版本，但讲的时候听起来像是个成熟产品；原本只是部分流程接入，但说法上却容易让人以为已经形成了业务闭环。

管理层的预期就这样被不断拉高，等到真正看到结果时，他们自然会认为：为什么听起来已经做了很多，看上去还只是基础阶段。

所以现在如果让我总结，我会觉得作为AI顾问，不能只交付内容，还要尽量争取对项目表达方式的影响力。哪怕改不了边界，改不了资源投入，至少也要尽量能对外讲明白：项目应该在什么阶段，做出什么效果。

它现在做的是基建，还是结果；是建设底层能力，还是影响经营业绩；是刚开始试点验证，还是已经规模化应用。

这些话如果不主动提出来，项目最后很容易认知错位。

第四步，尽量影响组织对 AI 项目的理解方式。

企业 AI 项目并不是一个只靠文档和功能就能顺利推进的事。它高度依赖组织内部不同层级的人，对同一个项目理解一致。如果这一点没处理好，那前面做得越认真，后面反而越容易在一个你不完全能控制的评价体系里被挑战。

身为项目方案的出口人，尽管自己可能不会对结果唯一负责，但也要尽量在项目推进过程中，主动去定义阶段、提示风险、写清依赖条件，提醒大家哪些成果是基建、哪些需要二期才能验证，以及哪些表达方式可能会误导高层。争取不到项目的决定权，至少也要尽量争取项目的解释权。

一个项目的成败，在于它在不同人眼里，是如何被理解的：

• 项目团队会觉得，已经做了那么多底层建设，知识梳理了，规则提炼了，流程也跑通了，怎么还说项目没价值。
• 高层会觉得，公司已经投入了资源，推进了一段时间，现在还是拿不出什么像样的成果，怎么还能说项目在正常前进。
• 业务会觉得，自己配合了访谈、给了材料、也被要求改规则、补文档，但眼前工作方式并没有轻松多少，为什么总在说项目有进展。

而我作为实施顾问，很容易夹在中间，一边知道基础工作很重要，一边又觉得这些重要的东西并没有被客户高层认可。

因此在立项时，务必要让组织统一认知到：这个项目到底属于哪一类建设，它现在处在哪个阶段，以及每个阶段应该用什么标准来看。

这件事之后，我变了

那场会开完到现在，也就过了3天，但在我心里却被复盘了无数次。它让我重新认识了在做 AI 项目时，该在什么位置思考问题。

以前我做项目，是以产品和咨询顾问的身份，去思考一个场景是不是真问题、问题背后有没有足够清晰的流程和结构、智能体的工作方式是什么样的。没这些拆解和判断，很多场景肯定落不下去。

但只从这个角度看是不够的。

因为企业级项目和纯产品项目不一样，它处在一个复杂的组织里，既要面对业务的真实配合，又要面对 IT 的实现约束，还要面对高层在不同阶段对项目价值的重新审视。我们做的每一个东西，都不是孤立存在的。

以前如果有人问我，一个企业 AI 项目最重要的是什么，我大概率会回答：需求是否真实、场景是否成立、能力边界是否清晰。

现在如果再有人这样问，我会再补上一句：还要看这个项目在组织内部是否对齐了认知，尤其是高层的预期校准。

高层看到的，永远是某一个时点的结果，他会用自己的位置，去判断这个结果到底值不值得继续投入。

如果这个差别没有被提前意识到，那就很容易反复吃亏。

还有一点也要改变，那就是：主动争取项目的解释权，尽量在合适的时机，向客户讲清楚：

• 哪些已经做到了；
• 哪些现在还只是基建；
• 哪些价值方向成立，但前提条件还没齐；
• 哪些成果短期内不该被用终局视角来评价

也要更主动地去提醒对接人、项目负责人，哪些话如果不提前说清楚，后面一定会踩坑。

好了，今天的这篇复盘长文就先到这里。如果你在的公司正在做 AI 方案、知识库、智能体或行业解决方案相关建设，也欢迎交流项目实施、方案共建，或更长期合作的可能性。