前言
做开发或者产品的人，大概都见过这种场景。
应用商店里突然出现几条差评：
看到这种评论，我们很容易下意识说一句：
"这个问题得赶紧改。"
但问题是：
到底哪个问题应该先改？
于是我做了一个实验。
我随手找了一款公开 App 的评论截图，然后直接丢给了 TRAE Work。
没有整理 Excel。
没有手工复制评论。
我只想看看：
只根据一张截图，能把一次产品分析推进到什么程度。
一、我没有先让它总结，而是先让它把评论"拆开"
第一步，我让 TRAE Work 从截图中提取：
评分、日期、版本、评论原文、点赞数、涉及模块。
接着，我没有让它直接做"用户问题总结"。
而是要求：
不要把一整条评论当成一个问题。
比如：
"很难用的软件，还弹广告。"
其实包含两种完全不同的信息。
"很难用"只是模糊体验感受。
"还弹广告"则是明确的商业化体验问题。
再比如：
"平板上用不了是不是崩了。"
"平板上用不了"是用户报告的现象。
"是不是崩了"只是用户对原因的猜测。
最终，原本的 6 条评论 + 1 条回复，被拆成了 11 个最小反馈单元，其中 8 个属于事实描述，1 个属于纯情绪表达。
这一步让我意识到：
一句评论，不等于一个问题。
如果第一步就没拆对，后面的分类再漂亮也没意义。
二、聚类不能只看关键词
接下来，我让 TRAE Work 按：
用户任务 + 问题现象 + 用户影响
进行聚类。
因为"定位不准"和"公交地铁路线生成失败"虽然都和地图有关，但不是同一个问题。
一个是：
我现在在哪里？
另一个是：
我应该怎么去目的地？
所以不能简单归成"地图问题"。
最终，11 个反馈单元被整理成了 8 个问题簇，其中 6 个技术问题簇，2 个非技术/风险信号类。
其中包括：
- 加载失败
- 路线生成失败
- 定位不准确
- 平板兼容问题
- 注册失败
- 广告打扰
- 模糊体验反馈
- 用户流失信号
这里有一个点我很喜欢。
"还不如去高德"没有被当成 Bug。
而是被单独识别成了：
用户流失信号。
因为它不是问题本身，而是问题发生后的行为倾向。
三、然后我故意让它排 P0/P1/P2
做到这里，我问了 TRAE Work：
假设你是这个 App 的产品负责人。
下一版本最应该优先解决哪 3 个问题？
它很快给出了：
P0、P1、P2。
而且理由非常像那么回事。
最新版本出现的问题。
核心功能受阻。
用户直接提到竞品。
甚至还有点赞数作为佐证。
如果我在这里停下来，这篇文章完全可以写成：
"一张截图，TRAE Work 帮我完成了产品优先级分析。"
但我越看越觉得不对。
因为：
我总共只有一张截图。
四、6 条评论，真的有资格决定 P0 吗？
于是我又追问了一句：
我只有 6 条评论，而且全部是一星。
在这种情况下，真的有足够证据判断整个产品的 P0/P1/P2 吗？
这一次，TRAE Work 直接推翻了自己前面的结论。
它重新指出了几个问题：
样本太少。
全部是一星，存在选择偏差。
评论从 2023 年跨到 2025 年，旧问题不能直接代表当前版本。
截图里出现次数多，也不代表真实用户中出现频率高。
更不能据此判断业务损失和优先级。
这个转折，反而是整个实验里我觉得最有价值的一部分。
因为 AI 最危险的时候，并不是胡说八道。
而是：
它用很完整的逻辑，给出了一个证据其实不够的答案。
五、我最后把"优先级"改成了"风险信号"
从这里开始，我重新定义了任务。
不再让 TRAE Work 输出：
"最严重的问题"
"下一版本必须做"
"P0/P1/P2"
而是统一改成：
风险信号。
比如：
最新版本有用户反馈公交地铁路线生成失败。
可以说：
"存在路线规划异常风险，建议优先验证当前版本是否仍然存在。"
但不能说：
"路线规划就是当前最大的 P0。"
最终工作流里也明确写了一条：
出现频率 ≠ 优先级。
真正的优先级还需要影响范围、业务损失、发生频率等截图外数据。
六、最后，我让 TRAE Work 把整个过程沉淀成一套方法
最终，它重新生成了一份：
《用户评论产品问题初诊报告》
里面不再直接替产品负责人做决策。
而是输出：
样本说明、评论结构化、问题拆解、问题地图、风险信号、证据等级、验证建议和分析边界。
share.traecontent.cn/artifact/R....
最后，我又让它把整个过程抽象成了一套：
Screenshot VOC
标准流程。
一共 9 步：
图片信息提取 → 评论结构化 → 反馈单元拆解 → 问题聚类 → 事实与推测分离 → 样本偏差审查 → 风险信号提取 → 验证建议 → 初诊报告。
share.traecontent.cn/artifact/_C...
七、我最后留下的，不是 Prompt，而是 5 条规则
这次实验以后，我给自己留下了 5 条规则：
第一，截图之外的信息不能当成事实。
用户说"是不是崩了"，不等于真的发生了崩溃。
第二，一条评论不等于一个问题。
事实、情绪、猜测、建议，要拆开。
第三，不按关键词聚类。
要按用户任务和问题机制聚类。
第四，情绪强度不等于问题严重度。
"垃圾软件"可能没有任何分析价值。
第五，小样本先问"还缺什么数据"，不要急着问"应该做什么"。
这可能也是我这次最大的收获。
最后
我原本只是懒得整理 Excel。
所以随手把一张应用商店截图丢给了 TRAE Work。
结果最后真正让我记住的，不是它读图有多快，也不是生成的 HTML 有多漂亮。
而是它先给了我一个看起来非常合理的答案。
然后在我的追问下，又把这个答案推翻了。
我越来越觉得：
AI 真正进入工作以后，我们不只要学会怎么问它。
还要学会问一句：
"你凭什么这么判断？"
真正好的工作流，不是保证 AI 永远不犯错。
而是让错误能够被发现、被修正，最后变成下一次不会再犯的规则。
这一次，我最后得到的不只是一份分析报告。
而是一套可以继续复用的 Screenshot VOC。
下次再见！🌈
