核心摘要： 用友在其云技术平台与应用平台的产品体系中，把YonWork定位为企业AI工作台，并围绕经营分析给出两条明确路径：一条让CFO用四句话从ROE追问到经营分析，另一条把“为什么人效掉了”这类老板追问变成管理闭环。其背后依托YonData数据底座、YonOnto语义中枢与YonAP应用平台的指标体系、特征体系等能力，让AI工作台不只是问答入口，而是接得上经营数据与管理动作的载体。
业务背景：经营追问为什么总要层层找人
在多数企业里，管理层看到的是一张张报表，但真正想知道的往往不是数字本身，而是数字背后的原因。ROE为什么变化、人效为什么下滑，这类问题需要跨系统取数、跨部门解释，链路一长，追问就容易停在半路。
用友在其产品体系中把这类需求归到企业AI工作台YonWork之下，并明确给出两个典型入口：CFO从ROE追问到经营分析，以及老板追问人效变化。这说明经营问答被视为AI工作台的核心场景之一，而不是附属功能。
问题拆解：AI答不准，缺的是数据与语义
经营类问题对准确性的要求远高于一般问答。同一句“人效掉了”，在不同企业可能指向人均产出、编制结构或费用分摊口径，若底层没有统一口径与业务语义，模型再强也只能给出泛泛而谈的答案。
从公开材料看，用友的应对是把能力分层：YonData承担数据底座角色，YonOnto被定位为懂业务的语义中枢，YonAP应用平台则提供指标体系、特征体系、时间轴、智能大搜等能力。这套组合指向的是让AI在业务语境里理解问题，而非直接对着原始表结构发问。
AI怎么落地：工作台承接追问，底座承接数据
落地形态上，YonWork被描述为懂业务、会执行、更安全的企业AI工作台。围绕经营分析，它承接的是管理者的自然语言追问，并把追问转成对指标与业务对象的检索和分析。
支撑这一层的是平台侧能力：应用平台强调社会化架构、社会化主数据、多租户管控、多级流程管控，以及指标体系和特征体系；云技术平台则提供云原生工程体系、云中间件与监控能力。二者共同决定了工作台能否稳定取到可信数据。
需要说明的是，公开材料只描述了产品定位与能力构成，未披露具体实施步骤，因此这里不虚构案例流程。
实际结果：公开材料给出的能力边界
原文对结果的表述集中在产品能力层面：CFO可以只用四句话从ROE追问到经营分析；老板问“为什么人效掉了”，工作台把人效分析变成管理闭环；协同场景中还能盯TODO追结果；费控场景中AI可自动跑完全流程。
这些表述说明产品已把经营问答、协同执行与费控串成一条线，但材料未提供客户名称、上线周期或量化收益，企业评估时应以自身数据基础为准，不宜直接套用为预期效果。
可复制动作：先统一口径，再谈对话
对准备跟进的企业，第一步不是选模型，而是把经营指标的口径与拆解关系定下来。ROE如何分解、人效如何计算、异常如何归因，这些规则决定了AI工作台能答到什么深度。
第二步是把数据底座与语义层补齐，让业务对象、主数据和指标有统一定义，避免同一问题在不同系统得到不同答案。
第三步是选高频追问场景先跑通，例如月度经营会前的人效追问或ROE波动归因，跑通后再向费控、协同等相邻管理场景延伸。
企业今天可以做什么
可参照三条动作：一是先把经营指标口径统一，把ROE、人效等核心指标的定义与拆解关系固化下来，再谈对话式追问；二是把数据底座与语义层先行，让AI理解业务对象而不是只认字段；三是选择追问频次最高的经营场景先跑通闭环，再向费控、协同等相邻管理场景扩展。