数据可信，AI 才可信：一条行为数据链的权限与解释边界

当团队开始让 AI「分析用户行为」时，最容易犯的错误，是把 AI 放在它不该在的位置上。

一种很自然的做法是：把数据库只读账号交给分析工具，让它自己写 SQL、自己取数、自己下结论。短期看很省事，长期看却把三件事混成了一件——谁能定义数据、谁能解释数据、谁为结论负责。

在我接手的这个项目里，行为数据分析是常态化工作：每天都要出日报，共享给团队成员和上级领导。这意味着一件事——我不可能每天抽出时间，人工审核 AI 为当天日报生成的 SQL。让几个 AI 交叉审核，最后也只是骗自己：一条有问题的 SQL 一旦造成数据库损坏、服务关停或数据丢失，就是不可逆的。我在有限设备条件下做过数据库备份方案，但备份不能成为放任风险的理由。更何况，直连本身还有凭据问题：连接方式一旦泄露，数据就可能外流。

所以我最后划下的线是：让 AI 能够获取数据，但不允许 AI 直连数据库。这条线的价值不在于「用了 AI」，而在于把数据权威和 AI 解释分开：系统负责采集、聚合、口径和权限；AI 只在脱敏、可审计的出口上做解释。

一、行为数据的第一性问题不是「能采」，而是「能信」

埋点系统最初看起来很简单：页面停留、点击、浏览路径、登录与收藏，发一个事件，落一张表。

但真正做过之后会发现，采集只是起点。我们遇到过几类很具体的问题：

• 定时任务崩溃，导致某段时间的事件没有正常聚合；
• 排除名单按单一用户维度录入时，触发数据库非空约束，整批写入失败；
• 聚合任务抢到锁之后没有释放，前端「立即刷新」卡住十几分钟；
• 消息队列里的坏消息不确认，每两秒重读一次，日志被同一行灌到几百兆；
• 停留时间没有上限，用户切到后台，计时仍在走，均值被放大一个数量级。

这些问题没有一个是「架构不优雅」，全是数据能不能信的问题。一条被放大十几倍的停留时长，会让运营得出完全错误的判断；一次静默失败的写入，会让报表少掉一整天的数据，而页面上仍然显示「成功」。

所以我后来把判断标准改成：先问这条数据在异常时会不会显形，再问它能不能被 AI 分析。异常不显形，AI 分析得越流畅，错得越自信。

二、一份口径，多个出口

第二个坑是「同一个问题，不同答案」。

后台页面、Excel 导出、日报文本、给 AI 的查询接口，如果各自写一套统计逻辑，很快就会出现：页面显示 100，导出是 98，AI 回答 103。没有人撒谎，只是四套代码各自演化。

我们的做法是把它们收敛成同一份取数口径、多个渲染出口：页面、导出、日报和 AI 接口共享同一套聚合结果，差别只在呈现形式。新增一个出口，不是新增一套计算，而是新增一层渲染。

这一步首先关乎信用。这套功能就是为了让团队做数据分析，如果不同渠道拿到的数字不一致，系统就没有信用可言。同一份口径意味着每个出口一视同仁：没有谁是上等公民，也没有谁配拿到“更准”的数字。

它还带来一个不那么显眼、但同样关键的好处：数据分享的边界只需要定义一次。给出去的是聚合数据还是原始明细？明细里哪些字段要隐藏、哪些要脱敏？如果各渠道边界不同，脱敏和管控就会各自漂移；口径统一之后，只需要一份标准的数据管控口径，所有出口共同遵守。日报面向团队共享时可以精简呈现，但生成它的源数据必须与其他出口绝对一致。

口径还要写下来。哪些事件算「咨询」、哪些算「内部自查」、回访用户怎么去重、跨天窗口怎么合并——这些规则如果只存在某个人的脑子里，AI 每次都会用不同的假设重新发明一遍。把它们钉进说明书，AI 才有可能被约束。

三、给 AI 开一扇受控的门

最关键的取舍在这里：AI 需要数据，但不需要数据库钥匙。

图 1：系统负责采集、聚合、口径与权限，AI 只站在出口之外；「AI 不直连数据库」是这条链路的底线，不是实现细节。

我给分析侧开放的不是数据库连接，而是一个受控出口：

• 优先给聚合数据，而不是原始明细。明细字段太多，打码重了，分析失去意义；打码轻了，一旦泄露就是重大隐患。只有在个别需要重点关注用户的时刻，我才会在可控范围内给出脱敏后的明细，供二次分析。“看不出具体是谁”不等于“这份数据可以随便给”——平台数据本身就有极高的商业价值，对竞品尤其如此。
• 数据先经过脱敏：排除内部自查事件，手机号等身份信息打码；对可能被「两次查询做差」反推的聚合结果，明确标注不可差集推算；
• 访问需要钥匙：钥匙不是明文常驻，而是哈希存储、带有效期；重新生成时旧钥匙在宽限期内失效；
• 频率按钥匙独立限流，避免一个调用方挤占所有人的配额；
• 每次调用留下审计记录，谁、什么时候、取了哪类数据，可以追溯。

