AI专题分享(一):我踩过的几个坑和一些使用建议

去之前，我觉得自己 AI 用得还不错。常用的分析工作已经整理成了一些 Skill，日常也一直在用，写代码、处理数据、整理资料、生成报告，基本都能让 AI 帮上忙。

大会结束后，我和几个同行分析师交流，发现有人已经把不少固定工作交给数据Agent 跑了，省下来的时间真的拿去玩游戏。后来晚宴上又和一位 MiniMax 的架构师交流，我才发现，自己当时做得更多的还是单点提效，离一套可以持续运行的 Agent 工作流还有不少距离。

回来以后，我给自己立了一个目标：把数据 Agent 真正做出来。

这几个月折腾下来，单是个人账号，Codex 的使用量累计已经超过 200 亿 Token，另外还有 DeepSeek、MiniMax 等 API，以及公司账号的消耗。这个数字本身没什么意义，只能说明我确实用得比较重。

现在做分析，我已经基本脱离了自己手搓代码。期间陆续做了十多个网站，也做了 Agent、ChatBI 和各种分析相关的 Skill。还有很多地方需要继续优化，但我的工作方式已经和几个月前有了很大变化。

以前写公众号，我主要想把自己在游戏分析中积累的方法和框架分享出来。AI 普及以后，我还想多做一件事：把其中一些相对成熟的方法整理成 Skill 和工作流，让这些框架除了“知道怎么做”，还可以更方便地重复使用。

所以准备开一个 AI 专题。第一篇先写几个我自己踩得比较深的坑，以及后来怎么处理。

随着交给 AI 的任务越来越多，我现在经常会多问一句：

这个结果，我怎么验证是正确的？

很多麻烦都发生在这里。程序没有报错，报告也顺利生成，内容甚至看起来挺合理，但仔细检查以后，问题可能出在完全不同的地方。

一、先把问题定义清楚，再让 AI 开始干

做 ChatBI 一段时间后，我发现，只靠不断补充问法，并不能真正解决语义问题。

用户说“DAU”“活跃用户”“昨天多少人玩过”，表达方式完全不同，最后可能指向同一个指标。反过来，“最近一周活跃怎么样”看起来很简单，却可能对应“最近七天每天的 DAU 趋势”，也可能是在问“七天内一共有多少去重活跃用户”。

如果继续沿着这个方向穷举问法，测试题会越来越多，但新的表达永远补不完。

后来我开始补一层标准语义。先把新增、活跃、留存、收入等业务概念定义成标准指标，同时把统计对象、时间范围、时间粒度、维度、筛选条件、聚合方式这些信息统一下来。AI 负责把用户千奇百怪的自然语言翻译成这套标准语义，再交给后面的查询逻辑处理。

例如用户问“昨天多少人玩过”，AI 可以识别成“昨天 + 活跃账号数”；用户问“上海最近七天每天有多少活跃用户”，则可以进一步拆成“活跃账号数 + 最近七天 + 按日 + 上海地区”。

如果一句话存在多个合理解释，就先问清楚。

比如：

最近一周活跃怎么样？

系统可以继续确认：

你想看最近七天每天的活跃趋势，还是七天内累计去重的活跃账号数？

这样以后，需要维护的就不再是几百种甚至几千种自然语言问法，而是一套相对稳定的业务语义。AI 负责理解用户怎么说，指标和语义规则负责确定业务上到底怎么算。

这个思路后来也影响了我平时怎么让 AI 做分析。

比如我真正想解决的问题是“后续去哪里找更多类似用户”，如果只说一句“帮我全面分析一下这批用户”，AI 很可能给我一份年龄、性别、游戏兴趣、视频偏好的完整画像。这些内容可能都有价值，但做完以后还是要重新回答一个问题：哪些特征真的可以帮助后续找人？

现在我会把要求写得更具体一些：

这次最终要回答的问题是：哪些用户值得继续获取，以及判断依据是什么。可以使用现有的用户行为数据，但不要因为“看过某类内容”就直接推断为“喜欢”，也不要把相关关系直接解释为原因。请围绕最终问题组织分析，每个主要结论都要给出对应证据；现有数据无法证明的部分，请明确标记为待验证，并告诉我还缺什么数据。

ChatBI 的要求会再细一点：

