"按地区和产品查看各季度销售额",业务人员说起来只要一句话,落到数据透视表却要决定行字段、列字段、值字段、汇总方式和日期分组。SpreadJS 19.1 AI 插件可以把自然语言转换为候选字段布局,但布局能否回答业务问题,仍要由人检查。
难点不是拖拽,而是把问题翻译成布局
一张销售明细表包含日期、地区、产品、销售员和销售额。传统做法是打开字段面板,把地区、产品拖到行区域,把日期放到列区域并按季度分组,再把销售额放到值区域并选择求和。熟悉数据透视表的人很快,偶尔分析数据的业务人员却容易卡在几个地方:维度和度量如何区分,日期应按月还是季度展开,销售额应该求和还是计数,以及两个行字段谁在外层。
自然语言入口降低了操作门槛。用户可以直接描述:"按地区和产品查看各季度销售额,地区放在行区域,季度放在列区域,销售额按求和汇总。"AI 根据字段名称和上下文生成布局,使用者再检查并调整。这里生成的是候选分析视图,不是经过认证的经营结论。

运行链路中,谁负责什么
SpreadJS 核心运行时承载浏览器中的工作簿和工作表;Pivot 插件创建并计算数据透视表;PivotPanel 提供字段选择和布局操作界面;AI 插件为面板增加自然语言布局生成、布局建议和结果分析能力。模型连接应通过企业后端代理,由后端处理密钥、鉴权、脱敏、限流和日志。
AI Agent、AI 插件与 MCP 不能混为一谈。AI Agent 面向跨工具任务编排,不是本文运行链路的一部分;AI 插件直接扩展 SpreadJS 界面能力;MCP 仅用于开发阶段查询官方文档和 API,也不会进入用户打开页面后的执行链路。
官方 19.1 文档还给出了一条重要边界:当前数据透视表 AI 辅助只支持生成字段布局,也就是维度、度量和小计类型。日期分组、筛选规则、格式、排序以及企业特有指标口径,不能假定模型会一次处理完整。
准备 19.1 依赖与数据源
项目至少需要核心包、Pivot 插件和 AI 插件:
npm install @grapecity-software/spread-sheets@^19.1.0
npm install @grapecity-software/spread-sheets-pivot-addon@^19.1.0
npm install @grapecity-software/spread-sheets-ai-addon@^19.1.0
页面中准备工作簿和透视表面板容器,然后创建销售明细表。生产数据通常来自后端,下面用小数据集说明字段结构:
import * as GC from '@grapecity-software/spread-sheets';
import '@grapecity-software/spread-sheets-pivot-addon';
import '@grapecity-software/spread-sheets-ai-addon';
import '@grapecity-software/spread-sheets/styles/gc.spread.sheets.excel2013white.css';
const spread = new GC.Spread.Sheets.Workbook('ss', { sheetCount: 2 });
const reportSheet = spread.getSheet(0);
const dataSheet = spread.getSheet(1);
reportSheet.name('销售分析');
dataSheet.name('销售明细');
const sales = [
['日期', '地区', '产品', '销售员', '销售额'],
[new Date(2026, 0, 12), '华东', '产品A', '陈琳', 128000],
[new Date(2026, 3, 18), '华东', '产品B', '陈琳', 96000],
[new Date(2026, 6, 9), '华南', '产品A', '周明', 117000]
];
dataSheet.setArray(0, 0, sales);
dataSheet.tables.add('SalesTable', 0, 0, sales.length, sales[0].length);
数据源质量会直接影响布局生成。表头应稳定、唯一且有业务含义;日期必须是真正的日期值,销售额必须是数值;不要用"字段 1"或合并表头让模型猜测。若"销售额"实际含税,还应在产品界面或数据字典中说明,AI 不会凭字段名获知财务制度。
创建可验证的初始透视表
AI 功能依托已有的数据透视表和面板。可以先创建一个空白或基准布局,再允许用户通过自然语言调整。以下代码把字段映射写清楚,也可作为 AI 结果的确定性对照:
const pivotTable = reportSheet.pivotTables.add(
'SalesPivot', 'SalesTable', 1, 1,
GC.Spread.Pivot.PivotTableLayoutType.outline,
GC.Spread.Pivot.PivotTableThemes.light8,
{ bandRows: true, showRowHeader: true, showColumnHeader: true }
);
pivotTable.suspendLayout();
pivotTable.add('地区', '地区', GC.Spread.Pivot.PivotTableFieldType.rowField);
pivotTable.add('产品', '产品', GC.Spread.Pivot.PivotTableFieldType.rowField);
pivotTable.group({
originFieldName: '日期',
dateGroups: [{ by: GC.Pivot.DateGroupType.quarters }]
});
pivotTable.add('季度 (日期)', '季度', GC.Spread.Pivot.PivotTableFieldType.columnField);
pivotTable.add('销售额', '销售额合计',
GC.Spread.Pivot.PivotTableFieldType.valueField,
GC.Pivot.SubtotalType.sum);
pivotTable.resumeLayout();
pivotTable.autoFitColumn();
new GC.Spread.Pivot.PivotPanel(
'salesPivotPanel', pivotTable, document.getElementById('pivot-panel')
);
suspendLayout() 与 resumeLayout() 用于批量调整字段时减少重复布局;add() 指定字段所在区域;group() 把日期按季度分组;值字段明确使用 sum。实际项目必须按真实字段名验证分组后生成的字段名,不能盲目复制示例。
把 AI 服务接到面板,而不是把密钥放进浏览器
官方示例通过 Workbook.injectAI() 注入回调。浏览器只把插件生成的请求交给企业后端,模型密钥留在服务端:
const callAI = async (requestBody) => {
const response = await fetch('/api/spreadjs-ai', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(requestBody)
});
if (response.status === 429) throw new Error('AI 服务繁忙,请稍后重试');
if (!response.ok) throw new Error(`AI 请求失败:${response.status}`);
return response;
};
spread.injectAI(callAI);
用户在面板点击"A"按钮后可输入布局要求;也可以获取三个 AI 布局建议并刷新;不满意时可重置到初始状态。"I"按钮用于针对当前透视结果提问。分析回答仍是模型输出,关键经营数据必须回到明细、透视表汇总和业务口径中核对。

