用百小应写提示词，挖出来的痛点总是不够深——这是很多产品经理的共同焦虑。问题出在哪？不是你不够努力，而是提问方式从一开始就偏了。

你还在问“用户觉得哪里不好”这种泛泛的问题？那得到的答案只可能是“体验差”“太慢了”“不好用”这类悬浮在半空的形容词。听着有道理，却根本没法落地成具体的产品动作。

所以，第一步就是：把感受类提问通通砍掉。

先砍掉所有“感受类”提问

像“你觉得这个功能用起来怎么样？”“操作顺不顺畅？”“有没有什么不满意的地方？”这类问题，直接删掉就好。它们默认要求用户做主观评价，而普通人既没能力也没意愿帮你归因。你问一万次，得到的也只是情绪反馈，不是行为数据。

真正能触发具体行为描述的，是【卡点动作+失败结果】这个组合。举个例子：“点击‘导出PDF’按钮后，页面卡住不动，等30秒才弹出‘内存不足’报错”——这句话里有动词（点击）、对象（导出PDF按钮）、失败结果（页面卡住）、可验证时间（30秒）、错误提示原文（内存不足）。每个要素都清晰可查，可以直接指导开发排查。

核心规则：必须出现一个具体动作和一个明确失败结果，缺一不可。没有动作，就是空谈；没有失败结果，就是情绪发泄。二者合在一起，才是能写进需求文档的痛点原型。

用“然后呢”链条逼出真实断点

光知道原则还不够，怎么在实际中落地？这里提供两个可操作的方法。

方法一：从客服工单里抄原始话术，套用“然后呢”追问模板
客户原话：“提交订单后收不到信息验证码”→然后呢？→手动点“重发”三次→然后呢？→跳转到404页面→然后呢？→刷新后发现地址栏多了个中文字符“订单确认页”→然后呢？→用手机浏览器能收到，微信内置浏览器收不到。

你看，顺着这条链条挖下去，真正的断点根本不是“收不到验证码”，而是“微信内置浏览器在处理回跳URL时对中文字符的兼容性问题”。如果没有“然后呢”的持续追问，你永远想不到问题出在这里。

方法二：自己模拟走一遍流程，每一步都问“这步做完，下一步该发生什么？实际发生了吗？”
比如测试“修改头像”功能：上传图片→系统裁剪框自动弹出→用户拖拽调整→点击“保存”→页面无任何反馈，网络请求状态显示pending→打开开发者工具发现接口返回500，错误信息是“文件尺寸超限但未提示”。

这一步最容易漏掉的，是【用户被迫多做的动作】。比如“收不到验证码”背后，用户其实已经做了“关Wi-Fi→开飞行模式→重连4G→再试”这一整套绕行动作。这些多余操作才是痛点强度的硬指标——用户越绕路，说明问题越痛。

锁定三类高敏场景，专挖真痛点

如果实在不知道从哪里入手，可以聚焦高敏场景。最直接的方式就是翻应用商店的差评，但要用对方法。

第一步：翻最近7天应用商店差评，只看带截图的评论，过滤掉纯文字抱怨。截图能证明用户说的真实性，也方便你还原现场。

第二步：在差评里找重复出现的【动词+失败结果+数字】组合。例如：“第3次上传视频就崩”“设置页第4层才找到隐私开关”“连续5次扫码识别失败”。这些组合是用户用脚投票的结果，比任何用户访谈都真实。

第三步：把这些短语直接塞进百小应提示词，格式为：“用户在【具体动作】时，出现【失败结果】，发生在【平台/设备/版本】上，真实差评截图显示【原话】”。

注意：不要加“请分析痛点”“请总结原因”这类指令——百小应会调用训练数据里的二手结论，给出“用户体验不佳”“建议优化流程”这类空洞分析。你要它干的活很简单，就是把原始行为链完整复述出来，不要加工、不要总结、不要解释。

示例提示词：
“用户在微信小程序点击‘同步通讯录’按钮后，进度条走到80%停止，10秒后弹窗提示‘服务暂不可用’，iOS 17.5系统，真实差评截图文字为‘点一次等半分钟，点了六次全失败’”

这样写出来的提示词，百小应能直接对应到具体代码逻辑，而不是给出一堆漂亮但无用的结论。痛点够深，产品动作才能足够精准。