产品反馈分类：分清缺陷、需求与咨询
将产品反馈分为问题反馈、功能请求、好评或咨询。区分未履行的产品承诺与对新行为的期待。
匿名体验受免费额度限制。登录后使用账户积分并保留决策历史。
你的下一次决策，从这里开始。
在上方添加背景信息，或使用示例开始体验。
先判断反馈类型，再讨论优先级
反馈来自客服对话、访谈记录和产品内消息。同一句话可能是在描述缺失的能力，也可能是在报告已承诺功能的故障，需要依照一致的产品定义来区分。这个工具建议的是反馈类别，而不是路线图决策。保留来源链接与相关产品版本，让分析趋势的人能够区分同一次事故的重复报告与独立的新功能需求。
从具体案例理解边界
以下为场景示例和人工判断要点，并非模型实跑结果。输入你的实际上下文，查看本次决策。
缺少保存成功的提示
点保存后什么反应都没有，应该有个提示告诉我到底有没有保存成功。
先核实数据是否保存。如果文档承诺的保存动作失效，应按缺陷报告调查；如果已保存，但产品从未提供确认提示，则可能是功能请求。仅凭这句话，无法判断尚未明确的产品承诺。
用好话表达故障
真棒，演示前仪表盘又崩了。
“真棒”并不让这条反馈成为好评，具体观察是再次发生崩溃。保留受影响的操作和版本供排查，并在评估样本中专门复核反讽，不要假设情感词可以决定反馈类型。
一个可能暴露缺陷的问题
怎么导出 PDF？帮助页面说有导出按钮，但我找不到。
客户提出了问题，但与帮助页面的差异也可能来自缺陷、权限限制或文档过时。相关时加入套餐与功能开放说明。如果咨询和调查都要处理，应保留关联，避免单个标签让其中一项消失。
先约定分类口径
以下是这些选项的建议复核口径。运行时，请在问题或上下文中写明适用于你团队的规则。
| 选项 | 适用情形 | 需要区分的边界 |
|---|---|---|
| 问题反馈 | 实际行为与受支持、已说明的产品行为不一致。 | 用户单方面的期待不一定代表产品缺陷。 |
| 功能请求 | 希望新增能力或改变现有行为。 | “希望它能正常工作”也可能在描述现有功能损坏。 |
| 好评 | 正面评价，且没有主要的未解决问题或请求。 | 积极措辞可能是反讽，也可能伴随实质性投诉。 |
| 咨询 | 询问如何使用或理解产品。 | 咨询可能同时揭示需要跟进的缺陷。 |
这些情况值得多看一步
把一次版本事故算成许多新需求
保留版本、受影响的流程和来源。比较数量之前先识别重复报告，否则一次故障可能让某个类别显得比实际更有代表性。
跨语言处理丢失细微含义
中英混杂、反讽和本地缩写需要独立的复核样本。如果加入翻译，请保留原文，不要假设译文与原文具有完全相同的意图。
先评估分类质量，再相信汇总趋势
用于报表时，应从每个类别抽样复核，观察哪些类别经常混淆。即使单条错误代价不高，系统性混淆缺陷与功能请求仍会扭曲规划。对不确定反馈保留复核，不统一设置一个偏低的阈值。
严重性、受影响客户和战略价值应与分类分数分开。少见的无障碍缺陷可能比频繁出现的外观请求更重要。类别数量描述的是收件箱，并不能决定路线图。
从一个 Jev API 示例开始接入
通过 cURL 调用 iajev REST API，以 JSON 获取选项、概率与置信度。
curl https://iajev.com/api/v1/decisions/run \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Idempotency-Key: YOUR_UNIQUE_REQUEST_ID' \
-H 'Content-Type: application/json' \
--data '{
"state": {
"message": "希望能把每周报告导出为 PDF，并分享给团队成员。"
},
"decision": {
"type": "choice",
"question": "这属于哪种客户反馈？",
"choices": [
"问题反馈",
"功能请求",
"好评",
"咨询"
]
}
}'关于这个工具
一条反馈能属于两个类别吗？
可以，但这个工具只返回一个选中项。需要保留两类时，将独立观察拆成两条输入，并保留共同来源，避免把问题及其关联缺陷当成来自两个不同客户。
匿名反馈和登录用户反馈要分开分类吗？
采用相同的类别定义。需要去重或跟进时，单独记录来源。不能仅因为知道了用户身份，就把同一个故障流程归为不同反馈类型。
使用 iajev
提供上下文
保留本次判断所需的事实。
确认选项
按业务流程调整问题与候选项。
运行并复核
查看结果分布，再决定下一步。
置信度就是判断正确的概率吗？
不是。置信度是模型单独给出的估计，选项概率则描述各候选项的分布。两者都不等于经过测量的准确率保证。
可以比较两种输入吗？
修改上下文后，用同一个问题再次运行即可比较概率变化。修改问题或选项会开始新的比较。