在生成查询之前，先把用户问题拆成统计对象、指标、时间范围、时间粒度、分组维度、筛选条件和输出形式。任何一项存在歧义时，先列出可能的解释，不要自行忽略。生成查询以后，再检查一遍这些条件是否全部保留，尤其不要静默丢失分组维度和筛选条件。

最近我也比较喜欢用目标模式。

以前碰到复杂任务，我经常会把过程拆得很细：先读哪个文件，再跑什么分析，再输出什么表，最后怎么写报告。这样比较稳，但任务一长，人还是要一直跟着过程走。

现在有些任务，我会直接把目标、资料、边界和验收标准说清楚，中间怎么推进让 AI 自己判断。比如：

目标是完成一份可以给项目组使用的用户研究报告，回答“目标用户是谁、为什么，以及后续可以去哪里找”。可以使用当前目录中的用户数据、已有报告和项目背景。不要修改原始数据，不要把相关性写成因果，没有证据的用户标签不要直接下结论。关键结论必须能找到对应数据或原始证据；证据不足时主动指出；报告完成后，再做一遍“结论—证据”核对。在这些范围内，你可以自己决定读取哪些文件、运行哪些分析和检查，非关键步骤不用逐个问我。

这样用下来，我主要盯目标、边界和几个关键验收点，中间过程可以交给 AI 自己推进。对于需要连续处理很多文件、分析和检查的任务，这种方式比提前把几十个步骤全部写死轻松很多。

二、AI 很会把一件模糊的事情讲得很顺

做用户研究时，这个坑我踩过很多次。

假设我们发现，一批用户观看某类视频的比例比较高。AI 很容易沿着这个结果继续写：这些用户喜欢这类内容，这种兴趣吸引他们进入某款游戏，所以后续可以围绕这类内容寻找目标用户。

整段话读起来很顺，拆开以后，中间其实少了不少证据。看过，不一定代表喜欢；喜欢，也不一定和进入游戏有关；进入游戏以后留下来，还需要另外的数据解释。

符合直觉的解释特别容易被接受。有时候自己做报告，也会顺着这个方向继续写，所以我后来开始刻意把观察结果、推断和下一步建议分开。

例如，“在相同时间范围和统计口径下，这批用户观看某类内容的比例高于参照人群”，如果数据已经核验，这是当前样本里已经观察到的结果。“这类内容可能与该人群的兴趣有关”，属于基于现有数据的推断。“可以围绕这类内容做一次小规模获取测试，看看目标用户触达效率有没有提升”，则是后续准备验证的方向。

分开以后，我自己也更容易看清楚中间还缺什么。

现在检查报告，我经常直接把下面这段交给 AI：

请逐条检查报告里的主要结论，并区分三类内容：已有数据直接支持的观察结果、基于数据作出的推断、仍需要验证的假设和行动建议。每条结论都写出对应证据。如果从“观察结果”直接跳到了“原因”或“行动建议”，请指出中间还缺什么。证据不足时保留不确定性，不要为了让报告看起来完整补出一个确定结论。

还有一句我自己特别常用：

如果这句话放到汇报里，我能拿什么原始证据支撑它？

数据、样本、玩家原文、实验结果都可以。如果一个重要结论回答不了这句话，我一般会把表述往回收。

三、“测试通过”以后，我会继续看它到底测了什么

固定测试很有价值。一个问题修完，把它加入测试集，后续每次调整系统再跑一遍，可以防止老问题重新出现。

436 个固定用例的作用也在这里。但如果这些题原来已经错过，后来又针对它们改了规则，那么它们下一次全部通过，只能说明这些老问题没有复发。系统碰到陌生表达会怎么样，还需要另外一批没有参与过修复的案例。

所以后来我会把测试拆开。一部分专门做回归，一部分保留成陌生问题，还有一些负责测边界情况，比如时间表达、账号和角色、多轮追问、维度组合。

除此之外，还需要单独做数值核对，因为一句话理解对了，数字也可能算错。

留存就是一个很典型的例子。用户问“最近七天新增用户的 D7 留存”，系统可能已经正确识别了“最近七天”“新增用户”和“D7 留存”，后面仍然要确认新增按账号还是角色、最近七天具体是哪几天、观察截止日期是什么，以及哪些新增 Cohort 已经有资格观察 D7。

