分析规则是知识对象，不是提示词

下面这个问题有一个正确答案，而任何称职的分析师都不会把它发出去。

已婚客户是不是比单身客户流失得更少？

拿客户表跑一遍，你会得到一个干净的结果。已婚客户流失率 4.1%，单身客户 7.8%，差了近一倍。SQL 没错，关联没错，数字也对得上。

而这个发现几乎毫无价值，资深分析师大约两秒钟就知道为什么：婚姻状况和年龄高度混杂，年龄决定在网时长，在网时长决定流失。你并没有发现任何关于婚姻的事实，你只是重新发现了“年长客户留得更久”。把它当作婚姻状况的影响报上去，就会有人据此立一个活动。

正确的做法是先按年龄分层，再看婚姻状况的差异是否还站得住。通常大部分都站不住。

接下来是关键：这不是一条关于你数据的事实，而是一条关于你方法的规则。 而市面上几乎所有 AI 分析产品，都没有地方安放它。

资深分析师真正揣着的那些规则

问一个有经验的分析师，他知道而新人不知道的是什么，你很少会听到“SQL”。你听到的是一整套沉淀下来的谨慎：

• 任何由少于 30 条记录算出的格子都要抑制。低于这个数，比率就是噪声，发出去等于邀请别人据此行动。
• 婚姻状况、职位、邮编都是年龄或收入的代理变量。对比之前先控制。
• 有周度季节性的业务，绝不要拿本月和上月比。要么和去年同期比，要么用四周滚动窗口。
• 除非问题明确问的是总签约额，否则收入不含内部往来。
• 三月之前来自迁移前数仓的任何数据，都不能和迁移之后的数据直接比。
• 如果分母的变动比分子还大，先讲分母。

这些都不是语义层意义上的指标定义。语义层能告诉你 revenue 是什么意思，但它不会告诉你“今年三月对比去年三月是唯一诚实的看法”，也不会告诉你“五个客户算出来的 40% 流失率永远不该流出这栋楼”。

这些是分析规则，而它们才是快答案和站得住脚的答案之间真正的差别。

这些规则现在存在哪

三个地方，而且都不好。

在人的脑子里。 一直有效，直到这个人休假、离职，或者干脆当时不在会议室里。

在提示词里。 这是当下多数工具提供的方案：一个叫“instructions”或“context”的大文本框，你把你的惯例粘进去，然后祈祷模型会照办。这确实比没有强，而它的失效方式很具体、也可预测。

在没人看的 wiki 里。 那本 2023 年写过一次、如今大约三分之一的说法已经失效的分析手册。

为什么提示词框不够

提示词是一个字符串。全部问题都出在这里。

字符串无法评审。 “我们三月把小样本阈值从 30 改成了 50”这件事没有 diff，没有审批人，没有评论，也没有任何关于“谁决定的、为什么”的记录。

字符串无法测试。 像小样本抑制这样的规则有个显而易见的测试：问一个答案依赖于某个 n=12 的格子的问题，然后检查系统是否抑制了它。存成知识对象的规则可以带着自己的测试用例；存成散文的规则根本无法被执行验证。

超过一页就不成立了。 一百条规则塞不进提示词而不挤掉真正的问题，而且排在最后面的那些被执行得最不稳定。检索能解决这件事——但前提是规则是可以被单独检索的离散对象，也就是说它们不能是一整坨文本。

它无法限定范围。 临床场景下的抑制阈值不等于市场场景下的抑制阈值。提示词要么对全部生效，要么全不生效；而对象可以挂到某个领域、某份数据集、某个团队上。

它不留审计痕迹。 半年后有人问三月那份报告为什么抑制了某个分段，“当时提示词里是这么写的”不是一个答案——那之后提示词已经被编辑过九次了。

一条规则作为对象长什么样

给规则和指标定义同等的待遇：一个身份、一个作用域、一个理由、一个版本，以及一个能验证它的东西。

rule: small-cell-suppression
scope: [customer-analytics, hr-analytics]
applies_to: 任何比率或百分比
condition: 分母 < 30
action: 抑制该格子，改为报告"n 过小"
rationale: >
  低于 n=30 时，比例的置信区间比我们几乎任何会据以行动的
  效应量都要宽。报告点估计等于邀请别人做出数据支撑不了的决策。
owner: analytics-governance
version: 3
supersedes: 2（2026-03-01 之前阈值为 20）
test:
  question: 北欧地区企业客户的流失率是多少？
  expect: 已抑制，n = 12

现在它可评审了，因为 v3 对 v2 有 diff；它可测试了，因为测试用例就挂在上面；它有作用域了，所以不会在“n=12 是完整总体而非样本”的场景里误触发。而当三月那份报告被拿去审计时，当时生效的那个版本的规则是可以被取出来的。

混杂那条规则同样处理，而且它更有意思，因为它改变的是答案的形状，而不只是藏起一个格子：

rule: control-for-age-before-demographic-comparison
scope: [customer-analytics]
applies_to: 任何按婚姻状况、职位或邮编做的对比
action: >
  先按年龄分层，报告层内对比。
  如果分层后效应不再存在，就明确说出来，
  而不是报告未调整的差异。
rationale: >
  在我们的客户结构里，这些属性都是年龄的代理变量。
  未调整的对比算术上正确、方向上误导。
owner: analytics-governance
version: 1

握着这个对象的系统，不会用 4.1% 对 7.8% 来回答婚姻状况那个问题。它会给出分层后的对比，并且会说明它为什么这么做。

这一层才是难被复制的

有做得好的文档产品，也有做得好的受管 SQL 生成产品。我们没有见过任何人建起来的是第三样东西：分析纪律本身，作为带版本、可检索、可测试的知识存下来，并且让前两半都受它约束。

它不光鲜，这也是它至今无人争夺的部分原因。它的演示效果比不上“一句话变出一张图”。而它同时也正是“能产出答案的工具”和“能产出敢摆到监管面前的答案的工具”之间的全部差距。

而且它会以另外两样东西不具备的方式复利。每当分析师纠正一次输出——不对，要控制年龄；不对，那个格子太小；不对，要同比——这次纠正就能变成一个带作用域、带版本的对象，作用于此后所有的提问。系统会越来越像你最好的那位分析师，而不是越来越像互联网的平均值。

该问供应商什么

如果你在评估这个领域的产品，下面四个问题能很快把品类区分开：

1. “n 小于 30 要抑制”这样的规则存在哪里，我能看到它的版本历史吗？
2. 如果我改这个阈值，什么会受影响，我能在上线前测试吗？
3. 规则能不能限定到某一份数据集或某个团队，还是只能全局生效？
4. 半年之后，你能把当初支配某个具体答案的那套规则原样给我看吗？

如果四个问题的答案都是“在系统提示词里”，那你买到的是一个很快的初级分析师。这确实是个值得买的东西，但它和一个资深分析师不是同一样东西。