把表格丢给 Grok，先别信它甩出来的合计和均值。自己先记下行数和一两个已知总数，再让它写出计算过程。对一下是不是漏了行，有没有把空值当零，或把小计加了两遍。
要点
- 消费端可以在 grok.com、iOS 和 Android 的对话里，点输入框旁的 +，或在网页端拖放，上传 CSV、XLSX 等表格。官方 FAQ 写过，Grok 能分析电子表格，也能根据 CSV 和 XLSX 做可视化。多数文件上限是每个 150 MB，限制可能因平台或套餐略有差别；超限会报错。（消费端 FAQ：如何上传）
- 同一页还写了：对话上下文会抽取并处理文件内容，超长文件可能被摘要，或分段处理。上传成功，不等于每一行都进了这一次计算。（同上）
- 官方法律 FAQ 提醒过：Grok 偶尔会给出不准确或不合适的信息，也可能出现幻觉，用前须仔细核验。表格统计同样适用。（Consumer FAQs）
- 官方 API cookbook《CSV to Answers》用实验说明了风险：模型也能直接读文件里的文本，于是可能跳过代码，口头估一个总数。他们对一个 167 KB、3,024 行的文件问某列合计，没跑代码的答案偏了三倍以上。上下文里这份文件只被看到一部分（约 50,000 token，按体积估应约 80,000）；沙箱磁盘上的副本是完整的，用代码才能数到全部行。这是 API 示例和官方实验，不是 grok.com 上的强制按钮。（CSV to Answers）
- 本篇只谈：上传表格做清洗和统计时，哪些数字不能直接信，以及怎么跟做核对。把财报或长 PDF 压成“数字＋出处页码”对照表，见站内旧文，这里不展开。（Grok：把财报／长 PDF 压成“数字＋出处页码”对照表）
正文
场景
你从后台导出一张销售明细，上传给 Grok，问：“平均客单价多少？这个月比上个月涨了吗？”
它很快回一个合计、一个均值，再跟一句趋势判断。数字看起来整齐，你差点就要写进周报。
回头用 Excel 筛一下，才发现表里有小计行，空值被当成了 0，日期还跨了两个统计口径。也可能文件很大，模型只处理了前面一段，却把结果写成了全表结论。
这是场景示意，不是某次逐字实测。
官方允许你上传 CSV 和 XLSX，也举例问过“这份 CSV 里有什么趋势”。它不会在给出平均数之前，先替你核对行数和口径。这条纪律要你自己写进提示，并亲手对一下已知总数。
可跟做步骤／可抄工作流
下面是用法建议。消费端没有“统计核对”模式。
1. 先自己记下基准，再开口问结论
上传之前，在 Excel 或你常用的工具里先记下基准：文件名和工作表名，总行数和列名，日期范围，以及一两个你已经知道的总数，比如全表销售额或订单数。
这些基准是对照尺。没有对照尺，模型给的“平均值涨了 12%”你没有办法当场拆穿。
超长文件尤其要先做这一步。官方写过，很长的文件可能被摘要或分段处理。文件能传上去，不保证这一问覆盖了全部行。
2. 第一轮只做体检，先不要均值和涨跌
先让它报告用的是哪张表、看到多少行，各列看起来是什么类型，缺失和重复大概在哪，有没有小计行或合计行，以及准备怎么处理空值和筛选。未经你同意，不要擅自改记录、删除或合并记录，也不要直接给出业务结论。
可抄提示，按你的表改括号：
【任务】先体检这张表，不要直接给均值、合计或涨跌结论。
【文件】（文件名／工作表名）
【请先报告】
1. 你实际读取的工作表、行数、列名和主要字段类型
2. 日期范围（若有日期列）
3. 各列缺失情况；是否把空值、空白或占位符（如 N/A）算进了计算
4. 是否存在重复键、小计行、合计行或明显的格式不一致
5. 你打算采用的筛选、排除或清洗规则（先列出，等我确认后再计算）
【禁止】
- 未经确认不要改原始数据，也不要覆盖原文件
- 不要把缺失值默认当成 0
- 不要把小计行和明细行加在一起
- 每一个数字都要写出计算方法和计算前、后的行数行的含义要先问清。一张“销售表”可能一行是一笔订单，也可能一行是一个商品明细。按行数当订单数，口径会错。
3. 计算时要它出示过程，你对已知总数
确认清洗规则之后，再问合计和均值，以及分组对比。提示里写死：每个数字都用可检查的计算得来。消费端就要求它写出代码或逐步计算，并打印将要汇报的数字；同时回报计算前后的行数，以及排除了哪些行。
然后你拿第 1 步记下的已知总数去对。对不上，先查它排除了什么、是否只处理了部分行，不要先改结论去迁就模型。
官方 cookbook 里的做法更硬：强制先跑代码再回答，因为模型“看见过文件”之后，可能跳过计算直接估一个数。消费端未必有同样的强制开关，所以更要自己看过程、对基准。那次官方实验里，没跑代码的合计偏了三倍以上。不要把这个数字理解成 grok.com 上每次都会偏这么多。它说明的是风险方向：口头估计不能当作全表统计。
4. 这些统计，默认不要直接信
- 没有出示计算方法的合计或均值，以及中位数和占比
- 把缺失值、空单元格直接当 0 之后的任何总数
- 明细和小计混加，或把分组均值再拿来平均。分母不同的比率尤其危险
- 只分析了样本或分段，却写成全表结论
- 筛选条件、日期窗口、币种或时区没写清的同比和环比
- 从趋势直接推出来的“原因”
清洗规则可以让它提议，但要你点头后再算。官方也提醒过，输出可能不准确，用前须核验。关键数字最终应回到原表，或在你本机用 Excel、SQL 或 Python 复算一遍。
真实用户诀窍／反例
- 诀窍：先对一个你已经知道的总数。 对上了，再信后面的分组数字。对不上，后面的表再漂亮也不要贴进周报。
- 诀窍：让它同时报告行数。 计算前后行数对不上，往往是偷偷筛了行，或只处理了部分文件。
- 诀窍：比率不要对比率做平均。 不同规模的转化率或折扣率，应该回到人数或金额再算，而不是把各行百分比加起来除以组数。
- 反例：上传成功就等于算过全表。 官方写过超长文件可能被摘要或分段处理。
- 反例：把 API cookbook 里的强制跑代码，当成 grok.com 的按钮。 那是官方实验和开发示例。消费端要靠提示把纪律写进去，再由你复算。
- 反例：问一句“有什么洞察”就交差。 洞察会把口径问题藏进流畅的句子里。
适用边界
- 本篇只谈：在 grok.com 或官方 App 里上传 CSV／XLSX 做清洗和统计时，哪些数字不能直接信。不覆盖把财报或长 PDF 压成“数字＋出处页码”对照表，那是另一篇。
- 消费端没有“保证统计正确”的模式。提示可以要求它展示计算，不能代替你对原表。
- 文件上限、一次能传多少个文件、具体按钮文案，以登录后现页和官方 FAQ 为准。多数文件单个不超过 150 MB，网页端一次大约可传最多约 100 个文件，Android 最多 20 个，限制可能因平台或套餐略有差别。
- 财务、医疗、法律或要对外披露的数字，模型结果只适合当工作底稿，最终数字应在原系统或可复核的脚本里出。