今天刚新增的用户，D7 留存目前还没有结果。如果把这批用户直接算成未留存，系统一样可以给出一个百分比，只是这个百分比已经错了。

所以我现在让 AI 做验收时，会直接写：

不要只给我一个“测试通过/失败”的总结果。请分别检查四层：第一，问题理解，对象、指标、时间、维度和筛选条件是否完整保留；第二，统计口径，去重方式、观察窗口、分子和分母是否正确；第三，数值核验，能否用独立方法或可信数据源复算；第四，结果呈现，页面里的数字、标题、单位和结论是否与实际结果一致。四部分分别给出 PASS、FAIL 或“未验证”，并附证据。

对于测试集，我还会再加一句：

已经用于修复的问题只进入回归测试，不要继续拿它们计算陌生问题通过率。请保留一批此前没有参与开发和修复的测试案例。

所以现在看到“436/436 全部通过”，我还会继续看它后面的说明。436 道是什么题，比 436 这个数字本身重要。

四、长任务开跑之前，先把中断以后怎么办写好

自动化最开始很爽，点一下，AI 自己跑。

做过几次长任务以后，我开始特别在意另一件事：如果它半夜跑挂了，第二天怎么办？

我做过批量游戏打标、评论处理、定时报告，这些任务都有可能运行很久。中间可能碰到网络失败、接口超时、登录过期、进程退出。有一次甚至只是跨了一个月，新月份的文件没有按预期生成，下游流程就找不到输入了。

如果之前没有保存状态，第二天会出现一串问题：已经处理了多少？哪些结果已经写进文件？哪些跑了一半？重新执行会不会重复？要不要全部从头再来？

所以长任务开始之前，我现在会先补一段要求：

这是一个长时间运行的任务。开始前先建立持久化进度记录，不要只把状态放在当前会话或内存里。至少记录总任务数、已完成数量、当前处理位置、成功项、失败项及失败原因、最后成功时间和当前输出文件。每完成一批数据保存一次检查点。如果任务中断，重新启动后先读取已有状态，从最后一个成功检查点继续，不要默认从头执行。任务结束时核对“总任务数 = 成功数 + 失败数 + 未处理数”，输出文件完整并通过检查以后，再把任务标记为完成。

这几句话后来帮我省了很多麻烦。

还有一个要求，我现在几乎会默认加上：

查询失败、权限不足、网络异常或者数据源不可用时，请明确返回失败状态，不要把它解释成业务结果。

邮箱登录失效，应该告诉我当前邮箱读不了；数据库查询失败，也应该明确告诉我这次查询没有拿到结果。“没有查到”和“结果为 0”，在业务上差得非常远。

五、长期项目一定要告诉 AI：哪一版才算数

这个坑以前我完全没想到。

项目一长，版本会迅速增加。聊天窗口有多个，代码有源码和运行副本，Skill 有开发版和实际安装版，报告还有 V10、V11、V12。

最麻烦的情况经常是：你觉得已经改好了，结果实际运行的还是旧版本；或者一个窗口已经基于最新文件继续工作，另一个窗口还在分析三天前的版本。

最后每天都要问一句：“我们现在到底在哪一版？”

后来我在长期项目里，会先给 AI 一条很明确的要求：

开始工作前，先确认当前项目的唯一有效母版和实际运行版本。如果目录里存在多个相似版本，先检查运行路径、修改时间、项目状态和已有说明，再确定当前版本。本轮修改只能基于当前母版继续。修改完成以后，更新项目状态，写清楚当前有效版本、实际运行位置、本轮修改内容、已经验证的内容、尚未验证的内容、已废弃版本，以及下一步从哪一版继续。没有必要时，不要继续创建 final2、final_new 这类无法判断先后关系的文件。

现在我也尽量不让关键项目状态只存在聊天记录里。聊天窗口可以换，状态文件应该一直留在项目里。这样下一个 AI 接手时，不需要重新猜之前发生过什么。

六、做不做 Agent，我会先算一下值不值得

用 AI 用到一定阶段以后，很容易看到什么都想自动化：这个做 Skill，那个做 Agent，最好什么都让 AI 跑。

我自己也经历过这个阶段。

后来慢慢发现，自动化也挺费时间。规则要整理，案例要准备，异常要处理，测试要补，后面还要维护。一个半年做一次、自己二十分钟就能完成的任务，为它搭两天 Agent，大概率不划算。

