开头：一句模糊反馈引发的数据库排查
我是做了 10 年前端、现在独立打磨一个微信答题小程序（宝可问答助手）的开发者。前几天用户给我提了句模糊的话："题目整体难度偏大，普通玩家没思路，想加个提示，或者加个跳图鉴查答案的出口。"
这种反馈做产品的天天听得到，但"难"到底难在哪、该先给哪两个玩法补提示，不能靠拍脑袋。我习惯的第一步永远是：先把形容词落成指标，再去翻数据库。
技术细节：用一条查询把"中途放弃"量化
答题记录存在云数据库 Record 集合，每次提交一次猜测才写一条，字段含 solved（是否猜中）、tries（已尝试次数）、quizType（玩法类型）。各玩法上限写在 quizTries.js：8 个玩法 6 次、数独 9 次。
要回答"多少人没答完就退出"，条件其实很明确：
const maxTriesByType = { item: 6, ability: 6, /* ... */ sudoku: 9 }
const STUCK = await db.collection('records')
.where({
solved: false,
tries: _.lt(maxTriesByType[quizType]) // 未达上限 = 中途放弃
})
.count()
全库 7705 条记录跑出来的结果：
- 猜中 6743（87.5%），未猜中 962；
- "没答完就停"的 445 条，占未猜中 46.3%；
- 只猜 1 次就走的 245 条（25.5%）。
光有放弃率还不够。它分不清"难"和"没耐心"——这两种人对产品的含义完全不同，解法也相反（一个该加提示，一个该加出口）。
关键技术点：用操作节奏中位数区分"难"和"没耐心"
真正把问题拆开的是第二个指标：同一局里相邻两次猜测的时间间隔。全库统计下来，中位数 19 秒，25 分位 10 秒、75 分位 40 秒，小于 3 秒的只占 0.7%。
如果玩家是"没耐心乱点"，间隔应该普遍极短；实际分布说明绝大多数人在认真看题、查线索。结论很清楚：瓶颈是"看了但没思路"，不是"懒得想"。于是需求从"加跳过按钮"被修正成"加提示"，方向完全反过来了。
再按玩法排一遍答完率：道具 76%、属性 81%、数独 84%，其余 89%~92%。"猜 1 次就走"的人集中在道具（38 人）和属性（43 人）。提示的优先级于是变得毫无争议：先做道具和属性，性价比最高。
踩坑记录：有些指标查不出来，就别硬查
我想顺手查"一道都没答就退出"的人，发现 Record 在第一次提交猜测时才写入，和"从没打开过"根本分不出来。这类指标要么加埋点，要么用微信"访问人数 vs 库里有记录"的差值估算（≈26~29%），不值得为它专门埋点。
另一个坑是自查基准：曾把 git show HEAD 当成"改动前"的基线，结果 HEAD 已含本次改动，导致误读。凡是结论依赖数据的，基线必须来自线上库真实统计，而不是本地 diff。
方法论沉淀：模糊反馈先落成指标，再谈方案
同一天我还拉了小红书创作者中心的数据做对照：曝光环比 +50%、观看总时长 +111%，但封面点击率连续两周卡在 19.3%，没一篇站上同类中位数 22.7%。同期其他指标都在动，唯一纹丝不动的是封面——这跟"题目难"是两件事，但定位方法完全一致：用数据说话，而不是凭感觉。
这套方法的通用性在于，它把"难"这种形容词，拆成了三个可量化信号：中途放弃率、操作间隔分布、分维度排序。有了这三个信号，加提示还是加出口、先补哪个玩法，都不用开会争论，查库两分钟就知道。
这大概就是我做独立产品这几年最值钱的一条习惯：先量，再改。