An AI gave me a confidently wrong spreadsheet total — so I built one where AI writes code, not guesses, and gets verified.

AI 给出的电子表格总计错得离谱，于是我构建了一个让 AI 写代码而非瞎猜，并能进行验证的工具。

How I Stopped an AI From Lying to Me About Spreadsheet Totals A few months ago I asked an AI tool to total up a sales spreadsheet. It gave me a clean, confident number. It was wrong. Not “rounding error” wrong — it had quietly skipped rows and produced a total that just looked plausible. Nothing flagged it. Nothing hedged. It just said the number, like it was fact. 我是如何阻止 AI 在电子表格总计上对我撒谎的 几个月前，我要求一个 AI 工具对一份销售电子表格进行求和。它给出了一个整洁、自信的数字。但它是错的。不是那种“舍入误差”的错误——它悄悄跳过了几行，得出了一个看起来很合理的总数。没有任何提示，也没有任何保留。它就像陈述事实一样给出了那个数字。

That’s the actual problem with LLMs on tabular data: they don’t calculate, they estimate. Ask a model to sum a column and, under the hood, it’s doing next-token prediction over a serialized chunk of your spreadsheet — not arithmetic. Sometimes it’s right. Sometimes it silently isn’t. And it never tells you which. So I built Sheet Analysis AI specifically so it can’t do that. Here’s the actual mechanism — not the marketing version. 这就是大语言模型（LLM）在处理表格数据时的真正问题：它们不是在计算，而是在估算。让模型对一列求和，其底层逻辑是对电子表格序列化后的片段进行“下一个 token 预测”，而不是进行算术运算。有时它是对的，有时它会悄无声息地出错，而且它从不告诉你哪次是对的。所以我专门构建了 Sheet Analysis AI 来杜绝这种情况。以下是它的实际运行机制，而非营销说辞。

Rule 1: the AI is never allowed to do arithmetic When you ask a question like “which region grew fastest?”, the model doesn’t see your data. It sees: your column names (region, revenue, date), their inferred types, and maybe 3-5 sample rows. From that, it writes a small piece of JavaScript — actual code, not a natural-language answer. That code is then executed locally, in your browser, against your full dataset (tested up to 100k rows). The model decides the approach (group by region, sum revenue, sort descending). Your machine does the calculating. This alone kills the “confidently estimated” failure mode, because there’s no estimation step left — it’s just code execution. 规则 1：绝不允许 AI 进行算术运算 当你问“哪个地区增长最快？”这类问题时，模型并不会看到你的原始数据。它看到的是：你的列名（地区、收入、日期）、推断出的数据类型，以及大约 3-5 行样本数据。基于这些，它会编写一小段 JavaScript 代码——是真正的代码，而不是自然语言回答。这段代码随后会在你的浏览器中本地执行，针对你的完整数据集（已测试支持高达 10 万行）。模型决定处理方法（按地区分组、求和收入、降序排列），而计算过程由你的机器完成。仅此一点就消除了“自信地估算”导致的故障模式，因为不再有估算步骤，只有代码执行。

The deterministic dashboard (KPIs, Mann-Kendall trend detection, ANOVA seasonality, Pareto/RFM segmentation, forecasting) doesn’t even involve the AI — it’s plain statistical code that runs the instant you upload a file, no API key required at all. 确定性仪表板（KPI、Mann-Kendall 趋势检测、ANOVA 季节性分析、帕累托/RFM 分段、预测）甚至不需要 AI 参与——它们是纯粹的统计代码，在你上传文件的瞬间就会运行，完全不需要 API 密钥。

Rule 2: nothing gets displayed until it’s re-verified Even code-generated numbers can be wrong — bad logic, an edge case, a misread column. So before anything renders, a separate deterministic auditor — no AI involved — re-checks every figure against the source rows. 规则 2：在重新验证之前，不显示任何内容 即使是代码生成的数字也可能出错——可能是逻辑错误、边界情况或列读取错误。因此，在任何内容渲染之前，一个独立的确定性审计程序（不涉及 AI）会根据原始数据行重新检查每一个数字。

