财务是数据敏感行业里最谨慎的一环。工资、成本、往来、税负，一张明细表就是公司的底牌；月结、季报又是重复劳动。分歧不在能不能用 AI，而在数据在哪一步、以什么形式离开你的环境。

一、财务数据的三个特殊性

合规是第一层。员工薪酬、银行流水、涉税信息都在《数据安全法》与《个人信息保护法》重点范围内，数据出去一次就收不回来，追责成本远高于省下的工时。

频次是第二层。同一口径每月要重跑，每次重传原始表，暴露面就随调用次数累加。

口径是第三层。同一个毛利率，不同人算法不同，结果对不上比算错更难解释。

三层叠加，财务场景的第一诉求不是模型多聪明，而是数据少流动、口径能复现。

二、本地处理不是把大模型装进电脑

这是常见误解。把几十亿参数的模型塞进办公机，硬件、效果、维护都不划算。

务实的做法是把“理解”和“执行”拆开：模型只负责把“按门店、按品类算毛利率，找出环比异常”翻译成可执行的处理逻辑；执行交给脚本，在本机数据文件上跑，原始数据不参与模型调用；脚本存下来，就是可复用的分析资产。

图一：三条路线的差别，在于数据在哪一步离开本地。

云端工具把原始表传上去算，上手快但暴露面最大；本地全栈自建要养模型、养显卡，中小企业扛不住；折中的做法是逻辑固化、本地执行，模型只写逻辑。

三、脚本复用带来的三件事

一是口径可复现。同一条脚本跑一月和二月，输出结构一致。

二是不再消耗 token。脚本执行不调模型，重复跑的成本趋近于零。

三是断网也能跑。月末结账赶时间，不必看网络脸色。配合语义定义，把营收口径写进产品，下次指令更短。

图二：脚本导入数据即可运行。

数以轻舟走的正是这条路：本地安装，数据文件本地处理，不进聊天框、不传第三方 SaaS。一句话生成分析脚本，固化后同口径直接调用；数以轻舟只在要出可编辑的 Word 或 PPT 报告时，通过模型接口成文排版，联网动作明确、可审计。

四、边界比承诺更重要

这套方案压缩的是数据外送的源头风险，替代不了本机权限管理、账号制度与操作留痕；报告生成那一步仍要参与模型调用，访问控制不能省。

给财务团队三条建议：能本地跑的不上传；把口径固化成脚本，而不是每次重新提问；联网收窄到一环。安全没有一劳永逸，数据少外送一次，暴露面就小一圈。