Pricor：本地AI读供应商表格，精确引擎算价格

一张供应商发来的表格，价格列写着 12.100,00，表头标注 c/IVA（含增值税），另一列是 10+5，还有一列写着 100。一件商品的净成本是多少？答案是 85.50：两层连锁折扣（不是简单相加的15%）、剔除增值税、再把整箱拆成100件。阿根廷的小店主每次收到供应商报价单都要手工算一遍，每家供应商、每种格式都不同，而且下周可能又有一列挪了位置。

Pricor（price + order）就是为解决这个重复劳动而生的本地应用。它把 Excel 或 CSV 文件转换成结构一致、可导入的产品记录：供应商编码、描述、净单位成本与币种，并保留行级可追溯性。它的核心原则只有一条：模型负责理解，引擎负责计算，用户负责决定。

一个被手工反复计算的场景

问题的根源不在于算术本身，而在于表格格式的混乱。同一个含税价可能有十几种写法，折扣有时写在一格里（10+5），有时分散在两列；包装规格和计量单位混在一起；增值税率可能隐含在表头文字里。人眼尚可靠经验猜测，但每一次猜测都可能出错，而错误的成本会直接进入定价。

Pricor 的处理链路是确定性的：先用规则分析器找到表头行、行类型、列类型和数字格式，确保 12.100,00 不会被误读成 12.1；再由微调过的多语言模型 Laya 把每一列归入封闭的角色集合；Laya 不确定的列交给通过 Ollama 本地运行的 Gemma 4 E4B；仍然不确定的部分，交给用户回答。

所有问题都由计划中缺失的信息确定性生成：价格含不含税？是按包还是按件？什么币种？Gemma 可以给出建议并显示其（未校准的）置信度，但不会替用户做任何决定。

增值税（IVA）与含税/不含税价格

IVA（Impuesto al Valor Agregado）是西班牙语国家通用的增值税，阿根廷的标准税率为21%，部分商品适用10.5%或27%等差别税率。供应商报价单常以 c/IVA（con IVA，含税）或 s/IVA（sin IVA，不含税）标注，但缩写和写法并不统一。含税价换算为净成本需要除以 (1 + 税率)，而非简单减去税率百分比——例如含21%税的价格除以1.21，得到的才是税前净额。当税率隐含在表头文字而非独立列中时，正确识别税率本身就构成一个解析难题，这也是 Pricor 需要模型参与列角色判断的原因之一。

连锁折扣（cascading discount）

连锁折扣指多个折扣按顺序依次作用于递减后的金额，而非把百分比相加。10+5 表示先打九折、再在折后价上打九五折，实际折扣率为 1 − 0.90 × 0.95 = 14.5%，低于直觉上的15%。折扣层级越多，与简单相加的偏差越大。供应商常用这种写法表达阶梯让利，而表格中有时写在一格（10+5）、有时分列两栏，解析器必须区分“连锁”与“并列”两种语义，否则会系统性高估成本。

计算不交给模型，交给精确引擎

这是 Pricor 最值得注意的设计取舍。执行器只理解一组封闭的操作：解析数字、应用连锁折扣、剔除增值税、拆分包装、映射取值、规范化文本，以及可选的汇率换算。它从不执行模型生成的代码，也从不把最终价格交给模型计算。

原文演示中的算例完整展示了这条链路：

12,100.00   每箱，含21%增值税
 × 0.90 × 0.95   10%和5%的连锁折扣
 ÷ 1.21          剔除增值税
 ÷ 100           每箱100件
=    85.50 净单位成本

所有中间步骤都会以“回执”形式展示，用户可以从原始单元格一路核对到最终成本，确认后才批准。被拒绝的行不会被静默丢弃，而是保留在单独的可导出报告中。

Decimal 精确算术与浮点误差

金额计算若使用 IEEE 754 双精度浮点数，0.1 + 0.2 不等于 0.3 这类二进制表示误差会在多次乘除后累积，导致分位偏差。Pricor 的执行器使用 Decimal（十进制定点）类型完成解析、折扣、除税和拆分，保证结果与人工按十进制规则计算一致，并可复现。这也是“不把最终价格交给模型”的技术依据之一：语言模型输出的是 token 序列而非可审计的数值类型，无法保证舍入行为。

本地模型在导入路径中，而不是外挂聊天框

Pricor 对开源模型的使用方式颇具参考价值：Laya 和 Gemma 直接处于数据导入的关键路径上，它们的判断边界决定了应用何时必须向用户提问。这种设计带来几个实际好处。

隐私。 小店的供应商清单和成本数据不会离开自己的电脑去往托管模型服务商。成本。 每周导入相同供应商时，复用已保存的计划没有按次调用费用；电费、硬件和支持并非免费，但没有计价器在跑。离线。 导入无需联网，只有可选的在线汇率刷新需要网络，缓存或手动输入的汇率同样可用。许可。 Gemma 4 采用 Apache-2.0 许可，可以嵌入商业交付的产品中。

记忆机制同样克制：只有当用户主动写下一条记忆，或接受 Gemma 建议并点击“记住这个”时才会创建，绝不自动生成。相关记忆以编号的不可信数据形式传给 Gemma，Gemma 必须引用它所依赖的记忆，界面会展示引用来源；如果回复引用了未提供的记忆，整条回复会被丢弃。

Ollama 与本地模型部署

Ollama 是一个本地大模型运行时，提供统一的模型拉取、量化加载和 HTTP 推理接口，开发者可以用少量代码在普通消费级硬件上运行 Gemma、Llama 等开源权重模型。Pricor 借助它将 Gemma 4 E4B 置于导入流程内部：应用直接调用本地推理端点，无需 API 密钥、不计 token 费用，数据不出本机。代价是推理速度与质量受本地硬件和量化精度限制，因此它被定位为 Laya 之后的兜底判断者，而非唯一决策者。

基准测试没有支持“全自动”

作者在仓库中公布的基准测试只有来自两家经销商的 29 个留出列，应当视为健全性检查而非排行榜。结果如下：关键词/类型启发式正确 24/29（82.8%），Laya 零样本 18/29（62.1%），Laya 微调后 22/29（75.9%），Gemma 纯提示 25/29（86.2%）。

在整表级联中，只有 11 列被自动解决（其中 10 列正确），29 列中仍有 18 列需要用户介入。作者对此的态度值得称道：在这份数据上，应用就应该提问。测试的局限也被如实记录——阈值部分基于合成验证数据选择，测试集缺少某些角色，启发式规则是在见过留出表头之后写的，两个标签在首轮运行后被修正。

值得公开的缺陷与下一步

原文坦率地列出了两个 bug。其一是百分比语义：Excel 把显示为 21% 的单元格存为 0.21，一旦丢失数字格式，21% 的增值税会变成 0.21%，而且仍能算出一个看起来合理的成本。其二是第二个折扣列：当表格有两个独立折扣列时，计划构建器只使用第一个，这违反了应用自己“绝不静默”的规则，修复已列入待办。

后端测试套件通过 1219 个测试，前端 194 个，但这并不证明能兼容供应商可能产出的每一种 Excel 文件。作者的下一步也不是加功能，而是与零售商做一次受监督的试用，用他们已经在处理的清单对比现有导入流程，观察确认步骤在哪里让人困惑，再判断持续支持服务值多少钱。在此之前，商业假设仍是暂定的。

Pricor 的启示或许在于：当 AI 处理涉及金额和规则的数据时，“让模型做理解、让确定性代码做执行、让用户保留最终决定权”是一条比端到端自动化更可靠的分工线。