A concrete example: Say your data is: Region, Product, Revenue. North, Phone, 200; North, Laptop, 200; South, Phone, 100; South, Laptop, 500. Total revenue is $1,000. The auditor checks this a few different ways: 一个具体的例子：假设你的数据是：地区、产品、收入。北区、手机、200；北区、笔记本、200；南区、手机、100；南区、笔记本、500。总收入为 1,000 美元。审计程序会通过几种不同的方式进行检查：

• Traceability — does “$1,000” actually equal the sum of real rows in your file, or did something get invented?
• Percent math — if a report says “North is 40% of revenue,” is that literally 400 / 1000, or a plausible-sounding guess?
• Cross-foot — the same total sliced two different ways must agree. By region: 400 + 600 = 1000. By product: 300 + 700 = 1000. If those don’t match, something’s broken upstream and the number is blocked, not shown.
• Claim binding — if the summary says “Laptop is the top product,” that claim is checked against the actually-computed numbers before it’s allowed to print. Any single failed check blocks that figure. It doesn’t get downgraded to “approximately” — it just doesn’t render.
• 可追溯性——“1,000 美元”是否真的等于文件中实际行的总和，还是凭空捏造的？
• 百分比计算——如果报告说“北区占收入的 40%”，这是否真的是 400/1000，还是听起来合理的猜测？
• 交叉核对——同一总数通过两种不同方式切分必须一致。按地区：400 + 600 = 1000。按产品：300 + 700 = 1000。如果两者不匹配，说明上游逻辑有误，该数字会被拦截，不会显示。
• 结论绑定——如果摘要说“笔记本是销量最高的产品”，该结论在允许打印前会与实际计算出的数字进行比对。 任何一项检查失败都会拦截该数字。它不会被降级为“大约”，而是直接不予渲染。

What’s deterministic vs. what needs a key To be upfront about scope: Free, no key, instant: dashboard, KPIs, trend stats, forecast, and a rule-based version of “talk to your data.” Needs your own AI key (OpenAI / Gemini / DeepSeek / etc., bring-your-own-key): the conversational Q&A gets smarter, and “Deep Analysis” (full AI report + hidden-pattern detection) becomes available. Nothing routes through my infrastructure or gets billed to me — your key talks directly to your provider from your browser. 哪些是确定性的，哪些需要密钥 关于范围的说明：免费、无需密钥、即时可用的功能包括：仪表板、KPI、趋势统计、预测以及基于规则的“与数据对话”功能。需要你自己的 AI 密钥（OpenAI / Gemini / DeepSeek 等，自带密钥）的功能包括：更智能的对话式问答，以及“深度分析”（完整的 AI 报告 + 隐藏模式检测）。没有任何数据会通过我的基础设施，也不会产生费用——你的密钥直接从你的浏览器与你的服务提供商通信。

Stack: React 19 + TypeScript + Vite. No backend in this build — parsing, analysis, and the reconciliation gate all run client-side. Licensed AGPL-3.0. 技术栈：React 19 + TypeScript + Vite。此版本没有后端——解析、分析和核对网关全部在客户端运行。采用 AGPL-3.0 许可证。

Why open source it I don’t think this needs to be a product. I think the pattern — AI proposes the method, deterministic code executes it, a separate auditor verifies it before display — is generally useful for anyone building “AI + your data” tools, and it’s more useful to more people as a reference than as a SaaS with a handful of users. 为什么要开源 我认为这不需要成为一个商业产品。我认为这种模式——AI 提出方法，确定性代码执行，独立的审计程序在显示前进行验证——对于任何构建“AI + 数据”工具的人来说都是通用的。作为参考资料，它比作为一个只有少数用户的 SaaS 产品对更多人更有价值。

Repo: https://github.com/Durlabhkumarjha/sheet-analysis-ai Genuinely curious if anyone’s solved this “AI + real numbers” trust problem differently — would love to compare notes in the comments. 仓库地址：https://github.com/Durlabhkumarjha/sheet-analysis-ai 真心好奇是否有人用不同的方式解决了这个“AI + 真实数字”的信任问题——欢迎在评论区交流心得。