一句话也要说清五个要素
"帮我做个销售透视表"给出的约束太少。更可靠的请求应说明数据范围、行维度、列维度、度量与汇总方式,例如:"基于 SalesTable,按地区和产品查看各季度销售额;地区、产品依次放在行区域,季度放在列区域,销售额按求和汇总。先生成布局,不添加筛选。"
生成后至少检查五项:地区和产品的层级顺序是否正确;季度是否来自日期分组;销售额是否被识别为值字段;汇总类型是否为求和而非计数;总计与小计是否符合报表口径。若要只看已确认订单、排除退款或按财年季度统计,应由应用提供明确规则并单独实现和验证,不能把自然季度和财务季度视为同一概念。
上线前如何验收
先用一组可以手算的小数据验证四个季度与总计,再覆盖空值、重复记录、负数退款、文本金额、无效日期和新增产品。对比明细合计与透视表总计,检查切换布局、重置和刷新建议后是否保持数据完整。模型超时或返回无效内容时,原有透视表和手工字段面板仍应可用。
权限也不能交给前端面板。后端代理应限制用户可发送的数据范围,敏感字段应最小化或脱敏;浏览器中的工作表保护不能代替服务端授权。审计记录至少包含操作者、数据源版本、自然语言请求、应用前后布局和确认结果,但应避免无必要地保存完整业务明细。
把布局当作可管理的业务配置
同一句"季度销售额",在销售部门可能按签单日期统计,在财务部门可能按确认收入日期统计。即使行、列和值区域完全相同,数据源字段不同也会产生不同结论。因此,正式应用不应只保存最终画面,还应给布局附上名称、数据源版本、字段映射、日期口径、汇总类型、创建人和确认状态。经过负责人确认的布局可以作为模板复用,AI 新生成的布局则保持"待确认"状态。
当数据源新增列、字段改名或枚举变化时,系统应提示用户重新验证,而不是静默沿用旧布局。对于月度经营会、预算复盘等重复场景,可以比较本次与上次的布局差异,明确哪些字段被增加、移除或移动。这样既保留自然语言探索的灵活性,也避免每次生成都成为无法追踪的一次性操作。
还要区分"布局正确"和"数据新鲜"。AI 可能准确放置字段,但数据源尚未刷新;透视表结果也可能正确计算了过期数据。验收界面最好同时展示数据更新时间、记录数量和筛选状态,让确认者知道自己正在检查哪一批数据。对外导出或进入审批前,再由后端验证数据版本,避免用户在旧快照上得出新结论。
AI 辅助最适合让不熟悉字段拖拽的用户快速得到候选分析视图,也适合为已有透视结果提供探索性解释。它不替代数据库、指标平台、完整 BI 系统和业务审批,更不意味着模型生成的布局天然正确。真正可靠的方案,是让 AI 缩短"问题到布局"的距离,让 Pivot 插件确定性执行,再由人确认汇总规则和经营含义。
结语
自然语言生成数据透视表的价值,不是省掉几次拖拽,而是让业务问题更快进入可检查的表格结构。只要把 AI 插件、Pivot 运行时、后端代理和人工责任分开,并围绕字段、分组、汇总与口径建立验收闭环,这个入口才能从演示功能变成企业应用中可控的分析助手。