那个「万众瞩目」的银行AI项目，差点让我翻车

去年年底，我接到一个银行客户智能体项目。

当时客户的 SOW 写得清清楚楚：做 10 个智能体，支持知识问答、知识图谱，要私有化部署，3 个月内上线，最后拿 500 个评测集来验收。

整体来看，目标和节奏都很明确，也有清晰的交付要求，就是个标准的企业 AI 项目，就欣然答应了。

但进场调研没多久，我就感觉不对劲了。

一、所有人都在讨论答案，却没人对齐问题

事情是这样的。

客户说要做 10 个智能体，我一开始也没多想，就按字面上的意思理解，准备按之前的项目，搭框架、套内容了。但跟不同部门聊了一圈后，我整个人有点懵。

同样都是「10 个智能体」，技术部理解的 10 个，是按业务场景来分，一个场景一个。业务部门理解的，是一个总智能体下面挂 10 个子智能体，把复杂能力拆进去。管理层那边的想法又不太一样，他们是按组织架构想的，希望 1 个部门对应 1 个智能体，方便管理和推进。

问题是，这家银行有 26 个部门。

我当时就愣住了。表面大家在讨论要做几个智能体，实际上聊的是完全不同的业务划分方式。按场景分、按架构分、按组织分，三条线根本不在一个频道上。

我接着往下调研，聊了十多个条线、几十个不同岗位的对接人。越聊越发现，每个角色对这个项目的理解都不一样。

技术侧想的是怎么把架构设计得足够完整，不仅要支持现有业务，还要考虑未来扩展到其他场景。业务侧在想怎么尽可能把日常 IT 需求也包进这个项目，减轻自己的工作量。管理层想的是如何让全行把 AI 用起来，让这笔预算不白花。

说实话，每个人的诉求都很合理。项目大方向也没错，需求听起来都很对。所以直到调研结束，这个项目一直在一种「万众瞩目」的气氛中坚定前行。

但我心里一直有点别扭。

如果顺着这些要求继续往下聊，很快就会进入方案阶段。拆功能、画结构图、确定平台能力、排实施计划，然后大家都会默认这个项目和自己想的一样，就等做出来了。

可奇怪的是，所有人都已经在讨论答案了，但「问题到底是什么」这个问题本身，似乎还没有被单独拿出来做一次对齐。

二、停下来定义问题，比什么都重要

我当时判断，如果继续往前推进，大概率会遇到一个卡点：

这个项目到底是在解决什么问题，团队并没有达成一致。这种情况下出的需求方案，肯定没法过评审。

于是我做了一个可能会得罪人的决定：

把项目停下来，重新对齐。

我召集了几位核心领导层，没有急着统一口径，而是先把当时几种不同的理解方式都梳理出来。有人按部门分，有人按场景分，有人按系统结构分。顺着这几种划分，一条条去看它们背后的逻辑关系。

整个过程不轻松，甚至可以说有点痛苦。

因为一旦完整拆开，问题反而变多了。原来大家用一个词在聊的东西，背后混着好几种逻辑。有的是查知识，有的是基于知识做报告生成，有的则是要连接内部数据库做数据关联检索。如果把这些都塞进一个智能体里，边界肯定会越拉越宽。

项目节奏瞬间慢了下来，我也顶着很大的压力。有人开始担心这样会影响排期，质疑为什么要重复造轮子。

但我非常清楚，不把边界定清楚，架构做得再完整，也很难对到具体场景上。最后做出来的就是个四不像，谁都没法验收通过。

幸运的是，经过又一轮讨论，大家很快对新目标达成了一致。确定了这 10 个智能体的使用人群、访问权限、问答范围，以及和公司内部系统的关联关系。

等这一步走完，再进入后面的方案设计，很多事情就顺多了。

三、不止一个项目会这样

这种情况，不只发生在银行那一个项目里。

差不多同一时期，我接触过一家零售公司。初次沟通，对方方向也很明确：做个智能体，打通 OA 和企业微信，用最好的大模型，尽快出效果。

听起来很正常，要打通内部系统、用最先进的模型、效果要可见——这些要求都没问题。

但聊深了就会发现，大家说的根本不是一回事。

管理层想的是 ROI，这个项目能不能量化出成果，能不能给业务带来实际价值。业务方更实际，他们趁机把 OA 里那些用得不顺的地方全拿了出来，想借这个机会一次性解决。IT 部门则反复和我确认：这套东西能不能复用？会不会又成一个孤岛？以后维护成本会不会剧增？

于是我又看到一个熟悉的画面：同一个项目里，有人想快速见到效果，有人担心系统稳定性；既要快，又要架构合理；既要解决眼前问题，又想实现未来扩展。

