为什么很多AI项目越做需求越多,最后反而交付不出来?

AI项目最危险的时刻，往往不是需求很多，而是每个人都觉得“这个顺手也能做”。

做售前和项目方案时，我越来越怕听到一句话：这个需求应该不复杂吧，既然大模型已经接上了，顺便一起做了。

最开始，项目可能只是一个很清楚的目标：做知识问答，或者做智能问数。Demo一出来，大家发现效果不错，想象空间一下子被打开了。有人说能不能再加报告生成，有人问能不能接业务系统，有人想做多轮分析，还有人觉得既然已经有对话入口，干脆把数字人、Agent、流程审批也接进来。

这些要求单独拿出来看，很多都“有道理”。问题在于，它们往往不是在同一个业务闭环里自然长出来的，而是在项目推进过程中不断被吸进来的。最后，原本一个边界清楚的AI应用，慢慢变成了一个知识平台、数据平台、Agent平台、系统集成项目和交互项目的混合体。

到了这个阶段，团队经常还在说“只是多几个需求”，但项目性质其实已经变了。

AI项目为什么特别容易“长需求”？

传统软件项目当然也会遇到需求蔓延，但AI项目更容易出现这个问题。一个重要原因是，大模型给人的感觉太“通用”了。

如果做的是传统ERP模块，大家通常知道库存、采购、财务各自有边界；但面对大模型，一个聊天框似乎可以回答问题、查数据、写报告、调接口、做分析、跑流程。技术能力看起来是连续的，于是业务需求也很容易被理解成连续的。

另一个原因是，AI的Demo特别擅长激发需求。一个20分钟的演示，很容易让现场不同部门都开始联想到自己的问题。演示越成功，新增想法反而越多。

还有一个更现实的原因：AI应用真正落地后，必然会碰到数据、权限、系统接口、业务规则和验收标准。很多一开始被理解成“AI能力”的需求，做到后面才发现其实是系统工程。于是项目不断把新的依赖吸进来。

所以，AI项目需求越做越多，并不一定说明客户“需求管理差”。很多时候，这是从概念验证走向生产系统必然暴露出的复杂度。问题不在于需求会不会增加，而在于团队有没有能力对新增需求重新分类。

我现在最想先做的，不是“砍需求”，而是把需求分层

需求一多，最容易犯的错误就是两种极端：要么什么都答应，先做再说；要么为了控范围，一律回答“不在一期”。前者容易失控，后者又容易把真正影响上线的必要需求挡掉。

更有效的做法，是先承认需求有不同性质。

这张表看起来很简单，但它会逼着项目组回答一个关键问题：新增需求是在补齐原来的业务闭环，还是已经在创造一个新的业务闭环？

如果是前者，可能必须做；如果是后者，就应该重新估算预算、周期和验收，而不是继续塞进原来的计划里。

最容易让项目失控的，是“顺手加一点”

我见过最典型的范围失控，不是一次性加了几十个功能，而是每次会议只多一点点。

智能问数加一个模板报告，看起来只是多一个输出方式；报告再加自动解读，好像也合理；有了解读，再加异常预警；有了预警，再接消息推送；消息推送之后，业务又希望能够自动触发流程。每一步单看都不夸张，但五步叠加以后，项目已经从“问数”变成了“分析+预警+流程自动化”。

真正危险的是，这种变化很少会触发正式的范围重估。因为每一次都太小，大家容易觉得不值得重新谈合同、工期或者资源。最后却是几十个“小需求”一起吞掉了项目缓冲。

所以我现在更关注累计变化，而不是单次变化。一个新增需求只需要3天，不代表十个这样的需求还是“顺手”。

如果需求一直在涨，项目通常会出现几个很明显的信号

第一个信号，是需求列表在变长，但核心验收标准没有变得更清楚。项目组每天都在增加功能，却越来越难回答“上线以后怎样算成功”。这通常说明大家已经从解决业务问题，转向堆功能。

