分析整理成 Skill 之后，为什么 AI 还是用错口径？

与 AI 协作分析 · 3/7

一次成功的分析，整理成 Skill，下一次就能直接用了吗？

好不容易跟 AI 对齐了口径、修完 SQL、排掉几个坑，当然会想把这些经验留下来。遵循着通用 Agent 的解决方案，我也自然而然地尝试使用 Skills 来记录，但经历几轮分析后，我发现我的 Agent chat 中多了许多「你用的是另一个专案的口径，这里应该是...」。

我开始思考，为什么这些对我来说很直观的「知识选择」，似乎对于 Agent 有一定的难度。

Skill 可以很完备，但哪些知识适合带到下一次？

我们的直观理想是：让 Agent 把做完的分析整理成 Skill，希望下次遇到类似问题，可以少沟通一点、直接接着做。

比如付费用户留存分析：

假设这次分析某个服务器的付费活动，最后决定只看活动期间有付费的角色，按账号 x 服务器计数。这个定义在当时完全合理，整理进 skill 也没有记错，但下一次分析整体历史付费用户的流失，这套口径就不一定适用了。

我用知识的「过拟合」来比喻这个问题：把单次案例里成立的条件，也整理成了可以反复使用的做法。AI 读这份 Skill 时，未必分得清哪些是通用方法，哪些是当时才做的决定（每个字都记对了，用起来还是错的，比忘记还难抓）。

很直觉的补法是，把付费期间、计数单位、跨服去重方式改成参数，要求 AI 每次先确认。对简单、稳定的分析，这样确实可能就够了，但随着同一份 Skill 被不同专案反复使用，里面开始多出各种默认值、适用条件与例外：这个专案看历史付费，那个专案只看近 30 天；这里跨服去重，那里又要分开算。

为了让 Agent 知道参数该怎么填，还得把每一种选择背后的业务背景一起写进去。原本只是想留下留存分析的方法，最后却顺便养了一本跨专案操作大全。

对稳定、范围清楚的方法，参数化可以是合适的做法；但当不同专案的规则混在一起时，它就比较像持续补洞：每遇到一个新情境，就继续往 Skill 补条件，但不同范围的知识仍然混在一起，如果拆成多份 Skill 各抄一份，共用口径更新时又容易漏改。

其实传统分析也有这些问题。我们也会复制旧 Notebook、拿上次的 SQL 改一改来用。但差别在于，自己的分析通常会有印象，记得哪些条件要调整，顶多算是「隐隐作痛」等级。可能到了交接，或隔几个月接回专案时，才会疑惑：「我当时为什么排除这群人？」

但 Agent 加入后，分析产出和任务切换都变快了，这种知识交接被快速放大到 daily work 中。每天除了审结果，还得检查它今天继承了哪些历史包袱，哪些可能是已经不适用的知识。

盘点混杂在既有 Skills 中的知识后，我逐渐分出几种落点：

这不是说每次开工都要先写四份文件，而是在 Agent 写入知识时进行「即时分流」。一次性的条件留在 Plan，确实需要反复使用时，再抽成方法或共用知识。

分开保存后，使用时也要接得起来：Skill 提醒 Agent 确认付费口径，专案规则提供可参考的定义，最后把本次采用的版本写进 Plan。AI 可以知道公司有好几种付费口径，但应该知道它们各自用在哪里，不确定时提出疑问而非静默选择。

其实没有 Agent 时，我们也知道边分析边记录，通常比做完再回忆完整，但过去没遇到几个分析师能持续这么做，除了麻烦、打断心流，deadline 通常也不太想听我们解释。

Agent 加入后，这件事反而有了比较自然的做法。与它协作本来就会经过一轮轮讨论、验证和确认，可以趁每个阶段结束，让它整理刚刚确认的知识、提出适合的落点，再由我确认。

于是「即时分析、即时分流、即时确认、即时写入」开始变得可行，不必等整份分析做完，才回头考古自己到底做了什么（不知道大家有没有想跟过去的自己搏击的时刻）。

在 Lantide Data 中试用这套分析工作方式：下载 Lantide Data。