"帮我汇总华东区已审批的差旅费。"业务人员能说清需求，却不一定能立刻写出 SUMIFS。SpreadJS 19.1 AI 插件可以把这句话转换成候选公式，也能解释复杂公式。但 AI 负责降低门槛，SpreadJS 负责执行，最终结果仍要由人核对范围和业务口径。
为什么公式适合 AI 辅助，却不适合盲目自动化
Excel 公式的门槛通常不在输入等号，而在于把业务语言翻译成准确的函数、条件和引用。财务人员知道"只汇总华东区已审批的差旅费"，却未必能迅速写出多条件公式；开发者熟悉 JavaScript，但可能不了解当前模板应该使用结构化引用还是普通区域引用。复杂公式还会嵌套 IF、LET、查找和错误处理，接手旧模板的人很难一次读懂。
AI 可以缩短这段翻译过程，但模型不知道企业全部规则。"本月"按申请日期、入账日期还是付款日期？"销售额"是否含税？空值按零处理还是提示缺失？如果提示词没有说明，模型可能返回语法正确但口径错误的公式。因此合理流程应是"自然语言需求、候选公式、人工检查、应用到活动单元格、样例验证"，而不是让模型直接批量覆盖工作簿。
五个组件各自负责什么
SpreadJS 核心运行时负责工作簿、工作表、单元格、公式存储和计算。公式编辑器面板来自 @grapecity-software/spread-sheets-formula-panel，为复杂公式提供独立编辑界面。AI 插件来自 @grapecity-software/spread-sheets-ai-addon，为公式编辑器增加自然语言生成与解释能力，并利用当前工作表上下文组织请求。
| 层级 | 主要职责 | 明确边界 |
|---|---|---|
| SpreadJS 核心运行时 | 保存、解析和计算公式 | 不理解企业业务语言 |
| FormulaPanel | 展示、格式化、编辑并提交公式 | 不提供模型服务 |
| AI 插件 | 组织表格上下文并连接 AI 服务 | 不保证业务口径正确 |
| 企业后端代理 | 鉴权、脱敏、密钥、限流和日志 | 不替代结果验收 |
| 使用者 | 确认范围、条件、口径和结果 | 不能把责任全部交给模型 |
AI Agent 是独立的任务编排项目；MCP 用于开发阶段检索官方文档和 API。本文讨论 AI 插件中的公式辅助能力，不使用 AI Agent 或 MCP 来证明运行时功能。
安装 19.1 模块
npm install @grapecity-software/spread-sheets@^19.1.0
npm install @grapecity-software/spread-sheets-formula-panel@^19.1.0
npm install @grapecity-software/spread-sheets-ai-addon@^19.1.0页面准备工作簿、公式编辑器和应用按钮：
<div id="ss" style="width:100%;height:420px"></div>
<div id="formula-editor" style="width:100%;height:220px"></div>
<button id="apply-formula">应用公式</button>建立工作簿并接入公式编辑器
import * as GC from '@grapecity-software/spread-sheets';
import '@grapecity-software/spread-sheets/styles/gc.spread.sheets.excel2013white.css';
import '@grapecity-software/spread-sheets-formula-panel';
import '@grapecity-software/spread-sheets-ai-addon';
const workbook = new GC.Spread.Sheets.Workbook('ss', { sheetCount: 1 });
const sheet = workbook.getActiveSheet();
sheet.name('费用明细');
sheet.setArray(0, 0, [
['部门', '费用类型', '金额', '状态'],
['华东区', '差旅费', 3200, '已审批'],
['华东区', '招待费', 1800, '已审批'],
['华南区', '差旅费', 2600, '待审批']
]);
const editor = new GC.Spread.Sheets.FormulaPanel.FormulaEditor(
document.getElementById('formula-editor'),
{ formatWidthLimit: -1, tabSize: 2 }
);
editor.attach(workbook);
document.getElementById('apply-formula').addEventListener('click', () => {
editor.commandManager().execute({ cmd: 'commitContentToActiveCell' });
});attach(workbook) 把编辑器绑定到工作簿。用户确认后，commitContentToActiveCell 将编辑器内容提交到当前活动单元格。提交只是写入工作簿，并不证明公式已经通过业务验证。
通过后端代理注入 AI 服务
官方文档支持通过 Workbook.injectAI() 注入回调。生产环境应使用后端代理，避免模型密钥暴露在浏览器：
const callAIThroughBackend = async (requestBody) => {
const response = await fetch('/api/spreadjs-ai', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-Request-ID': crypto.randomUUID()
},
body: JSON.stringify(requestBody)
});
if (response.status === 429) throw new Error('AI 服务繁忙，请稍后重试');
if (!response.ok) throw new Error(`AI 请求失败：${response.status}`);
return response;
};
workbook.injectAI(callAIThroughBackend);后端应完成用户鉴权、请求大小限制、敏感字段清理、模型路由、超时、日志和费用控制。不要把 API Key 写进浏览器，也不要把整份含敏感财务信息的工作簿无差别发送给模型。
怎样描述公式需求
提示词越接近可执行规则，候选公式越容易验证。应说明工作表和列、汇总或查找条件、日期字段、空值处理、目标单元格，以及是否需要绝对引用或跨表引用。例如：
"费用明细"表中 A 列是部门，B 列是费用类型，
C 列是金额，D 列是审批状态。
请生成公式，汇总华东区、差旅费、已审批的金额，
范围为第 2 到第 500 行。不要自动应用，
先说明每个条件对应的区域。模型可能给出 SUMIFS 候选公式。用户需要核对求和范围与条件范围是否等高、文本是否与枚举完全一致、范围是否包含标题或漏掉新增行。若使用结构化引用，还要确认真实表名和字段名。
如何解释现有公式
用户把公式放入编辑器并点击查询后，AI 可以给出公式含义、函数与参数、嵌套结构以及上下文说明。解释不是重新计算，也不是权威业务文档。以公式为例：
=IFERROR(SUMIFS(C2:C500,A2:A500,"华东区",B2:B500,"差旅费",D2:D500,"已审批"),0)复核解释时要检查：SUMIFS 的求和范围是否为金额列，三个条件范围是否等高，字符串是否匹配真实枚举，IFERROR 是否会把数据错误掩盖成零。AI 能解释语法，却不知道财务制度是否允许这种错误处理。
对于确定性检查，可以配合 CalcEngine 的 formulaToExpression 或 formulaToRanges 分析公式结构和引用范围。这些 API 与生成自然语言解释的 AI 功能不是同一件事。
生成后的四层验证
第一层是语法验证：在测试单元格确认没有名称、引用或解析错误。第二层是引用验证：逐项检查表名、起止行、绝对和相对引用。第三层是样例验证：用正常值、空值、未审批记录、边界日期和异常文本构造小数据集，手工计算预期值。第四层是业务验证：由口径负责人确认"金额""状态""本月"等含义。
批量应用前，应先在副本或测试区域验证，再扩展到目标范围。保存到后端时记录公式文本、目标单元格、模板版本、操作者和时间。模型、网络或代理不可用时，也应明确核心公式编辑与计算的降级方式。
安全、审计和适用边界
前端工作表数据、模型返回内容和用户提示都不能直接视为可信输入。后端应限制可发送范围，对姓名、账号、金额明细等敏感字段进行最小化和脱敏；审计日志记录请求标识、模型版本、目标工作表和应用结果，但避免保存完整敏感上下文。
AI 公式辅助适合生成常见汇总、查找和条件判断公式，解释复杂嵌套公式，以及帮助业务人员形成候选方案。资金结算、税务申报、监管报送和医疗计算等高风险场景，只能把 AI 用作草稿和解释工具。公式必须由确定性测试、业务规则和责任人共同确认。
从候选公式到生产公式的验收用例
以"华东区已审批差旅费汇总"为例，至少准备六类测试数据。第一类是正常记录，用来确认符合三个条件的金额均被累计；第二类是同地区但不同费用类型，确认不会误计；第三类是同费用类型但待审批，确认状态条件生效；第四类是金额为空或为文本，确认公式的处理符合制度；第五类是区域中新增记录，确认固定范围是否需要改为表格结构化引用；第六类是错误值，确认 IFERROR 是否会掩盖应当暴露的问题。
每个用例都要写明输入、预期结果和实际结果。若 AI 重新生成公式，应重新运行同一套用例，而不是因为公式外观相似就直接替换。对于跨表引用，还应测试工作表重命名、列移动和模板升级。对于向下填充的公式，应分别检查首行、中间行和末行，确认相对引用按预期变化，绝对引用保持不变。
公式上线前可以设置双人复核：开发者检查模块依赖、公式语法、引用和异常处理，业务负责人检查字段含义、日期口径、审批状态和舍入规则。通过后，把公式文本、模板版本、测试用例和审批记录一起归档。这样当数据异常或模板更新时，可以判断问题来自模型建议、公式实现还是业务口径变化。
失败处理与降级设计
AI 服务可能超时、限流、断网或返回无法解析的内容。界面应保留用户正在编辑的公式，并提示具体错误，不要清空编辑器，也不要把错误文本写入单元格。用户可以稍后重试、切换到手工编辑，或者继续使用工作簿中已有公式。AI 不可用不应阻断 SpreadJS 核心公式编辑与计算，这是插件能力和核心运行时分层的重要价值。
后端代理需要为重复请求设置标识，避免用户连续点击造成多次模型调用；还应限制单次请求携带的工作表范围和文本长度。若响应缺少候选公式、包含额外脚本或不符合约定格式，应拒绝提交并记录可诊断错误。对于敏感工作表，可以完全关闭 AI 功能，或者仅发送字段名称和脱敏样例。
运行监控应关注请求成功率、响应时间、429 比例、用户应用率、公式被人工修改的比例和验证失败类型。这些指标只能用于改进体验，不能被宣传为公式准确率。模型或提示模板升级时，应使用固定测试工作簿重新回归，并记录模型、插件、SpreadJS 与模板版本。
发布前检查清单
- 核心包、FormulaPanel 和 AI 插件均锁定为经过验证的 19.1 版本。
- AI 请求通过后端代理，浏览器代码中没有模型密钥。
- 用户权限决定哪些工作表可以启用 AI，以及允许发送多少上下文。
- 生成公式默认先预览，不直接批量覆盖。
- 公式引用、样例结果和业务口径均有复核记录。
- 网络失败、限流和无效响应不会破坏当前工作簿。
- 日志不保存不必要的财务明细或个人信息。
- AI Agent、AI 插件和 MCP 在产品说明中保持明确区分。
- 正式截图与示意图均完成来源、授权、文字和路径检查。
发布后的复盘
发布后应收集用户最常使用的公式任务、生成失败类型、人工修改比例和验证耗时。若用户反复修正同一类结果，应优先补充字段说明、测试样例和确定性规则，而不是简单提高模型权限。产品版本、模型版本、提示词和模板版本也应记录，方便后续定位差异。
结语
SpreadJS AI 插件降低的是"业务语言到候选公式"的门槛。SpreadJS 公式引擎负责执行，企业后端负责安全接入模型，使用者负责范围、口径和结果。建立生成、检查、应用、验证和审计闭环，AI 才会成为可靠的公式助手，而不是新的计算风险。
正式发布前应补齐配图，核对画面文字、来源、授权和相对路径，并在锁定的 19.1 工程中完成依赖安装、构建、浏览器运行和模型代理测试。