项目的复杂度，在不断被抬高。

更麻烦的是，这些诉求一开始并不会都摊开来说。而是在不断访谈中逐渐被揭开。于是项目很容易陷入一种状态：方向清楚、目标全面，但到底先解决什么，没人会明说。

后来我慢慢想明白了，这种情况的反复出现，不是需求沟通不到位，而是 AI 项目本身就特别容易被当成「万能入口」。

一旦进了这个入口，就很容易让各种不同层面的事揉在一起，被打包塞进方案里。

四、为什么 AI 项目特别容易叠加复杂度

把这两个项目放在一起看，你会发现它们出奇地相似。

一开始都是目标很明确。银行那边要做一批智能体，把全行知识用起来；零售公司那边要做一个能打通系统、尽快见效的智能体。听起来都是企业做 AI 升级改造最常见的诉求。

然后，不同角色开始往项目里塞各自关心的东西。

业务把日常最头疼的问题带进来，想借这个项目一起解决。IT 把系统结构、数据来源、权限控制这些约束带进来，怕后面出乱子。管理层把对效果的期待、对推广的要求也放进来，想要个能拿得出手的成果。

而且这些都是在聊的过程中，一点点渗透进去的。

每一项单独看都合理，身为实施方也不好直接拒绝。于是项目就在边界不明的情况下，逐步走向混乱。

每个人都认为自己的问题会被优先考虑，对项目抱有很高的预期。而一旦进入这个状态，你就会发现，无论你设计出了多完整的方案，都很容易在汇报时被挑战。

等到那时候再要调整，就不是改个想法那么简单，而是要动已经铺开的整套设计。

所以你会看到，有的项目做到一半，不断会有问题被反复拿出来讨论，每次都像是说了，但又没真正说透。有些地方来回改，改到后面大家自己都嫌烦。还有些功能单看都说得过去，拼在一起却总觉得别扭。

你很难说是哪处错了，但就是能感觉到这套东西就没有完全对齐过。

表面上是执行问题。但如果在项目还没真正进入方案之前，不同角色带进来的目标、约束和期待没拆开、没被排序，等问题真正显现出来，就只能重新再把事情讲一遍了。

五、我的解法：前置边界确认

复盘这些项目后，我总结出一个应对这类问题的解法。

关键点在于，在收到 SOW 之后，不要急着进入方案设计，而是先插入一个前置边界确认环节。

具体来说，我会和客户的项目负责人对清楚这几个问题：

第一，优先解决哪一类问题？

是知识查询、工作提效，还是要介入到具体的业务流程中？这个问题没有标准答案，但必须选一个。不能既要又要还要。

第二，哪些必须放进这一期，哪些可以先放后面？

想做的东西永远很多，但资源和时间有限。把范围收敛到一个可交付的最小闭环，比画一个大而全的饼更重要。

第三，不同角色的诉求，哪些是目标，哪些是约束，哪些只是顺带的期待？

业务的需求、IT 的担心、管理层的期待，这三类东西性质完全不同，不能混在一起当需求处理。

第四，如果只选一个最小范围落地，应该落在哪个场景？

先跑通一个真实存在、痛点明确、用户愿意用的场景，而不是同时铺十个场景。

当然，不用一次把这些问题都捋出来，但至少能把方向定下来，也便于做优先级排期。否则后面不管怎么设计，都是空中楼阁。

范围一旦明确，再讨论智能体怎么拆逻辑、知识从哪来、接不接内部系统、验收怎么设计，就都有了更清晰的参照。

六、写在最后

说实话，在我接触的大多数项目里，这个前置边界确认环节默认是不存在的。

项目一启动，军心大振，恨不得早点出方案、进设计，让所有人觉得项目在加速推进。但如果前面的边界没单独过一遍，后面每一步都是在叠复杂度。

我现在再做项目的习惯就是：看到问题没定义清楚，就先停下来，把问题分层、明确边界，再决定怎么继续走。

这可能会影响排期，可能会让人觉得一直在研讨不推进，甚至可能会得罪一些人。

但不这么做，后面返工的成本会更高。

AI 项目的复杂度，往往是来自人对同一个问题的不同理解。对齐这些理解，才是最花时间的部分。

所以，如果你也在做 AI 项目，不妨在出方案之前，先问问自己：

我们真的对齐了要解决的问题吗？

还是只是在讨论各自想要的答案？

我是申悦，一名企业AI咨询顾问。长期在一线为企业提供AI产品咨询与培训服务，专注企业AI能力导入、流程再造和数字化转型。欢迎加我好友，聊聊你的AI困惑。

回复“ 微信 ”，加我 个人微信