第二个信号，是新增需求开始跨越原来的技术边界。原本只是知识问答，后来开始涉及结构化数据分析；原本只读数据，后来要求写回业务系统；原本是辅助决策，后来要求自动执行。每跨一层，风险、权限、测试和责任边界都会改变。

第三个信号，是排期看起来一直没变，但项目组开始靠加班“消化需求”。这是最容易被忽略的风险。需求增加而时间不变，最后一定会在测试、评测、文档、稳定性或者异常场景上还债。

第四个信号，是每次评审都在讨论“还能不能再加”，却很少讨论“哪些可以不做”。一个项目没有退出机制，通常也就没有真正的优先级。

我更愿意冻结的，不是需求清单，而是业务闭环

很多项目为了控范围，会在启动时做一版非常详细的需求清单，然后要求“冻结需求”。这在AI项目里往往并不现实，因为模型效果、数据情况和用户反馈会不断暴露新问题。完全不允许变化，反而可能让项目做出一个按清单完成、但并不好用的系统。

所以我更倾向于冻结四样东西：核心用户是谁、要解决的业务问题是什么、必须打通的业务闭环是什么、最后用什么指标验收。

只要这四件事不变，具体实现方式可以迭代；如果其中任何一件发生变化，就应该把它当成范围变更，而不是普通优化。

比如，一个项目的目标是“让经营人员能够用自然语言查询已经定义好的80个核心指标，并得到可解释结果”。在这个闭环里，补充指标别名、优化追问、增加权限校验，都属于把原来的场景做完整。

但如果中途增加“自动生成经营分析报告”“自动预测下个月趋势”“自动给出经营建议并推送到负责人”，这已经是新的能力边界。哪怕技术上可以复用同一套模型，也不应该假装它还是原来的需求。

一个能按时交付的AI项目，往往主动放弃了不少“看起来很酷”的东西

这件事有时候很反直觉。大家容易把“需求多、能力全”理解成项目价值高，但企业AI真正的价值不是展示了多少能力，而是有没有一个场景稳定跑进业务。

一期项目里，我宁愿看到一个场景从数据、权限、交互到验收完整闭环，也不太希望看到五个场景各做了60%。前者上线以后能积累真实使用数据，后者往往只能继续停留在演示状态。

尤其是在第一批AI项目里，主动不做什么，其实比决定做什么更重要。因为企业最缺的不是更多AI想法，而是第一个被业务真正接受、能够持续使用的成功闭环。

当然，AI项目也不能把“控需求”变成拒绝变化

AI和传统软件最大的不同之一，就是很多效果只有用真实数据、真实用户跑起来以后才能看见。过程中出现新增需求，本身并不是坏事，有些甚至是生产化必须补上的。

所以范围管理不是把项目变成一份不能动的合同清单，而是要有一个明确的变化机制：什么属于原目标内优化，什么属于范围扩展；新增内容需要多少工作量，会挤掉什么；如果必须增加，预算、工期、验收是否同步调整。

只有这样，团队才能既保留AI项目必要的探索空间，又不让探索无限侵蚀交付。

最后，我会用一个问题判断项目是不是已经偏了

每次需求评审，如果大家又提出了几个“很有价值”的新功能，我会重新问一句：如果这个功能不做，原来那个业务闭环还能不能上线、还能不能被用户使用？

如果答案是“能”，那它大概率不是一期必须项；如果答案是“不能”，再继续判断它到底是在补齐原需求，还是说明原来的项目边界定义错了。

企业AI项目不是需求越多越先进，也不是功能越全越成功。真正成熟的项目管理，是让每一次需求增加都对应明确的价值、成本和取舍。

否则，项目最容易出现的一种结局就是：大家一路都在说“这个也很重要”，最后每个功能都做了一点，却没有一个场景真正交付。

关注「凯哥谈企业 AI」

用真实项目经验，聊透企业AI怎么选、怎么建、怎么落地。