现在我主要看几个条件：这件事多久做一次，每次人工花多少时间，规则稳不稳定，做错一次影响多大，以后有没有别人也要用。

如果自己也拿不准，我会先让 AI 算一遍：

先不要开始做 Agent 或 Skill，请先评估这个任务是否值得工程化。从执行频率、单次人工耗时、规则稳定程度、错误成本、多人复用价值和维护成本几个方面分析。最后建议采用以下一种方式：直接使用 AI 临时完成、固化成脚本或模板、做成 Skill、做成 Agent 或自动工作流，并说明理由。

我现在也会把一些规则已经很稳定的工作从 AI 里拿出来，比如去重、固定指标计算、格式转换和定时执行。这些工作交给普通程序更合适，同样的输入和规则，多跑几次应该得到同样的结果。

自然语言理解、例外情况、开放式分析和解释结果，再交给 AI。重要的业务判断，我自己留着。

七、“帮我优化一下”太宽了，我现在更常让 AI 做检查

以前一份报告做完，我经常会说：“再帮我优化一下。”

这个要求的问题在于，“优化”什么都可以。AI 可能改文字，可能加章节，可能重新画图，也可能把我原来已经满意的东西一起改掉。

现在我更习惯直接告诉它我要检查什么。例如：

请检查这份报告中哪些结论证据最弱，有没有混用统计口径，有没有样本偏差，有没有把相关性写成因果，以及有没有其他解释也能产生现在的数据现象。

这个方法很好用，不过也有一个小坑。你让 AI 找问题，它有时候会非常努力地找。没有明显问题，也可能给你凑出几个。

所以我后来把要求补完整：

请审查这份报告。所有发现分成三类：已确认的问题，需要有明确证据；待验证的风险，可以存在疑点，但要说明当前证据不足；已经检查、暂未发现问题的部分也可以明确写出来。每一项都说明依据和可能影响。如果证据不足，请保留“无法确认”，不要为了完成检查任务强行得出问题。

这段我现在经常用。它会让 AI 少一点为了完成任务而“挑刺”，更接近一次真正的审查。

当然，这种检查只能帮助我找方向。涉及数据的地方，该回原始数据还是要回原始数据，该复算还是要复算。

最后，我现在怎么算 AI 帮我省了多少时间

AI 生成东西确实快。以前一天才能整理出来的报告，现在可能很快就有初稿。

但我现在不会只算生成用了多久，后面的时间也要一起算：检查用了多久，返工用了多久，确认统计口径用了多久，找正确版本用了多久，任务挂掉以后有没有全部重跑，同一个问题下次还会不会重新出现。

如果 AI 十分钟生成一份报告，后面三个小时都在修，这次到底省没省时间，还要和以前做到同等质量需要多久比较。

必要的核验当然还要做。我更希望减少的是那些重复返工：同一个背景不用解释五遍，一个 Bug 不要修五次，不用每天找哪个文件才是最新，任务失败以后不用全部从头开始，已经否定的结论下次也不要重新出现。

所以我现在判断一套 AI 工作方式有没有变好，会看几个很简单的问题：同类任务下一次是不是更省力，修过的问题有没有少复发，结果是不是更容易检查，中断以后是不是更容易继续，这次做完的东西下次能不能直接复用。

我现在也还在不断调整这些方法，很多东西没有做到完全自动，中途一样会有误判和返工。相比几个月前，我只是更清楚哪些地方容易出问题，也开始把这些问题一点点留成规则、测试和流程。

如果刚开始把 AI 放进自己的工作，我不太建议第一步就做一个很复杂的 Agent。先找一件自己经常重复做的事，把目标、输入、边界和验收方式说清楚，跑几次以后，再决定哪些地方值得继续自动化。

这样做下来，AI 带来的效率会更踏实一点。

后续我也想挑几个实际案例单独展开，比如怎样用 AI 分析一批用户评论，怎样和 AI 协作完成一份完整的研究报告，以及怎样把一件重复工作整理成可以反复运行的 Skill 或工作流。

我会尽量把具体输入、实际产出和中间修改过程都展示出来。第一次哪里做错了，提示词后来怎么改，最后又是怎么验收的，都尽量保留下来。

如果这几个方向里有你更感兴趣的，也欢迎告诉我：你最想先看哪一个？