这套设计不追求「让 AI 无所不能」，而是追求让 AI 的每一次取数都可解释、可拒绝、可追责。

这里有一个容易被忽略的细节：分析侧调用方不是系统的一部分，它会犯错，而且钥匙的生成和传递过程里还有人。我们真实遇到过调用方拿着旧钥匙取数、被系统拒绝的情况。审计结论很清楚：鉴权链路没有 bug，根因是人为轮换加上新旧文本混用；而更早一代设计里「每次生成立即杀掉旧钥匙」，才是结构性事故源——本来只是一次平淡的日报分析，却因为旧钥瞬间失效而推进不下去。

于是我们参考微信 access_token 的截断模型重新设计：新钥匙 24 小时有效，再生成时旧钥匙只保留 30 分钟，只缩短、不延长；限流按钥匙哈希分窗口。30 分钟足够走完一次取数分析，又不会留下长期有效的凭证。与其提醒对方「记得换钥匙」，不如让系统设计吸收这个必然会发生的错误。

四、采集会静默失败，所以异常必须显形

同一条链路上，还有一个值得单独说的教训。

在另一个端（不是本文这条小程序链路），同事维护的埋点写入曾经静默断流数天：写入语句因为一个字段缺省值不匹配而全部失败，但接口仍然返回 HTTP 200。接口看起来正常，报表也没有告警，只有数据没有进来。等到发现时，那几天的数据已经永久丢失。

这不是本文这条链路的已证实事故，但它说明了一个通用风险：采集失败最可怕的形态不是报错，而是「看起来成功」。

所以可靠的做法不是假设链路永远健康，而是让失败显形：写入失败要有可观测的计数，聚合任务要有状态和超时，坏消息要有重读上限和死信记录，报表要能区分「今天没有数据」和「今天数据没进来」。

五、AI 解释的边界

把上面几件事放在一起，这条链路的责任划分其实很清楚：

层	负责什么	不负责什么
采集	事件真实、失败显形	解释业务含义
聚合	口径统一、可复现	判断结论对错
出口	脱敏、鉴权、限频、审计	保证 AI 说得对
AI	在给定数据上做归纳与表达	定义数据、拥有数据、替代人决策
人	判断、取舍、对外负责	手工重算每一行

图 2：每一层只对一件事负责。出口保证「AI 拿得到、拿得合规」，不保证「AI 说得对」；后者始终是人的判断。

AI 在这个结构里的价值是降低成本，不是做到人做不到的事。没有 AI，我们依然可以分析，只是要为每类数据设计结构、分析方式和结果导向；每新增一类埋点，还要再配一套分析逻辑。AI 擅长的是理解这些不那么规整的信息，并在我本地不断迭代的日报工作流（skill）里复用它们——我的历史日报和生成方式都沉淀在里面，每天、每个新功能都可能让它继续进化。

但边界同样清楚：数字的加减、定量计算，我不让 AI 天马行空地做，那只会放大幻觉；更重要的是，数据拿来做什么，只能由人决定。是人决定了要回答“小程序和网站每天运行得怎么样、哪些客户有高回访价值”，AI 才能在这个目标下工作。把数据丢给它，它只能想象你要什么。

所以判断一份 AI 分析是否可信，至少要回查三样：数据源头对不对、分析方式有没有问题、数据口径是否一致。源头和口径由系统保证，分析方式由人把守——这三样缺一个，结论再流畅也不能直接对外。

六、这条链路没有解决什么

诚实地说，这条链路还有明显的边界：

• 脱敏是「排除内部 + 打码 + 防差集推算」的组合，不是一份可以对外宣称「字段级完备」的白名单；
• 聚合口径是持续治理，不是一次上线就永久正确；每新增一类事件，字典和翻译都要跟着补；
• 我们验证了日报口径能与人工版本对平，但没有证明「AI 出报比人快多少」——工具让重复劳动更可复现，不等于已经量化提效；
• 采集侧的修复与客户端发布是脱钩的，老版本用户仍可能贡献失真的数据。

但这些边界并不削弱核心判断，反而印证了它：行为数据的价值，不取决于 AI 有多聪明，而取决于数据链路有多可信、权限边界有多清楚。

七、写在最后

如果要用一句话总结这条链路的工程原则：

让 AI 解释数据，但不要让 AI 拥有数据。

采集要鲁棒，聚合要同源，出口要脱敏、要鉴权、要可审计；AI 只在这些约束之内工作。做到这些，AI 的分析才有讨论价值；做不到，越流畅的分析，越像一场精致的误会。

---

复核口径：分析侧统一使用中性「分析型 AI／分析侧调用方」，不混同具体外部工具与内部日报工作流；保留旧钥匙事故及明确归属的同域断流教训。