经营分析里，门店流水、品类明细往往是成千上万行的长表，而汇报口径要的是「每店一行合计」「每品类一行合计」，甚至整张表只看一共卖了多少钱、有多少单。明细仍要留着核对，汇总结果却必须压成一张短表，再按合计门槛做二次取舍。

如果采用传统手工方式，只能反复拉数据透视表、写 SUMIF 或把小计行复制到新工作表。源表一更新，透视缓存与公式引用全部失效；先汇总再卡「合计超过某门槛」还要再筛一遍，极易改错底稿，也无法沉淀成可回溯、可自动复跑的工作流。

DT-Bot 的 「聚合计算」 算子专为解决此类压行汇总而设计。它对当前工作空间里的一张源表只读扫描，按字段分组或整表收口，写出一张更短的结果表；未点名结果表时，新表名是「源表名_聚合计算」。源表明细一行不删、一列不改。若要把组合计贴回每一行明细，请使用「组内加列」，不要把本算子写成贴列。

一、 核心能力与适用场景

「聚合计算」算子聚焦于把多行压成更少的行，覆盖以下四大核心能力：

核心能力 解决什么业务问题 典型业务场景
按字段分组压行 按一列或多列切开，对合计、平均、计数、最大、最小等度量收成每组一行。 按门店把销售额加总，每店一行；按大区看有多少单并求平均销售额。
整表压成一行 不按维度切开，整张表收成一条总账。 整表看一共卖了多少钱、有多少单，不要再按门店切开。
先汇总再二次计算 先压成短表，再对汇总结果卡门槛或继续加工。 先按品类合计销售额，再只要合计超过某门槛的品类。
计数与多度量同出 同一分组下同时给出行数与平均值等，而不是只留一个合计。 按大区看有多少单，再求平均销售额。

二、 边界指南：它与相近算子有何区别？

在构建数据工作流时，理解算子之间的职责边界至关重要：

比较维度 「聚合计算」算子 「组内加列」算子 「透视反透视」算子 「NP-SQL」算子
主要定位 压行汇总出短表 组合计/占比贴回每一行明细 长表与宽表交叉互换 自然语言或查询出新表，可跨表
输出机制 源表只读，另写短表 默认就地加列，行数不变 源表只读，另写透视/反透视表 源表只读，另写查询结果表
典型动作 按门店加总、整表一条、先汇总再卡门槛 本区合计、组内占比贴到明细行 地区做行、月份做列，金额求和 多表按已确认关系对齐后再汇总
如何选择 “每店一行合计，明细表别动” “明细还在，只要每行带上本组合计” “要交叉宽表，不要分组后列集合不变的短表” “两张表先关联再汇总，单表压行不够”

同比、环比请用「同比环比」。近 N 天合计请用「累计统计」。

三、 提示词编写规范与公式

「聚合计算」算子支持自然语言直接表达，建议遵循以下标准的三要素编写公式：

【目标表】 + 【怎么压：分组列与合计/平均/计数/最大/最小】 + 【结果表名（可选）】

1. 目标表范围表达

  • 单表精准点名：明确指定要汇总的表，例如 “销售明细” ：...；
  • 默认当前流转表：若提示词中未显式提及表名，算子将默认继承上一节点连线流入的数据表。

2. 怎么压

  • 分组压行：按 “门店” 把 “销售额” 加总、按 “大区” 看有多少单，再求平均销售额；
  • 整表一条：全表把 “销售额” 加总，不要再按门店切开；
  • 先汇总再二次计算：先点名结果表，再对这张短表卡门槛，例如 先按品类合计销售额，结果表叫 品类销售；再对 品类销售 只要合计超过 400 的品类。

3. 结果表名

  • 显式命名：输出 “门店销售”、结果表叫 品类销售；
  • 未点名时：新表名是「源表名_聚合计算」。源表始终只读，不会被这张短表覆盖。
“销售明细” ：按 “门店” 把 “销售额” 加总，输出 “门店销售”。

四、 核心功能与图解实战

以下结合真实企业数据场景，展示「聚合计算」在不同需求下的处理效果：

场景 1：按一列分组压行（每店一行合计）

业务背景：零售运营要把四行、两家门店的销售明细压成「每店一个合计」，用于门店排名会。明细底稿必须原样保留，供财务抽查品类构成。

【处理前：销售明细】

门店 品类 销售额
东门店 饮料 100
东门店 零食 80
西门店 饮料 50
西门店 零食 70

