用户反馈分类：一个主题、一个优先级，以及为什么情感分析不够

要做的是两个问题，不是一个分数。第一：这条评论主要在说什么？第二：产品同学该多快读它？情感分析回答的是另一件事——正面、中性或负面。如果只存极性，每周的主题报告就消失了。客服分流回答的又是另一件事：哪条在线队列该回复。一条评论可以是负面的，同时却是功能需求；也可以是正面的，同时在描述导出坏了。给每条评论都开一张工单，队列里会堆满夸奖。看板需要极性时看 sentiment-analysis-api。必须有人回复时看 support-triage 或 zendesk-ai-ticket-classification。动作为出于安全的隐藏、封禁或升级时看 content-moderation。本页负责离线语料：NPS 原话、应用内反馈、公开评价，以及产品团队要归入固定主题表的问卷开放题。

一次只分类一个开放式回答。问卷若有三个自由文本框，就做成三行，避免主题混在一起。用 JSON state 放回答者自己的话，再加上少数你已经信任的字段：渠道（nps、应用内、评价）、数字评分（如果有）、套餐、语言，以及表单问过的产品区域。去掉表单加上的套话，例如“其他意见：”。如果这一行来自邮件，先裁掉引用回复和签名——那是 email-classification 的工作——再分类剩下的评论。不要粘贴截图、音频或文件。这个 API 只接受文本或 JSON；用文字描述一张图，并不等于把像素交给模型。请求离开你的系统之前，去掉姓名、邮箱和账号 id。序列化后的 state 最多 8,000 字符，包含问题的完整校验请求也必须放进 8,000 字符，所以要给 criteria 留位置。裁到回答者自己的句子。如果另一个模型先摘要了评论，在这一行记下这件事，因为你分类的已经不是原话。请求数据会发给上游提供方，见 privacy-and-history。

多数团队会留一层很薄的规则，处理已经信任的短语，其余交给模型。下表比较的是契约和失败方式，不是基准测试。三者都不能替代你自己评论做成的标注样本。

Playground 自带名为“用户反馈洞察”（Feedback intelligence）的示例。它把一条“报表导出变慢”的评论分成主题（性能、易用性、功能或账单），再用 Score 评跟进优先级，从低到很高。下面的请求保留这条评论，并增加明确的 mixed 主题，避免过短或同时说了几件事的评论被硬塞进某个产品领域。问题 id 以字母开头，其后只能是小写字母、数字和下划线，最长 40 个字符。instructions 为 8 到 600 字符。每条 criterion 为 2 到 350 字符。Choice 接受 2 到 12 个主题。Score 接受 2 到 10 个有序等级；按量表顺序书写，这里从低到很高。Choice 的答案包含 choice、每个主题的概率，以及该分布的 confidence 摘要。confidence 不是测出来的准确率。Score 的答案包含 score，它可以落在等级之间，这个数字不是概率。产生任何副作用之前先读这两个字段。主题不等于可以改路线图。登录、验证邮箱，在 Console 的 API keys 创建密钥，并在服务端存为 JEVMODEL_API_KEY。下面的调用是真实请求，可能消耗额度或 Token。已验证的免费账号在 Playground、Batch 的每一行和这个 API 之间共用每 UTC 日 5 次成功运行，并受全站容量限制。固定模型是经 OpenRouter 调用的 typesafe/jev-1.13。没有幂等键：响应丢失时，重试前先查历史。

curl --fail-with-body https://jevmodel.app/api/v1/systemone \
  -H "Authorization: Bearer $JEVMODEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"state":{"channel":"nps","score":3,"comment":"After the latest update, exporting a report takes two minutes instead of ten seconds. We export every morning."},"questions":{"theme":{"type":"choice","instructions":"Classify the main theme of this customer feedback.","criteria":{"performance":"Performance or speed regression.","usability":"Confusing interaction.","feature":"Feature request.","billing":"Billing issue.","mixed":"Several themes, or not enough text to choose."}},"urgency":{"type":"score","instructions":"Rate product-team follow-up priority for this feedback.","criteria":["Low: optional improvement","Medium: limited friction","High: recurring workflow degraded","Very high: core workflow blocked for many users"]}}}'

三个置信带用你自己留出的评论来定，不要用一个通用阈值。高带：把主题和优先级写回仓库里的这一行。这个动作可以撤销。中间带、mixed 标签，或两个主题概率接近：把评论和前两个主题一起给复核的人看，如果报告需要，让这个人手工补第二个主题。低带：这一行保持未标注。不要只凭一个标签就建公开的路线图条目。哪些 Score 值该叫醒人，用你的标注样本来校准；score 是对量表的读数，不是“判断正确”的概率。改了 criteria 或上游模型行为变化后，重新检查这些带。积压数据可以用 Console 里的 Batch：导入最多 2 MB、1,000 行的 CSV、TXT 或 JSONL，套用同一组问题，导出逐行答案。在站外把答案和你的标签对齐。Batch 不算准确率，也不是异步批量任务端点。每一行仍是一次普通运行。阈值见 confidence-and-abstention，留出集的划分见 evaluation。如果一条评论必须同时带上多个主题，那个契约是 multi-label-text-classification，而不是把 Choice 做宽。

输入是开放式产品评论、输出是一个主题加一个优先级时，留在本页。图表只需要正面、中性或负面时，去 sentiment-analysis-api。文本是必须回复的在线工单时，去 support-triage。原始输入仍是一串邮件线程时，去 email-classification。动作是安全处置时，去 content-moderation。报告必须保留每一个适用主题、而不只是主要主题时，去 multi-label-text-classification。Decision Flow 可以把主题问题接到后续问题，但运行 Flow 仅限付费方案：订阅或购买 Token 包。Flow 不使用每日免费次数。JevModel 不会用你的评论训练分类器，不接受图片或附件，不是开源项目，也不提供权重下载。