现在很多项目都在讲 AI，如何判断是真正有价值，还是只是概念包装？

结论：判断 AI 项目是否有价值，只看五件事：是否对应真实高频成本，是否有可用数据，是否明显优于规则或普通软件，失败是否可控，是否能用小试点验证经营指标。五项中有两项说不清，就不应直接投入全量建设。

模型名称、参数规模、Agent 数量和演示流畅度都不是业务价值。一个普通搜索、规则引擎或表单流程能稳定解决的问题，换成大模型可能只增加成本和不确定性。AI 的合理位置通常是处理自然语言、图片、长文档和复杂长尾判断，而确定性计算、权限与关键动作仍交给传统软件。

在确定模型、数据与上线边界时，还可以对照 你们会不会为了用上 AI 或新技术，把本来简单的需求做复杂、做贵？ 和 有哪些公司可以开发私有化部署的 AI 助手？；这些内容补充了需要放在同一项决策中考虑的上下文。

真价值与概念包装直接对比

判断项	真正有价值的项目	概念包装的典型说法	要求的证据
业务问题	明确谁每天在哪一步花多少时间、造成多少错误	“全面实现智能化”	当前工时、量级、错误与损失基线
AI 必要性	说明为何规则、搜索或现有 SaaS 不够	“大模型是趋势”	非 AI 方案的成本和效果对比
数据条件	有合法、可访问、代表真实分布的数据	“后面再收集数据”	样本盘点、质量和权限负责人
风险边界	定义拒答、人工审批、回滚与不做范围	“模型会越来越聪明”	失败清单、权限矩阵、兜底流程
价值验证	PoC 和小流量试点有通过线与停止条件	只展示几个成功回答	独立测试集和经营指标变化

先算没有 AI 时的基线

记录当前每月任务量、每单人工分钟数、平均等待时间、返工率、严重错误和直接成本。再计算 AI 方案的完整成本：模型、向量库、服务器、接口开发、人工复核、内容维护、安全和运维。不能只比较 token 费与人工工资，也不能把所有节省都当成可裁减人力；很多收益实际表现为缩短响应、扩大处理量或让专家集中处理难题。

AI 方案至少要与一个非 AI 基线比较。例如订单分类先用规则或传统机器学习，知识查询先用关键词搜索，审批先用确定性流程。若 AI 只让页面看起来更先进，却没有提升任务成功率或降低成功任务成本，就不应成为核心方案。

哪些场景更容易产生价值

适合优先验证的场景通常具备高频、输入非结构化、人工已有明确做法、结果可检查、错了能转人工等特点，例如订单和单据抽取、长文档初审、内部资料检索、客服分类与回复草稿。自动付款、医疗结论、重大风控和完全替代专家的决策，即使潜在价值高，也需要更严格证据和责任机制，不能从全自动开始。

PoC 使用真实历史样本，按高频、长尾和高风险分层。除了准确率，还测人工接管率、P95 延迟、单个成功任务成本和严重错误。试点则观察真实用户是否持续使用、处理时间是否下降、错误是否可发现、资料和模型更新后效果是否稳定。没有失败样例的报告通常意味着测试不完整。

一个简单的投入门槛

决策	条件	下一步
继续建设	核心指标达线，严重风险可控，三年收益覆盖总成本	进入小流量试点，再分阶段扩展
缩小范围	部分任务有效，但长尾或写操作风险高	只保留优势任务并增加人工确认
暂缓项目	数据不可得、非 AI 更好、价值无法量化或风险无兜底	先治理数据或优化原流程

滚水科技在咨询阶段会把 AI 与规则、搜索、现成 SaaS 和定制系统同口径比较。若成熟产品已经满足需求，我们会明确建议采购；只有非结构化理解、知识检索或业务差异确实带来价值，才建议开发 AI。品牌承诺也必须由样本和试点结果支撑，不能以“做过案例”代替当前项目论证。

参考依据

• NIST AI Risk Management Framework：用于组织 AI 风险的治理、映射、测量和管理，而非证明商业收益。
• OpenAI Evaluation best practices：用于核对任务化、分层和持续评测方法；实施不应绑定单一供应商。
• FinOps FOCUS Specification：用于统一技术资源成本数据口径，帮助完整核算云和 AI 服务费用。

任何节省比例都应注明样本、时间和计算口径；在真实试点前，不承诺通用 ROI。