【执行提示词】

“销售明细” ：按 “门店” 把 “销售额” 加总，输出 “门店销售”。

【处理后：门店销售（新短表）】

门店 销售额_合计 变更说明
东门店 180 100 + 80，两行压成一行
西门店 120 50 + 70，两行压成一行

逻辑详解：源表「销售明细」四行原样只读；结果表按提示词命名为「门店销售」，行数从 4 压到 2。合计列名为「销售额_合计」。本算子不会把 180、120 写回明细的每一行——那是「组内加列」的职责。

场景 2：整表压成一行（不再按门店切开）

业务背景：店长会只要一个全渠道销售总额，不要按门店切开的对照表。分析师必须明确写出「不要再按门店切开」，避免引擎仍按门店分组。

【处理前：销售明细】

门店 销售额
东门店 100
东门店 80
西门店 50

【执行提示词】

“销售明细” ：全表把 “销售额” 加总，不要再按门店切开。

【处理后：销售明细_聚合计算（新短表）】

销售额_合计 变更说明
230 100 + 80 + 50，整表收成一行

逻辑详解：提示词未点名结果表，新表名为「销售明细_聚合计算」。源表三行仍在；短表只有合计一列、一行。若漏写「不要再按门店切开」，则会走分组压行，而不是整表一条。

场景 3：先汇总再卡门槛（短表上的二次计算）

业务背景：品类经营只要「合计超过 400」的重点品类。必须先按品类压成短表，再在汇总结果上卡门槛；不能在明细行上用单笔 410 误判「日用过线、零食没过线」。

【处理前：销售明细】

品类 销售额
饮料 300
饮料 220
零食 150
零食 40
日用 410

【执行提示词】

“销售明细” ：先按品类合计销售额，结果表叫 品类销售；再对 品类销售 只要合计超过 400 的品类。

【处理后：品类销售（聚合后的短表）】

品类 销售额_合计 变更说明
饮料 520 300 + 220
零食 190 150 + 40
日用 410 单行 410

【再筛之后：品类销售】

品类 销售额_合计 变更说明
饮料 520 合计 520，超过 400，保留
日用 410 合计 410，超过 400，保留

逻辑详解：第一步由「聚合计算」写出「品类销售」三行；第二步「只要合计超过 400」是在短表上的二次裁剪（零食 190 被去掉）。源表明细五行动都只读。单笔日用 410 能留下，是因为它的合计过线，不是因为明细里碰巧有一笔大单。

场景 4：计数与平均同出

业务背景：大区复盘既要看「有多少单」，也要看平均销售额，不能只留一个加总。

【处理前：销售明细】

大区 销售额
华东 100
华东 200
华北 50

【执行提示词】

“销售明细” ：按 “大区” 看有多少单，再求平均销售额。

【处理后：销售明细_聚合计算（新短表）】

大区 行数 销售额_平均 变更说明
华东 2 150 两单，(100 + 200) ÷ 2 = 150
华北 1 50 一单，平均即自身

逻辑详解：未点名结果表，新表名为「销售明细_聚合计算」。计数列名为「行数」，平均列名为「销售额_平均」。源表三行只读，短表按大区压成两行。

五、 常见问题与操作贴士（FAQ）

Q1：为什么执行后左侧多了一张短表，源表明细还在？

答：这是「聚合计算」的核心设计。它把多行压成更少的行，必须另写结果表，否则会毁掉核对用的明细底稿。未点名时新表名是「源表名_聚合计算」。源表始终只读。

Q2：我想把部门合计写回每一行明细，该用本算子吗？

答：不要用本算子。本算子会丢掉明细行，只留每组一行。把组合计、平均或占比贴回每一行、且行数不变，请使用 「组内加列」。

Q3：未写结果表名时，新表叫什么？合计列叫什么？

答：未点名结果表时，新表名是「源表名_聚合计算」。原文案例里，加总得到「销售额_合计」，计数得到「行数」，平均得到「销售额_平均」。不要另行臆造列名。

Q4：同比、近 N 天、交叉宽表，为什么不能写在本算子里？

答：职责已经切开：日历对齐的同比/环比用「同比环比」；沿日期的近 N 天与累计用「累计统计」；地区做行、月份做列的交叉表用「透视反透视」；多表先关联再汇总用「NP-SQL」。本算子只做单表压行汇总。

六、 关联算子导航