企业 AI 项目 ROI：一套可复盘的测算框架

ROI 不是项目结束时补的一张表

不少企业在 AI 项目立项时讨论模型、供应商和预算，验收时却只能展示几段对话、几张界面和一次效果不错的演示。问题不一定是项目没有价值，而是团队从一开始就没有约定：价值由什么指标体现、原来的基线是多少、成本算到哪一层、观察多久才算有效。

企业 AI 项目 ROI 应当是贯穿立项、试点和运营的管理框架。它既回答“值不值得做”，也回答“下一轮预算应该投在哪里”。最简单的表达是收益与成本的比较，但在真实项目中，收益和成本都必须被拆开，否则一个漂亮的百分比很容易掩盖口径差异。

先把收益拆成四本账

第一本是效率账。记录完成同一任务所需的人时、等待时间、返工次数和吞吐量。例如客服辅助不是只看回答快不快，还要看平均处理时长、首次响应、一次解决率以及转人工比例。节省时间只有在被释放到更高价值工作，或确实减少外包和加班时，才更接近财务收益。

第二本是质量账。AI 可能减少漏检、格式错误和知识口径不一致，也可能引入幻觉和新的复核成本。质量收益要同时记录正确率、返工率、投诉率和人工抽检结果，不能只挑模型表现最好的样本。

第三本是增长账。销售线索增加、转化周期缩短、客单价变化和复购提升都可以纳入，但必须建立可比较的对照。若同期还调整了价格、渠道和促销，就不能把全部增量归给 AI。可以采用分组试点、分阶段上线或前后同期对比，降低归因偏差。

第四本是风险账。合同审查、合规检查、设备预警等场景的价值常表现为损失概率下降。此类收益不宜包装成已经发生的收入，更适合记录风险事件数量、人工发现率、平均处置时间和潜在损失区间。

TCO 要覆盖看不见的长期成本

只把模型调用费算作成本，会系统性低估项目投入。总拥有成本（TCO）至少包括数据整理与标注、产品与开发、系统集成、模型或 API、算力和存储、安全合规、评测、培训、运营维护，以及业务人员参与试点的时间。

还要区分一次性成本与持续成本。知识库初次清洗属于一次性投入，但新增文档审核、权限维护、提示词和评测集回归属于持续投入。随着使用量扩大，请求量、日志量、失败重试和人工复核也会增长。试点阶段便宜，不等于规模化之后仍然便宜。

建议同时保留三个结果：净收益等于总收益减总成本；收益成本比等于总收益除以总成本；回收期表示累计净收益何时覆盖初始投入。三者一起看，才能避免不同团队都说“ROI”，实际算的却不是同一件事。

用基线、目标和护栏组成指标卡

每个核心指标都要写清五项信息：定义、数据来源、试点前基线、目标区间、观察周期。例如“处理时长降低”必须说明从接单到关闭还是从首次回复到关闭，是否排除异常工单，按平均值还是中位数计算。

除业务目标外，还要设置护栏指标。客服效率提升不能以投诉增加为代价；内容产量增长不能以事实错误为代价；销售预测更快不能导致库存波动扩大。护栏决定项目是否可以扩容，而不是在出事后才补救。

本地知识资料中的“首次响应从 5 分钟缩短到 30 秒”“处理时长降低 20%”属于计算示例，不是通用承诺。正式方案应使用企业自己的历史数据建立基线，再通过真实样本验证。

让 ROI 成为每轮迭代的决策依据

立项时先选高价值、低复杂度且结果可测的场景；试点时记录模型效果和完整流程数据；验收时同时看业务指标、护栏与 TCO；上线后按月复盘使用率、单位成本和效果漂移。若项目没有形成稳定使用，即使单次效果很好，也不应提前宣告成功。

今天可以先做一张一页纸指标卡：写下一个业务问题、三项收益指标、两项风险护栏、完整成本清单和一个退出条件。只有当这些口径得到业务、财务和技术共同确认，企业 AI 项目 ROI 才从汇报语言变成可复盘的投资纪律。

本文依据本地知识库《AI 项目 ROI》《AI 项目实施方法》整理；其中示例数字仅用于说明测算方法，不构成收益承诺。