先说几个核心判断，如果你在用文心一言整理用户反馈，却只把它当成一个“堆料机器”——把原始数据一股脑丢进去，然后指望它自动生成完美的摘要，那大概率会翻车。模型自己不会猜业务背景，不会判断用户是谁，更不会自动理解某个词背后的优先级。想让输出结果靠谱，关键不在于“提示词写多长”，而在于“背景信息补得多全”。

具体来说，在提示词中，你需要明确告诉模型：这是哪个业务单元的反馈？用户是谁？处于什么产品阶段？反馈采集于什么时间、对应什么版本？以及，隐含在字里行间的线索，比如情绪词、设备网络特征，应该按什么规则来解读。

明确限定反馈所属的业务单元

开头第一句话，就必须把业务范围锚定清楚。比如：“你正在为「企业微信服务商平台」整理2024年Q3的客户反馈。”

不要只写“整理用户反馈”，这太笼统了。必须带上具体产品名、服务对象（比如“面向中小企业的财税SaaS”）、以及当前所处的阶段（比如“上线第3个月的公测阶段”）。问题在于，模型本身没有常识推理能力，不写清楚业务单元，它会默认按通用互联网产品逻辑来处理，结果很可能把教育类用户的“作业提交失败”当成一个普通的表单错误来归纳。

注入用户分层信息

方法一：直接列出用户类型及占比
“本次反馈来自三类用户：①已续费2年的老客户（62%）；②试用期未转正客户（28%）；③首次注册未完成实名认证用户（10%）。”

方法二：用角色标签替代抽象描述
“反馈者身份需映射为：【金牌服务商顾问】【区域渠道经理】【终端使用会计】——注意区分决策者与执行者。”

这一步直接决定了问题归因的方向。如果“财务主管说报表导出卡顿”和“出纳说导出按钮点不动”被混在一起处理，很容易掩盖掉权限配置本身的缺陷。

绑定具体时间与版本上下文

第一步：写清反馈采集时间段
“所有反馈均产生于2024年7月15日–8月10日期间。”

第二步：标注对应系统版本
“后台服务运行v2.3.1-hotfix2，前端H5页面为v1.8.7，iOS App为v3.0.4（Build 1923）。”

第三步：说明是否关联已知故障
“此期间发生过两次数据库主从延迟（7月22日、8月5日），若反馈含‘数据不一致’‘列表刷新后消失’，需优先关联该事件。”

版本号缺失会导致模型把性能问题归因为新功能缺陷，而实际情况往往是旧模块在新环境下的兼容性崩溃。

定义反馈中的隐含线索提取规则

方法一：强制识别情绪关键词并映射到影响等级
“出现‘再也不用’‘立刻下架’‘已向竞品咨询’视为P0级；‘希望优化’‘建议考虑’视为P2级；未带情绪词的纯功能描述默认为P1级。”

方法二：提取设备与网络组合特征
“若反馈含‘WiFi下正常、4G必崩’‘仅iPhone 12 Pro复现’，必须单列‘环境强相关’标签，不纳入通用缺陷池。”

这里需要注意的是，不要写“请分析用户情绪”，而要给出可执行的判定边界。模型无法主观判断“有点烦”算不算严重，但它能精准匹配“再也不用”这个字符串。