采购AI软件,到底该买软件功能,还是买可验收的业务结果?

合同不能只列一百项功能，也不能只写一句“降本增效”。

做企业AI项目的时候，甲方采购文件里有两类要求，我都很熟悉。第一类列满功能：大模型、知识库、智能问数、Agent、权限管理、日志审计，最好每一项都写“支持”；第二类则干脆把要求写成“提升效率30%”“实现经营分析智能化”“显著降低人工成本”。

前一类看起来容易招标，却可能买回一套功能齐全、业务上不好用的软件；后一类看起来更重视价值，却可能把采购合同变成一份谁都说不清怎么验收的愿望清单。

如果一定要二选一，我不会简单回答“买结果”。我的判断是：企业采购AI，真正应该买的是有明确边界、能通过测试证明的业务能力；经营结果必须评价，但不能把所有不受供应商控制的结果都变成软件公司的履约承诺。

一个容易被忽略的区别：功能、能力和业务结果，不是同一件事

想象一个智能问数项目。采购条款写着“支持自然语言查询”“支持图表生成”“支持数据导出”，供应商全部演示通过了。按功能清单，似乎可以验收。

但业务人员真正会问的是：“上个月各区域采购金额是多少？比去年同期增长了多少？为什么这张报表与你们系统查出来的不一样？”这些问题需要指标口径、时间维度、用户权限、数据来源、查询解释和异常兜底形成完整链路。

功能是系统“有没有这个菜单或按钮”；可验收的业务能力，是指定用户在指定条件下能否完成指定任务；业务结果，则是这个能力上线后，是否真的减少了人工取数、缩短了分析时间，或者改善了决策质量。

买功能，容易只验软件；只买结果，又容易忽略责任边界。采购的关键，是把业务目标翻译成可验证的交付能力。

我为什么越来越反对“功能点越多，采购越稳”

从烟草经营、能源司库大屏到航空物流智能问数这类项目，我参与过的方案工作有一个共同特点：需求往往不是一个孤立的AI功能，而是一段真实业务链路。这里讨论的是我在此类项目中的方案判断，不代表任何客户的具体合同、验收结论或运营成效。

以能源司库大屏为例，甲方真正需要的，往往是经营数据能否在授权范围内被正确理解、查询、展示，并与既有业务系统保持一致。采购文件如果只强调“接入大模型”“支持语音交互”“支持可视化”，却不明确指标含义、数据更新时点和例外处理，功能越多，后续扯皮的空间可能越大。

航空物流或制造场景则更加明显。一条看似简单的业务查询，背后可能跨数据平台、业务系统、组织权限和多套统计规则。技术团队可以证明“自然语言转查询指令”的功能存在，但这距离“业务人员稳定拿到可信答案”还有一段距离。

所以，我不太看重招标文件最后列了多少条“支持”。我更想看：哪些任务是第一期必须完成的？由谁来操作？依赖哪些数据？什么情况算正确，什么情况必须拒答或转人工？出了问题应该定位到哪一层？

采购文件里，我建议把验收分成三层

第一层是产品与交付物：软件模块、版本、账号并发、部署架构、接口文档、知识域或指标数量等，属于“交了什么”。第二层是生产可用性：准确性、权限、可追溯、性能、异常处理和试运行，属于“能不能放心用”。第三层才是业务效果：减少多少重复操作、缩短多少处理时间、业务人员实际使用情况，属于“用了以后有没有价值”。

这三层缺一不可，但不能用同一把尺子、同一张验收单混在一起。尤其是第三层，通常要由业务部门、数据部门、IT和供应商共同定义统计口径，不能只交给软件供应商“包结果”。

以“一期10个经营指标的智能问数”为例，可以这样拆验收对象（方法示例，非实际项目合同）：

交付范围10个指标清单、口径文档、接入范围、权限配置、版本及部署交付物；由双方签字确认交付基线。

业务可用覆盖高频问法和边界问法，核对口径一致性、越权拒答、异常提示、查询溯源及响应时延；用共同确认的题库与数据快照验收。

使用效果记录业务用户能否完成任务、取数耗时及人工复核工作量；业务部门提供原流程基线，双方结合试运行数据复盘。

注意：题库数量、正确率阈值、时延和试运行天数，不应在合同里套用通用模板；必须根据业务风险、场景复杂度和双方确认的测试环境确定。

真正难写的不是“结果”，而是谁对结果负责

假设合同承诺“将经营分析效率提升30%”。这句话很有吸引力，但仔细拆开就会发现一连串问题：原来取数要多久？统计的是全体员工还是试点用户？新的分析流程有没有被业务部门采用？数据源是否按期开放？指标口径是否有人确认？新系统上线后，原有审批和人工复核是否保留？

如果甲方迟迟无法提供合规的数据接口，或者业务部门根本没有安排试用人员，供应商很难单独保证“效率提升30%”；反过来，如果供应商交付的系统总是返回错误口径、频繁超时，也不能把没效果全部归结为“客户没有推广”。

我更倾向于在合同或工作说明书（SOW）里把责任拆开：供应商对产品能力、约定接口实现、实施质量、测试合格和缺陷修复负责；甲方对源数据质量、业务口径确认、系统开放、使用组织和必要的审批配合负责；业务价值指标由双方设定基线、定期评价。确有结果承诺的项目，要同时写清归因规则、前置条件与例外情形。

尤其要小心把“客户上线后持续使用人数”“全年减少多少岗位”“总成本下降多少”直接当成唯一付款条件。它们可以成为项目价值指标，却未必是供应商可单方交付的验收物。

如果让我参加一次AI采购评审，我会重点改这几句话

我不会把“支持智能问数”四个字删掉，但会要求它后面必须跟上范围与证据：支持哪些业务指标，谁来确认口径，测试问题如何抽样，遇到不明确口径是否允许追问，错误答案能不能溯源，权限拦截如何验收。

我也不会简单保留“提升企业决策效率”这种宏大表述，而会改成一个阶段性目标：先让某类用户在固定业务范围内完成原来需要跨系统手工查询的任务；在试运行期记录原流程和新流程的耗时、人工核对次数及用户反馈，再据此决定二期扩展范围。

付款节点同样要跟阶段成果匹配：部署与基础交付、场景验收、试运行缺陷关闭，可以分别对应不同证据；涉及供应商无法控制的经营改善，则宜作为持续优化或另行约定的绩效合作目标，而不是含糊地“一票否决”全部软件款。具体比例和法律条款，应由采购、法务及项目双方依实际合同确定。

最后，我想把这个问题再往前推一步

有时甲方问“买功能还是买结果”，其实真正担心的是：买回去以后没人用；乙方担心的则是：明明按合同交付了，却被一个没有基线的“没有达到预期”无限追责。双方的担心都合理。

解决办法不是把合同写得更漂亮，而是在采购前就把“谁用、用什么数据、完成什么业务动作、按什么证据验收、出了问题谁负责”谈透。业务价值是采购的方向，业务能力是合同的交付对象，生产证据是验收的依据，运营指标则决定下一笔钱该不该继续投。

企业采购AI，不是买一套会演示的功能，也不是买一句无法兑现的ROI承诺，而是买一条能够交付、能够验证、还能持续产生价值的业务闭环。

凯哥谈企业 AI｜从真实企业 AI 项目出发，聊决策、落地与避坑。