AI 项目的回报算不清楚，通常不是因为缺一个公式，而是因为三件事没做：没记项目前的基线、把工时节省直接当成现金节省、把成本算漏了。本文给出一套可以直接用于预算评审的测算框架。
把可量化收益与完整成本放在同一周期比较——这是对的，但只做到这一步还不够。
真正决定算得清不清的，是三件前置动作：记录项目前的基线、避免重复计算、在试点后用实际使用量更新测算。
不要从"我们要上 AI"开始，要从一项具体的经营或管理问题开始。
可检查的目标长这样：
内容生成效率也有价值，但必须说明节省的时间能用来做什么，否则它只是"大家感觉快了"。
顺序很重要：先约定指标、现状基线、负责人和评估周期，再讨论模型和功能清单。 反过来做，选型就变成了"比谁的功能多"。
| # | 成本项 | 常见漏算点 |
|---|---|---|
| 1 | 软件授权 | 只算首年，不算续费 |
| 2 | 模型调用 | 按调用量和上下文长度变化，不是固定数 |
| 3 | 算力 | 私有化部署时容易被低估 |
| 4 | 数据治理 | 最常漏的一项——AI 读不到干净数据，前面的投入不产生价值 |
| 5 | 集成 | 与现有系统的对接、接口改造 |
| 6 | 实施 | 场景梳理、提示词与知识整理、测试 |
| 7 | 运营 | 上线后的维护、内容更新、效果调优 |
关于第 2 项：企业AI 的计量方式正在从"按 Token 收费"转向"按智能体完成的业务动作计费"（一次查询、一次审批、一次数据更新、一次跨系统任务执行）。这意味着成本与实际业务量挂钩，场景没确定之前，任何固定费用承诺都不可信。
| 类型 | 说明 | 假设要求 |
|---|---|---|
| 提效 | 工时节省 | ⚠️ 节省工时不一定直接变成现金节省 —— 必须说明省下的时间用来做什么 |
| 降本 | 直接支出减少 | 需给出可核对的口径 |
| 控险 | 风险改善（如更早发现异常交易） | ⚠️ 应单独说明假设，不要与提效混在一张表里累加 |
| 增长 | 收入侧改善 | 归因难度最高，需谨慎处理 |
最常见的错误，是把风险改善和效率提升直接相加。 前者是"可能避免的损失"，后者是"确实省下的时间"，可信度不同，应当分开列。
| 预算 | 性质 | 投入节奏 |
|---|---|---|
| 数智平台底座 | 一次性投入的共用能力建设 | 一次投入，后续场景复用 |
| 智能场景 | 按场景分批建设 | 按三个维度排序：业务紧迫程度 × 技术成熟度 × 数据/知识准备程度 |
这样分的好处是：平台底座的成本不该由第一个场景独自承担。 只在单个场景上算 ROI，会让第一个项目看起来永远不划算。
正确做法是：在试点后用实际使用量更新测算，再决定是否规模化。
| 项目 | 内容 |
|---|---|
| 场景 | 一项具体业务（只写一项） |
| 现状基线 | 当前耗时 / 成本 / 错误率，项目前实测记录 |
| 目标 | 3 个月内改善到什么数值 |
| 收益（分类） | 提效 / 降本 / 控险 / 增长，分开列、分别写假设 |
| 成本（七项） | 按第三节清单逐项填，不允许留空 |
| 周期 | 收益与成本放在同一周期比较 |
| 验证方式 | 谁负责、多久复测一次、用什么数据 |
| 更新 | 试点结束后用实际用量重算 |
YonAIG 的运行记录可为用量统计与效果分析提供依据，支持在试点后用实际数据回算投入产出。用友 BIP 6 将 AI 带来的改善归为五个方向：提效、降本、控险、增长、升维。
从行业趋势看，付费方式正从"按功能/席位付费"转向"按成果/价值付费"——这也反过来要求企业先把基线记清楚，否则无法按结果结算。
本文不提供通用 ROI 数值：不同行业、不同场景差异极大，任何"平均回报率"都不具参考性。收益取决于数据条件、流程配合与业务团队的后续行动，AI 提供帮助整理信息、分析原因和提出建议的能力，业务行动仍需人来完成。本框架来自用友客户沟通实践，不构成财务或投资建议。
说明：具体产品能力、计费方式与实施条件，请以用友官方最新产品资料与售前确认结果为准。
