Querri：把反复问的数据问题，变成可核对的业务口径

每周问一次“本月销售额是多少”，答案却可能不一样：有人算所有订单，有人只算已付款订单，还有人扣掉退款。难点不只在加总，还在于先说明哪些记录应该计入。

Querri 把自然语言提问、数据整理和结果输出放在一个产品里。用户可以导入表格或连接数据源，询问数据、查看处理步骤，再生成图表或导出整理后的表。运营人员可以从业务问题开始，分析人员则能继续检查计算依据。

本文聚焦它的 Library（资料库）：这里不仅存放文件，还组织业务规则、常问问题和 Views。View 可以理解为“保存的计算方法及其结果表”，例如每位客户一行的消费汇总。规则说明“已付款才计入销售额”，结果表按这个定义准备数据，后续回答便能复用它。原始数据不会因此被改写。

这适合会反复出现的问题。一次性的简单加总未必需要先建设完整资料库；如果团队本身还没决定退款如何处理，AI 也不能替大家确定业务口径。

下面用一个建议练习串起操作：整理同一月份、同一币种的订单，计算各渠道已付款金额。这是便于手工核对的小例子，不是实际客户数据或产品实测结果。

1. 建立项目并导入数据。 按官方入门指南登录 Querri 后选择 + New Project，给项目起一个能辨认任务的名字，再用 + 上传 CSV 或 Excel。准备三条记录：官网已付款 100 元、官网待付款 80 元、门店已付款 60 元。字段包括渠道、状态、金额；先不用客户姓名等无关字段。
2. 先说清计算范围。 在聊天中写：“本次销售额只计算状态为已付款的订单，按渠道汇总金额。请先说明排除了哪些记录。”确认这也是团队今后要沿用的定义后，再明确告诉助手：“请为这张订单表记住规则：销售额只计算已付款订单，以后按此定义。”Facts & Rules 文档说明，聊天确定的规则会记录在相关表上。到 Library 的 Facts & Rules 查看条目，核对所附数据表和规则内容，确认已记录后再建立 View；不要把一次提问里的临时条件当成已经保存。可以请求 Show the query 查看实际计算查询。此例应保留官网 100 元和门店 60 元，排除待付款 80 元，总额为 160 元。
3. 把需要重复使用的结果做成 View。 在相关问题上选择 + Build a view to answer this，或从聊天里的表选择 Save this table as a view。说明每行代表“一个渠道在一个月份的汇总”，避免把订单明细与渠道合计混在一起。Librarian 是 Querri 中协助整理资料库的助手：它先寻找可用的已有 View，并在需要业务判断时提问。
4. 读完假设，再批准保存。 构建后核对它说明的假设、匹配数量和排除记录。只有用户批准，View 才保存进 Library。对这个小样本，检查是否只有两个渠道、金额是否分别为 100 和 60；发现定义错误时先调整要求，不能只看总额凑巧相同就认可。
5. 继续提问并交付结果。 再问“两个渠道分别贡献多少已付款金额？”查看答案引用的 View。需要展示时，可让 Querri 生成图表，或按入门指南导出整理后的表。正式交付前，把图表标签与 View 的行含义一起检查，避免把“已付款金额”改写成含退款处理的“净收入”。

Views 文档说明，连接数据源的后续同步会触发相关 View 按依赖顺序重建；依赖关系就是“这张表由哪张表算来”。如果输入同步失败，相关 View 不会拿这次失败的数据重建；冻结快照也保持不变。面板给出构建时间，仪表盘和项目在下次运行时读取更新后的 View，因此不能把“能自动刷新”理解成任何时候都已取得最新数据。

规则跟着数据走

把“只算已付款”只写在一次聊天里，下一次提问仍可能换一种算法。Querri 将业务定义附到表，并让后续问题和新建 View 使用这些定义。用户还能查看查询中的过滤条件。它把讨论对象从“这个答案看起来对不对”变成“这条规则有没有被正确执行”。收益的前提是规则本身正确；退款口径改变时，旧定义也要重新检查。

保存前把假设交还给人

跨系统数据经常需要决定如何认定同一位客户。Querri 的 View 文档展示了先询问匹配方式、再报告未匹配数据的过程，并把保存放在用户批准之后。这样，人可以在错误关系进入复用结果之前发现问题。代价是首次整理仍需要了解业务的人参与，不能仅凭 AI 已生成一张表就跳过核对。

问题范围决定能否复用

常问问题机制让 Library 围绕一个主要问题组织资料、规则和结果。Querri 会寻找确实覆盖当前问题、范围不宽不窄的 View；没有合适 View 时，从来源回答并说明。举例说，只有“已付款金额”的表不能自然回答“待付款金额”。这是本文对复用边界的解释：相似措辞不等于相同数据范围。

更新沿着依赖传递，也保留失败边界

先准备客户匹配表，再计算客户汇总，可以让多份结果复用同一份整理工作。同步后按依赖顺序重建，减少下游各自重复清洗的机会；输入失败则跳过相应重建，避免把坏输入当成新结果。由此仍需区分“保留旧结果”和“已经刷新成功”。可借鉴的原则是让规则、来源和更新时间随结果一起可查，使复用建立在可解释的判断上。