经营数据分析

"这个月华东掉了 12%"——业务方看到这个数之后真正想知道的是原因，以及现在该做什么。但常规流程是：提需求、排期、等数、拿到一张图、发现图回答不了问题、再提一次需求。等第二轮数据到手，决策窗口已经过了。

另一个老问题是口径。同一个"活跃用户"，运营按登录算、产品按产生关键行为算、财务按付费算。三方各拿一个数上会，前半小时都在对口径。

先做一件看着琐碎但决定成败的事：把指标定义、统计周期、对比基准、排除规则整理成文档，导入通用知识库。分析链路在取数前先检索这份定义，而不是让模型自己猜"活跃"指什么。

这一步做不做，直接决定后面所有分析是不是同一套口径。省掉它，你会得到一堆跑得很快但互相对不上的数。

工作流里用数据库节点连业务库，配置 SELECT 查询，条件用 {{变量}} 引用开始节点入参。

数据库节点本身只支持 SELECT，平台文档也建议用只读账号连接。对于要接生产库的分析场景，这一点值得向 DBA 和安全团队明确说明：分析链路在机制上不具备写库能力，不存在"AI 误改生产数据"这条风险路径。这通常是内部评审能不能过的关键。

查询结果（outputList）送进代码执行节点：处理缺失与异常值，按维度拆解，算同比、环比、贡献度。统计逻辑以代码形式固定，同一份数据每次跑出来一致，也方便被评审和复用。

算好的数值再送进 LLM 节点，让它做三件事：指出哪个维度贡献了主要变化、给出可能原因、说明验证这些原因还需要看什么数据。模型不碰计算，只把数字翻译成业务语言和下一步动作。

这个分工不是保守，是因为业务分析的结论要拿去做决策。一个算错的数配上一段流畅的解释，比没有分析更危险。

经营日报、周报这类固定节奏的分析交给定时任务，按天或按周自动跑，产物写入云盘。

与传统报表的区别在于：业务方看完想追问细节时，可以直接在 Cowork 里接着对话——数据链路还在，上下文还在。分析是活的，不是一张发出去就结束的静态图。